Messages in this thread | | | From | Grant Likely <> | Date | Fri, 27 Jan 2012 15:13:02 -0700 | Subject | Re: [RFCv2 00/14] |
| |
On Fri, Jan 27, 2012 at 3:08 PM, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Thu, 2012-01-26 at 14:33 -0700, Grant Likely wrote: > >> I've got the x86 fix in my tree now. It will be part of the next >> merge. MIPS, Microblaze and OpenRISC cannot turn on CONFIG_IRQ_DOMAIN >> without rework. I just hacked together the microblaze version, but >> Michal will have to verify that it is correct. I just posted it. It >> will be similar for the other two. >> >> The real problem is sparc which does something entirely different for >> irqs. Rather than resolving irqs on-demand, it calculates the Linux >> irq numbers at boot time for every node in the tree. The irq_domains >> will need to be set up for all interrupt controllers before sparc >> begins it's big walk of the tree to resolve interrupts. I haven't dug >> into everything that needs to be done to support this. >> >> I don't think you can count on turning on IRQ_DOMAIN on all >> architectures just yet. Adding irq_domain support directly to >> irq_generic_chip is going to be difficult for that reason. However, >> it would be useful to have an irq_domain+irq_generic_chip wrapper that >> can be enabled only when IRQ_DOMAIN is enabled. > > Beware also that there are plenty of cases where 1 irq domain != 1 irq > chip, for example on cell or xics where a single domain can encompass > multiple chips. I don't know whether x86 APICs are the same, they could > be tho :-)
Right, there will be some controllers using multiple irq_generic_chip instances for a single irq_domain. Anything with banks of irq registers is a candidate here.
g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |