All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 





WARNING: multiple messages have this Message-ID (diff)
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,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	kernel@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
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-09-04 15:55 UTC|newest]

Thread overview: 30+ 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:23 ` Nicolas Frattaroli
2025-09-02 18:25 ` Nicolas Frattaroli
2025-09-02 18:25   ` Nicolas Frattaroli
2025-09-04  9:17 ` Ulf Hansson
2025-09-04  9:17   ` Ulf Hansson
2025-09-04 12:50   ` Nicolas Frattaroli
2025-09-04 12:50     ` Nicolas Frattaroli
2025-09-04 15:43     ` Nicolas Frattaroli
2025-09-04 15:43       ` Nicolas Frattaroli
2025-09-05 14:27       ` Ulf Hansson
2025-09-05 14:27         ` Ulf Hansson
2025-09-08 13:14         ` Nicolas Frattaroli
2025-09-08 13:14           ` Nicolas Frattaroli
2025-09-08 13:40           ` Ulf Hansson
2025-09-08 13:40             ` Ulf Hansson
2025-09-08 20:08             ` Sebastian Reichel
2025-09-08 20:08               ` Sebastian Reichel
2025-09-09 12:46               ` Ulf Hansson
2025-09-09 12:46                 ` Ulf Hansson
2025-09-04 16:13     ` Ulf Hansson
2025-09-04 16:13       ` Ulf Hansson
2025-09-04 17:41       ` Nicolas Frattaroli
2025-09-04 17:41         ` Nicolas Frattaroli
2025-09-04 15:49 ` Heiko Stübner
2025-09-04 15:49   ` Heiko Stübner
2025-09-04 15:55   ` Heiko Stübner [this message]
2025-09-04 15:55     ` Heiko Stübner
2025-09-04 16:07     ` Ulf Hansson
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.