From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: <linus.walleij@linaro.org>, <bgolaszewski@baylibre.com>
Cc: <linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<m.szyprowski@samsung.com>, <broonie@kernel.org>,
<t-kristo@ti.com>, <mripard@kernel.org>, <p.zabel@pengutronix.de>
Subject: Re: [RFC 0/2] gpio: Support for shared GPIO lines on boards
Date: Wed, 30 Oct 2019 14:03:12 +0200 [thread overview]
Message-ID: <15adbc79-a0df-5c3e-fac4-cf8a3552abfe@ti.com> (raw)
In-Reply-To: <20191030114530.872-1-peter.ujfalusi@ti.com>
Hi,
On 30/10/2019 13.45, Peter Ujfalusi wrote:
> Hi,
>
> The shared GPIO line for external components tends to be a common issue and
> there is no 'clean' way of handling it.
I have missed Rob and the DT list from the recipients list, I'll send
the RFC v2 asap.
- Péter
> I'm aware of the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag, which must be provided when
> a driver tries to request a GPIO which is already in use.
> However the driver must know that the component is going to be used in such a
> way, which can be said to any external components with GPIO line, so in theory
> all drivers must set this flag when requesting the GPIO...
>
> But with the GPIOD_FLAGS_BIT_NONEXCLUSIVE all clients have full control of the
> GPIO line. For example any device using the same GPIO as reset/enable line can
> reset/enable other devices, which is not something the other device might like
> or can handle.
> For example a device needs to be configured after it is enabled, but some other
> driver would reset it while handling the same GPIO -> the device is not
> operational anymmore as it lost it's configuration.
>
> With the gpio-shared gpiochip we can overcome this by giving the gpio-shared
> the role of making sure that the GPIO line only changes state when it will not
> disturb any of the clients sharing the same GPIO line.
>
> The 'sticky' state of the line depends on the board design, which can be
> communicated with the hold-active-state property:
>
> GPIO_ACTIVE_HIGH: the line must be high as long as any of the clients want it to
> be high
> GPIO_ACTIVE_LOW: the line must be low as long as any of the clients want it to
> be low
>
> In board DTS files it is just adding the node to descibe the shared GPIO line
> and point the users of this line to the shared-gpio node instead of the real
> GPIO.
>
> Something like this:
>
> codec_reset: gpio-shared0 {
> compatible = "gpio-shared";
> gpio-controller;
> #gpio-cells = <2>;
>
> root-gpios = <&audio_exp 0 GPIO_ACTIVE_HIGH>;
>
> branch-count = <2>;
> hold-active-state = <GPIO_ACTIVE_HIGH>;
> };
>
> &main_i2c3 {
> audio_exp: gpio@21 {
> compatible = "ti,tca6416";
> reg = <0x21>;
> gpio-controller;
> #gpio-cells = <2>;
> };
>
> pcm3168a_a: audio-codec@47 {
> compatible = "ti,pcm3168a";
> reg = <0x47>;
>
> #sound-dai-cells = <1>;
>
> rst-gpios = <&codec_reset 0 GPIO_ACTIVE_HIGH>;
> ...
> };
>
> pcm3168a_b: audio-codec@46 {
> compatible = "ti,pcm3168a";
> reg = <0x46>;
>
> #sound-dai-cells = <1>;
>
> rst-gpios = <&codec_reset 1 GPIO_ACTIVE_HIGH>;
> ...
> };
> };
>
> If any of the codec requests the GPIO to be high, the line will go up and will
> only going to be low when both of them set's their shared line to low.
>
> Note: other option would be to have something similar to gpio-hog (gpio-shared)
> support in the core itself, but then all of the logic and state handling for the
> users of the shared line needs to be moved there.
> Simply counting the low and high requests would not work as the GPIO framework
> by design does not refcounts the state, iow gpio_set(0) three times and
> gpio_set(1) would set the line high.
>
> I have also looked at the reset framework, but again it can not be applied in a
> generic way for GPIOs shared for other purposes and all existing drivers must
> be converted to use the reset framework (and adding a linux only warpper on top
> of reset GPIOs).
>
> Regards,
> Peter
> ---
> Peter Ujfalusi (2):
> dt-bindings: gpio: Add binding document for shared GPIO
> gpio: Add new driver for handling 'shared' gpio lines on boards
>
> .../devicetree/bindings/gpio/gpio-shared.yaml | 100 ++++++++
> drivers/gpio/Kconfig | 6 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-shared.c | 229 ++++++++++++++++++
> 4 files changed, 336 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-shared.yaml
> create mode 100644 drivers/gpio/gpio-shared.c
>
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2019-10-30 12:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 11:45 Peter Ujfalusi
2019-10-30 11:45 ` [RFC 1/2] dt-bindings: gpio: Add binding document for shared GPIO Peter Ujfalusi
2019-10-30 11:45 ` [RFC 2/2] gpio: Add new driver for handling 'shared' gpio lines on boards Peter Ujfalusi
2019-10-30 12:03 ` Peter Ujfalusi [this message]
2019-11-01 15:56 ` [RFC 0/2] gpio: Support for shared GPIO " Linus Walleij
2019-11-08 11:21 ` Peter Ujfalusi
2019-11-12 8:17 ` Peter Ujfalusi
2019-11-13 17:06 ` Linus Walleij
2019-11-19 8:34 ` Peter Ujfalusi
2019-11-19 15:01 ` Peter Ujfalusi
2019-11-21 14:47 ` Linus Walleij
2019-11-22 12:49 ` Peter Ujfalusi
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=15adbc79-a0df-5c3e-fac4-cf8a3552abfe@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=t-kristo@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®