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 ...
|