On 11/06/2016 11:58, Marc Zyngier wrote: > Mason wrote: > >> I think Sebastian is even more baffled by the DT mess >> (sorry, intricacies) than I am. > > This mess is what has saved us from the apocalypse 5 years ago, and > describing a complex system is not easy (what a surprise...).
The problem with some Linux APIs is that they're logical and obvious to people who've been using them for years. For newcomers, it's not always so obvious. In this specific instance, the problem statement seems rather simple, on the surface. An interrupt controller, X=0..127 lines in, Y=0..23 lines out (connected to GIC interrupt lines 0..23) and "all" we need is a way to map Xs to Ys. As a first order approximation, it's enough to map all Xs to 0. And provide a way for the kernel to check the registers containing the bit-vectors indicating which interrupt(s) fired. > If you just want to apply recipes without understanding the underlying > constraints, you're in for a lot of pain. For example, the IRQ driver for Tango3/4 calls irq_find_mapping generic_handle_irq irq_desc_get_handler_data irq_desc_get_chip chained_irq_enter/chained_irq_exit irq_setup_alt_chip irq_get_domain_generic_chip irq_domain_add_linear irq_alloc_domain_generic_chips irq_set_chained_handler irq_set_handler_data Taking irq_find_mapping, I see that there's a short comment in kernel/irq/irqdomain.c /** * irq_find_mapping() - Find a linux irq from an hw irq number. * @domain: domain owning this hardware interrupt * @hwirq: hardware irq number in that domain space */ Is this Doxygen format? Is there a make target to generate some documentation? Other relevant resources, for my own reference: https://www.kernel.org/doc/Documentation/IRQ-domain.txt https://stackoverflow.com/questions/34371352/what-are-linux-irq-domains-why-are-they-needed https://community.nxp.com/thread/332183 Are there other important kernel documentation? >> The base file he was referring to is: >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-common.dtsi > > I know which file that is, it is mentioned in the diff. I was merely > trying to point out the glaring mistakes that could be enough for a > interrupt controller hierarchy to be completely non-functional: Only the name of the file was provided, not the path. I was not aware that you already knew where to find it. I made no claim whatsoever on the implementation. In fact, I agree with everything Lennart wrote. > - Your crossbar doesn't have a #interrupt-cells property. How do you > expect the interrupt specifiers to be interpreted? Why do "fundamental" DT properties start with hash? > - You've changed the default interrupt controller to be your crossbar. > Which means that all the sub-nodes are inheriting it. Have you > checked that this was valid for all of these nodes? I'm not sure I follow. All platform interrupts flow into the platform controller. Maybe other platforms have more complex setups, with several cascaded controllers? Have a nice week end :-)