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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
