Hi Simon, Magnus, Laurent, Morimoto-san,
This patch series describes the reset control topology for on-SoC devices
connected to the Renesas Clock Pulse Generator / Module Standby and
Software Reset module on the R-Car H3 and M3-W, RZ/G1M, and RZ/G1E SoCs.
Resets usually match the corresponding module clocks. Exceptions are:
- The Display Unit has only 2 resets, one per channel pair, cfr.
"[PATCH v2] dt-bindings: drm: rcar-du: Document optional reset
properties" (http://www.spinics.net/lists/dri-devel/msg134637.html),
- The audio module has resets for the Serial Sound Interfaces only.
Adding resets and reset-names properties depends on a DT binding
update for renesas,rsnd (note: the DT binding documentation in
Documentation/devicetree/bindings/sound/renesas,rsnd.txt doesn't
even document clocks and clock-names?).
Upon request from Laurent for the DU, and upon a DT bindings update
for rcar_sound, the addition of resets (and reset-names) properties for
these complex modules is postponed.
Note that this patch series contains hardware description only.
Actual reset policy is to be defined and implemented separately.
Also, this is an optional feature, to be enabled explicitly using
CONFIG_RESET_CONTROLLER=y. When enabled, an on-SoC device can be reset
easily using device_reset(), or by using the reset_control_*() API when
more fine-grained control is desired.
Possible use cases are (not exhaustive):
- Reset a device before use, to make sure it's in a predefined state, and
doesn't depend on earlier configuration by e.g. the boot loader,
- Reset a device after detecting an anomaly,
- Reset a device to verify suspend/resume is handled correctly by the
driver in case the device would be part of a power domain on a
different/future SoC.
Dependencies and impact:
- The corresponding driver changes to the CGP/MSSR driver are already
present in v4.11-rc1.
- These patches have no impact as long as CONFIG_RESET_CONTROLLER=n.
However, if CONFIG_RESET_CONTROLLER=y and resets properties are
prsesent in DTS, the EHCI and OHCI drivers already deassert reset as
part of their initialization sequences, and put the devices back
into reset state in case initialization failed, or on unbind.
I'm not aware of other relevant drivers already using reset control.
For testing, these patches are also available in the
topic/renesas-cpg-mssr-reset-dts-v2 branch of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
This has been tested on the R-Car Gen3 Salvator-X (H3 and M3-W) and the
R-Car M2-W (using out-of-tree driver modifications) Koelsch development
boards, by inspecting device register contents before and after reset,
and by comparing them with their documented reset values.
Changes compared to v1:
- Break out from "[PATCH 0/8] Renesas CPG/MSSR Reset Control Support"
(https://lkml.org/lkml/2017/1/20/336),
- Postpone adding resets and reset-names properties for complex
devices (du, rcar_sound),
- Rebase on top of renesas-devel-20170313-v4.11-rc2,
- Add reset properties to recently added device nodes.
Thanks for applying!
Geert Uytterhoeven (4):
arm64: dts: r8a7795: Add reset control properties
arm64: dts: r8a7796: Add reset control properties
ARM: dts: r8a7743: Add reset control properties
ARM: dts: r8a7745: Add reset control properties
arch/arm/boot/dts/r8a7743.dtsi | 24 +++++++++
arch/arm/boot/dts/r8a7745.dtsi | 24 +++++++++
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 93 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 46 ++++++++++++++++
4 files changed, 187 insertions(+)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
