On Friday 09 May 2014 10:00 AM, Nishanth Menon wrote: > On 05/09/2014 08:45 AM, Santosh Shilimkar wrote: >> On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote: [..] >> Looks like I am missing something. Is the issue because of SPI offset (32) >> which makes above confusion ? > > The way we modelled crossbar is that the irqchip is GIC and routable > mapper is crossbar - which makes sense. now for every "interrupts" > description we try to find a map using the crossbar driver as the irq > framework rightly identifies that peripheral interrupts are routable > and crossbar driver is the guy who knows how to map these to a proper > GIC interrupt number. So far, we are good. > > Now the trouble starts when our hardware description in dts assumes > that every peripheral interrupt is a routable interrupt - as this > thread describes - that is NOT the case. > > Now the question is how do you differentiate? > > interrupts = <GIC_SPI Number Level> > > GIC_SPI is correct since we are attempting to describe the SPI > interrupt (offset what ever it is, is a NOP from conceptual discussion). > > Level is fine as well. > > Number: what does this indicate? crossbar number is what we have > assumed so far. however, then you loose the ability to describe > interrupts on GIC SPI which dont have crossbar interrupts. > > Question is how do we differentiate between the two? > Updating the thread about an off-list discussion on $subject. Nishant understood the how he was indirectly changing the meaning of IRQ bindings and why its a bad idea. The point which didn't came out clearly on the list was also the limited set of route-able IRQ registers at cross-bar which is utter non-sense and broken hardware. And since we are patching up the cross-bar hardware bugs, it should be done such a way that the cross-bar device tree bindings reflect that. Here is the way forward we decided... Add additional/optional properties to cross-bar binding so that you can represent IRQs which can't be routed by cross-bar. Something like 'MAX_ROUTABLE_IRQS'. Then on the cleint modules which has the shortcoming, you just add MAX_ROUTABLE_IRQS to those IRQs. That way cross-bar driver fails to route them and just returns the offset IRQline thinking it is already hard wired. As a proof of concept I suggest you to just create a bidnig patch with example usage of such case in the Documentation and send it for review. Copy Device Tree folks and Thomas to see if they are ok with it or can suggest some better way to deal with the issue. Thanks for the patience and explaining the issue repeatedly. regards, Santosh -- 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
