Hello,
While testing various features of the GICv3 ITS, I came across some behavior regarding the ITS retry mechanism and wanted to ask a couple of questions.
After a command causes the ITS to stall, I observed that writing 1 to the GITS_CWRITER.retry bit causes the GITS_CREADR value to catch up with GITS_CWRITER.
1
GITS_CWRITER.retry
GITS_CREADR
GITS_CWRITER
In my setup (kernel 5.10.y) with dummy device, the ITS always stalls at the MAPD command during MSI setup.
MAPD
As a result, the system fails to complete the MAPD and MAPTI commands during boot.
MAPTI
However, after issuing a retry, GITS_CREADR catches up with GITS_CWRITER, and when I trigger the MSI (via an INT command), the interrupt handler is correctly called.
INT
I have two questions:
Why does the ITS always stall at the MAPD command? (Could this be because I'm testing with a dummy device?)
After retrying the stalled command, everything appears to work normally — is it safe to assume that the commands completed successfully without issues?
Thank you in advance!
When I was performing the retry, I had the command queue region open in Trace32. I’ll try the retry again without viewing the command queue to see if that changes anything.
This issue doesn’t occur on kernel 6.12. I’ll also check if there are any differences in cache operations between kernel versions. Thank you!