Message-ID: <5bca4eb6-6379-394f-c95e-5bbbba5308f1@ti.com>
Date:   Wed, 30 Oct 2019 15:32:09 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     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>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        <devicetree@...r.kernel.org>
Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards



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.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists