Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism

[Alexandre Courbot]

On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou
<panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Alexandre,
>
>> On Dec 4, 2014, at 16:58 , Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>
>> On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou
>> <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> Hi Alexandre,
>>>
>>>> On Dec 4, 2014, at 16:41 , Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>>>
>>>> On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou
>>>> <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>> Hi Alexandre,
>>>>>
>>>>> I tried to stay away while things are being fleshed out butâ
>>>>>
>>>>>> On Dec 4, 2014, at 16:15 , Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>>>>>
>>>>>> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard
>>>>>> <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
>>>>>>> On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote:
>>>>>>>> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>>>>>>>> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
>>>>>>>>> <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>>> The only thing I'd like to have would be that the request here would
>>>>>>>>>> be non-exclusive, so that a later driver would still be allowed later
>>>>>>>>>> on to request that GPIO later on and manage it itself (ideally using
>>>>>>>>>> the usual gpiod_request function).
>>>>>>>>>
>>>>>>>>> Actually we have a plan (and I have some code too) to allow multiple
>>>>>>>>> consumers per GPIO. Although like Benoit I wonder why you would want
>>>>>>>>> to hog a GPIO and then request it properly later. Also, that probably
>>>>>>>>> means we should abandon the hog since it actively drives the line and
>>>>>>>>> would interfere with the late requested. How to do that correctly is
>>>>>>>>> not really clear to me.
>>>>>>>>
>>>>>>>> I don't get the usecase. A hogged GPIO is per definition hogged.
>>>>>>>> This sounds more like "initial settings" or something, which is another
>>>>>>>> usecase altogether.
>>>>>>>
>>>>>>> We do have one board where we have a pin (let's say GPIO14 of the bank
>>>>>>> A) that enables a regulator that will provide VCC the bank B.
>>>>>>>
>>>>>>> Now, both banks are handled by the same driver, but in order to have a
>>>>>>> working output on the bank B, we do need to set GPIO14 as soon as
>>>>>>> we're probed.
>>>>>>>
>>>>>>> Just relying on the usual deferred probing introduces a circular
>>>>>>> dependency between the gpio-regulator that needs to grab its GPIO from
>>>>>>> a driver not there yet, and the gpio driver that needs to enable its
>>>>>>> gpio-regulator.
>>>>>>
>>>>>> I don't get it. According to what you said, the following order should
>>>>>> go through IIUC:
>>>>>>
>>>>>> 1) bank A is probed, gpio 14 is available
>>>>>> 2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available
>>>>>> 3) bank B is probed, grabs its regulator and turn it on, probes.
>>>>>>
>>>>>> What am I missing?
>>>>>>
>>>>>>>
>>>>>>> GPIO hogging needs to be the ideal solution for that, since we can
>>>>>>> just enforce the GPIO14 value as the driver is probed, which provides
>>>>>>> the guarantee that any driver using the bank B will actually drive the
>>>>>>> GPIO it might use.
>>>>>>
>>>>>> At this point I start wondering if such initial setup should not be
>>>>>> the job of the bootloader? GPIO hogging ought to be simple and
>>>>>> definitive, adding the possibility to have it just as an initial value
>>>>>> would considerably complexify it. E.g. when is the gpio chip driver
>>>>>> supposed to release the hogged descriptor in such a case?
>>>>>>
>>>>>
>>>>> Do not count on the bootloader setting up anything. The trend is
>>>>> for the bootloader to setup the minimal environment to load your kernel
>>>>> and jump to it.
>>>>>
>>>>> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/2013-ELCE-U-Boot-Falcon-Boot.pdf
>>>>
>>>> Just wondering. :)
>>>>
>>>> But yeah, there are some use-cases (such as this one or
>>>> Linux-as-a-bootloader) for which this would not play nicely.
>>>>
>>>>>
>>>>>
>>>>>> Note that if the multiple GPIO consumer feature we are planning goes
>>>>>> through, you should be able to use both hogging *and* a regulator on
>>>>>> the same GPIO and achieve what you want. The expectation of multiple
>>>>>> consumers is that the board designers know what they are doing, and
>>>>>> this case would certainly fit (chip hogs the line and doesn't touch
>>>>>> the value after that, letting the regulator control it without any
>>>>>> conflict afterwards), although it would of course be better to solve
>>>>>> the issue through regular probing...
>>>>>
>>>>>
>>>>> Thatâs why I was advocating a simple probing driver for all this.
>>>>> Figure out a way for this driver to be probed first would be an easier
>>>>> solution that whatâs going on here.
>>>>
>>>> Do you mean, a driver whose sole job is to probe other drivers in the
>>>> right order? :/
>>>
>>> $DEITY no :)
>>>
>>> I mean instead of having the gpio hog in the gpio adapter driver, have
>>> a gpio-hog driver, thatâs using an undisclosed method to make sure that
>>> itâs the first one to be probed afterwards.
>>
>> IIUC that would not solve this particular issue - here the GPIO
>> controller is both a provider and (indirect) consumer of a GPIO for
>> itself. If the hog is in a separate node, if would have to be probed
>> from inside the probe() function of the GPIO controller to do the job,
>> which would be the same effect as having the hogs directly under the
>> controller node, only with more hassle.
>>
>> Again, IIUC. >_<
>
> If you had a way to specify the order of probing that would work no?
> You donât have to do it in the gpio-controller, you can do it in the
> platform bus probe.

A probe order that works would be the following:

1) bank A is probed, gpio 14 is available
2) gpio-regulator is probed, acquires GPIO 14, regulator for Bank B is available
3) bank B is probed, grabs its regulator and turn it on, probes.

The problem is that in the present case, 1) and 3) are the same
operation because both banks are the same device.

You could probably solve this by making bank A and bank B separate
devices, then even EPROBE_DEFER would allow you to probe everything in
the right order. But since the DT bindings are (supposedly) already
published this is likely not an option (?). And logically speaking,
these banks form one device anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/