A gic problem about eoi
Hi, Marc
We found if hardware clear pending and active status is slower than software handling, the new sgi will be merged because of hardware status. The new sgi will be lost.
If we add a dsb instruction after gic_write_eoir(), it can avoid this case happening.
Is it a right way to add a dsb instruction after gic_write_eoir() in current gic driver code ?
Thanks,
Yang
On Thu, 18 Feb 2016 13:00:58 +0800
Yang Yingliang <[email protected]> wrote:
Hi Yang,
Quoted 11 lines
Hi, Marc
We found if hardware clear pending and active status is slower than software handling, the new sgi will be merged because of hardware status. The new sgi will be lost.
If we add a dsb instruction after
gic_write_eoir(), it can avoid this case happening.Is it a right way to add a dsb instruction after
gic_write_eoir()in current gic driver code ?
I suspect your problem is not so much the EOI, but that the read of ICC_IAR1_EL1 doesn't propagate the Ack quickly enough, leading to the transition from pending to active to still be in flux when the interrupt is EOIed. This is where a DSB is required (and was missing until very recently).
Does 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor") solve your problem?
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny.
Quoted 17 lines · Marc Zyngier
On Thu, 18 Feb 2016 13:00:58 +0800
Yang Yingliang <[email protected]> wrote:Hi Yang,
Quoted 11 lines
Hi, Marc
We found if hardware clear pending and active status is slower than software handling, the new sgi will be merged because of hardware status. The new sgi will be lost.
If we add a dsb instruction after
gic_write_eoir(), it can avoid this case happening.Is it a right way to add a dsb instruction after
gic_write_eoir()in current gic driver code ?
Quoted 8 lines
I suspect your problem is not so much the EOI, but that the read of
ICC_IAR1_EL1doesn't propagate the Ack quickly enough, leading to the transition from pending to active to still be in flux when the interrupt is EOIed. This is where a DSB is required (and was missing until very recently).Does 1a1ebd5 ("irqchip/gic-v3: Make sure read from
ICC_IAR1_EL1is visible on redestributor") solve your problem?
I tested this patch, it can solve the problem.
Will this patch queue to stable ?
Quoted 26 lines · Yang Yingliang
Quoted 23 lines · Marc Zyngier
On Thu, 18 Feb 2016 13:00:58 +0800
Yang Yingliang <[email protected]> wrote:Hi Yang,
Quoted 11 lines
Hi, Marc
We found if hardware clear pending and active status is slower than software handling, the new sgi will be merged because of hardware status. The new sgi will be lost.
If we add a dsb instruction after
gic_write_eoir(), it can avoid this case happening.Is it a right way to add a dsb instruction after
gic_write_eoir()in current gic driver code ?I suspect your problem is not so much the EOI, but that the read of
ICC_IAR1_EL1doesn't propagate the Ack quickly enough, leading to the transition from pending to active to still be in flux when the interrupt is EOIed. This is where a DSB is required (and was missing until very recently).
Quoted 6 lines
Quoted 2 lines
Does 1a1ebd5 ("irqchip/gic-v3: Make sure read from
ICC_IAR1_EL1is visible on redestributor") solve your problem?I tested this patch, it can solve the problem.
Will this patch queue to stable ?
Yes - It may not directly apply to older versions, but it is pretty trivial to backport.
Thanks for testing,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...