Message-ID: <116e2d1eb1333c322450f20a5f591b7038586865.camel@pengutronix.de>
Date:   Wed, 30 Oct 2019 14:51:35 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Peter Ujfalusi <peter.ujfalusi@...com>,
        Rob Herring <robh+dt@...nel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Mark Brown <broonie@...nel.org>, Tero Kristo <t-kristo@...com>,
        Maxime Ripard <mripard@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards

On Wed, 2019-10-30 at 15:32 +0200, Peter Ujfalusi wrote:
> 
> On 30/10/2019 15.12, Rob Herring wrote:
> > On Wed, Oct 30, 2019 at 7:03 AM Peter Ujfalusi <peter.ujfalusi@...com> 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'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.
> > 
> > Why can't we just add a shared flag like we have for interrupts?
> > Effectively, we have that for resets too, it's just hardcoded in the
> > the drivers.
> 
> This would be kind of the same thing what the
> GPIOD_FLAGS_BIT_NONEXCLUSIVE does, which was a quick workaround for
> fixed-regulators afaik.
> 
> But let's say that a board design will pick two components (C1 and C2)
> and use the same GPIO line to enable them. We already have the drivers
> for them and they are used in boards already.
> 
> Both needs the GPIO line to be high for normal operation.
> One or both of them needs register writes after they are enabled.
> 
> During boot both requests the GPIO (OUTPUT_LOW) and sets it high, then
> run the register setup.
> 
> C1 request GPIO (LOW)
> C1 gpio_set(1)
> C1 register writes
> C2 requests GPIO (LOW)
>  C1 placed to reset and looses the configuration
> C2 gpio_set(1)
>  C1 also enabled
> C2 register writes
> 
> At this point C2 is operational, C1 is not.
> 
> In shared GPIO case the GPIO should be handled like a regulator with a
> twist that the 'sticky' state of the GPIO might be low or high depending
> on the needs of the components it is connected to.
> 
> The shared GPIO line is a board design quirk and basically any device
> which have reset/enable GPIO must be able to work in a situation when
> they are sharing that line with other components and the driver should
> not know much about this small detail.

What about components that require a register write right after being
enabled, for example to put the device into a low power state, to
silence it on a bus, or to mask some initially enabled interrupts?

regards
Philipp

Powered by blists - more mailing lists