Re: [PATCH] iommu/dma: Fix NEED_SG_DMA_LENGTH dependency

On Mon, Feb 29, 2016 at 11:13:39AM +, Robin Murphy wrote: > IOMMU_DMA does indeed depend on scatterlists having a DMA length, but > the NEED_SG_DMA_LENGTH symbol should be selected, not depended upon. > > Reported-by: Arnd Bergmann > Signed-off-by: Robin Murphy

Re: [PATCH] iommu/exynos: Use proper readl/writel register interface

On Mon, Feb 29, 2016 at 01:42:57PM +0100, Marek Szyprowski wrote: > Drivers should use generic readl/writel calls to access HW registers, so > replace all __raw_readl/writel with generic version. > > Suggested-by: Arnd Bergmann > Signed-off-by: Marek Szyprowski

Re: [PATCH] iommu: exynos: pointers are nto physical addresses

On Mon, Feb 29, 2016 at 09:45:59AM +0100, Arnd Bergmann wrote: > The exynos iommu driver changed an incorrect cast from pointer > to 'unsigned int' to an equally incorrect cast to a 'phys_addr_t', > which results in an obvious compile-time error when phys_addr_t > is wider than pointers are: > >

Re: [RFC v4 09/14] msi: IOMMU map the doorbell address when needed

Hi Thomas, On 02/26/2016 07:19 PM, Thomas Gleixner wrote: > On Fri, 26 Feb 2016, Eric Auger wrote: >> +static int msi_map_doorbell(struct iommu_domain *d, struct msi_msg *msg) >> +{ >> +#ifdef CONFIG_IOMMU_DMA_RESERVED >> +dma_addr_t iova; >> +phys_addr_t addr; >> +int ret; >> + >>

Re: [RFC v4 07/14] msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

Hi Thomas, On 02/26/2016 07:06 PM, Thomas Gleixner wrote: > On Fri, 26 Feb 2016, Eric Auger wrote: > >> Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING >> meant to tell the domain supports IRQ REMAPPING, also known as Interrupt >> Translation Service. On Intel HW this

[PATCH 06/12] iommu/arm-smmu: Streamline SMMU data lookup

Simplify things by stashing our SMMU instance data in drvdata, so that we don't need to go off hunting for it in the driver model callbacks. Watch out, arm_smmu_devices list, your days are numbered! Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu.c | 20

[PATCH 05/12] arm64/dma-mapping: Remove default domain workaround

With the IOMMU core now taking care of default domains for groups regardless of bus type, we can gleefully rip out this stop-gap, as slight recompense for having to expand the other one. CC: Catalin Marinas CC: Will Deacon Signed-off-by: Robin

[PATCH 07/12] iommu/arm-smmu: Factor out mmu-masters handling

Reorder the SMMU probe routine slightly to separate probing and configuring the SMMU itself from processing the mmu-masters property, and break the handling of the latter out into self-contained functions. In preparation for changes to come, the failure mode is changed slightly such that instead

[PATCH 11/12] iommu/arm-smmu: Generic IOMMU DT bindings support

Implement an of_xlate callback and the appropriate registration so that we can configure masters via generic DT bindings. Initially, we have the equivalent level of functionality with respect to groups, stream ID limits, etc. as for the old bindings, but the door is now open for further

[PATCH 09/12] iommu/arm-smmu: Simplify mmu-masters handling

With the preceding data reshuffles allowing SMMU instances to be looked up directly wherever needed, we can now wipe out the last vestiges of the global SMMU list. With mmu-masters lookup now a one-time thing outside of any real hotpath, condense our stash of those out of the SMMU instance data

[PATCH 03/12] iommu/of: Handle iommu-map property for PCI

Now that we have a way to pick up the RID translation and target IOMMU, hook up of_iommu_configure() to bring PCI devices into the of_xlate mechanism and allow them IOMMU-backed DMA ops without the need for driver-specific handling. CC: Rob Herring CC: Frank Rowand

[PATCH 01/12] Docs: dt: add PCI IOMMU map bindings

From: Mark Rutland The existing IOMMU bindings are able to specify the relationship between masters and IOMMUs, but they are insufficient for describing the general case of hotpluggable busses such as PCI where the set of masters is not known until runtime, and the

[PATCH 10/12] Docs: dt: document ARM SMMU generic binding usage

Document how the generic "iommus" binding should be used to describe ARM SMMU stream IDs instead of the old "mmu-masters" binding. Signed-off-by: Robin Murphy --- .../devicetree/bindings/iommu/arm,smmu.txt | 40 ++ 1 file changed, 25

[PATCH 04/12] arm64/dma-mapping: Extend DMA ops workaround to PCI devices

PCI devices now suffer the same hiccup as platform devices, in that they get their DMA ops configured before they have been added to their bus, and thus before we know whether they have successfully registered with an IOMMU or not. Until the necessary driver core changes to reorder calls during

[PATCH 08/12] iommu/arm-smmu: Refactor master/group config handling

We currently have some very vague and blurred boundaries around devices, groups, and what exactly an arm_smmu_master_cfg represents. Before we can properly deal with multi-master groups, this needs sorting out. Ratify arm_smmu_master_cfg to strictly represent the set of stream IDs used by an

Re: [PATCH] iommu/exynos: Use proper readl/writel register interface

On Monday 29 February 2016 13:42:57 Marek Szyprowski wrote: > Drivers should use generic readl/writel calls to access HW registers, so > replace all __raw_readl/writel with generic version. > > Suggested-by: Arnd Bergmann > Signed-off-by: Marek Szyprowski

[PATCH] iommu/exynos: Use proper readl/writel register interface

Drivers should use generic readl/writel calls to access HW registers, so replace all __raw_readl/writel with generic version. Suggested-by: Arnd Bergmann Signed-off-by: Marek Szyprowski --- drivers/iommu/exynos-iommu.c | 38

Re: [PATCH 1/2] iommu/mediatek: select ARM_DMA_USE_IOMMU

On 29/02/16 10:53, Arnd Bergmann wrote: On Monday 29 February 2016 10:37:40 Robin Murphy wrote: Hi Arnd, On 29/02/16 09:19, Arnd Bergmann wrote: The newly added Mediatek IOMMU driver uses the IOMMU_DMA infrastructure, but unlike other such drivers, it does not select 'ARM_DMA_USE_IOMMU',

Re: [PATCH 1/2] iommu/mediatek: select ARM_DMA_USE_IOMMU

Hi Arnd, On 29/02/16 09:19, Arnd Bergmann wrote: The newly added Mediatek IOMMU driver uses the IOMMU_DMA infrastructure, but unlike other such drivers, it does not select 'ARM_DMA_USE_IOMMU', which is a prerequisite, leading to a link error: warning: (MTK_IOMMU) selects IOMMU_DMA which has

Re: [PATCH] iommu/mediatek: select IOMMU_IOVA

On Monday 29 February 2016 10:11:58 Arnd Bergmann wrote: > This adds the same select that the other drivers have. On a related > note, I wonder if we should just always select ARM_DMA_USE_IOMMU > whenever any IOMMU driver is enabled. Are there any cases where > we would enable an IOMMU but not use

[PATCH] iommu/mediatek: select IOMMU_IOVA

The newly added Mediatek IOMMU driver uses the IOMMU_DMA infrastructure, but unlike other such drivers, it does not select 'ARM_DMA_USE_IOMMU', which is a prerequisite, leading to a link error: warning: (MTK_IOMMU) selects IOMMU_DMA which has unmet direct dependencies (IOMMU_SUPPORT &&