On Mon, Apr 15, 2013 at 6:58 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 04/14/2013 02:53 PM, Linus Walleij wrote: >> This is a pretty hard design pattern to properly replicate in every such >> driver is it not? > > Well, instead of adding .request_irq() to the irqchip, and then making > each driver call gpio_request() from the implementation, perhaps you > could add a .irq_to_gpio() to the irqchip, have the IRQ core call that, > and if it gets back a non-error response, the IRQ core could call > gpio_request(). That means that the change to each GPIO+IRQ driver is > simply to implement a standalone data transformation function > .irq_to_gpio(). > > Now, this does re-introduce irq_to_gpio() in some way, but with the > following advantages: > > 1) The implementation is per-controller, not a single global function, > so isn't introducing any kind of centralized mapping scheme again. > > 2) This irq-chip-specific .irq_to_gpio() would only be implemented for > IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs. > Its potential existence doesn't imply that all IRQ chips need implement > this; it would be very specifically be for this one particular case. I sort of like the idea. It'd have to go past Grant and Thomas G though. A problem is that this will result in the same kind of dilemma that the pinctrl subsystem has been facing with mapping the global GPIO numbers back into local numbers (as is the nature of IRQ numbers). Such as is done by the GPIO ranges in pinctrl. The good part is that we now know how to actually contain that, even how to do it in DT. 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
