Thread (15 messages) 15 messages, 5 authors, 2012-10-31
STALE4965d

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

From: Rob Herring <hidden>
Date: 2012-10-31 00:04:38

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:
quoted
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.

Rob
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help