Re: [PATCH v2 0/4] arm: renesas: Add reset control properties

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 [off-list ref] wrote:

quoted

On Thu, Mar 16, 2017 at 03:07:22PM +0100, Geert Uytterhoeven wrote:

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html