arm: renesas: Add reset control properties

Hi Simon, Shimoda-san,

Quoted 43 lines · Simon Horman

Quoted 34 lines · Geert Uytterhoeven

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

Quoted 7 lines

    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.

Quoted 3 lines

It appears that for arm64 defconfig CONFIG_RESET_CONTROLLER=y is true so by default there will be a behavioural change on arm64. I'd like to understand if it is a desirable (or at least not undesirable) change.

V1 of this patch series has been part of renesas-drivers since renesas-drivers-2017-01-24-v4.10-rc5, so I'd hope any negative impact would have been discovered by now.

Shimoda-san: Have you noticed any oddities w.r.t. USB?