The ITS provides a software mechanism for translating message-based interrupts into LPIs. The ITS is supported optionally in configurations that support LPIs.
A peripheral generates an LPI by writing to the GITS_TRANSLATER in the ITS. The write provides the ITS with the following information:
- EventID (VID). A value written to GITS_TRANSLATER. The EventID identifies which interrupt the peripheral is sending. Each interrupt source is identified by an Interrupt Identifier (INTID). The EventID might be the same as the INTID, or it might be translated by the ITS into the INTID.
- DeviceID (DID). The DeviceID is a unique identifier that identifies the peripheral.
The following figure shows the ITS block.
Figure 2-3 ITS block
The ITS is an implementation of the GICv3 Interrupt Translation Service as described in the Arm® Generic Interrupt Controller Architecture Specification, GIC architecture version 3.0 and version 4.0. The ITS translates MSI requests to the required LPI and target. It also has a set of commands for managing LPIs for core power management and load balancing.
A main use of the ITS is the translation of MSI/MSIx messages from a PCIe Root Complex (RC). To complete the translation, the ITS must be supplied with a DeviceID that is derived from the PCIe RequestorID. To reduce the distance that the DeviceID is transferred and to enable better compartmentalization between RCs, the ITS is best placed next to the RC. To ease integration, the ITS has an optional bypass switch as shown in the ITS block diagram. If the bypass switch is not configured, the ACE-Lite slave and master ports connect to the ITS directly. See ITS ACE-Lite slave interface and ITS ACE-Lite master interface.
In accordance with PCIe dependency rules, read responses on a PCIe Root Complex slave port must be ordered against completion of posted writes on a Root Complex master port. This means that writes must always make forward progress. The functionality of the ITS means that there is a dependency between writes to the GITS_TRANSLATER register and reads to memory and therefore one of the following must be true:
- The interconnect must allow forward progress of reads under all circumstances.
- The GIC parameter <
dgi_mem_support> must be set. This option provides support for routing all ITS translation dependent traffic via the ACE-Lite master port on the Distributor which must have free flowing access to memory. Once configured this feature must be enabled at boot time via writes to the GITS_FCTLR.DMA to route the traffic via the distributor.
NoteThis increases the width of the AxID fields on the Distributor master interface.
If the neither of the above is then you must not use the configuration shown in Figure 2-3 ITS block. This also applies to the CoreLink CMN-600 Coherent Mesh Network if the I/O coherent Requesting Node (RN-I) is able to access the same I/O Home Node (HN-I) that provides access to the PCIe Root Complex slave port. If the ITS is configured without a bypass switch, then a bypass switch can still be used to provide ITS access to memory through a different interconnect port, without merging the master ports.
See Interrupt translation service (ITS) for more information.
The following figure provides an example of the ITS integration process.
Figure 2-4 ITS integration
An ITS can be placed anywhere in the system so that it is seen by devices that want to send MSIs. However, the system is responsible for ensuring that the DeviceID reaching each ITS is not spoofed by rogue software using either a<x>user signals or MSI-64. See MSI-64 Encapsulator.
If the ITS is placed downstream of an ACE interconnect, care must be taken to avoid system deadlock. For more information, see the chapter describing Key Integration points in the Arm®CoreLink™ GIC‑600 Generic Interrupt Controller Configuration and Integration Manual.
See Interrupt translation service (ITS) for more information about each inner block.
This section contains the following subsections: