Re: [PATCH 5/5] ARM: gic: add OF based initialization

From: Cousson, Benoit
Date: Mon Sep 19 2011 - 09:08:21 EST

On 9/19/2011 2:07 PM, Dave Martin wrote:
On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely<grant.likely@xxxxxxxxxxxx> wrote:
On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
For now, we express the mapping by putting an interrupt-map in the
core-tile DT, but this feels inelegant as well as wasteful -- expressing
"+ 32" using a table which is about 1K in size and duplicates that
information 43 times.

Using a dedicated irq domain or a fake interrupt controller node to
encapsulate the motherboard interrupts feels like a cleaner approach,
but for now I'm not clear on the best way to do it.

An irq nexus node would indeed be something to investigate for your
particular case. Look for examples of interrupt-map. It is most
often used for handling IRQ swizzling on PCI busses.

That's what I currently have -- this is logically correct, and it
works; it just feels like a sledgehammer for cracking this particular
nut, because we don't really have 43 independent interrupt mappings
and types. We have one offset and one type which is applied to all
the interrupts, and this situation is expected to be the same for all
variations of this board, except that offset may change. I suspect
this situation applies to many platforms -- the number of interrupts
may in general be much larger than the number of independent mappings.

Another way of looking at the problem is that it's difficult to come
up with a one-size-fits-all description of interrupt mappings which is
also efficient. Requiring a single set of mapping semantics requires
the mappings to be both rather overspecified for most cases, and
flattened into a large, structureless table which may become pretty
large and unwieldy. If there were 100+ interrupts instead of 43, we'd
really have to be generating the device tree using a script in order
for it to be maintainable (which is not necessarily a problem, but can
be a warning sign)

Yep, this is exactly the issue I was facing when I tried to map the 128 interrupts lines of an OMAP4 to the GIC. Adding 128 entries to an interrupt map just to handle a simple linear translation with a constant value of 32 is clearly overkill.

An alternative approach is to introduce a special interrupt controller
node which serves as the interrupt-parent for the child domain and
maps the interrupts with flexible semantics defined by the node's
bindings; or different kinds of interrupt-map/interrupt-map-mask
properties could be defined. Bindings could be added as needed to
support different cases -- though really we should only expect to have
a small number at most. When the interrupt mapping is significantly
complex, using interrupt-map will probably be the best approach
anyway.

Maybe we can just extend or add a new type of interrupt nexus to handle simple translation. The actual one was done for complex PCI mapping but with a small number of lines to handle. In our case, the mapping is simple, but the number of lines is huge.

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/