Re: [PATCH 4/6] dt: generalize irq_of_create_mapping()

[Benjamin Herrenschmidt]

On Wed, 2011-05-04 at 10:05 -0600, Grant Likely wrote:
> > I think you are going the wrong way around.
> > 
> > First thing first, is to make the irq domain / mapping API generic
> > without the OF bits.
> > 
> > IE. move the IRQ domain generically, get rid of irq_map by putting
> the
> > domain ptr & hw numbers in the irq desc/data etc...
> > 
> > Then you can move over the OF specific bits which are optional and
> > orthogonal to a large extent.
> 
> As discussed in my other reply, I disagree.  There isn't an immediate
> need for the mapping interface in common code.  It would be useful,
> sure, for some interrupt controllers, but for many of them
> irq_alloc_descs() and an irq_base value is all the functionality that
> is needed, and irq_host doesn't gain anything.

No but the concept of domain is a pre-requisite. Even if it's an opaque
data structure. And I don't want to have it be some "of" specific thing.

> The OF translation on the other hand is needed immediately by several
> architectures and are very much non-optional in that regard.

But it relies on having an underlying mapping. I don't see how you can
do one without the other, even if your mapping in effect is just an
offset.

And it is -not- related to OF.

Whether you obtain that your interrupt you are interested it is
interrupt 5 of your PIC "foo" via the device-tree or any other way (an
arch quirk for example), you need the mechanism to associate them
together, whether it's a simple offset as you propose (I'm ok with that
for simple things, I just didn't think it was the right approach for
powerpc but it's perfectly valid as an option generically) or a more
complex radix-tree style mapping.

Thus sort out the mapping interfaces first. _Then_ layout the
device-tree bits on top.

The basic parsing for the DT is already there. It will return a parent
node and a __be32* pointer.

Cheers,
Ben.

--
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/