[PATCH v10 16/20] coresight: Add PM callbacks for sink device
Jie Gan
jie.gan at oss.qualcomm.com
Mon Apr 13 02:27:33 PDT 2026
Hi Leo,
On 4/13/2026 4:48 PM, Leo Yan wrote:
> On Mon, Apr 13, 2026 at 01:45:50PM +0800, Jie Gan wrote:
>
> [...]
>
>>> @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct coresight_path *path)
>>> to = list_prev_entry(coresight_path_last_node(path), link);
>>> coresight_disable_path_from_to(path, from, to);
>>> + ret = coresight_pm_device_save(coresight_get_sink(path));
>>> + if (ret)
>>> + goto sink_failed;
>>> +
>>> return 0;
>>> +
>>> +sink_failed:
>>> + if (!coresight_enable_path_from_to(path, coresight_get_mode(source),
>>> + from, to))
>>> + coresight_pm_device_restore(source);
>>
>> I have go through the history messages. I have a question about this point
>> here:
>>
>> how can we handle the scenario if coresight_enable_path_from_to failed? It
>> means we are never calling coresight_pm_device_restore for the ETM and
>> leaving the ETM with OS lock state until CPU reset?
>
> From a design perspective, if any failure occurs in the idle flow, the
> priority is to avoid further mess, especially partial enable/disable
> sequences that could lead to lockups.
>
> The case you mentioned is a typical risk - if a path after source to
> sink fails to be enabled, it is unsafe to arbitrarily enable the source
> further. We rely on the per-CPU flag "percpu_pm_failed" to disable idle
> states, if ETE/TRBE fails to be disabled, if CPU is turned off, this
> also might cause lockup.
understood.
>
>> Consider we are calling etm4_disable_hw with OS lock:
>> etm4_disable_hw -> etm4_disable_trace_unit -> etm4x_wait_status (may timeout
>> here?)
>
> This is expected. I don't want to introduce a _recovery_ mechanism for
> CPU PM failures, which is complex and over-engineering. CPU PM notifier
> is low level code, and in my experience, PM issues can be easily
> observed once CPU idle is enabled and should be resolved during the
> development phase.
>
> In many cases PM issues are often not caused by CoreSight drivers but by
> other modules (e.g., clock or regulator drivers). The log "Failed in
> coresight PM save ..." reminds developers the bugs. As said,
> percpu_pm_failed is used as a last resort to prevent the platform from
> locking up if there is a PM bug.
Thanks for the explanation.
Thanks,
Jie
>
> Thanks,
> Leo
More information about the linux-arm-kernel
mailing list