Re: [PATCH] soc/tegra: pmc: Ensure power-domains are in a known state

[Jon Hunter]

On 12/09/2025 15:13, Ulf Hansson wrote:
> On Tue, 26 Aug 2025 at 17:29, Thierry Reding <thierry.reding@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx>
> > >
> > > 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.

I need to check that but that could be a good idea.

Thanks
Jon

--
nvpublic