On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote: >> 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. That is true. But for such a complex usecase I think it's reasonable that we only specify the GPIO in the device tree, and the driver utilizing the IRQ need to take that and perform gpio_to_irq() on it, and then it still works to use it both ways. >> 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. That is true. It would be easier if all GPIO drivers has an irqchip and and irqdomain, then we could implement irq_to_gpio() properly in gpiolib and this would not be a problem. Alas, not all do. But I also think that the DT contains (as demonstrated by the patch) all information about what interrupts and GPIOs may conflict, so I also see this as something of a consistency check, but it could go in either way. Yours, Linus Walleij -- 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
