Hi Nishanth, On 05/09/2014 07:54 AM, Nishanth Menon wrote: [..] > Yep - thanks Santosh for clarifying this. Now, we still have the > issues that I pointed out in [1] - without resolving which, we should > not enable crossbar for dra74x/72x. > > A. taking example of PMU > interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH> > this wont work. instead the crossbar driver needs some sort of a hint > to know that it should not map these on crossbar register instead > assign GIC mapping directly. > > I propose doing the following > #define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 << 31)) > > and dts will define the following: > interrupts = <GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH> I would pick something smaller like GIC_SKIP_CROSSBAR. > This will also work for the other cases (B.2, B.3) > > For B.2: L3_APP_IRQ: > instead of: > interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH> > we do: > interrupts = <GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH> > > For B.3: NMI > interrupts = <GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH> > > xlate is easy -> > > diff --git a/drivers/irqchip/irq-crossbar.c > b/drivers/irqchip/irq-crossbar.c > index de021638..fd09ab4 100644 > --- a/drivers/irqchip/irq-crossbar.c > +++ b/drivers/irqchip/irq-crossbar.c > @@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct > irq_domain *d, > { > unsigned long ret; > > + /* Check to see if direct GIC mapping is required */ > + if (intspec[1] & BIT(31)) > + return intspec[1] & ~BIT[31]; > + > ret = get_prev_map_irq(intspec[1]); > if (!IS_ERR_VALUE(ret)) Sounds good, one problem I see here though is once you do the xlate, the information that the IRQ number is GIC cross bar is lost because you are 0'ing bit 31. Then how will map/unmap decide if it needs to be crossbar mapped/unmapped or GIC? Perhaps, the info in bit 31 should be stored somewhere and reused later during map time, or I am missing something. thanks, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html