On arm64 ACPI systems, we unconditionally reconfigure the entire PCI
hierarchy at boot. This is a departure from what is customary on ACPI
systems, and may break assumptions in some places (e.g., EFIFB), that
the kernel will leave BARs of enabled PCI devices where they are.
Given that PCI already specifies a device specific ACPI method (_DSM)
for PCI root bridge nodes that tells us whether the firmware thinks
the configuration should be left alone, let's sidestep the entire
policy debate about whether the PCI configuration should be preserved
or not, and put it under the control of the firmware instead.
The patch adds support for Amazon Graviton custom variant of GICv2m, where
hw irq is encoded using the MSI message address, as opposed to standard
GICv2m, where hw irq is encoded in the MSI message data.
In addition, the Graviton flavor of GICv2m is used along GICv3 (and not
GICv2).
Co-developed-by: Benjamin Herrenschmidt <email address hidden>
Signed-off-by: Benjamin Herrenschmidt <email address hidden>
Signed-off-by: Zeev Zilberman <email address hidden>
Reference: https://<email address hidden>/
Signed-off-by: Kamal Mostafa <email address hidden>
gicv2m_compose_msi_msg() may be called from non-preemptible context.
However, on RT, iommu_dma_map_msi_msg() requires to be called from a
preemptible context.
A recent change split iommu_dma_map_msi_msg() in two new functions:
one that should be called in preemptible context, the other does
not have any requirement.
The GICv2m driver is reworked to avoid executing preemptible code in
non-preemptible context. This can be achieved by preparing the MSI
mapping when allocating the MSI interrupt.
Signed-off-by: Julien Grall <email address hidden>
Reviewed-by: Eric Auger <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from commit 737be74710f30e611ee871f7b4f47975d1c6f71a)
Signed-off-by: Kamal Mostafa <email address hidden>
On RT, iommu_dma_map_msi_msg() may be called from non-preemptible
context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as
the function is using spin_lock (they can sleep on RT).
iommu_dma_map_msi_msg() is used to map the MSI page in the IOMMU PT
and update the MSI message with the IOVA.
Only the part to lookup for the MSI page requires to be called in
preemptible context. As the MSI page cannot change over the lifecycle
of the MSI interrupt, the lookup can be cached and re-used later on.
iomma_dma_map_msi_msg() is now split in two functions:
- iommu_dma_prepare_msi(): This function will prepare the mapping
in the IOMMU and store the cookie in the structure msi_desc. This
function should be called in preemptible context.
- iommu_dma_compose_msi_msg(): This function will update the MSI
message with the IOVA when the device is behind an IOMMU.
Signed-off-by: Julien Grall <email address hidden>
Reviewed-by: Robin Murphy <email address hidden>
Reviewed-by: Eric Auger <email address hidden>
Acked-by: Joerg Roedel <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from commit ece6e6f0218b7777e650bf93728130ae6f4feb7d)
Signed-off-by: Kamal Mostafa <email address hidden>
When an MSI doorbell is located downstream of an IOMMU, it is required
to swizzle the physical address with an appropriately-mapped IOVA for any
device attached to one of our DMA ops domain.
At the moment, the allocation of the mapping may be done when composing
the message. However, the composing may be done in non-preemtible
context while the allocation requires to be called from preemptible
context.
A follow-up change will split the current logic in two functions
requiring to keep an IOMMU cookie per MSI.
A new field is introduced in msi_desc to store an IOMMU cookie. As the
cookie may not be required in some configuration, the field is protected
under a new config CONFIG_IRQ_MSI_IOMMU.
A pair of helpers has also been introduced to access the field.
Signed-off-by: Julien Grall <email address hidden>
Reviewed-by: Robin Murphy <email address hidden>
Reviewed-by: Eric Auger <email address hidden>
Signed-off-by: Marc Zyngier <email address hidden>
(cherry picked from commit aaebdf8d68479f78d9f72b239684f70fbb0722c6)
Signed-off-by: Kamal Mostafa <email address hidden>
ff5fd6d...
by
Jonathan Chocron <email address hidden>
Add driver for Amazon's Annapurna Labs PCIe host controller. The
controller is based on DesignWare's IP.
The controller doesn't support accessing the Root Port's config space via
ECAM, so we obtain its base address via an AMZN0001 device.
Furthermore, the DesignWare PCIe controller doesn't filter out config
transactions sent to devices 1 and up on its bus, so they are filtered by
the driver.
All subordinate buses do support ECAM access.
Implementing specific PCI config access functions involves:
- Adding an init function to obtain the Root Port's base address from
an AMZN0001 device.
- Adding a new entry in the MCFG quirk array.
[bhelgaas: Note that there is no Kconfig option for this driver because it
is only intended for use with the generic ACPI host bridge driver. This
driver is only needed because the DesignWare IP doesn't completely support
ECAM access to the root bus.]
Link: https://<email address hidden>
Co-developed-by: Vladimir Aerov <email address hidden>
Signed-off-by: Jonathan Chocron <email address hidden>
Signed-off-by: Vladimir Aerov <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
Reviewed-by: David Woodhouse <email address hidden>
Reviewed-by: Benjamin Herrenschmidt <email address hidden>
Acked-by: Lorenzo Pieralisi <email address hidden>
(cherry-picked from commit 4166bfe53093b687a0b1b22e5d943e143b8089b2)
Signed-off-by: Kamal Mostafa <email address hidden>
In 5.0.12 "staging: axis-fifo: add CONFIG_OF dependency" upstream
makes the module build depend on building with open firmware enabled.
This is only true for arm64, armhf, and ppc64el. Meaning the module
will no longer be built for amd64.
Only removing from the previous ABI directory is needed. No changes to
the configs or annotation files.
Ignore: Yes
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
