On Mon, Apr 17, 2017 at 09:29:37PM +0200, Hauke Mehrtens wrote:
> From: Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx>
>
> The reset controllers (on xRX200 and newer SoCs have two of them) are
> provided by the RCU module. This was initially implemented as a simple
> reset controller. However, the RCU module provides more functionality
> (ethernet GPHYs, USB PHY, etc.), which makes it a MFD device.
> The old reset controller driver implementation from
> arch/mips/lantiq/xway/reset.c did not honor this fact.
>
> For some devices the request and the status bits are different.
>
> Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx>
> ---
> .../devicetree/bindings/reset/lantiq,rcu-reset.txt | 43 ++++
> arch/mips/lantiq/xway/reset.c | 68 ------
> drivers/reset/Kconfig | 6 +
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-lantiq-rcu.c | 231 +++++++++++++++++++++
> 5 files changed, 281 insertions(+), 68 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
> create mode 100644 drivers/reset/reset-lantiq-rcu.c
>
> diff --git a/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
> new file mode 100644
> index 000000000000..7f097d16bbb7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
> @@ -0,0 +1,43 @@
> +Lantiq XWAY SoC RCU reset controller binding
> +============================================
> +
> +This binding describes a reset-controller found on the RCU module on Lantiq
> +XWAY SoCs.
> +
> +
> +-------------------------------------------------------------------------------
> +Required properties (controller (parent) node):
> +- compatible : Should be "lantiq,rcu-reset"
> +- lantiq,rcu-syscon : A phandle to the RCU syscon, the reset register
> + offset and the status register offset.
> +- #reset-cells : Specifies the number of cells needed to encode the
> + reset line, should be 1.
> +
> +Optional properties:
> +- reset-status : The request status bit. For some bits the request bit
> + and the status bit are different. This is depending
> + on the SoC. If the reset-status bit does not match
> + the reset-request bit, put the reset number into the
> + reset-request property and the status bit at the same
> + index into the reset-status property. If no
> + reset-request bit is given here, the driver assume
> + status and request bit are the same.
> +- reset-request : The reset request bit, to map it to the reset-status
> + bit.
These should either be implied by SoC specific compatible or be made
part of the reset cells. In the latter case, you still need the SoC
specific compatible.
> +-------------------------------------------------------------------------------
> +Example for the reset-controllers on the xRX200 SoCs:
> + rcu_reset0: rcu_reset {
> + compatible = "lantiq,rcu-reset";
> + lantiq,rcu-syscon = <&rcu0 0x10 0x14>;
> + #reset-cells = <1>;
> + reset-request = <31>, <29>, <21>, <19>, <16>, <12>;
> + reset-status = <30>, <28>, <16>, <25>, <5>, <24>;
> + };
> +
> + rcu_reset1: rcu_reset {
> + compatible = "lantiq,rcu-reset";
These 2 blocks are identical? Given different registers sizes, I'd say
not. So they should have different compatible strings.
> + lantiq,rcu-syscon = <&rcu0 0x48 0x24>;
> + #reset-cells = <1>;
> + };
--
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
