Cortex-R52 GICv3 Interrupt1023

A read of ICC_IARn returns 1023 either when there is no HPPI or the HPPI is one that you can't ack via that register at this time.

As ICC_HPPIR0 reports 0x1B (27) you know there is a HPPI.  Now, just because there is a HPPI doesn't mean the GIC will signal an IRQ or FIQ to the core.  The HPPI might be masked either by ICC_PMR (priority mask) or ICC_RPR (running priority).  Running priority is derived from the ICC_APxR0_EL1 registers.

Grace WANG said:

As the irq_exception will not mask FIQ, I suppose that when the CPU is handling vector270 (IRQ), vector27 (FIQ) comes and interrupts it. But as the priority of vector27 is lower than vector270, interrupt1023 is reported due to no sufficient priority. Is my understanding right ?

Each INTID has a configurable priority, meaning you can't (architecturally) infer the relative of priorities of two interrupts based on their INITDs.  I know on some interrupt controllers INTID and priority are connected, but it is not true for GICs.  If you're see the FIQ exception then that implies the HPPI beat both the PMR and RPR, that means it's higher priority than the already active priority.

A couple of questions:

• Are you seeing the FIQ exception be taken?  (I've guessed yet, but it would be good to have it confirmed)
• Which register returned 1023?  Was it ICC_IAR1 or ICC_IAR0?
  • Note: With the R52, the GIC uses FIQs for interrupts configured as Group 0.  Group 0 interrupts can only be acknowledged via a read of ICC_IAR0

A read of ICC_IARn returns 1023 either when there is no HPPI or the HPPI is one that you can't ack via that register at this time.

As ICC_HPPIR0 reports 0x1B (27) you know there is a HPPI.  Now, just because there is a HPPI doesn't mean the GIC will signal an IRQ or FIQ to the core.  The HPPI might be masked either by ICC_PMR (priority mask) or ICC_RPR (running priority).  Running priority is derived from the ICC_APxR0_EL1 registers.

Grace WANG said:

As the irq_exception will not mask FIQ, I suppose that when the CPU is handling vector270 (IRQ), vector27 (FIQ) comes and interrupts it. But as the priority of vector27 is lower than vector270, interrupt1023 is reported due to no sufficient priority. Is my understanding right ?

Each INTID has a configurable priority, meaning you can't (architecturally) infer the relative of priorities of two interrupts based on their INITDs.  I know on some interrupt controllers INTID and priority are connected, but it is not true for GICs.  If you're see the FIQ exception then that implies the HPPI beat both the PMR and RPR, that means it's higher priority than the already active priority.

A couple of questions:

• Are you seeing the FIQ exception be taken?  (I've guessed yet, but it would be good to have it confirmed)
• Which register returned 1023?  Was it ICC_IAR1 or ICC_IAR0?
  • Note: With the R52, the GIC uses FIQs for interrupts configured as Group 0.  Group 0 interrupts can only be acknowledged via a read of ICC_IAR0

Grace WANG said:

Yes, I saw FIQ exception was taken and ICC_IAR0 returned 1023.

Now that's interesting.  If the GIC is asserting the FIQ input, then it shows the HPPI passed all the GIC tests (PMR, RPR...).  

Inside the handler (so after you've taken the FIQ exception), could you try:

• Read ICC_HPPIR0
• Read ICC_AP0R0
• Read ISR_EL1
• Read ICC_IAR0
• ISB
• Read ICC_HPPIR0
• Read ICC_AP0R0
• Read ISR_EL1

I'm checking what the state is immediately before and after the read of the IAR.  

Grace WANG said:

• CC_HPPIR0 = 0x3FF
• ICC_AP0R0 = 0x0
• ISR = 0x80

The ISR is showing that the IRQ line is asserted (bit 7) and the FIQ line is de-asserted (bit 6).  That's consistent with what the GIC registers are reporting.  ICC_HPPIR0 reports if the HPPI is a Group 0 interrupt, 0x3FF means there isn't.  It's Group 0 interrupt which the GIC signals as FIQs.  We can infer that if we read ICC_HPPIR0, which reports on Group 1 interrupts which are signalled as IRQs, it would report 270 (or some other G1 ID).

The read of ICC_IAR0 rightly returns 1023.  IAR0 can only ack Group 0 interrupts, the HPPI is a Group 1 interrupt.

The bit I'm confused by is that you said you have this inside the FIQ handler.  That's odd because the GIC isn't signalling an FIQ, it's signalling an IRQ.

Interrupts are asynchronous events, there's no guarantee that the HPPI that caused the initial exception is the one that's still there when you try to handle it.  Two possibilities spring to mind:

• The FIQ went away between the CPU taking the exception and the registers being read.
• The Group 1 interrupt (INTID 270?) became pending between the CPU taking the exception and the registers being read.

I think the second is more likely, given what you said about the priorities in the original post. 

Grace WANG said:

vector270: priority: 12, group1 (IRQ) and vector27: priority 16, group0 (FIQ).

If it's true, it's just unlucky timing.  The GIC saw a G0 interrupt, raised an FIQ.  While the core was taking the exception, the G1 interrupt became pending and was selected as the HPPI (as its higher priority).  When software in the FIQ handler tries to ack the interrupt it fails as the current HPPI is G1.  If the handler then returned, I'd expect the core to take an IRQ exception pretty immediately (assuming PSTATE.I=0) and then you'd handle that.  Once the G1 interrupt is priority dropped (ICC_EOIR1), the GIC will be able to select the original G0 interrupt as the HPPI again.

Martin Weidmann said:

If the handler then returned, I'd expect the core to take an IRQ exception pretty immediately (assuming PSTATE.I=0) and then you'd handle that.  Once the G1 interrupt is priority dropped (ICC_EOIR1), the GIC will be able to select the original G0 interrupt as the HPPI again.

Currently, for the FIQ1023, the CPU will do nothing but stop there. Are you saying that I can make the CPU complete the fiq exception handling after entered vector1023. Then it will go to handle IRQ normally. 

If so, what's the safe handling for INT1023 ?