| Age | Commit message (Collapse) | Author |
|---|
|
Add an optional iommu callback to be invoked before a device probes.
This can be used to configure the IOMMU in preparation for the device
(e.g. by allocating a context bank)
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
The dev_pci_iommu_enable() function is only available when CONFIG_PCI is
enabled, replace the runtime check with a preprocessor one to fix
compilation with pci disabled.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Systems such as Apple's M1 and M2 SoCs may have separate IOMMUs
for each PCIe root port. In this case the right IOMMU for a
PCI device behind a particular root port is described by an
"iommu-map" property in the device tree. Parse this property
and use it to find the right IOMMU device for PCI devices.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
|
|
In order to support IOMMUs in non-bypass mode we need device ops
to map and unmap DMA memory. The map operation enters a mapping
for a region specified by CPU address and size into the translation
table of the IOMMU and returns a DMA address suitable for
programming the device to do DMA. The unmap operation removes
this mapping from the translation table of the IOMMU.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
|
|
This uclass is intended to manage IOMMUs on systems where the
IOMMUs are not in bypass mode by default. In that case U-Boot
cannot ignore the IOMMUs if it wants to use devices that need
to do DMA and sit behind such an IOMMU.
This initial IOMMU uclass implementation does not implement and
device ops and is intended for IOMMUs that have a bypass mode
that does not require address translation. Support for IOMMUs
that do require address translation is planned and device ops
will be defined when support for such IOMMUs will be added.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
