Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards
To:     Philipp Zabel <p.zabel@pengutronix.de>,
        Rob Herring <robh+dt@kernel.org>
CC:     Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Mark Brown <broonie@kernel.org>, Tero Kristo <t-kristo@ti.com>,
        Maxime Ripard <mripard@kernel.org>,
        <devicetree@vger.kernel.org>
References: <20191030120440.3699-1-peter.ujfalusi@ti.com>
 <CAL_JsqK-eqoyU7RWiVXMpPZ8BfT8a0WB47756s8AUtyOqbkPXA@mail.gmail.com>
 <5bca4eb6-6379-394f-c95e-5bbbba5308f1@ti.com>
 <116e2d1eb1333c322450f20a5f591b7038586865.camel@pengutronix.de>
From:   Peter Ujfalusi <peter.ujfalusi@ti.com>
Message-ID: <9e862d4d-6661-e7ec-24ba-4e621155e145@ti.com>
Date:   Wed, 30 Oct 2019 16:03:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <116e2d1eb1333c322450f20a5f591b7038586865.camel@pengutronix.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 30/10/2019 15.51, Philipp Zabel wrote:
> 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@ti.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?

You are right, if a device needs driver to silence it when enabled (we
might not have the driver compiled) then this can be a problem.

But the same thing applies to components without enable/reset GPIO and
only needing power, no?

I would trust (I know...) on the board designers to not bundle
components of such kinds.

> 
> regards
> Philipp
> 

- Péter

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