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

[Leo Yan <leo.yan@arm.com>]

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

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