On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add an IOMMU device registry for drivers to register with and implement
> a method for users of the IOMMU API to attach to an IOMMU device. This
> allows to support deferred probing and gives the IOMMU API
From: Thierry Reding
Attach to the device's master interface of the IOMMU at .probe() time.
IOMMU support becomes available via the DMA mapping API interoperation
code, but this explicit attachment is necessary to ensure proper probe
order.
Signed-off-by: Thierry Reding
---
drivers/mmc/host/sd
From: Thierry Reding
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/t
From: Thierry Reding
The SDMMC controllers can use the IOMMU to avoid the need for bounce
buffers.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 8
From: Thierry Reding
This enables IOMMU interoperation with the DMA mapping API so that
clients that use the DMA mapping API can seemlessly make use of an
existing IOMMU.
Signed-off-by: Thierry Reding
---
arch/arm/mach-tegra/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/
From: Thierry Reding
Add an iommus property to each of the display controllers and encode the
SWGROUP in the specifier.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
Signed-of
From: Thierry Reding
The memory controller on NVIDIA Tegra124 exposes various knobs that can
be used to tune the behaviour of the clients attached to it.
Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
c
From: Thierry Reding
This series adds support for the IOMMU found on Tegra124 SoCs. The SMMU
groups memory clients into SWGROUPs and each SWGROUP can be assigned to
one I/O virtual address space. Translation of virtual addresses can be
enabled per memory client.
Patch 1 adds an IOMMU device regi
From: Thierry Reding
Add an IOMMU device registry for drivers to register with and implement
a method for users of the IOMMU API to attach to an IOMMU device. This
allows to support deferred probing and gives the IOMMU API a convenient
hook to perform early initialization of a device if necessary
From: Thierry Reding
The memory controller on NVIDIA Tegra124 exposes various knobs that can
be used to tune the behaviour of the clients attached to it.
In addition, the memory controller implements an SMMU (IOMMU) which can
translate I/O virtual addresses to physical addresses for clients. Thi
From: Thierry Reding
Add the memory controller and wire up the interrupt that is used to
report errors. Also add an #iommu-cells property to make the device
as an IOMMU.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra124.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
On Thu, 2014-06-26 at 19:10 +, Chalamarla, Tirumalesh wrote:
> Thanks for the clarification Alex, That’s exactly my point, why are we
> relying on QEMU or something else to emulate the MSI space when we can
> directly give access to devices using ITS (of course with a small emulation
> code
From: Thierry Reding
This structure is read-only data and should never be modified.
Signed-off-by: Thierry Reding
---
drivers/iommu/amd_iommu.c | 4 ++--
drivers/iommu/arm-smmu.c| 2 +-
drivers/iommu/exynos-iommu.c| 2 +-
drivers/iommu/fsl_pamu_domain.c | 2 +-
drivers/io
On Thu, 2014-06-26 at 18:41 +, Chalamarla, Tirumalesh wrote:
> Sorry there was a type,
>
> The question is:
>
> How is VFIO restricting software from writing to MSI/MSI-X
> vectors of the device.
All interrupts are configured via ioctl, not MSI config space or the
MSI-X vector
On 2014/6/26 2:00, Bjorn Helgaas wrote:
>> iommu/vt-d: match segment number when searching for dev_iotlb capable
>> devices
>> iommu/vt-d: use correct domain id to flush virtual machine domains
>> iommu/vt-d: introduce helper functions to improve code readability
>> iommu/vt-d: introduc
16 matches
Mail list logo