drivers/base/core.c | 8 +- drivers/cpuidle/cpuidle-psci-domain.c | 14 -- drivers/cpuidle/cpuidle-riscv-sbi.c | 14 -- drivers/firmware/xilinx/zynqmp.c | 18 +- drivers/pmdomain/core.c | 239 ++++++++++++++++++-- drivers/pmdomain/qcom/rpmhpd.c | 2 + drivers/pmdomain/qcom/rpmpd.c | 2 + drivers/pmdomain/xilinx/zynqmp-pm-domains.c | 16 -- drivers/soc/tegra/pmc.c | 26 ++- include/linux/device.h | 13 ++ include/linux/firmware/xlnx-zynqmp.h | 6 - include/linux/pm_domain.h | 17 ++ 12 files changed, 294 insertions(+), 81 deletions(-)
Changes in v2:
- Well, quite a lot as I discovered various problems when doing
additional testing of corner-case. I suggest re-review from scratch,
even if I decided to keep some reviewed-by tags.
- Added patches to allow some drivers that needs to align or opt-out
from the new common behaviour in genpd.
If a PM domain (genpd) is powered-on during boot, there is probably a good
reason for it. Therefore it's known to be a bad idea to allow such genpd to be
powered-off before all of its consumer devices have been probed. This series
intends to fix this problem.
We have been discussing these issues at LKML and at various Linux-conferences
in the past. I have therefore tried to include the people I can recall being
involved, but I may have forgotten some (my apologies), feel free to loop them
in.
I have tested this with QEMU with a bunch of local test-drivers and DT nodes.
Let me know if you want me to share this code too.
Please help review and test!
Finally, a big thanks to Saravana for all the support!
Kind regards
Ulf Hansson
Saravana Kannan (1):
driver core: Add dev_set_drv_sync_state()
Ulf Hansson (20):
pmdomain: core: Use of_fwnode_handle()
pmdomain: core: Add a bus and a driver for genpd providers
pmdomain: core: Add the genpd->dev to the genpd provider bus
pmdomain: core: Export a common ->sync_state() helper for genpd
providers
pmdomain: core: Prepare to add the common ->sync_state() support
soc/tegra: pmc: Opt-out from genpd's common ->sync_state() support
cpuidle: psci: Opt-out from genpd's common ->sync_state() support
cpuidle: riscv-sbi: Opt-out from genpd's common ->sync_state() support
pmdomain: qcom: rpmhpd: Use of_genpd_sync_state()
pmdomain: qcom: rpmhpd: Use of_genpd_sync_state()
firmware/pmdomain: xilinx: Move ->sync_state() support to firmware
driver
firmware: xilinx: Don't share zynqmp_pm_init_finalize()
firmware: xilinx: Use of_genpd_sync_state()
driver core: Export get_dev_from_fwnode()
pmdomain: core: Add common ->sync_state() support for genpd providers
pmdomain: core: Default to use of_genpd_sync_state() for genpd
providers
pmdomain: core: Leave powered-on genpds on until late_initcall_sync
pmdomain: core: Leave powered-on genpds on until sync_state
cpuidle: psci: Drop redundant sync_state support
cpuidle: riscv-sbi: Drop redundant sync_state support
drivers/base/core.c | 8 +-
drivers/cpuidle/cpuidle-psci-domain.c | 14 --
drivers/cpuidle/cpuidle-riscv-sbi.c | 14 --
drivers/firmware/xilinx/zynqmp.c | 18 +-
drivers/pmdomain/core.c | 239 ++++++++++++++++++--
drivers/pmdomain/qcom/rpmhpd.c | 2 +
drivers/pmdomain/qcom/rpmpd.c | 2 +
drivers/pmdomain/xilinx/zynqmp-pm-domains.c | 16 --
drivers/soc/tegra/pmc.c | 26 ++-
include/linux/device.h | 13 ++
include/linux/firmware/xlnx-zynqmp.h | 6 -
include/linux/pm_domain.h | 17 ++
12 files changed, 294 insertions(+), 81 deletions(-)
--
2.43.0
Hi Ulf, On 23/05/2025 16:39, Ulf Hansson wrote: > Changes in v2: > - Well, quite a lot as I discovered various problems when doing > additional testing of corner-case. I suggest re-review from scratch, > even if I decided to keep some reviewed-by tags. > - Added patches to allow some drivers that needs to align or opt-out > from the new common behaviour in genpd. > > If a PM domain (genpd) is powered-on during boot, there is probably a good > reason for it. Therefore it's known to be a bad idea to allow such genpd to be > powered-off before all of its consumer devices have been probed. This series > intends to fix this problem. > > We have been discussing these issues at LKML and at various Linux-conferences > in the past. I have therefore tried to include the people I can recall being > involved, but I may have forgotten some (my apologies), feel free to loop them > in. > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes. > Let me know if you want me to share this code too. > > Please help review and test! I tested this Renesas white-hawk board, and it hangs at boot. With earlycon, I captured with/without boot logs, attached. The hang case doesn't look very healthy with all these: "kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is being called." Tomi
On Fri, 13 Jun 2025 at 12:33, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote: > > Hi Ulf, > > On 23/05/2025 16:39, Ulf Hansson wrote: > > Changes in v2: > > - Well, quite a lot as I discovered various problems when doing > > additional testing of corner-case. I suggest re-review from scratch, > > even if I decided to keep some reviewed-by tags. > > - Added patches to allow some drivers that needs to align or opt-out > > from the new common behaviour in genpd. > > > > If a PM domain (genpd) is powered-on during boot, there is probably a good > > reason for it. Therefore it's known to be a bad idea to allow such genpd to be > > powered-off before all of its consumer devices have been probed. This series > > intends to fix this problem. > > > > We have been discussing these issues at LKML and at various Linux-conferences > > in the past. I have therefore tried to include the people I can recall being > > involved, but I may have forgotten some (my apologies), feel free to loop them > > in. > > > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes. > > Let me know if you want me to share this code too. > > > > Please help review and test! > > I tested this Renesas white-hawk board, and it hangs at boot. With > earlycon, I captured with/without boot logs, attached. > > The hang case doesn't look very healthy with all these: "kobject: > '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is > being called." Tomi, thanks a lot for helping out with testing! rcar_gen4_sysc_pd_init() calls pm_genpd_init() and of_genpd_add_provider_onecell(). rcar_gen4_sysc_pd_init() is an early_initcall, which I guess is the reason for these problems, as the genpd_provider_bus has not been registered that early (it's done at core_initcall) Do you think it would be possible to move rcar_gen4_sysc_pd_init() to a postcore/arch_initcall? Kind regards Uffe
On Thu, 19 Jun 2025 at 13:40, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Fri, 13 Jun 2025 at 12:33, Tomi Valkeinen > <tomi.valkeinen@ideasonboard.com> wrote: > > > > Hi Ulf, > > > > On 23/05/2025 16:39, Ulf Hansson wrote: > > > Changes in v2: > > > - Well, quite a lot as I discovered various problems when doing > > > additional testing of corner-case. I suggest re-review from scratch, > > > even if I decided to keep some reviewed-by tags. > > > - Added patches to allow some drivers that needs to align or opt-out > > > from the new common behaviour in genpd. > > > > > > If a PM domain (genpd) is powered-on during boot, there is probably a good > > > reason for it. Therefore it's known to be a bad idea to allow such genpd to be > > > powered-off before all of its consumer devices have been probed. This series > > > intends to fix this problem. > > > > > > We have been discussing these issues at LKML and at various Linux-conferences > > > in the past. I have therefore tried to include the people I can recall being > > > involved, but I may have forgotten some (my apologies), feel free to loop them > > > in. > > > > > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes. > > > Let me know if you want me to share this code too. > > > > > > Please help review and test! > > > > I tested this Renesas white-hawk board, and it hangs at boot. With > > earlycon, I captured with/without boot logs, attached. > > > > The hang case doesn't look very healthy with all these: "kobject: > > '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is > > being called." > > Tomi, thanks a lot for helping out with testing! > > rcar_gen4_sysc_pd_init() calls pm_genpd_init() and > of_genpd_add_provider_onecell(). > > rcar_gen4_sysc_pd_init() is an early_initcall, which I guess is the > reason for these problems, as the genpd_provider_bus has not been > registered that early (it's done at core_initcall) > > Do you think it would be possible to move rcar_gen4_sysc_pd_init() to > a postcore/arch_initcall? I did some investigation around this and found that both drivers/pmdomain/renesas/rcar-gen4-sysc.c and drivers/pmdomain/renesas/rcar-sysc.c are registering their genpd providers at the early_initcall() level. I was trying to find (by browsing renesas DTSes and looking into drivers) if there is any consumers that actually relies on this, but so far the earliest consumer I have found is the drivers/irqchip/irq-renesas-irqc.c, but that's at postcore_initcall(). Of course, it's difficult to say if my analysis is complete as there are a lot of platform variants and I didn't check them all. Maybe we should just give it a try and move both two drivers above to postcore_initcall and see if it works (assuming the irq-renesas-irqc supports -EPROBE_DEFER correctly too). If this doesn't work, I think we need to find a way to allow deferring the call to device_add() in of_genpd_provider_add*() for genpd provider's devices. Kind regards Uffe
Hi Ulf,
On Mon, 23 Jun 2025 at 16:21, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Thu, 19 Jun 2025 at 13:40, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Fri, 13 Jun 2025 at 12:33, Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> > > On 23/05/2025 16:39, Ulf Hansson wrote:
> > > > Changes in v2:
> > > > - Well, quite a lot as I discovered various problems when doing
> > > > additional testing of corner-case. I suggest re-review from scratch,
> > > > even if I decided to keep some reviewed-by tags.
> > > > - Added patches to allow some drivers that needs to align or opt-out
> > > > from the new common behaviour in genpd.
> > > >
> > > > If a PM domain (genpd) is powered-on during boot, there is probably a good
> > > > reason for it. Therefore it's known to be a bad idea to allow such genpd to be
> > > > powered-off before all of its consumer devices have been probed. This series
> > > > intends to fix this problem.
> > > >
> > > > We have been discussing these issues at LKML and at various Linux-conferences
> > > > in the past. I have therefore tried to include the people I can recall being
> > > > involved, but I may have forgotten some (my apologies), feel free to loop them
> > > > in.
> > > >
> > > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes.
> > > > Let me know if you want me to share this code too.
> > > >
> > > > Please help review and test!
> > >
> > > I tested this Renesas white-hawk board, and it hangs at boot. With
> > > earlycon, I captured with/without boot logs, attached.
> > >
> > > The hang case doesn't look very healthy with all these: "kobject:
> > > '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is
> > > being called."
> >
> > Tomi, thanks a lot for helping out with testing!
> >
> > rcar_gen4_sysc_pd_init() calls pm_genpd_init() and
> > of_genpd_add_provider_onecell().
> >
> > rcar_gen4_sysc_pd_init() is an early_initcall, which I guess is the
> > reason for these problems, as the genpd_provider_bus has not been
> > registered that early (it's done at core_initcall)
> >
> > Do you think it would be possible to move rcar_gen4_sysc_pd_init() to
> > a postcore/arch_initcall?
>
> I did some investigation around this and found that both
> drivers/pmdomain/renesas/rcar-gen4-sysc.c and
> drivers/pmdomain/renesas/rcar-sysc.c are registering their genpd
> providers at the early_initcall() level.
>
> I was trying to find (by browsing renesas DTSes and looking into
> drivers) if there is any consumers that actually relies on this, but
> so far the earliest consumer I have found is the
> drivers/irqchip/irq-renesas-irqc.c, but that's at postcore_initcall().
> Of course, it's difficult to say if my analysis is complete as there
> are a lot of platform variants and I didn't check them all.
>
> Maybe we should just give it a try and move both two drivers above to
> postcore_initcall and see if it works (assuming the irq-renesas-irqc
> supports -EPROBE_DEFER correctly too).
>
> If this doesn't work, I think we need to find a way to allow deferring
> the call to device_add() in of_genpd_provider_add*() for genpd
> provider's devices.
Commit dcc09fd143bb97c2 ("soc: renesas: rcar-sysc: Add DT support for
SYSC PM domains") explains:
"Initialization is done from an early_initcall(), to make sure the PM
Domains are initialized before secondary CPU bringup."
but that matters only for arm32 systems (R-Car Gen1 and Gen2).
Arm64 systems (R-Car Gen3 and Gen4) use PSCI for CPU PM Domain control.
While changing rcar-sysc.c to use a postcore_initcall indeed moves PM
Domain initialization after secondary CPU bringup, the second CPU core
on R-Car M2-W is still brought up fine.
For R-Car H1, there is a regression:
smp: Bringing up secondary CPUs ...
CPU1: failed to boot: -19
CPU2: failed to boot: -19
CPU3: failed to boot: -19
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated (500.00 BogoMIPS).
CPU bringup/teardown in userspace using
/sys/devices/system/cpu/cpu*/online still works.
R-Car H1 was never converted to use "enable-method" in DT, and relies
on calling into the rcar-sysc driver directly (see [1]). However,
that does not use any actual calls into the genpd core, so probably it
can be made to work by splitting rcar_sysc_pd_init() in two parts: an
early_initcall() that allocates all domain structures and populates the
internal hierarchy, and a postcore_initcall() that registers everything
with the genpd core.
As expected, there is no impact on R-Car H3 ES2.0.
I will test on R-Car V4M tomorrow, but expect no issues.
FTR, drivers/pmdomain/renesas/rmobile-sysc.c uses core_initcall().
Changing that to postcore_initcall does not seem to make a difference
(on R-Mobile A1).
[1] https://elixir.bootlin.com/linux/v6.15.3/source/drivers/pmdomain/renesas/rcar-sysc.c#L439
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 23 Jun 2025 at 17:06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Ulf,
>
> On Mon, 23 Jun 2025 at 16:21, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Thu, 19 Jun 2025 at 13:40, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > On Fri, 13 Jun 2025 at 12:33, Tomi Valkeinen
> > > <tomi.valkeinen@ideasonboard.com> wrote:
> > > > On 23/05/2025 16:39, Ulf Hansson wrote:
> > > > > Changes in v2:
> > > > > - Well, quite a lot as I discovered various problems when doing
> > > > > additional testing of corner-case. I suggest re-review from scratch,
> > > > > even if I decided to keep some reviewed-by tags.
> > > > > - Added patches to allow some drivers that needs to align or opt-out
> > > > > from the new common behaviour in genpd.
> > > > >
> > > > > If a PM domain (genpd) is powered-on during boot, there is probably a good
> > > > > reason for it. Therefore it's known to be a bad idea to allow such genpd to be
> > > > > powered-off before all of its consumer devices have been probed. This series
> > > > > intends to fix this problem.
> > > > >
> > > > > We have been discussing these issues at LKML and at various Linux-conferences
> > > > > in the past. I have therefore tried to include the people I can recall being
> > > > > involved, but I may have forgotten some (my apologies), feel free to loop them
> > > > > in.
> > > > >
> > > > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes.
> > > > > Let me know if you want me to share this code too.
> > > > >
> > > > > Please help review and test!
> > > >
> > > > I tested this Renesas white-hawk board, and it hangs at boot. With
> > > > earlycon, I captured with/without boot logs, attached.
> > > >
> > > > The hang case doesn't look very healthy with all these: "kobject:
> > > > '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is
> > > > being called."
> > >
> > > Tomi, thanks a lot for helping out with testing!
> > >
> > > rcar_gen4_sysc_pd_init() calls pm_genpd_init() and
> > > of_genpd_add_provider_onecell().
> > >
> > > rcar_gen4_sysc_pd_init() is an early_initcall, which I guess is the
> > > reason for these problems, as the genpd_provider_bus has not been
> > > registered that early (it's done at core_initcall)
> > >
> > > Do you think it would be possible to move rcar_gen4_sysc_pd_init() to
> > > a postcore/arch_initcall?
> >
> > I did some investigation around this and found that both
> > drivers/pmdomain/renesas/rcar-gen4-sysc.c and
> > drivers/pmdomain/renesas/rcar-sysc.c are registering their genpd
> > providers at the early_initcall() level.
> >
> > I was trying to find (by browsing renesas DTSes and looking into
> > drivers) if there is any consumers that actually relies on this, but
> > so far the earliest consumer I have found is the
> > drivers/irqchip/irq-renesas-irqc.c, but that's at postcore_initcall().
> > Of course, it's difficult to say if my analysis is complete as there
> > are a lot of platform variants and I didn't check them all.
> >
> > Maybe we should just give it a try and move both two drivers above to
> > postcore_initcall and see if it works (assuming the irq-renesas-irqc
> > supports -EPROBE_DEFER correctly too).
> >
> > If this doesn't work, I think we need to find a way to allow deferring
> > the call to device_add() in of_genpd_provider_add*() for genpd
> > provider's devices.
>
> Commit dcc09fd143bb97c2 ("soc: renesas: rcar-sysc: Add DT support for
> SYSC PM domains") explains:
>
> "Initialization is done from an early_initcall(), to make sure the PM
> Domains are initialized before secondary CPU bringup."
>
> but that matters only for arm32 systems (R-Car Gen1 and Gen2).
> Arm64 systems (R-Car Gen3 and Gen4) use PSCI for CPU PM Domain control.
Geert, thanks a lot for providing these details and helping out, much
appreciated!
>
> While changing rcar-sysc.c to use a postcore_initcall indeed moves PM
> Domain initialization after secondary CPU bringup, the second CPU core
> on R-Car M2-W is still brought up fine.
>
> For R-Car H1, there is a regression:
>
> smp: Bringing up secondary CPUs ...
> CPU1: failed to boot: -19
> CPU2: failed to boot: -19
> CPU3: failed to boot: -19
> smp: Brought up 1 node, 1 CPU
> SMP: Total of 1 processors activated (500.00 BogoMIPS).
>
> CPU bringup/teardown in userspace using
> /sys/devices/system/cpu/cpu*/online still works.
> R-Car H1 was never converted to use "enable-method" in DT, and relies
> on calling into the rcar-sysc driver directly (see [1]). However,
> that does not use any actual calls into the genpd core, so probably it
> can be made to work by splitting rcar_sysc_pd_init() in two parts: an
> early_initcall() that allocates all domain structures and populates the
> internal hierarchy, and a postcore_initcall() that registers everything
> with the genpd core.
Yes, that seems like a viable option.
Unless you prefer to have a stab at it, I intend to look into it and
make the patch(es) part of a new version of the $subject series. Of
course I am still relying on your help with testing/review.
>
> As expected, there is no impact on R-Car H3 ES2.0.
> I will test on R-Car V4M tomorrow, but expect no issues.
>
> FTR, drivers/pmdomain/renesas/rmobile-sysc.c uses core_initcall().
> Changing that to postcore_initcall does not seem to make a difference
> (on R-Mobile A1).
Okay, it sure looks like we should be able to take care of this
problem for the Renesas platforms. That's great!
That said, it seems like we should also add some internal check in
genpd to see whether the genpd_provider_bus has been registered,
before we try to add devices to it. Then, perhaps log a warning and
return -EPROBE_DEFER if we hit that case.
>
> [1] https://elixir.bootlin.com/linux/v6.15.3/source/drivers/pmdomain/renesas/rcar-sysc.c#L439
>
Kind regards
Uffe
Hi Ulf,
On Tue, 24 Jun 2025 at 17:30, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On Mon, 23 Jun 2025 at 17:06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, 23 Jun 2025 at 16:21, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > On Thu, 19 Jun 2025 at 13:40, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > Do you think it would be possible to move rcar_gen4_sysc_pd_init() to
> > > > a postcore/arch_initcall?
> > >
> > > I did some investigation around this and found that both
> > > drivers/pmdomain/renesas/rcar-gen4-sysc.c and
> > > drivers/pmdomain/renesas/rcar-sysc.c are registering their genpd
> > > providers at the early_initcall() level.
> > >
> > > I was trying to find (by browsing renesas DTSes and looking into
> > > drivers) if there is any consumers that actually relies on this, but
> > > so far the earliest consumer I have found is the
> > > drivers/irqchip/irq-renesas-irqc.c, but that's at postcore_initcall().
> > > Of course, it's difficult to say if my analysis is complete as there
> > > are a lot of platform variants and I didn't check them all.
> > >
> > > Maybe we should just give it a try and move both two drivers above to
> > > postcore_initcall and see if it works (assuming the irq-renesas-irqc
> > > supports -EPROBE_DEFER correctly too).
> > >
> > > If this doesn't work, I think we need to find a way to allow deferring
> > > the call to device_add() in of_genpd_provider_add*() for genpd
> > > provider's devices.
> >
> > Commit dcc09fd143bb97c2 ("soc: renesas: rcar-sysc: Add DT support for
> > SYSC PM domains") explains:
> >
> > "Initialization is done from an early_initcall(), to make sure the PM
> > Domains are initialized before secondary CPU bringup."
> >
> > but that matters only for arm32 systems (R-Car Gen1 and Gen2).
> > Arm64 systems (R-Car Gen3 and Gen4) use PSCI for CPU PM Domain control.
>
> Geert, thanks a lot for providing these details and helping out, much
> appreciated!
>
> > While changing rcar-sysc.c to use a postcore_initcall indeed moves PM
> > Domain initialization after secondary CPU bringup, the second CPU core
> > on R-Car M2-W is still brought up fine.
To rule out relying on anything being enabled by the bootloader,
I offlined the second CPU, and booted the kernel using kexec.
The second CPU still comes up fine. Which is not that unsurprising,
as rcar-sysc.c ignores domains with the PD_CPU flag...
> > For R-Car H1, there is a regression:
> >
> > smp: Bringing up secondary CPUs ...
> > CPU1: failed to boot: -19
> > CPU2: failed to boot: -19
> > CPU3: failed to boot: -19
> > smp: Brought up 1 node, 1 CPU
> > SMP: Total of 1 processors activated (500.00 BogoMIPS).
> >
> > CPU bringup/teardown in userspace using
> > /sys/devices/system/cpu/cpu*/online still works.
> > R-Car H1 was never converted to use "enable-method" in DT, and relies
> > on calling into the rcar-sysc driver directly (see [1]). However,
> > that does not use any actual calls into the genpd core, so probably it
> > can be made to work by splitting rcar_sysc_pd_init() in two parts: an
> > early_initcall() that allocates all domain structures and populates the
> > internal hierarchy, and a postcore_initcall() that registers everything
> > with the genpd core.
>
> Yes, that seems like a viable option.
... so it's just R-Car H1 that needs some code to run early.
> Unless you prefer to have a stab at it, I intend to look into it and
> make the patch(es) part of a new version of the $subject series. Of
> course I am still relying on your help with testing/review.
Sure, I will do testing and review.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 23 Jun 2025 at 17:06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, 23 Jun 2025 at 16:21, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > On Thu, 19 Jun 2025 at 13:40, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > rcar_gen4_sysc_pd_init() is an early_initcall, which I guess is the
> > > reason for these problems, as the genpd_provider_bus has not been
> > > registered that early (it's done at core_initcall)
> > >
> > > Do you think it would be possible to move rcar_gen4_sysc_pd_init() to
> > > a postcore/arch_initcall?
> >
> > I did some investigation around this and found that both
> > drivers/pmdomain/renesas/rcar-gen4-sysc.c and
> > drivers/pmdomain/renesas/rcar-sysc.c are registering their genpd
> > providers at the early_initcall() level.
> >
> > I was trying to find (by browsing renesas DTSes and looking into
> > drivers) if there is any consumers that actually relies on this, but
> > so far the earliest consumer I have found is the
> > drivers/irqchip/irq-renesas-irqc.c, but that's at postcore_initcall().
> > Of course, it's difficult to say if my analysis is complete as there
> > are a lot of platform variants and I didn't check them all.
> >
> > Maybe we should just give it a try and move both two drivers above to
> > postcore_initcall and see if it works (assuming the irq-renesas-irqc
> > supports -EPROBE_DEFER correctly too).
> >
> > If this doesn't work, I think we need to find a way to allow deferring
> > the call to device_add() in of_genpd_provider_add*() for genpd
> > provider's devices.
>
> Commit dcc09fd143bb97c2 ("soc: renesas: rcar-sysc: Add DT support for
> SYSC PM domains") explains:
>
> "Initialization is done from an early_initcall(), to make sure the PM
> Domains are initialized before secondary CPU bringup."
>
> but that matters only for arm32 systems (R-Car Gen1 and Gen2).
> Arm64 systems (R-Car Gen3 and Gen4) use PSCI for CPU PM Domain control.
[...]
> As expected, there is no impact on R-Car H3 ES2.0.
> I will test on R-Car V4M tomorrow, but expect no issues.
R-Car V4M is fine, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 23/05/2025 16:39, Ulf Hansson wrote: > Changes in v2: > - Well, quite a lot as I discovered various problems when doing > additional testing of corner-case. I suggest re-review from scratch, > even if I decided to keep some reviewed-by tags. > - Added patches to allow some drivers that needs to align or opt-out > from the new common behaviour in genpd. > > If a PM domain (genpd) is powered-on during boot, there is probably a good > reason for it. Therefore it's known to be a bad idea to allow such genpd to be > powered-off before all of its consumer devices have been probed. This series > intends to fix this problem. > > We have been discussing these issues at LKML and at various Linux-conferences > in the past. I have therefore tried to include the people I can recall being > involved, but I may have forgotten some (my apologies), feel free to loop them > in. > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes. > Let me know if you want me to share this code too. > > Please help review and test! > Finally, a big thanks to Saravana for all the support! For TI AM62A and Xilinx ZynqMP ZCU106: Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tomi
Hi Ulf, On Fri, May 23, 2025 at 03:39:57PM +0200, Ulf Hansson wrote: > Changes in v2: > - Well, quite a lot as I discovered various problems when doing > additional testing of corner-case. I suggest re-review from scratch, > even if I decided to keep some reviewed-by tags. > - Added patches to allow some drivers that needs to align or opt-out > from the new common behaviour in genpd. > > If a PM domain (genpd) is powered-on during boot, there is probably a good > reason for it. Therefore it's known to be a bad idea to allow such genpd to be > powered-off before all of its consumer devices have been probed. This series > intends to fix this problem. > > We have been discussing these issues at LKML and at various Linux-conferences > in the past. I have therefore tried to include the people I can recall being > involved, but I may have forgotten some (my apologies), feel free to loop them > in. > > I have tested this with QEMU with a bunch of local test-drivers and DT nodes. > Let me know if you want me to share this code too. > > Please help review and test! > Finally, a big thanks to Saravana for all the support! > > Kind regards > Ulf Hansson > > > Saravana Kannan (1): > driver core: Add dev_set_drv_sync_state() > > Ulf Hansson (20): > pmdomain: core: Use of_fwnode_handle() > pmdomain: core: Add a bus and a driver for genpd providers > pmdomain: core: Add the genpd->dev to the genpd provider bus > pmdomain: core: Export a common ->sync_state() helper for genpd > providers > pmdomain: core: Prepare to add the common ->sync_state() support > soc/tegra: pmc: Opt-out from genpd's common ->sync_state() support > cpuidle: psci: Opt-out from genpd's common ->sync_state() support > cpuidle: riscv-sbi: Opt-out from genpd's common ->sync_state() support > pmdomain: qcom: rpmhpd: Use of_genpd_sync_state() > pmdomain: qcom: rpmhpd: Use of_genpd_sync_state() > firmware/pmdomain: xilinx: Move ->sync_state() support to firmware > driver > firmware: xilinx: Don't share zynqmp_pm_init_finalize() > firmware: xilinx: Use of_genpd_sync_state() > driver core: Export get_dev_from_fwnode() > pmdomain: core: Add common ->sync_state() support for genpd providers > pmdomain: core: Default to use of_genpd_sync_state() for genpd > providers > pmdomain: core: Leave powered-on genpds on until late_initcall_sync > pmdomain: core: Leave powered-on genpds on until sync_state > cpuidle: psci: Drop redundant sync_state support > cpuidle: riscv-sbi: Drop redundant sync_state support > > drivers/base/core.c | 8 +- > drivers/cpuidle/cpuidle-psci-domain.c | 14 -- > drivers/cpuidle/cpuidle-riscv-sbi.c | 14 -- > drivers/firmware/xilinx/zynqmp.c | 18 +- > drivers/pmdomain/core.c | 239 ++++++++++++++++++-- > drivers/pmdomain/qcom/rpmhpd.c | 2 + > drivers/pmdomain/qcom/rpmpd.c | 2 + > drivers/pmdomain/xilinx/zynqmp-pm-domains.c | 16 -- > drivers/soc/tegra/pmc.c | 26 ++- > include/linux/device.h | 13 ++ > include/linux/firmware/xlnx-zynqmp.h | 6 - > include/linux/pm_domain.h | 17 ++ > 12 files changed, 294 insertions(+), 81 deletions(-) > > -- > 2.43.0 > Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Colibri iMX8X Best Regards, Hiago.
© 2016 - 2025 Red Hat, Inc.