ARM64 GICv3 IRQ handling on i.MX8MP

[Krzysztof Hałasa]

Hi,

I'm looking at the i.MX8MP I2C transfers to an image sensor (Sony IMX290
and 462) and I find the following interesting. I wonder about the time
spent before the IRQ handler is called. This is mostly mainline v6.13
kernel (not any of the NXP branches).

The i.MX8MP uses drivers/i2c/busses/i2c-imx.c driver:

request_irq(irq, i2c_imx_isr, IRQF_SHARED, pdev->name, i2c_imx);

As I can see, this means i2c_imx_isr() will be called by el1h_64_irq()
(constructed with the entry_handler macro). el1h_64_irq() is the
ultimate hardware interrupt:

Call trace:
 i2c_imx_isr
 __handle_irq_event_percpu
 handle_irq_event
 handle_fasteoi_irq
 generic_handle_domain_irq
 gic_handle_irq
 call_on_irq_stack
 do_interrupt_handler
 el1_interrupt
 el1h_64_irq_handler
 el1h_64_irq
 cpuidle_enter_state

Now I put some debugging GPIO outputs (very short) in both i2c_imx_isr()
and el1h_64_irq_handler() and this is what I'm getting:

- the CPU gets from el1h_64_irq_handler() to i2c_imx_isr() in less than
  20 us (sometimes < 3 us).

- but, it usually takes like 350 us to get from the end of I2C byte
  transfer to the actual el1h_64_irq_handler(). This is the case when
  the CPU is only slightly loaded.

- sometimes el1h_64_irq_handler() is called within 2 us after the
  end of transfer. This appears to be much more frequent when I put
  4 busy shell loops on the CPU.

- especially with the busy loops, the I2C IRQs appear to work in some
  sort of polled mode as well - the el1h_64_irq_handler() isn't called
  before i2c_imx_isr(). This is fast, though - ca. 1 us after the end
  of transfer.

Why do the times between the hardware event and the actual call of
el1h_64_irq_handler() vary so much? Is this some sort of power saving
issue? Maybe I can prevent it when e.g. the I2C xfer is ongoing?

BTW it appears the I2C transfer times are much better now (in comparison
with the old 5.15.71 Freescale/NXP branch), most probably thanks to a
recent patch by Stefan Eichenberger (5f5c2d4579ca683 "i2c: imx: prevent
rescheduling in non dma mode"). Still, I2C is (in this case) 400 kHz (or
so) and the IRQ delays make it much slower.

Could that be caused by the ATF/TEE?

Obviously, the "polled" mode isn't a problem - only the 350 us delay is.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa