On Mon, Mar 20, 2017 at 10:31:50AM +0100, Geert Uytterhoeven wrote: > Hi Simon, Shimoda-san, > > On Mon, Mar 20, 2017 at 9:28 AM, Simon Horman <horms@xxxxxxxxxxxx> wrote: > > On Thu, Mar 16, 2017 at 03:07:22PM +0100, Geert Uytterhoeven wrote: > >> 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. > > > > 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? Thanks for the extra information. With the above in mind I think its reasonable to queue-up this series for v4.12 and I have done so. If any oddities arise then we can revisit this. -- 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
