Thread (30 messages) 30 messages, 6 authors, 2012-01-29

Re: [RFCv2 00/14]

From: Grant Likely <hidden>
Date: 2012-01-27 22:13:23
Also in: linux-devicetree, lkml

On Fri, Jan 27, 2012 at 3:08 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
On Thu, 2012-01-26 at 14:33 -0700, Grant Likely wrote:
quoted
I've got the x86 fix in my tree now. =A0It will be part of the next
merge. =A0MIPS, Microblaze and OpenRISC cannot turn on CONFIG_IRQ_DOMAIN
without rework. =A0I just hacked together the microblaze version, but
Michal will have to verify that it is correct. =A0I just posted it. =A0I=
t
quoted
will be similar for the other two.

The real problem is sparc which does something entirely different for
irqs. =A0Rather than resolving irqs on-demand, it calculates the Linux
irq numbers at boot time for every node in the tree. =A0The 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. =A0I 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. =A0Adding irq_domain support directly to
irq_generic_chip is going to be difficult for that reason. =A0However,
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 !=3D 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help