Message-ID: <CAPDyKFpVohjP4bkSkxxOXiEsbWqWNa2GFRdDbQ7YC60NyC=c9A@mail.gmail.com>
Date: Fri, 12 Sep 2025 16:13:37 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Jon Hunter <jonathanh@...dia.com>, linux-tegra@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc/tegra: pmc: Ensure power-domains are in a known state

On Tue, 26 Aug 2025 at 17:29, Thierry Reding <thierry.reding@...il.com> wrote:
>
> On Mon, Aug 11, 2025 at 12:37:25PM +0200, Ulf Hansson wrote:
> > On Thu, 31 Jul 2025 at 14:18, Jon Hunter <jonathanh@...dia.com> wrote:
> > >
> > > After commit 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on
> > > until late_initcall_sync") was applied, the Tegra210 Jetson TX1 board
> > > failed to boot. Looking into this issue, before this commit was applied,
> > > if any of the Tegra power-domains were in 'on' state when the kernel
> > > booted, they were being turned off by the genpd core before any driver
> > > had chance to request them. This was purely by luck and a consequence of
> > > the power-domains being turned off earlier during boot. After this
> > > commit was applied, any power-domains in the 'on' state are kept on for
> > > longer during boot and therefore, may never transitioned to the off
> > > state before they are requested/used. The hang on the Tegra210 Jetson
> > > TX1 is caused because devices in some power-domains are accessed without
> > > the power-domain being turned off and on, indicating that the
> > > power-domain is not in a completely on state.
> > >
> > > From reviewing the Tegra PMC driver code, if a power-domain is in the
> > > 'on' state there is no guarantee that all the necessary clocks
> > > associated with the power-domain are on and even if they are they would
> > > not have been requested via the clock framework and so could be turned
> > > off later. Some power-domains also have a 'clamping' register that needs
> > > to be configured as well. In short, if a power-domain is already 'on' it
> > > is difficult to know if it has been configured correctly. Given that the
> > > power-domains happened to be switched off during boot previously, to
> > > ensure that they are in a good known state on boot, fix this by
> > > switching off any power-domains that are on initially when registering
> > > the power-domains with the genpd framework.
> > >
> > > Note that commit 05cfb988a4d0 ("soc/tegra: pmc: Initialise resets
> > > associated with a power partition") updated the
> > > tegra_powergate_of_get_resets() function to pass the 'off' to ensure
> > > that the resets for the power-domain are in the correct state on boot.
> > > However, now that we may power off a domain on boot, if it is on, it is
> > > better to move this logic into the tegra_powergate_add() function so
> > > that there is a single place where we are handling the initial state of
> > > the power-domain.
> > >
> > > Fixes: a38045121bf4 ("soc/tegra: pmc: Add generic PM domain support")
> > > Signed-off-by: Jon Hunter <jonathanh@...dia.com>
> >
> > Thanks for looking into this!
> >
> > I have picked this up via my pmdomain tree and applied it as a fix
> > with a stable tag. Please let me know if you prefer to take this via
> > your soc tree instead.
> >
> > That said, I guess we have some use-cases on Tegra where it actually
> > would make sense to allow powered-on PM-domains to stay on during
> > boot. Although, at this point, it seems better to deal with those on a
> > case by case basis, as improvements on top.
>
> We're actually running into one of these cases right now. This happens
> for display hardware where we have simple-framebuffer device tree nodes
> that are meant to allow a seamless transition from the firmware's early
> framebuffer to the Linux framebuffer. But since Jon's patch disables all
> of the power domains, the seamless transition no longer works.
>
> I suppose we could argue that seamless display is less important than
> systems booting, so I'm inclined to say we want to keep this patch to
> fix the earlier regression and then apply a fix on top to address the
> issue with the early display.
>
> Do you have any thoughts on how to deal with specific power domains that
> should remain powered on during boot? Ideally it would be something
> standard, but worst case we can also special-case in the Tegra PMC
> driver.

Does it work to leave that particular PM domain for the display powered-on?

Genpd should deal with this then, by simply leaving the PM domain on,
until the consumers of it have been probed.

Kind regards
Uffe

Powered by blists - more mailing lists