On Tue, 2010-09-21 at 16:57 -0300, Grant Likely wrote: > On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham <shaju.abra...@linaro.org> > wrote: > > Hi Grant > > > > Since there does not exist a mechanism to map the hw irq to linux irq > > on ARM (device tree), I would like to discuss with you the plans or > > ideas to implement the same.
Note that the powerpc hw -> linux IRQ mapping (virtualized irq numbering scheme) is orthogonal to the device-tree. It can be used without the device-tree and the device-tree doesn't mandate such a scheme. However, when used together, it does provide some nice features such as making most cases of cascaded controllers totally trivial. > I don't have any immediate plans, but this topic has come up a lot in > the last two weeks, so I guess I need to focus on it. :-) [cc'ing > devicetree-discuss and linux-arm-kernel as well as Lorenzo and Eric > since this is a conversation that should be had publically] > > > Can you share with me your thoughts on it? > > I have browsed through the power pc code for the same. But not sure > > the same approach is usable on ARM as well. > > I haven't thought deeply about the powerpc implementation of virqs to > determine if it is suitable for other architectures or not, but the > concept behind it is sound. We need a method of mapping controller > specific IRQ (or hw irq) numbers into the global Linux irq space > (referred to a virqs from this point on). First it requires a > per-controller reference which can be a pointer to a per-controller > data structure, or any other unique identifier. It could even be the > interrupt controller device tree node pointer. Just so long as there > is a reliable method to derive the virq from the controller reference > + hw irq number. I like keeping it somewhat orthogonal. See how I do that on powerpc. That way, you can still exploit it, map interrupts etc... even if your device-tree happens to be deficient or missing. The main grief one could have with my scheme is the naming of irq_host which has confused people in the past. It should probably be irq_domain to make clear what it is. It generally have a 1:1 relationship to the irq_chip but there are cases where that isn't the case (essentially where you have multiple irq_chip per domain) for various reasons so it's better to keep those separate. > There also needs to be a method for each interrupt controller to > register itself and allocate a portion of the virq range. This > shouldn't be too hard. PowerPC handles this with the irq_map[] flat > table. This approach is limited to whatever NR_IRQs is set to, and > could potentially be limited by that, but on the other hand the number > of discrete IRQ sources in a system is limited so a flat table > (instead of a dynamic hash table) is probably sufficient. It is > certainly simpler to implement. It's an implementation detail. We can make sure nothing accesses the table directly so we can turn it into something else if needed. > I think the first step is to simply try generalizing the code in > arch/powerpc/kernel/irq.c. It isn't very complex and it would give a > better impression of what needs to be done. The ARM interrupt > controller drivers would need to be modified to register with the virq > infrastructure. None of this is either ARM or OF specific; it would > be useful for any system than need to dynamically allocate IRQ > numbers. I could see some x86 use cases (Xilinx FPGAs) where this > would be useful. Right. Cheers Ben. _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss