On Thu, Dec 4, 2014 at 11:52 PM, Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote: > Hi again, > > It looks like I missed some part of it. > > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote: >> > 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? > > Relying on the bootloader for such trivial (and critical) things may > not work at all. You don't always have the option to replace it, > either because you physically can't, or just because you don't have > any alternative. > > I agree that in general this is something that should go in the > bootloader, but we should have a way to deal with the case where it's > not done. > >> 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... > > If such an effort is on-going, then I'm totally fine waiting for it > and leaving that outside the hogging mechanism. As long as it works, > I'm happy. Ok. I just want to wait until the next -rc1 to make sure that the large GPIO array removal patch (on which the multiple consumers feature depend) did not break anything important, then I will submit it. -- 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
