On Friday 24 October 2014 14:14:43 Linus Walleij wrote:

On Wed, Oct 8, 2014 at 4:52 PM, Y Vo [off-list ref] wrote:

quoted

Add APM X-Gene standby GPIO controller driver.

Signed-off-by: Y Vo <redacted>

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.

quoted

+       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);

(...)

quoted

+       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