| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPDyKFpZOgrOtAcpopkk0s+OYr6f+_yFz1v1E+4NHgUsnDhLtg@mail.gmail.com>
Date: Thu, 4 Sep 2025 18:07:23 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>, Heiko Stübner <heiko@...ech.de>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel@...labora.com, linux-rockchip@...ts.infradead.org,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
Sebastian Reichel <sebastian.reichel@...labora.com>
Subject: Re: [PATCH] pmdomian: core: don't unset stay_on during sync_state
On Thu, 4 Sept 2025 at 17:55, Heiko Stübner <heiko@...ech.de> wrote:
>
> 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@...labora.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.
Okay, so to follow up on your analysis.
I am thinking that the PM domain "looks like" it's properly powered-on
during boot/init, while in-fact it may not.
In other words, calling pm_genpd_init() and stating that the genpd is
powered-on seems to be the problem here. Could a proper power-off be
done before calling pm_genpd_init() and then leaving it off until
later?
Kind regards
Uffe
>
>
> 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
> >
>
>
>
>
Powered by blists - more mailing lists