On Mon, Dec 05, 2011 at 02:47:29PM -0600, Rob Herring wrote: > On 12/05/2011 02:21 PM, Anton Vorontsov wrote: > > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote: > > [...] > >> At least for DT enabled platforms, we could force "no irq" to be 0 in > >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0. > > > > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers. > > dev->irq and thus the thing that we pass into request_irq() is a > > virtual IRQ thing, a "cookie". > > > > While in device tree you see real HW IRQ numbers. > > > > Legal VIRQ is always > 0, while HW IRQ could be >= 0. > > > > If this was all true, then there would be no discussion. > > This is what we are working towards, but irq_chips all over the arm tree > do not support any translation or have base fixed at compile time. Only > a few have been converted. And some ARM platforms may never get > converted to DT. > > >> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2 > >> should be fine currently as it doesn't use the of_irq_* functions to get > >> the timer irq, but that is an issue as it skips any translation. > >> VersatileAB should be okay with the VIC irqdomain support. > > > > It shouldn't be an issue to use of_irq_*() functions for these IRQs. > > of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do > > this currently, then it's a bug and should be fixed. > > I think that's what I'm saying. It's either a bug or incomplete DT > conversion for the platform. Either way, those should get fixed first. Do we expect there to be any platform drivers which are shared between legacy platforms and newer DT-ised platforms? Those drivers would be pain points since they would need to understand both conventions. So far as I can see, only boards which are not DT-ised, which do not use DT-ised drivers and which do not use drivers which use interrupts and are either used by DT-ised boards or by arches with a non-zero NO_IRQ could safely carry on using a non-zero NO_IRQ. Tracking down exactly which boards and drivers this applies to could be hard. We could have a CONFIG_NO_IRQ and make them depend on it, but we still have to find that list of boards and drivers in the first place. Otherwise, it feels like we might need a strategy for migrating pretty much everything if we don't want to end up in a mess. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
