| 303010f4 | 09-Sep-2025 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: renesas: rmobile-sysc: Don't keep unused PM domains powered-on
The recent changes to genpd makes a genpd OF provider that is powered-on at
initialization to stay powered-on, until the ->sy
pmdomain: renesas: rmobile-sysc: Don't keep unused PM domains powered-on
The recent changes to genpd makes a genpd OF provider that is powered-on at
initialization to stay powered-on, until the ->sync_state() callback is
invoked for it.
This may not happen at all, if we wait for a consumer device to be probed,
leading to wasting energy. There are ways to enforce the ->sync_state()
callback to be invoked, through sysfs or via the probe-defer-timeout, but
none of them in its current form are a good fit for rmobile-sysc PM
domains.
Let's therefore opt-out from this behaviour of genpd for now, by using the
GENPD_FLAG_NO_STAY_ON.
Link: https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state")
Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| d929e42d | 09-Sep-2025 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: renesas: rcar-gen4-sysc: Don't keep unused PM domains powered-on
The recent changes to genpd makes a genpd OF provider that is powered-on at
initialization to stay powered-on, until the ->
pmdomain: renesas: rcar-gen4-sysc: Don't keep unused PM domains powered-on
The recent changes to genpd makes a genpd OF provider that is powered-on at
initialization to stay powered-on, until the ->sync_state() callback is
invoked for it.
This may not happen at all, if we wait for a consumer device to be probed,
leading to wasting energy. There are ways to enforce the ->sync_state()
callback to be invoked, through sysfs or via the probe-defer-timeout, but
none of them in its current form are a good fit for rcar-gen4-sysc PM
domains.
Let's therefore opt-out from this behaviour of genpd for now, by using the
GENPD_FLAG_NO_STAY_ON.
Link: https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state")
Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| 36bbaec4 | 09-Sep-2025 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: renesas: rcar-sysc: Don't keep unused PM domains powered-on
The recent changes to genpd makes a genpd OF provider that is powered-on at
initialization to stay powered-on, until the ->sync_
pmdomain: renesas: rcar-sysc: Don't keep unused PM domains powered-on
The recent changes to genpd makes a genpd OF provider that is powered-on at
initialization to stay powered-on, until the ->sync_state() callback is
invoked for it.
This may not happen at all, if we wait for a consumer device to be probed,
leading to wasting energy. There are ways to enforce the ->sync_state()
callback to be invoked, through sysfs or via the probe-defer-timeout, but
none of them in its current form are a good fit for rcar-sysc PM domains.
Let's therefore opt-out from this behaviour of genpd for now, by using the
GENPD_FLAG_NO_STAY_ON.
Link: https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state")
Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| b27e9842 | 01-Jul-2025 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: renesas: rcar-gen4-sysc: Move init to postcore_initcall
Subsequent changes to genpd adds a limitation that registering a genpd OF
providers must be done after its bus registration, which i
pmdomain: renesas: rcar-gen4-sysc: Move init to postcore_initcall
Subsequent changes to genpd adds a limitation that registering a genpd OF
providers must be done after its bus registration, which is at
core_initcall. To adopt to this, let's move to a postcore_initcall.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20250701114733.636510-4-ulf.hansson@linaro.org
show more ...
|
| 7b2b9aee | 01-Jul-2025 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: renesas: rmobile-sysc: Move init to postcore_initcall
Subsequent changes to genpd adds a limitation that registering a genpd OF
providers must be done after its bus registration, which is
pmdomain: renesas: rmobile-sysc: Move init to postcore_initcall
Subsequent changes to genpd adds a limitation that registering a genpd OF
providers must be done after its bus registration, which is at
core_initcall. To adopt to this, let's move to a postcore_initcall.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20250701114733.636510-3-ulf.hansson@linaro.org
show more ...
|
| c5ae5a0c | 01-Jul-2025 |
Ulf Hansson <ulf.hansson@linaro.org> |
pmdomain: renesas: rcar-sysc: Add genpd OF provider at postcore_initcall
Subsequent changes to genpd adds a limitation that registering a genpd OF
providers must be done after its bus registration,
pmdomain: renesas: rcar-sysc: Add genpd OF provider at postcore_initcall
Subsequent changes to genpd adds a limitation that registering a genpd OF
providers must be done after its bus registration, which is at
core_initcall.
To adopt to this, let's split the initialization into two steps. The first
part keep registering the PM domains with genpd at early_initcall, as this
is needed to bringup the CPUs for R-Car H1, by calling
rcar_sysc_power_up_cpu(). The second and new part, moves the registration
of the genpd OF provider to a postcore_initcall().
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20250701114733.636510-2-ulf.hansson@linaro.org
show more ...
|
| a4abebf3 | 03-Jul-2025 |
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> |
pmdomain: renesas: sort Renesas Kconfig configs
Renesas Kconfig is using "SoC chip number" for CONFIG symbol, but is
using "SoC chip name" for menu description. Because of it, it looks
random order
pmdomain: renesas: sort Renesas Kconfig configs
Renesas Kconfig is using "SoC chip number" for CONFIG symbol, but is
using "SoC chip name" for menu description. Because of it, it looks
random order when we run "make menuconfig".
commit 6d5aded8d57f ("soc: renesas: Sort driver description title")
sorted Renesas Kconfig by "menu description title order" (= SoC chip
name), but it makes confusable to add new config, because developer
usually checks CONFIG symbols (= SoC chip number).
Let's indicate both "SoC chip number" and "SoC chip name" in description
and sort it again.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/87ikkacacf.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| fdea114a | 17-Apr-2024 |
Geert Uytterhoeven <geert+renesas@glider.be> |
pmdomain: renesas: rcar-sysc: Add R-Car M3-W power-off delay quirk
R-Car M3-W needs a delay of 1 µs before powering off the A3IR and A3VC
power domains. Add support for this using a new flag, which
pmdomain: renesas: rcar-sysc: Add R-Car M3-W power-off delay quirk
R-Car M3-W needs a delay of 1 µs before powering off the A3IR and A3VC
power domains. Add support for this using a new flag, which indicates
that a power area is subject to this quirk.
Inspired by a patch in the BSP by Dien Pham.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/ecbc3465c598084c904dd3714e2894463094ed9a.1713348705.git.geert+renesas@glider.be
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| c8d87704 | 17-Apr-2024 |
Geert Uytterhoeven <geert+renesas@glider.be> |
pmdomain: renesas: rcar-sysc: Remove rcar_sysc_nullify() helper
There are no more users left of the rcar_sysc_nullify() helper, so it
can be removed.
Signed-off-by: Geert Uytterhoeven <geert+renesa
pmdomain: renesas: rcar-sysc: Remove rcar_sysc_nullify() helper
There are no more users left of the rcar_sysc_nullify() helper, so it
can be removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/ad61b09283cc8a9cf93a5ea9fffd1cb283b9db92.1713348705.git.geert+renesas@glider.be
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| 43fefaea | 17-Apr-2024 |
Geert Uytterhoeven <geert+renesas@glider.be> |
pmdomain: renesas: rcar-sysc: Split R-Car M3-W and M3-W+ sub-drivers
Currently R-Car M3-W and M3-W+ are handled by a single sub-driver,
but using separate Kconfig symbols and separate rcar_sysc_info
pmdomain: renesas: rcar-sysc: Split R-Car M3-W and M3-W+ sub-drivers
Currently R-Car M3-W and M3-W+ are handled by a single sub-driver,
but using separate Kconfig symbols and separate rcar_sysc_info
structures, and fixup code to handle the remaining differences.
Prepare for handling more differences by splitting them in two separate
sub-drivers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/a416e2bae7227c08d7e7d158366ab021f4d6cc18.1713348705.git.geert+renesas@glider.be
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| ccabbb67 | 01-Mar-2024 |
Geert Uytterhoeven <geert+renesas@glider.be> |
pmdomain: renesas: rcar-gen4-sysc: Reduce atomic delays
The delays used with the various atomic polling loops are already at the
maximum value of ~10µs, as documented for read_poll_timeout_atomic().
pmdomain: renesas: rcar-gen4-sysc: Reduce atomic delays
The delays used with the various atomic polling loops are already at the
maximum value of ~10µs, as documented for read_poll_timeout_atomic().
Hence reduce the delays from 10 to 1 µs. Increase PDRESR_RETRIES
accordingly, to retain the old (generous) timeout value.
Measurements on R-Car V3U, S4, V4H, and V4M show that the first three
polling loops rarely (never?) loop, so the actual delay does not matter.
The fourth loop (for SYSCISCR in rcar_gen4_sysc_power()) typically ran
for one or two cycles with the old delay. With the reduced delay, it
typically runs for two to 17 cycles, and finishes earlier than before,
which can reduce loop time up to a factor of three.
While at it, rename the SYSCISR_{TIMEOUT,DELAY_US} definitions to
SYSCISCR_{TIMEOUT,DELAY_US}, to match the register name they apply to.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/77f150522096d55c6da0ff983db61e0cf6309344.1709317289.git.geert+renesas@glider.be
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
| 71324087 | 13-Feb-2024 |
Dien Pham <dien.pham.ry@renesas.com> |
pmdomain: renesas: Adjust the waiting time to cover the worst case
Description in HWM rev0.51E, 9.4 Usage notes, page 455 tells
"It takes several hundreds of microseconds to shutting off and
res
pmdomain: renesas: Adjust the waiting time to cover the worst case
Description in HWM rev0.51E, 9.4 Usage notes, page 455 tells
"It takes several hundreds of microseconds to shutting off and
resuming power domain. Because actual time required for
shutting off and resuming depends on the status of on-board
power line, shutoff/resume time is not guaranteed by
electrical specification"
Let's assume the safe value of waiting is about 1000us.
Signed-off-by: Dien Pham <dien.pham.ry@renesas.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Tho Vu <tho.vu.wh@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/8734tx8b18.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|