Re: [RFC 01/10] iommu: Add IOMMU device registry

2014-06-26 Thread Thierry Reding
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

[RFC 10/10] mmc: sdhci-tegra: Add IOMMU support

2014-06-26 Thread Thierry Reding
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

[RFC 09/10] drm/tegra: Add IOMMU support

2014-06-26 Thread Thierry Reding
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

[RFC 07/10] ARM: tegra: tegra124: Enable IOMMU for SDMMC controllers

2014-06-26 Thread Thierry Reding
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

[RFC 08/10] ARM: tegra: Select ARM_DMA_USE_IOMMU

2014-06-26 Thread Thierry Reding
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/

[RFC 06/10] ARM: tegra: tegra124: Enable IOMMU for display controllers

2014-06-26 Thread Thierry Reding
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

[PATCH v3 02/10] devicetree: Add generic IOMMU device tree bindings

2014-06-26 Thread Thierry Reding
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

[RFC 04/10] memory: Add Tegra124 memory controller support

2014-06-26 Thread Thierry Reding
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

[RFC 00/10] Add NVIDIA Tegra124 IOMMU support

2014-06-26 Thread Thierry Reding
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

[RFC 01/10] iommu: Add IOMMU device registry

2014-06-26 Thread Thierry Reding
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

[RFC 03/10] of: Add NVIDIA Tegra124 memory controller binding

2014-06-26 Thread Thierry Reding
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

[RFC 05/10] ARM: tegra: Add memory controller on Tegra124

2014-06-26 Thread Thierry Reding
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

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

2014-06-26 Thread Alex Williamson
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

[PATCH] iommu: Constify struct iommu_ops

2014-06-26 Thread Thierry Reding
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

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

2014-06-26 Thread Alex Williamson
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

Re: [Patch Part3 V3 00/21] Enable support of Intel DMAR device hotplug

2014-06-26 Thread Jiang Liu
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