|Home > Operation > Interrupt translation service (ITS) > ITS cache control, locking, and test|
The GIC-600 can lock certain interrupts to the ITS caches.
The ITS caches are described in 3.10 Interrupt translation service (ITS).
If an LPI or translation is missed in a cache, several memory reads can be required to obtain the data necessary from memory. This can result in a range of latency that might not be acceptable for some LPIs.
The GIC-600 can lock certain translations into the ITS caches, with the following guarantee:
The ITS caches are automatically managed and invalidated as necessary when the GITS_BASERn registers are updated. Therefore, software intervention is not required. However, to aid debug and integration testing, you can force invalidation of the appropriate cache by setting the relevant bit in the GITS_FCTLR register.
A forced invalidation of the Event cache abandons all locked entries.
The GITS_OPR and GITS_OPSR registers control cache locking, which is DEVICE_ID, EVENT_ID, and the correct GITS_OPR.LOCK_TYPE (ITS = 2). The GIC attempts to perform the lock, and reports in GITS_OPSR. If the lock succeeds, GITS_OPSR.REQUEST_COMPLETE == 1 and GITS_OPSR.REQUEST_PASS == 1.
Each cache set is two-way set associative. Only one entry can be locked in each cache set. Any attempt to lock both ways in a set, reports as failed in GITS_OPSR. You can also use the GITS_OPSR register to unlock entries that are locked.
The GITS_OPSR register has two test features:
While any GITS_OPR operation, other than Track, is in progress, the GITS_OPSR.REQUEST_IN_PROGRESS bit is set and no further updates are accepted by GITS_OPR until the previous operation completes. To ensure that the operation is accepted, Arm recommends that the GITS_OPR value is read after writing. You can abort Track operation by writing GITS_OPR.LOCK_TYPE == Track_abort.