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

[Alexandre Courbot <gnurou@xxxxxxxxx>]

On Fri, Dec 5, 2014 at 12:22 AM, Pantelis Antoniou
<panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Alexandre,
>
>> On Dec 4, 2014, at 17:10 , Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
>>
>> 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.
>
> 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?

Right. And actually this would work without any DT annotation, altough
it might take a few more loops to get to the right order.

But as Maxime confirmed later, his device is more like this:

/* Contains both banks A and B */
gpio: gpio {
        compatible = "foo,gpio-controller";
        bankb-supply = <&GPIO_REGULATOR>'
};

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

And here there is nothing we can do, I'm afraid, without splitting the
banks into their own nodes first.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html