On Mon, Sep 16, 2013 at 7:09 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > Put another way, I don't believe > there's any rule when writing DT bindings that states that bindings must > not describe the same pin as both a GPIO and an IRQ, although admittedly > that may be unusual. Actually I think you've won me over here. But I do not think that this shall be done at the expense of letting DT-based drivers do nasty things like setting up the same GPIO line as an IRQ (hammering the hardware to do that) and then request the same line to be an output line and drive it, for example. So the state of the GPIO line has to be tracked: if it is set as input and tied to an IRQ it should *not* be possible for the other code path to request it and set it as output. But it should be possible to set it as input again and read the value. Laurent deascribed exactly the latter usecase, which is OK. >> I agree with you that it would be the best if the only call would be >> request_irq and the chip driver programs the HW appropriately. It would be a >> dream, but unfortunately this is not possible at the moment. This is something >> that Linus pointed out very very early in this whole discussion. The gpio and >> irq frameworks don't share any information. The irq framework has no chance to >> program the HW, because it will never find the related gpio. >> For this to work the frameworks have to change (and possibly all drivers/board >> files/whatever using request_irq() and/or request_gpio()) have to change. >> That is something that I do not dare to do alone. > > This is a controller-specific issue, and has nothing to do with the GPIO > or IRQ frameworks. The driver for the combined irq/gpio_chip simply > needs to program the HW when the IRQ is requested or set up. The Tegra > driver already works this way, so there's actual proof that it is > possible to do this in practice. And how to you block the same line from being gpio_request()ed and set as output? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
