mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®