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

Pantelis Antoniou
2014-12-04T15:22:58Z

Hi Alexandre,

> On Dec 4, 2014, at 17:10 , Alexandre Courbot <gnurou@gmail.com> wrote:
>
> On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou
> <panto@antoniou-consulting.com> wrote:
>> Hi Alexandre,
>>
>>> On Dec 4, 2014, at 16:58 , Alexandre Courbot <gnurou@gmail.com> wrote:
>>>
>>> On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou
>>> <panto@antoniou-consulting.com> wrote:
>>>> Hi Alexandre,
>>>>
>>>>> On Dec 4, 2014, at 16:41 , Alexandre Courbot <gnurou@gmail.com> wrote:
>>>>>
>>>>> On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou
>>>>> <panto@antoniou-consulting.com> 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@gmail.com> wrote:
>>>>>>>
>>>>>>> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard
>>>>>>> <maxime.ripard@free-electrons.com> 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@gmail.com> wrote:
>>>>>>>>>> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
>>>>>>>>>> <maxime.ripard@free-electrons.com> 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.

Let’s put that in a pseudo DT definition.

BANK_A: bank_a {
compatible = “banka,gpio-controller”;
};

GPIO_REGULATOR: gpio-regulator {
compatible = “gpio-regulator”;
gpio = <&BANK_A 14>;
};

BANK_B: bank_b {
compatible = “bankb,gpio-controller”;
power-supply = <&GPIO_REGULATOR>;
};

The correct probe order is bank_a, gpio-regulator, bank_b correct?

It is possible to modify DTC to follow phandle references and spit out
a depends node that the platform bus probe can use.

For instance,

__depends__ {
gpio-regulator = <&BANK_A>;
bank_b = <&GPIO_REGULATOR>;
};

Would that work for your case?

Regards

— Pantelis