We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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!