[PATCH] arm/tegra: convert tegra20 to GIC devicetree binding

[Stephen Warren]

Peter De Schrijver wrote at Monday, November 21, 2011 5:22 AM:
> On Fri, Nov 18, 2011 at 05:25:33PM +0100, Stephen Warren wrote:
> > Peter De Schrijver wrote at Friday, November 18, 2011 5:04 AM:
> > > On Thu, Nov 17, 2011 at 07:51:35PM +0100, Stephen Warren wrote:
> > > > Peter De Schrijver wrote at Thursday, November 17, 2011 8:07 AM:
> > > > > Convert tegra20 IRQ intialization to the GIC devicetree binding. Modify the
> > > > > interrupt definitions in the dts files according to
> > > > > Documentation/devicetree/bindings/arm/gic.txt
> > > > >
> > > > > Signed-off-by: Peter De Schrijver <pdeschrijver at nvidia.com>
> > > >
> > > > tegra-harmony.dts contains an interrupts property that wasn't updated,
> > > > for the WM8903 codec.
> > >
> > > But that's a GPIO interrupt no?
> >
> > The interrupt line from codec to Tegra is a GPIO, yes.
> >
> > But the WM8903 still has the same interrupt-parent as everything else,
> > since it's inherited from /interrupt-parent and doesn't define its own.
> > Perhaps this is a mistake?
> 
> Yes. I think this is a mistake. If we want the device tree to reflect the
> hardware, I think the WM8903 node should specify the GPIO, not the IRQ
> number.

Hmm. This somewhat goes back to the previous irq_to_gpio discussion...

The WM8903 driver only cares about having an interrupt. In this case at
least, the driver never performs any GPIO-like manipulation on this
interrupt line. As such, shouldn't the driver receive the interrupt ID
to use?

The rationale here is that while the WM8903's interrupt output is hooked
to a GPIO input on Tegra systems, there's no reason to believe that it
couldn't be hooked to a dedicated interrupt input pin on some other SoC
(i.e. not a GPIO). In that case, there'd be no GPIO to pass to the driver.

Now perhaps what this means is that we need a DT binding for "the IRQ
generated by this given GPIO pin", rather than encoding that interrupt
number into the WM8903 node directly? That's certainly exactly what we
do when creating the platform data in board files in this case.

-- 
nvpublic