On Wed, Sep 17 2014 at 07:51:38 PM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
Hi Russell,
On Wed, Sep 17, 2014 at 09:10:16AM -0700, Daniel Thompson wrote:
This patch provides support for arm's newly added IPI FIQ. It works by placing all interrupt sources *except* IPI FIQ in group 1 and then flips a configuration bit in the GIC such that group 1 interrupts use IRQ and group 0 interrupts use FIQ.
All GIC hardware except GICv1-without-TrustZone support provides a means to group exceptions into group 0 and group 1. However the hardware functionality is unavailable to the kernel when a secure monitor is present because access to the grouping registers are prohibited outside "secure world" (a feature that allows grouping to be used to allow hardware peripherals to send interrupts into the secure world). However when grouping is not available we can rely on the GIC's RAZ/WI semantics and avoid conditional code.
I've been chasing a bug with this on the Versatile Express CT9x4. It seems that the GIC there is a GICv1, with secure extensions. It seems to support interrupt grouping.
However, setting SPIs to group 1, with the control registers enabling both group 0 and group 1 (such that both groups are treated as IRQs) results in no SPIs being delivered to the kernel. In other words, setting GIC_DIST_IGROUP for SPIs, and setting both GIC_CPU_CTRL and GIC_DIST_CTRL to 3.
This is rather worrying, because we seem to have a GIC which for all intents and purposes appears to be compatible with what we want to do, appears to conform with the GIC architecture specifications, but doesn't actually work.
I suspect that running the Versatile Express CT9x4 in non-secure mode wouldn't work (because in non-secure mode, the GIC only allows access to group 1 interrupts.)
I've added Will and Mark to this to see whether they have any comment.
I'm rather far away from my VE-A9 board (and won't be to get back to it for another two weeks), so this is all a shot in the dark...
Can you have a look at the GICC_AIAR register (located at GICC_IAR + 0x14)? It *shouldn't* exist on this HW, assuming this is a real GICv1. But what you describe makes me think of something like this.
Thanks,
M.