| #
99b2ae26 |
| 20-Feb-2025 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge changes from topic "jw/gic-lca-support" into integration
* changes: fix(rdn2): add LCA multichip data for RD-N2-Cfg2 fix(rdv3): add LCA multichip data for RD-V3-Cfg2 feat(gic): add suppo
Merge changes from topic "jw/gic-lca-support" into integration
* changes: fix(rdn2): add LCA multichip data for RD-N2-Cfg2 fix(rdv3): add LCA multichip data for RD-V3-Cfg2 feat(gic): add support for local chip addressing
show more ...
|
| #
c89438bc |
| 16-Sep-2024 |
Jerry Wang <Jerry.Wang4@arm.com> |
feat(gic): add support for local chip addressing
This patch adds support for Local Chip Addressing (LCA). In a multi-chip system, enablig LCA allows each GIC Distributor to maintain its own version
feat(gic): add support for local chip addressing
This patch adds support for Local Chip Addressing (LCA). In a multi-chip system, enablig LCA allows each GIC Distributor to maintain its own version of routing table. This feature is activated when the GICD_CFGID.LCA bit is set to 1.
The existing `gic600_multichip_data` data structure did not account for the LCA feature. To support LCA: - `rt_owner_base` is replaced by `base_addrs[]`. This is required because each GICD in the system needs to be configured independently, and their base addresses must be passed to the driver. - `chip_addrs` is changed from 1D to 2D array to store the routing table for each chip's GICD. The entries in `chip_addrs` are configuration dependent, as the GIC specification does not enforce this.
On a multi-chip platform with chip count N where LCA is enabled by default, the `gic600_multichip_data` structure should contain all copies of the routing table (N*N entries). On platforms where LCA is not supported, only the first sub-array with N entries is required. The function signature of `gic600_multichip_init` remains unchanged, but if the LCA feature is enabled, the driver will expect the routing table configuration in the described format.
Change-Id: I8830c2cf90db6a0cae78e99914cd32c637284a2b Signed-off-by: Jerry Wang <Jerry.Wang4@arm.com>
show more ...
|
| #
5a63aed2 |
| 24-Mar-2023 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4" into integration
|
| #
a02a45df |
| 08-Mar-2023 |
Varun Wadekar <vwadekar@nvidia.com> |
fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4
The purpose of this patch is to address the T241 erratum T241-FABRIC-4, which causes unexpected behavior in the GIC when multiple transactions
fix(gicv3): workaround for NVIDIA erratum T241-FABRIC-4
The purpose of this patch is to address the T241 erratum T241-FABRIC-4, which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs.
This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior.
Erratum documentation: https://developer.nvidia.com/docs/t241-fabric-4/nvidia-t241-fabric-4-errata.pdf
The workaround is to ensure that MMIO accesses target the GIC on the socket that holds the data, for example SPI ranges owned by the socket’s GIC. This ensures that the GIC will not utilize the inter-socket AXI Stream interface for servicing these GIC MMIO accesses.
This patch updates the functions that use the GICD_In{E} registers to ensure that the accesses are directed to the chip that owns the SPI, instead of using the global alias.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I04e33ba64eb306bd5fdabb56e63cbe273d8cd632
show more ...
|
| #
415f67e3 |
| 12-Nov-2019 |
Paul Beesley <paul.beesley@arm.com> |
Merge changes from topic "gic600_multichip" into integration
* changes: gic/gic600: add support for multichip configuration plat/arm/gicv3: add support for probing multiple GIC Redistributor fra
Merge changes from topic "gic600_multichip" into integration
* changes: gic/gic600: add support for multichip configuration plat/arm/gicv3: add support for probing multiple GIC Redistributor frames
show more ...
|
| #
fcc337cf |
| 16-Sep-2019 |
Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com> |
gic/gic600: add support for multichip configuration
Add support to configure GIC-600's multichip routing table registers. Introduce a new gic600 multichip structure in order to support platforms to
gic/gic600: add support for multichip configuration
Add support to configure GIC-600's multichip routing table registers. Introduce a new gic600 multichip structure in order to support platforms to pass their GIC-600 multichip information such as routing table owner, SPI blocks ownership.
This driver is currently experimental and the driver api may change in the future.
Change-Id: Id409d0bc07843e271ead3fc2f6e3cb38b317878d Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
show more ...
|