Device node for a controller with two interrupt parents

[David Gibson]

On Wed, Mar 21, 2012 at 07:05:26PM +0530, Thomas Abraham wrote:
> Hi David,
> 
> On 21 March 2012 09:11, David Gibson <david at gibson.dropbear.id.au> wrote:
> > On Wed, Mar 21, 2012 at 07:55:43AM +0530, Thomas Abraham wrote:
> >> Hi,
> >>
> >> Exynos5 includes a gpio wakeup interrupt controller that generates 32
> >> interrupts. The first 16 interrupts are routed to the interrupt
> >> combiner controller. The last 16 are muxed into one interrupt and this
> >> interrupt line is connected to the GIC interrupt controller.
> >>
> >> So, the wakeup interrupt controller node in device tree requires two
> >> interrupt parents. I do not know how to handle this. Any suggestions
> >> will be very helpful.
> >
> > This has occurred before, for example on the MAL device on 440EP (see
> > the bamboo board dts for example).  The semi-standard approach is to
> > make the node an interrupt-nexus for itself.  That is in the node's
> > interrupts property, just list 0..N giving as many interrupts as you
> > need.  Set the node's interrupt-parent to point to the node itself,
> > then add interrupt-map and interrupt-map-mask properties which remap
> > those interrupts 0..N to the correct interrupts on the actual
> > interrupt controllers.  Each entry in the interrupt map specifies an
> > interrupt parent phandle, so you can distribute the irqs to multiple
> > interrupt controllers that way.
> 
> Thanks for your suggestion and pointing out an example. I tried this
> approach for Exynos4 and Exynos5. It mostly works but there are two
> issues here.
> 
> 1. In the Exynos5 case, the wakeup interrupt controller (which has two
> separate interrupt parents - gic and combiner) is itself a interrupt
> controller and has the 'interrupt-controller' property. So
> of_irq_map_raw() function does not process the interrupt-map in the
> wakeup interrupt controller device node. I did the following change to
> get past this but I am not sure if this the correct thing to do.

That might work, but it obviously won't help you with existing
kernels.  I think a better idea is not to try to make the
interrupt-controller and interrupt-nexus the same node in this case.
Instead add an intermediate nexus node to remap the
interrupt-controller's output interrupts into it's various parents.
You could make this fake nexus node a subnode of the interrupt
controller itself.

It's a bit of a hack, but it should work with existing parsing code,
and I think it's better than inventing a whole new convention to cover
this case.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson