[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFrTTUs2xwoY+Tmff1SHhsGjj-XmW3maDnO7V6T7m_8H=Q@mail.gmail.com>
Date: Thu, 11 Sep 2025 12:25:09 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>,
Saravana Kannan <saravanak@...gle.com>, linux-pm@...r.kernel.org,
Stephen Boyd <sboyd@...nel.org>, "Rafael J . Wysocki" <rafael@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
Sebastian Reichel <sebastian.reichel@...labora.com>, Sebin Francis <sebin.francis@...com>,
Diederik de Haas <didi.debian@...ow.org>, Bjorn Andersson <andersson@...nel.org>,
Abel Vesa <abel.vesa@...aro.org>, Peng Fan <peng.fan@....nxp.com>,
Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Johan Hovold <johan@...nel.org>,
Maulik Shah <maulik.shah@....qualcomm.com>, Michal Simek <michal.simek@....com>,
Konrad Dybcio <konradybcio@...nel.org>, Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] pmdomain: core: Restore behaviour for disabling
unused PM domains
On Thu, 11 Sept 2025 at 09:56, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Ulf,
>
> On Tue, 9 Sept 2025 at 13:11, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > Recent changes to genpd prevents those PM domains being powered-on during
> > initialization from being powered-off during the boot sequence. Based upon
> > whether CONFIG_PM_CONFIG_PM_GENERIC_DOMAINS_OF is set of not, genpd relies
> > on the sync_state mechanism or the genpd_power_off_unused() (which is a
> > late_initcall_sync), to understand when it's okay to allow these PM domains
> > to be powered-off.
> >
> > This new behaviour in genpd has lead to problems on different platforms.
> > Let's therefore restore the behavior of genpd_power_off_unused().
> > Moreover, let's introduce GENPD_FLAG_NO_STAY_ON, to allow genpd OF
> > providers to opt-out from the new behaviour.
> >
> > Link: https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
> > Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> > Link: https://lore.kernel.org/all/20250902-rk3576-lockup-regression-v1-1-c4a0c9daeb00@collabora.com/
> > Reported-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
> > Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state")
> > Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
> > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
>
> Thanks for your patch!
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@...der.be>
>
> > --- a/include/linux/pm_domain.h
> > +++ b/include/linux/pm_domain.h
> > @@ -115,6 +115,12 @@ struct dev_pm_domain_list {
> > * genpd provider specific way, likely through a
> > * parent device node. This flag makes genpd to
> > * skip its internal support for this.
> > + *
> > + * GENPD_FLAG_NO_STAY_ON: For genpd OF providers a powered-on PM domain at
> > + * initialization is prevented from being
> > + * powered-off until the ->sync_state() callback is
> > + * invoked. This flag informs genpd to allow a
> > + * power-off without waiting for ->sync_state().
>
> This also restores power-down of pmdomains after a failed device
> probe (due to a real issue, or just -EPROBE_DEFER), possibly
> interfering with other devices that are part of the same pmdomain(s)
> but haven't been probed yet. E.g. what if your serial console is
> part of the same pmdomain? Probably the pmdomain(s) should not
> be powered down immediately, but only later, when either sync state
> or genpd_power_off_unused() kicks in.
That is exactly one of the problems we solve with the new sync_state
support in genpd.
If you have this problem for one of the PM domains, we should not set
GENPD_FLAG_NO_STAY_ON for it. In fact, that's exactly why I added this
flag, to allow it to be set on a per genpd basis. Otherwise we might
as well have used of_genpd_sync_state().
Down the road, if we can improve the sync_state support in genpd,
especially a more fine-grained control for those providers that use
of_genpd_add_provider_onecell(), I hope we should be able to remove
this flag.
[...]
Kind regards
Uffe
Powered by blists - more mailing lists