Re: [PATCH v3 2/5] pmdomain: core: Allow a non-CPU device in a CPU PM domain to do power on

[Ulf Hansson]

On Fri, Sep 11, 2026 at 11:06 AM Ulf Hansson
<ulf.hansson@xxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 10, 2026 at 8:31 PM Dhruva G <goledhruva@xxxxxxxxx> wrote:
> >
> > On 07-09-2026 16:46, Ulf Hansson wrote:
> > > A driver for a non-CPU device that is attached to a CPU PM domain (the
> > > genpd has the GENPD_FLAG_CPU_DOMAIN configuration set), is currently not
> > > able to power on the PM domain. More precisely, to power on a CPU PM domain
> > > one of its corresponding CPUs needs to be woken up if they are idle.
> > >
> > > The current support for a non-CPU device is that its driver can only
> > > prevent an already powered on CPU PM domain from being powered off. This
> > > leads to problems for a driver while probing its device or when it needs to
> > > call pm_runtime_get_sync() to turn on the power for it. From the driver
> > > point of view it looks like it all works fine, but when accessing the
> > > device it may end up with various errors as the device may not be fully
> > > powered on.
> > >
> > > To fix the behavior for these types of devices, let's adjust the behaviour
> > > in genpd_power_on() to wake up an idle CPU that belongs to it, in cases
> > > when it's needed.
> > >
> > > Link: https://lore.kernel.org/all/CAPx+jO-sCierYj8jnoKQHckJG16dOBxnNrsZVYO=38R2cLV8nw@xxxxxxxxxxxxxx/
> > > Reviewed-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
> > > Tested-by: Yuanfang Zhang <yuanfang.zhang@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxxxxxxxx>
> > > ---
> > >
> > > Changes in v3:
> > >       - Moved to atomic polling, pointed out by Dhruva.
> >
> > Thanks, but even in v3 we still have potential issues.
> > It does not fully address the consequences of polling for five seconds in that context,
> > nor the parent-lock nesting issue.
>
> Well, I assume we will not be polling for 5s, as it would be an error
> and it means that we fail to wake up the CPU. But, I get your point,
> 5s is really an unnecessary long timeout.
>
> Ideally the timeout should map towards the deepest domain idle state's
> entry+exit-latency-us, but rather than looking at what is actually
> available for the PM domain(s) in question, I think it's easier (and
> good enough) if we just pick a common value. Usually these values are
> in the range of a couple milliseconds and in some cases up to
> ~15-20ms. I suggest we decrease the timeout to 300ms and see how that
> plays out.
>
> Also note that, at this point I don't know of any use cases similar to
> what you describe, where the device in question is in an irqsafe child
> domain. Hence the polling would not be done in an atomic context at
> all, so we should be safe. Anyway, if this doesn't work we would
> simply have to limit the support to non irqsafe child domains.
>
> In regards to the parent-lock nesting issue. I don't think it's a
> problem as genpd_wakeup_cpu() is not being called recursively, but let
> me double check this to be sure.

Confirmed, I could not trigger any lockdep problems with my tests.

If you are fine with the above suggestion for the timeout, I am
thinking of amending the patch when applying to avoid posting a new
version of the series. Please let me know.

[...]

Kind regards
Uffe