[PATCH v2] pinctrl: queue GPIO operations instead of defering
From: Stephen Warren <hidden>
Date: 2013-08-21 23:23:42
Also in:
lkml
On 08/21/2013 05:07 PM, Linus Walleij wrote:
On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren [off-list ref] wrote:quoted
On 08/17/2013 08:56 AM, Linus Walleij wrote:quoted
quoted
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)quoted
quoted
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?
quoted
quoted
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.