[PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip

Rob Herring robherring2 at gmail.com
Tue Oct 30 20:04:38 EDT 2012

On 10/30/2012 05:47 PM, Russell King - ARM Linux wrote:
> On Tue, Oct 30, 2012 at 12:21:20PM -0500, Rob Herring wrote:
>> Looking at this some more, arm64 doesn't need most of what's in gic.h.
>> The register defines should be moved into the .c file. The remaining
>> function declarations either are not needed (i.e. gic_init) or should
>> should be done like the handle_irq function pointer init. We don't want
>> to have platform code calling gic_cascade_irq or gic_raise_softirq
>> directly.
> Softirqs are about the SPIs which are used for SMP IPIs and platform
> specific wakeup of CPUs.  And platform code _needs_ to specify the
> way IPIs are delivered on the platform.  irqchip can't do that because
> irqchip knows nothing about SPIs (neither does genirq.)

Right. v7 is unchanged, so the question is really only about how v8 will
do this. Hopefully, ARM is standardizing this for v8. We probably want
the gic (or other irqchip) to setup a raise_softirq function ptr on init
rather than having a direct call to gic_raise_softirq.


> The thing about gic_cascade_irq() is that it's to do with handling the
> (rare) case of having a system with two GICs cascaded together.  There's
> only one set of platforms I know of which has that kind of madness and
> it's the ARM development platforms, where the baseboard has a GIC, and
> the SMP tile has its own GIC as part of the SMP implementation.
> Apart from that, gic_cascade_irq() should not be used - it should
> probably be ifdef'd out when not on one of the ARM dev platforms which
> suffer this weirdness.

More information about the linux-arm-kernel mailing list