Message-ID: <c16477c8-95e9-4e07-9202-042b1070c76f@nvidia.com>
Date: Wed, 17 Sep 2025 14:16:25 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
 Thierry Reding <thierry.reding@...il.com>
Cc: 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 12/09/2025 15:13, Ulf Hansson wrote:
> 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.

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

Thanks
Jon

-- 
nvpublic

Powered by blists - more mailing lists