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. Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
