Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device

[James Clark <james.clark@linaro.org>]

On 09/04/2026 3:49 pm, Leo Yan wrote:
> On Thu, Apr 09, 2026 at 03:30:56PM +0100, James Clark wrote:
> 
> [...]
> 
>>>>> @@ -1759,16 +1760,36 @@ static int coresight_pm_check(struct
>>>>> coresight_path *path)
>>>>>        if (source_has_cb)
>>>>>            return 1;
>>>>> +    sink_has_cb = coresight_ops(sink)->pm_save_disable &&
>>>>> +              coresight_ops(sink)->pm_restore_enable;
>>>>> +    /*
>>>>> +     * It is not permitted that the source has no callbacks
>>>>> while the sink
>>>>> +     * does, as the sink cannot be disabled without disabling
>>>>> the source,
>>>>> +     * which may lead to lockups. Alternatively, the ETM driver should
>>>>> +     * enable self-hosted PM mode at probe (see etm4_probe()).
>>>>> +     */
>>>>> +    if (sink_has_cb) {
>>>>> +        pr_warn_once("coresight PM failed: source has no PM
>>>>> callbacks; "
>>>>> +                 "cannot safely control sink\n");
>>>>
>>>> This prints out on my Orion board on a fresh boot because of how
>>>> pm_save_enable is setup there. Do we really need the configuration
>>>> of pm_save_enable for ETE/TRBE if we know that it always needs
>>>> saving?
> 
> Yeah, I can remove this check and always bind CPU PM ops for ETE.
> 
>>>> It also stops warning if I rmmod and modprobe the module after
>>>> booting. Seems like pm_save_enable is different depending on how the
>>>> module is loaded which doesn't seem right.
>>>
>>> Thats because the warning is pr_warn_*once*()
>>
>> I don't think so, I tested it with a printf instead of a warn once and also
>> tested modprobeing straight after a reboot.
> 
> I am a bit surprised that Orion6 hits the CPU idle flow, as I observed
> that idle states are not enabled on my board:
> 
>    # ls /sys/devices/system/cpu/cpu*/cpuidle
>    ls: cannot access '/sys/devices/system/cpu/cpu*/cpuidle': No such file or directory
> 

/sys/devices/system/cpu/cpu0/cpuidle:
total 0
drwxr-xr-x 9 root 0 Apr 10 10:08 ..
drwxr-xr-x 2 root 0 Apr 10 10:10 state2
drwxr-xr-x 2 root 0 Apr 10 10:10 state1
drwxr-xr-x 2 root 0 Apr 10 10:10 state0
drwxr-xr-x 2 root 0 Apr 10 10:10 driver
drwxr-xr-x 6 root 0 Apr 10 10:10 .


> If you hit only once CPU idle notifier, it is good to add a
> dump_stack() in coresight_cpu_pm_notify and print the "cmd" argument,
> so we can know the calling coming from where.  I am a bit suspect it
> might be a glitch in CPUIdle layer.
> 
> Thanks,
> Leo


cmd: 2


[    7.878456]  coresight_cpu_pm_notify+0x148/0x4b0
[    7.878462]  notifier_call_chain+0x8c/0x1e0
[    7.878467]  raw_notifier_call_chain+0x24/0x38
[    7.878469]  cpu_pm_exit+0x34/0x68
[    7.878472]  acpi_processor_ffh_lpi_enter+0x40/0x78
[    7.878476]  acpi_idle_lpi_enter+0x54/0x78
[    7.878481]  cpuidle_enter_state+0xb4/0x250
[    7.878483]  cpuidle_enter+0x44/0x68
[    7.878487]  do_idle+0x1e0/0x278
[    7.878492]  cpu_startup_entry+0x40/0x50
[    7.878495]  rest_init+0xec/0xf8
[    7.878497]  start_kernel+0x348/0x400
[    7.878503]  __primary_switched+0x88/0x98



  -> zcat /proc/config.gz | grep IDLE
CONFIG_CONTEXT_TRACKING_IDLE=y
CONFIG_NO_HZ_IDLE=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_CPU_IDLE_GOV_TEO is not set
CONFIG_DT_IDLE_STATES=y
CONFIG_DT_IDLE_GENPD=y
CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_ARM_PSCI_CPUIDLE_DOMAIN=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
# CONFIG_IDLE_PAGE_TRACKING is not set
# CONFIG_NETFILTER_XT_TARGET_IDLETIMER is not set