Am 12.05.2017 um 11:51 schrieb Linus Walleij: > On Fri, May 12, 2017 at 8:08 AM, Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: > >> Following Jerome's suggestion I prepared a version making the irq multiplexer >> an own device. Nice here is that with this approach basically only one line of >> code needs to be changed in the existing pinctrl driver. >> >> As discussion basis I add it here w/o submitting a v2 of patch 5. > > I think this is the right way to go, but would ideally like some feedback from > the irqchip maintainers. > > Have you looked at drivers/irqchip/irq-crossbar.c for inspiration? > Also read > Documentation/devicetree/bindings/arm/omap/crossbar.txt > > It uses an hierarchical domain for a similar cross-connection > usecase. > When looking at the crassbar driver it seems to be quite similar to Jerome's Meson GPIO IRQ driver version. Therefore I think we'd face the same challenges. What is special about the Meson GPIO IRQ hw: - We have only 8 parent IRQs for 100+ GPIO's. - If a GPIO requests IRQ_TYPE_EDGE_BOTH (concrete example: mmc sd detection) then we have to use two parent IRQs, one for each edge. - We must be able to dynamically map a GPIO to a parent IRQ, e.g. if a driver uses gpiod_to_irq(). These specifics are the reason why I do the mapping magic in the irq_set_type callback of the irq_chip. Only in this callback I have all the info needed to do the mapping. > Under any circumstances I think decoupling the IRQ multiplexer > and dealing with it in separate is easier for maintainance and > also for the irq maintainers to review. > Then I'll submit the latest version with the separated device as v2 and we'll see which further review comments and suggestions for alternative approaches come in. Rgds, Heiner > 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