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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html