Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> writes: > On Tue, 2006-06-20 at 16:28 -0600, Eric W. Biederman wrote: >> With the msi support comes a new concept in irq handling, >> irqs that are created dynamically at run time. >> >> Currently the msi code allocates irqs backwards. First it >> allocates a platform dependent routing value for an >> interrupt the ``vector'' and then it figures out from the >> vector which irq you are on. > > You may want to look at the work I'm currently doing for powerpc where > we need a fully dynamic linux irq number allocation, completely separate > spaces for hw numbers (vectors) and linux irq numbers for arbitrary PICs > (and more than one in a given system) etc... > > I'll post a patch that shows the stuff I'm adding later today so you can > have a look. There is some overlap with your dynamic irq stuff. > > I haven't completely ported all of powerpc to my new core yet which is > why I haven't posted patches yet, but I'll have something out today. Sure. I know by the end of my patchset I have separated out hw numbers from the linux irq numbers, so this should work for powerpc. I would love to hear feedback on it though. So to be very clear what we mean, because I have gotten bitten in the past. I understand the linux irq number to be: a) An index in the irq_desc array. b) An enumeration of the hardware interrupts sources. c) Human visible so ideally it is neither arbitrary, nor very dynamic if the hardware is not. Then there is the destination cookie (vector on x86) that is available to the cpu when the interrupt is delivered. I think we are on a similar track but I'm not at all certain I like the idea of a fully dynamic linux irq number except in cases like MSI where your sources are dynamic. But I may be making the wrong assumptions about what you are doing. I think implementations where we expose the hardware cookie instead of an enumeration of irq sources like ia64 does, impedes debugging because the irq number will be different between boots, or loads of the kernel module. At the same time as long as we don't assume the irq number is the hardware cookie I don't see any maintenance problems with an implementation like that. What I do know is that on x86_64 the multiple levels of translation from the firmwares notion of the irq number to linux different notion of the irq number made the code overly complex and fragile. Which is one of the things I address in this patchset. But I would be happy to have a look, and I very much hope we can our implementations working together. Eric - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
