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. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
