lkml.org 
[lkml]   [2014]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Patch v2 1/2] gpio: add GPIO hogging mechanism
From
Date
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.

Regards

— Pantelis



\
 
 \ /
  Last update: 2014-12-04 16:41    [W:0.053 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site