From: "Heiko Stübner" <heiko@sntech.de>
To: Ulf Hansson <ulf.hansson@linaro.org>,
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@collabora.com, linux-rockchip@lists.infradead.org,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Subject: Re: [PATCH] pmdomian: core: don't unset stay_on during sync_state
Date: Thu, 04 Sep 2025 17:55:33 +0200 [thread overview]
Message-ID: <878503621.0ifERbkFSE@diego> (raw)
In-Reply-To: <117136352.nniJfEyVGO@diego>
Am Donnerstag, 4. September 2025, 17:49:16 Mitteleuropäische Sommerzeit schrieb Heiko Stübner:
> Hi,
>
> Am Dienstag, 2. September 2025, 20:23:04 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> > This reverts commit de141a9aa52d6b2fbeb63f98975c2c72276f0878.
> >
> > On RK3576, the UFS controller's power domain has a quirk that requires
> > it to stay enabled, infrastricture for which was added in Commit
> > cd3fa304ba5c ("pmdomain: core: Introduce dev_pm_genpd_rpm_always_on()").
> >
> > Unfortunately, Commit de141a9aa52d ("pmdomain: core: Leave powered-on
> > genpds on until sync_state") appears to break this quirk wholesale. The
> > result is that RK3576 devices with the UFS controller enabled but unused
> > will freeze once pmdomain shuts off unused domains.
> >
> > Revert it until a better fix can be found.
> >
> > Fixes: de141a9aa52d ("pmdomain: core: Leave powered-on genpds on until sync_state")
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
> just an observation independent of the conversation in the other thread.
> This patch/revert whatever fixes an actual issue for me.
ah and just saw Nicolas' mail from 6 minutes earlier.
So I guess what saves me here is the rocket driver being built as a
module, power-domain getting turned off early, rocket probes with
pd off and then gets its supplies as expected.
Heiko
>
> On the rk3588 the NPU power-domains are a hirarchy of
>
> PD_NPU
> PD_NPUTOP (core0)
> PD_NPU1 (core1)
> PD_NPU2 (core2)
>
> and the PD_NPU does need a supply regulator.
>
> (1) With "just" v6.17-rc + the rocket driver probing and then idling, I get:
>
> # cat /sys/kernel/debug/regulator/regulator_summary
> regulator use open bypass opmode voltage current min max
> ---------------------------------------------------------------------------------------
> dc_12v 4 3 0 unknown 12000mV 0mA 12000mV 12000mV
> [...]
> vcc5v0_baseboard 2 1 0 unknown 5000mV 0mA 5000mV 5000mV
> vcc5v0_sys 18 18 0 unknown 5000mV 0mA 5000mV 5000mV
> [...]
> vdd_npu_s0 0 0 0 normal 800mV 0mA 550mV 950mV
> vcc_1v2_s3 2 1 0 unknown 1200mV 0mA 1200mV 1200mV
> fe1b0000.ethernet-phy 1 0mA 0mV 0mV
> vdd_gpu_s0 1 2 0 normal 675mV 0mA 550mV 950mV
> fb000000.gpu-mali 1 0mA 675mV 850mV
> fd8d8000.power-management:power-controller-domain 0 0mA 0mV 0mV
> [...]
>
> # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain status children performance
> /device runtime status managed by
> ------------------------------------------------------------------------------
> [...]
> gpu off-0 0
> fb000000.gpu suspended 0 SW
> npu2 off-0 0
> fdada000.iommu suspended 0 SW
> fdad0000.npu suspended 0 SW
> npu1 off-0 0
> fdaca000.iommu suspended 0 SW
> fdac0000.npu suspended 0 SW
> nputop off-0 0
> npu1, npu2
> fdab9000.iommu suspended 0 SW
> fdab0000.npu suspended 0 SW
> npu on 0
> nputop
>
> Observe that the PD_NPU never got its regulator and the domain also
> never actually gets turned off. While the domains directly attached to
> the cores get turned off.
>
>
> (2) with Nicolas's patch applied on top, I get the correct behaviour,
> that was also happening with v6.16 before
>
> # cat /sys/kernel/debug/regulator/regulator_summary
> regulator use open bypass opmode voltage current min max
> ---------------------------------------------------------------------------------------
> dc_12v 4 3 0 unknown 12000mV 0mA 12000mV 12000mV
> [...]
> vcc5v0_baseboard 2 1 0 unknown 5000mV 0mA 5000mV 5000mV
> vcc5v0_sys 18 18 0 unknown 5000mV 0mA 5000mV 5000mV
> [...]
> vdd_npu_s0 0 1 0 normal 800mV 0mA 550mV 950mV
> fd8d8000.power-management:power-controller-domain 0 0mA 0mV 0mV
> vdd_cpu_big1_s0 2 1 0 normal 1000mV 0mA 550mV 1050mV
> cpu6-cpu 1 0mA 1000mV 1000mV
> vdd_gpu_s0 1 2 0 normal 675mV 0mA 550mV 950mV
> fb000000.gpu-mali 1 0mA 675mV 850mV
> fd8d8000.power-management:power-controller-domain 0 0mA 0mV 0mV
> [...]
>
> # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain status children performance
> /device runtime status managed by
> ------------------------------------------------------------------------------
> [...]
> gpu off-0 0
> fb000000.gpu suspended 0 SW
> npu2 off-0 0
> fdada000.iommu suspended 0 SW
> fdad0000.npu suspended 0 SW
> npu1 off-0 0
> fdaca000.iommu suspended 0 SW
> fdac0000.npu suspended 0 SW
> nputop off-0 0
> npu1, npu2
> fdab9000.iommu suspended 0 SW
> fdab0000.npu suspended 0 SW
> npu off-0 0
> nputop
>
> The regulator handling is working correctly and also the parent PD_NPU
> domain gets turned off when its children are off.
>
>
> Heiko
>
next prev parent reply other threads:[~2025-09-04 15:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 18:23 [PATCH] pmdomian: core: don't unset stay_on during sync_state Nicolas Frattaroli
2025-09-02 18:25 ` Nicolas Frattaroli
2025-09-04 9:17 ` Ulf Hansson
2025-09-04 12:50 ` Nicolas Frattaroli
2025-09-04 15:43 ` Nicolas Frattaroli
2025-09-05 14:27 ` Ulf Hansson
2025-09-04 16:13 ` Ulf Hansson
2025-09-04 17:41 ` Nicolas Frattaroli
2025-09-04 15:49 ` Heiko Stübner
2025-09-04 15:55 ` Heiko Stübner [this message]
2025-09-04 16:07 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878503621.0ifERbkFSE@diego \
--to=heiko@sntech.de \
--cc=cristian.ciocaltea@collabora.com \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=nicolas.frattaroli@collabora.com \
--cc=sebastian.reichel@collabora.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).