[PATCH v2] pinctrl: queue GPIO operations instead of defering

[Stephen Warren]

On 08/21/2013 05:07 PM, Linus Walleij wrote:
> On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 08/17/2013 08:56 AM, Linus Walleij wrote:
> 
>>> and the pin controller need the GPIO driver to be ready.
>>
>> Why does that happen?
> 
> The pin controller call back into the GPIO-side controller
> functions by utilizing the GPIO ranges.
> (Maybe the code is silly, I dunno, check drivers/pinctrl/pinctrl-nomadik.c)
> 
>>> This also happens if
>>> pin controllers and GPIO controllers compiled as modules
>>> are inserted in a certain order.
>>
>> Shouldn't deferred probe resolve that just fine, assuming there are no
>> circular dependencies?
> 
> The above leads to circular dependencies so that is what I'm
> trying to fix with this.

But the circular dependencies are imposed by a specific driver, not by
the GPIO and pinctrl subsystems.

gpiolib operations call into pinctrl to acquire pin ownership. Hence, no
pinctrl operation (or implementation in a driver) can call into gpiolib,
or a GPIO driver.

Shouldn't this simply be fixed inside whichever driver is performing
circular operations, rather than leaving the driver performing circular
operations, and attemping to make the subsystems support something that
can't be supported?

>>> On the Nomadik we get this situation with the pinctrl
>>> driver when moving to requesting GPIOs off the gpiochip
>>> right after it has been added,
>>
>> So, the pinctrl driver calls gpio_request()? Surely the solution is
>> simply not to do that?
> 
> This is what the other patch we're discussing is doing.
> The one that harvests and requests interrupt GPIO's when
> a gpiochip is added...

It would have been good to mention the two patches were related, or did
I just miss that?

So that's another reason for me to object to that other patch. If that
whole process was triggered inside the IRQ controller implementation,
which is logically part of the GPIO controller implementation for the
same HW, the call direction would also be GPIO -> pinctrl or IRQ -> GPIO
-> pinctrl, and hence have no circular issues.