[PATCH v2 0/4] arm: renesas: Add reset control properties
Simon Horman
horms at verge.net.au
Tue Mar 21 01:20:37 PDT 2017
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 at verge.net.au> 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.
More information about the linux-arm-kernel
mailing list