Re: [PATCH V3 0/5] iommu/arm-smmu: Add runtime pm/sleep support

On Fri, Mar 31, 2017 at 1:54 PM, Will Deacon wrote: > On Thu, Mar 09, 2017 at 09:05:43PM +0530, Sricharan R wrote: >> This series provides the support for turning on the arm-smmu's >> clocks/power domains using runtime pm. This is done using the >> recently introduced device links patches, which l

Re: [PATCH V3 0/5] iommu/arm-smmu: Add runtime pm/sleep support

On Thu, Mar 09, 2017 at 09:05:43PM +0530, Sricharan R wrote: > This series provides the support for turning on the arm-smmu's > clocks/power domains using runtime pm. This is done using the > recently introduced device links patches, which lets the symmu's > runtime to follow the master's runtime p

[PATCH RESEND 2/3] iommu/dma: Clean up MSI IOVA allocation

Now that allocation is suitably abstracted, our private alloc/free helpers can drive the trivial MSI cookie allocator directly as well, which lets us clean up its exposed guts from iommu_dma_map_msi_msg() and simplify things quite a bit. Reviewed-by: Nate Watterson Tested-by: Nate Watterson Sign

[PATCH RESEND 3/3] iommu/dma: Plumb in the per-CPU IOVA caches

With IOVA allocation suitably tidied up, we are finally free to opt in to the per-CPU caching mechanism. The caching alone can provide a modest improvement over walking the rbtree for weedier systems (iperf3 shows ~10% more ethernet throughput on an ARM Juno r1 constrained to a single 650MHz Cortex

[PATCH RESEND 1/3] iommu/dma: Convert to address-based allocation

In preparation for some IOVA allocation improvements, clean up all the explicit struct iova usage such that all our mapping, unmapping and cleanup paths deal exclusively with addresses rather than implementation details. In the process, a few of the things we're touching get renamed for the sake of

[PATCH RESEND 0/3] IOVA allocation improvements for iommu-dma

Hi Joerg, Here's the series rebased onto your current next branch just for the sake of it, and with the tags added. No other changes. Thanks, Robin. Robin Murphy (3): iommu/dma: Convert to address-based allocation iommu/dma: Clean up MSI IOVA allocation iommu/dma: Plumb in the per-CPU IOVA

Re: [PATCH 0/3] IOVA allocation improvements for iommu-dma

On Fri, Mar 31, 2017 at 02:13:13PM +0100, Robin Murphy wrote: > I was assuming this would go through the IOMMU tree if there were no > problems and the feedback was good, and that would seem to be the case. > I'm pleasantly surprised that this series doesn't even conflict at all > with my other iom

[PATCH] iommu/rockchip: Make use of 'struct iommu_device'

From: Joerg Roedel Register hardware IOMMUs seperatly with the iommu-core code and add a sysfs representation of the iommu topology. Signed-off-by: Joerg Roedel --- drivers/iommu/rockchip-iommu.c | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git

[PATCH] iommu/mediatek: Teach MTK-IOMMUv1 about 'struct iommu_device'

From: Joerg Roedel Make use of the iommu_device_register() interface. Signed-off-by: Joerg Roedel --- drivers/iommu/mtk_iommu_v1.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c index 19e

Re: [PATCH 0/3] IOVA allocation improvements for iommu-dma

On 31/03/17 13:40, Will Deacon wrote: > Hi Robin, Joerg, > > On Wed, Mar 15, 2017 at 01:33:13PM +, Robin Murphy wrote: >> Here's the first bit of lock contention removal to chew on - feedback >> welcome! Note that for the current users of the io-pgtable framework, >> this is most likely to sim

Re: [PATCH v2] iommu/arm-smmu: Add global SMR masking property

On Fri, Mar 31, 2017 at 12:03:33PM +0100, Robin Murphy wrote: > The current SMR masking support using a 2-cell iommu-specifier is > primarily intended to handle individual masters with large and/or > complex Stream ID assignments; it quickly gets a bit clunky in other SMR > use-cases where we just

Re: [PATCH 0/3] IOVA allocation improvements for iommu-dma

Hi Robin, Joerg, On Wed, Mar 15, 2017 at 01:33:13PM +, Robin Murphy wrote: > Here's the first bit of lock contention removal to chew on - feedback > welcome! Note that for the current users of the io-pgtable framework, > this is most likely to simply push more contention onto the io-pgtable >

Re: [PATCH v2 0/4] ARM SMMU TLB sync improvements

On Thu, Mar 30, 2017 at 05:56:28PM +0100, Robin Murphy wrote: > Here's a quick v2 to address your comments and drop the needless meddling > (whaddaya know, it makes the whole lot look simpler!) > > I'll put it on my list to take a look at SMMUv3 queue polling as suggested. Thanks, I've queued thi

[PATCH 4/5] iommu/omap: Make use of 'struct iommu_device'

From: Joerg Roedel Modify the driver to register individual iommus and establish links between devices and iommus in sysfs. Signed-off-by: Joerg Roedel --- drivers/iommu/omap-iommu.c | 25 + drivers/iommu/omap-iommu.h | 2 ++ 2 files changed, 27 insertions(+) diff --g

[PATCH 1/5] iommu/omap: Move data structures to omap-iommu.h

From: Joerg Roedel The internal data-structures are scattered over various header and C files. Consolidate them in omap-iommu.h. Signed-off-by: Joerg Roedel --- drivers/iommu/omap-iommu.c | 16 drivers/iommu/omap-iommu.h | 32 +++

[PATCH 0/5] iommu/omap: Add support for iommu-groups and 'struct iommu_device'

Hi, here is a small patch-set for the omap-iommu driver to make it use new features of the iommu-core. Please review. Thanks, Joerg Joerg Roedel (5): iommu/omap: Move data structures to omap-iommu.h iommu/omap: Permanently keep iommu_dev pointer in arch_data iommu/omap: Set dev->a

[PATCH 5/5] iommu/omap: Add iommu-group support

From: Joerg Roedel Support for IOMMU groups will become mandatory for drivers, so add it to the omap iommu driver. Signed-off-by: Joerg Roedel --- drivers/iommu/omap-iommu.c | 43 +-- drivers/iommu/omap-iommu.h | 1 + 2 files changed, 42 insertions(+),

[PATCH 2/5] iommu/omap: Permanently keep iommu_dev pointer in arch_data

From: Joerg Roedel Instead of finding the matching IOMMU for a device using string comparision functions, keep the pointer to the iommu_dev in arch_data permanently populated. Signed-off-by: Joerg Roedel --- drivers/iommu/omap-iommu.c | 56 -- driver

[PATCH 3/5] iommu/omap: Set dev->archdata.iommu = NULL in omap_iommu_remove_device

From: Joerg Roedel Don't leave a stale pointer in case the device continues to exist for some more time. Signed-off-by: Joerg Roedel --- drivers/iommu/omap-iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 45df5c8..04b3718

Re: [PATCH v2] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code

On Fri, Mar 31, 2017 at 01:02:51PM +0200, Andrzej Hajda wrote: > In this version of the patch I have replaced temporal pages and > iommu_dma_mmap with remap_pfn_range or rather its simplified version > vm_iomap_memory. > Unfortunately I have not find nice helper for sgtable creation, so I > left sg

[PATCH v2] arm64/dma-mapping: fix DMA_ATTR_FORCE_CONTIGUOUS mmaping code

In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages is invalid. __iommu_mmap_attrs and __iommu_get_sgtable should not use it and take advantage of contiguous nature of the allocation. Fixes: 44176bb ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU") Signed-off-by: Andrzej Ha

[PATCH v2] iommu/arm-smmu: Add global SMR masking property

The current SMR masking support using a 2-cell iommu-specifier is primarily intended to handle individual masters with large and/or complex Stream ID assignments; it quickly gets a bit clunky in other SMR use-cases where we just want to consistently mask out the same part of every Stream ID (e.g. f