On Friday 24 October 2014 14:14:43 Linus Walleij wrote:
> On Wed, Oct 8, 2014 at 4:52 PM, Y Vo <yvo@xxxxxxx> wrote:
>
> > Add APM X-Gene standby GPIO controller driver.
> >
> > Signed-off-by: Y Vo <yvo@xxxxxxx>
>
> That's a very terse commit message. Please tell us a bit about the
> hardware and what platforms it is used on, etc.
>
> For example that is uses ACPI, as seems to be the case.
I think that was just the header file inclusion, but no actual ACPI
support. Al Stone is experimenting with ACPI support for X-Gene, and
some earlier patches from APM had rudimentary support as well, but
we are not adding ACPI support to X-Gene drivers upstream until we
know whether we can support the entire platform in that mode or not.
> So this platform uses some interesting combination of ACPI and device tree
> at the same time? Or alternatively?
Just DT at the moment.
> > + apm_gc->irq = devm_kzalloc(&pdev->dev, sizeof(u32) * XGENE_MAX_GPIO_DS,
> > + GFP_KERNEL);
> > + if (!apm_gc->irq)
> > + return -ENOMEM;
> > + memset(apm_gc->irq, 0, sizeof(u32) * XGENE_MAX_GPIO_DS);
> (...)
> > + for (i = 0; i < apm_gc->nirq; i++) {
> > + apm_gc->irq[default_pins[i]] = platform_get_irq(pdev, i);
>
> So the IRQs for all the GPIO pins are handled somewhere else instead
> of being a cascaded IRQ controller.
>
> This means that the IRQ lines from each individual GPIO pin is
> connected to a unique IRQ line on a secondary interrupt controller,
> instead of the GPIO block being a cascaded interrupt controller
> in its own right.
>
> Is this correct?
See the discussion I had on this. Yes, each line is connected to a
GIC SPI interrupt by itself. I've discussed this with Marc Zyngier
and Thomas Gleixner at the conference last week, and we concluded
that we will need a new generic interface to get data out of the
parent interrupt controller in a proper way. The current implementation
just maps the GIC registers and reads them directly, which of course
is not a proper way to do it.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
