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