From: Rob Herring <robh@kernel.org>
To: Sean Anderson <sean.anderson@seco.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: reset: Add generic GPIO reset binding
Date: Tue, 26 Oct 2021 21:27:21 -0500 [thread overview]
Message-ID: <YXi5CUCEi7YmNxXM@robh.at.kernel.org> (raw)
In-Reply-To: <20211018234923.1769028-1-sean.anderson@seco.com>
On Mon, Oct 18, 2021 at 07:49:21PM -0400, Sean Anderson wrote:
> This adds a binding for a generic GPIO reset driver. This driver is
> designed to easily add a GPIO-based reset to a driver which expected a
> reset controller. It offers greater flexibility than a reset-gpios
> property, and allows for one code path to be shared for GPIO resets and
> MMIO-based resets.
I would like to do this last part, but not requiring a binding change.
IOW, be able to register any 'reset-gpios' property as a reset provider
directly without this added level of indirection.
>
> Signed-off-by: Sean Anderson <sean.anderson@seco.com>
> ---
>
> .../devicetree/bindings/reset/gpio-reset.yaml | 93 +++++++++++++++++++
> 1 file changed, 93 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.yaml
>
> diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.yaml b/Documentation/devicetree/bindings/reset/gpio-reset.yaml
> new file mode 100644
> index 000000000000..de2ab074cea3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/gpio-reset.yaml
> @@ -0,0 +1,93 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
GPL-2.0-only not GPL-2.0+
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/gpio-reset.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic GPIO reset driver
> +
> +maintainers:
> + - Sean Anderson <seanga2@gmail.com>
> +
> +description: |
> + This is a generic GPIO reset driver which can provide a reset-controller
> + interface for GPIO-based reset lines. This driver always operates with
> + logical GPIO values; to invert the polarity, specify GPIO_ACTIVE_LOW in the
> + GPIO's flags.
> +
> +properties:
> + compatible:
> + const: gpio-reset
> +
> + '#reset-cells':
> + const: 1
> +
> + reset-gpios:
> + description: |
> + GPIOs to assert when asserting a reset. There is a one-to-one mapping
> + between the reset specifier and the index of the GPIO in this list to
> + assert.
> +
> + done-gpios:
> + description: |
> + GPIOs which indicate that the device controlled by the GPIO has exited
> + reset. There must be one done GPIO for each reset GPIO, or no done GPIOs
> + at all. The driver will wait for up to done-timeout-us for the
> + corresponding done GPIO to assert before returning.
This is odd. Do you have some examples of h/w needing this done signal?
It certainly doesn't seem like something we have a generic need for.
> +
> + pre-assert-us:
> + default: 0
> + description: |
> + Microseconds to delay between when the reset was requested to be
> + asserted, and asserting the reset GPIO
> +
> + post-assert-us:
> + default: 0
> + description: |
> + Microseconds to delay after asserting the reset GPIO and before returning
> + to the caller.
> +
> + pre-deassert-us:
> + default: 0
> + description: |
> + Microseconds to delay between when the reset was requested to be
> + deasserted, and asserting the reset GPIO
> +
> + post-deassert-us:
> + default: 0
> + description: |
> + Microseconds to delay after deasserting the reset GPIO and before
> + returning to the caller. This delay is always present, even if the done
> + GPIO goes high earlier.
> +
> + done-timeout-us:
> + default: 1000
> + description:
> + Microseconds to wait for the done GPIO to assert after deasserting the
> + reset GPIO. If post-deassert-us is present, this property defaults to 10
> + times that delay. The timeout starts after waiting for the post deassert
> + delay.
There's a reason we don't have all these timing values in DT. The timing
requirements are defined by each device (being reset) and implied by
their compatible strings. If we wanted a macro language for power
sequence timings of regulators, clocks, resets, enables, etc., then we
would have designed such a thing already.
> +
> +required:
> + - '#reset-cells'
> + - compatible
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + pcs_reset: reset-pcs {
> + #reset-cells = <1>;
> + compatible = "gpio-reset";
> + reset-gpios = <&gpio 0 GPIO_ACTIVE_LOW>,
> + <&gpio 1 GPIO_ACTIVE_LOW>,
> + <&gpio 2 GPIO_ACTIVE_LOW>,
> + <&gpio 3 GPIO_ACTIVE_LOW>;
> + done-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>,
> + <&gpio 5 GPIO_ACTIVE_HIGH>,
> + <&gpio 6 GPIO_ACTIVE_HIGH>,
> + <&gpio 7 GPIO_ACTIVE_HIGH>;
> + post-deassert-us = <100>;
> + };
> --
> 2.25.1
>
>
next prev parent reply other threads:[~2021-10-27 2:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 23:49 [PATCH 1/2] dt-bindings: reset: Add generic GPIO reset binding Sean Anderson
2021-10-18 23:49 ` [PATCH 2/2] reset: Add GPIO-based reset controller Sean Anderson
2021-10-25 18:17 ` Sean Anderson
2021-11-02 11:26 ` Philipp Zabel
2021-10-27 2:27 ` Rob Herring [this message]
2021-10-28 15:19 ` [PATCH 1/2] dt-bindings: reset: Add generic GPIO reset binding Sean Anderson
2021-10-28 15:26 ` Sean Anderson
2021-10-29 1:35 ` Rob Herring
2021-11-01 16:24 ` Sean Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YXi5CUCEi7YmNxXM@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=sean.anderson@seco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.