[PATCH 1/2] of: base: Allow more args than MAX_PHANDLE_ARGS if required

2015-07-16 Thread Joerg Roedel
From: Joerg Roedel jroe...@suse.de The main use of MAX_PHANDLE_ARGS is to define the number of args elements in 'struct of_phandle_args'. This struct is often declared on the stack and thus it is impractical to increase MAX_PHANDLE_ARGS again and again. To handle situations where more than

[PATCH 0/2 v2] Fix MAX_PHANDLE_ARGS limitations

2015-07-16 Thread Joerg Roedel
From: Joerg Roedel jroe...@suse.de Hi, here is the second version of my patches to fix the MAX_PHANDLE_ARGS limitation for the arm-smmu driver. On my AMD Seattle system the max value of 16 is not enough to initialize the SMMU, as the device tree node has an entry with 25 phandle args (possible

Re: [PATCH 2/2] arm/smmu: Make use of of_parse_phandle_with_var_args

2015-07-16 Thread Will Deacon
Hi Joerg, On Thu, Jul 16, 2015 at 09:30:44AM +0100, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de The function of_parse_phandle_with_args() can only handle 16 args, but there are systems that require more (25 in my case). So use the newly introduced function

Re: [PATCH 1/2] of: base: Allow more args than MAX_PHANDLE_ARGS if required

2015-07-16 Thread Will Deacon
On Thu, Jul 16, 2015 at 09:30:43AM +0100, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de The main use of MAX_PHANDLE_ARGS is to define the number of args elements in 'struct of_phandle_args'. This struct is often declared on the stack and thus it is impractical to increase

Re: [PATCH 1/2] of: base: Allow more args than MAX_PHANDLE_ARGS if required

2015-07-16 Thread Joerg Roedel
Hi Will, On Thu, Jul 16, 2015 at 11:23:26AM +0100, Will Deacon wrote: On Thu, Jul 16, 2015 at 09:30:43AM +0100, Joerg Roedel wrote: +struct of_phandle_args *of_alloc_phandle_args(int size) +{ + struct of_phandle_args *args; + int e = max(0, size - MAX_PHANDLE_ARGS); + + args =

[PATCH v3 6/6] dts: mt8173: Add iommu/smi nodes for mt8173

2015-07-16 Thread Yong Wu
This patch add the iommu/larbs nodes for mt8173 Signed-off-by: Yong Wu yong...@mediatek.com --- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81 ++ 1 file changed, 81 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi

[PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.

2015-07-16 Thread Yong Wu
This patch is for ARM Short Descriptor Format. Signed-off-by: Yong Wu yong...@mediatek.com --- drivers/iommu/Kconfig| 18 + drivers/iommu/Makefile |1 + drivers/iommu/io-pgtable-arm-short.c | 742 ++

[PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

2015-07-16 Thread Yong Wu
This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu yong...@mediatek.com --- drivers/iommu/Kconfig | 13 + drivers/iommu/Makefile|1 + drivers/iommu/mtk_iommu.c | 724 + 3 files changed,

[PATCH v3 1/6] dt-bindings: iommu: Add binding for mediatek IOMMU

2015-07-16 Thread Yong Wu
This patch add mediatek iommu dts binding document. Signed-off-by: Yong Wu yong...@mediatek.com --- .../devicetree/bindings/iommu/mediatek,iommu.txt | 61 include/dt-bindings/memory/mt8173-larb-port.h | 105 2 files changed, 166 insertions(+) create

Re: [PATCH] iommu/vt-d: Fix VM domain ID leak

2015-07-16 Thread Alex Williamson
On Thu, 2015-07-16 at 17:20 +0200, Joerg Roedel wrote: On Tue, Jul 14, 2015 at 02:48:53PM -0600, Alex Williamson wrote: This continues the attempt to fix commit fb170fb4c548 (iommu/vt-d: Introduce helper functions to make code symmetric for readability). The previous attempt in commit

Re: [PATCH] iommu/vt-d: Fix VM domain ID leak

2015-07-16 Thread Joerg Roedel
On Tue, Jul 14, 2015 at 02:48:53PM -0600, Alex Williamson wrote: This continues the attempt to fix commit fb170fb4c548 (iommu/vt-d: Introduce helper functions to make code symmetric for readability). The previous attempt in commit 71684406905f (iommu/vt-d: Detach domain *only* from attached

Re: [PATCH] iommu/vt-d: Fix VM domain ID leak

2015-07-16 Thread Joerg Roedel
On Thu, Jul 16, 2015 at 09:43:55AM -0600, Alex Williamson wrote: I was tempted to do this as well, but what about domain_remove_dev_info() where we also handle vm domains specially and don't do a symmetric detach in both directions? I started down that path but quickly found the code to

[PATCH v4 2/4] iommu: Implement common IOMMU ops for DMA mapping

2015-07-16 Thread Robin Murphy
Taking inspiration from the existing arch/arm code, break out some generic functions to interface the DMA-API to the IOMMU-API. This will do the bulk of the heavy lifting for IOMMU-backed dma-mapping. Signed-off-by: Robin Murphy robin.mur...@arm.com --- drivers/iommu/Kconfig | 7 +

[PATCH v4 1/4] iommu/iova: Avoid over-allocating when size-aligned

2015-07-16 Thread Robin Murphy
Currently, allocating a size-aligned IOVA region quietly adjusts the actual allocation size in the process, returning a rounded-up power-of-two-sized allocation. This results in mismatched behaviour in the IOMMU driver if the original size was not a power of two, where the original size is mapped,

[PATCH v4 4/4] arm64: Hook up IOMMU dma_ops

2015-07-16 Thread Robin Murphy
With iommu_dma_ops in place, hook them up to the configuration code, so IOMMU-fronted devices will get them automatically. Signed-off-by: Robin Murphy robin.mur...@arm.com --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 15 +++

[PATCH v4 0/4] arm64: IOMMU-backed DMA mapping

2015-07-16 Thread Robin Murphy
Hi all, Here's a quick repost to address feedback on v3, and a couple of other tweaks. Changes this round: - Fix the heinous dma_mask/coherency confusion, which also simplifies some prototypes and parameter passing as a bonus. - Reorder the iommu_map/unmap in alloc/free to prevent any

[PATCH v4 3/4] arm64: Add IOMMU dma_ops

2015-07-16 Thread Robin Murphy
Taking some inspiration from the arch/arm code, implement the arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer. Unfortunately the device setup code has to start out as a big ugly mess in order to work usefully right now, as 'proper' operation depends on changes to device

Re: [PATCH] PCI: Don't use SR-IOV lock for ATS

2015-07-16 Thread Bjorn Helgaas
Hi Joerg, On Thu, Jun 18, 2015 at 10:50:20AM +0200, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de The use of the SR-IOV lock for ATS causes a dead-lock in the AMD-IOMMU driver when virtual functions are added that have an ATS capability. The problem is that the VFs will be added