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!