On Wed, Mar 21, 2012 at 07:05:26PM +0530, Thomas Abraham wrote: > Hi David, > > On 21 March 2012 09:11, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |