Hi Linus, On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote: > On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely wrote: > > On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij wrote: > >> To solve this dilemma, perform an interrupt consistency check > >> when adding a GPIO chip: if the chip is both gpio-controller and > >> interrupt-controller, walk all children of the device tree, > >> check if these in turn reference the interrupt-controller, and > >> if they do, loop over the interrupts used by that child and > >> perform gpio_reques() and gpio_direction_input() on these, > >> making them unreachable from the GPIO side. > > > > Ugh, that's pretty awful, and it doesn't actually solve the root > > problem of the GPIO and IRQ subsystems not cooperating. It's also a > > very DT-centric solution even though we're going to see the exact same > > issue on ACPI machines. > > The problem is that the patches for OMAP that I applied and now have had to > revert solves it in an even uglier way, leading to breaking boards, as was > noticed. > > The approach in this patch has the potential to actually work without > regressing a bunch of boards... > > Whether this is a problem in ACPI or not remains to be seen, but I'm not > sure about that. Device trees allows for a GPIO line to be used as an > interrupt source and GPIO line orthogonally, and that is the root of this > problem. Does ACPI have the same problem, or does it impose natural > restrictions on such use cases? > > > We have to solve the problem in a better way than that. Rearranging > > your patch description, here are some of the points you brought up so > > I can comment on them... > > > >> This has the following undesired effects: > >> > >> - The GPIOlib subsystem is not aware that the line is in use > >> and willingly lets some other consumer perform gpio_request() > >> on it, leading to a complex resource conflict if it occurs. > > > > If a gpio line is being both requested as a gpio and used as an > > interrupt line, then either a) it's a bug, or b) the gpio line needs > > to be used as input only so it is compatible with irq usage. b) should > > be supportable. > > Yes this is what I'm saying too I think... > > The bug in (a) manifested itself in the OMAP patch with no real solution in > sight. > > >> - The GPIO debugfs file claims this GPIO line is "free". > > > > Surely we can fix this. I still don't see a problem of having the > > controller request the gpio when it is claimed as an irq if we can get > > around the problem of another user performing a /valid/ request on the > > same GPIO line. The solution may be to have a special form of request > > or flag that allows it to be shared. > > I don't see how sharing works here, or how another user, i.e. another one > than the user wanting to recieve the IRQ, can validly request such a line? > What would the usecase for that valid request be? When the GPIO is wired to a status signal (such as an MMC card detect signal) the driver might want to read the state of the signal independently of the interrupt handler. > Basically I believe these two things need to be exclusive in the DT world: > > A: request_irq(a resource passed from "interrupts"); > -> core implicitly performs gpio_request() > gpio_direction_input() > > B: gpio_request(a resource passed from "gpios"); > gpio_direction_input() > request_irq(gpio_to_irq()) > > Never both. And IIUC that was what happened in the OMAP case. Isn't the core issue that we can translate a GPIO number to an IRQ number, but not the other way around ? If that could be done, we could request the GPIO and configure it as an input when the IRQ is requested. > >> - The line direction of the interrupt GPIO line is not > >> > >> explicitly set as input, even though it is obvious that such > >> a line need to be set up in this way, often making the system > >> depend on boot-on defaults for this kind of settings. > > > > Should also be solvable if the gpio request problem is solved. > > Agreed... -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
