Message-Id: <0EF6A712-5FF1-41BE-B8A9-21ABE7FE37F9@antoniou-consulting.com>
Date:	Thu, 4 Dec 2014 16:27:00 +0200
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Benoit Parrot <bparrot@...com>,
	Jiri Prchal <jiri.prchal@...ignal.cz>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism

Hi Alexandre,

I tried to stay away while things are being fleshed out but…

> On Dec 4, 2014, at 16:15 , Alexandre Courbot <gnurou@...il.com> wrote:
> 
> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard
> <maxime.ripard@...e-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@...il.com> wrote:
>>>> On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
>>>> <maxime.ripard@...e-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


> 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.

Regards

— Pantelis


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists