RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

> From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Tuesday, March 06, 2018 0:22 > > On 05/03/18 18:39, Christoph Hellwig wrote: > > On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote: > >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > >>

[PATCH v7 13/14] iommu/rockchip: Add runtime PM support

When the power domain is powered off, the IOMMU cannot be accessed and register programming must be deferred until the power domain becomes enabled. Add runtime PM support, and use runtime PM device link from IOMMU to master to startup and shutdown IOMMU. Signed-off-by: Jeffy Chen

[PATCH v7 12/14] iommu/rockchip: Fix error handling in init

It's hard to undo bus_set_iommu() in the error path, so move it to the end of rk_iommu_probe(). Signed-off-by: Jeffy Chen Reviewed-by: Tomasz Figa Reviewed-by: Robin Murphy --- Changes in v7: None Changes in v6: None Changes

[PATCH v7 11/14] iommu/rockchip: Use OF_IOMMU to attach devices automatically

Converts the rockchip-iommu driver to use the OF_IOMMU infrastructure, which allows attaching master devices to their IOMMUs automatically according to DT properties. Signed-off-by: Jeffy Chen Reviewed-by: Robin Murphy --- Changes in v7: None

[PATCH v7 14/14] iommu/rockchip: Support sharing IOMMU between masters

There would be some masters sharing the same IOMMU device. Put them in the same iommu group and share the same iommu domain. Signed-off-by: Jeffy Chen Reviewed-by: Robin Murphy --- Changes in v7: Use iommu_group_ref_get to avoid ref leak

[PATCH v7 10/14] iommu/rockchip: Use IOMMU device for dma mapping operations

Use the first registered IOMMU device for dma mapping operations, and drop the domain platform device. This is similar to exynos iommu driver. Signed-off-by: Jeffy Chen Reviewed-by: Tomasz Figa Reviewed-by: Robin Murphy ---

[PATCH v7 09/14] dt-bindings: iommu/rockchip: Add clock property

Add clock property, since we are going to control clocks in rockchip iommu driver. Signed-off-by: Jeffy Chen Reviewed-by: Rob Herring --- Changes in v7: None Changes in v6: Fix dt-binding as Robin suggested. Use aclk and iface clk as Rob and Robin

[PATCH v7 08/14] iommu/rockchip: Control clocks needed to access the IOMMU

From: Tomasz Figa Current code relies on master driver enabling necessary clocks before IOMMU is accessed, however there are cases when the IOMMU should be accessed while the master is not running yet, for example allocating V4L2 videobuf2 buffers, which is done by the VB2

[PATCH v7 05/14] iommu/rockchip: Use iopoll helpers to wait for hardware

From: Tomasz Figa This patch converts the rockchip-iommu driver to use the in-kernel iopoll helpers to wait for certain status bits to change in registers instead of an open-coded custom macro. Signed-off-by: Tomasz Figa Signed-off-by: Jeffy Chen

[PATCH v7 06/14] iommu/rockchip: Fix TLB flush of secondary IOMMUs

From: Tomasz Figa Due to the bug in current code, only first IOMMU has the TLB lines flushed in rk_iommu_zap_lines. This patch fixes the inner loop to execute for all IOMMUs and properly flush the TLB. Signed-off-by: Tomasz Figa Signed-off-by: Jeffy Chen

[PATCH v7 04/14] iommu/rockchip: Fix error handling in attach

From: Tomasz Figa Currently if the driver encounters an error while attaching device, it will leave the IOMMU in an inconsistent state. Even though it shouldn't really happen in reality, let's just add proper error path to keep things consistent. Signed-off-by: Tomasz Figa

[PATCH v7 03/14] iommu/rockchip: Request irqs in rk_iommu_probe()

Move request_irq to the end of rk_iommu_probe(). Suggested-by: Robin Murphy Signed-off-by: Jeffy Chen Reviewed-by: Tomasz Figa --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in

[PATCH v7 01/14] iommu/rockchip: Prohibit unbind and remove

Removal of IOMMUs cannot be done reliably. This is similar to exynos iommu driver. Signed-off-by: Jeffy Chen Reviewed-by: Tomasz Figa --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: Rewrite commit message. Changes

[PATCH v7 00/14] iommu/rockchip: Use OF_IOMMU

This series fixes some issues in rockchip iommu driver, and add of_iommu support in it. Changes in v7: Add WARN_ON in irq isr, and modify iommu archdata comment. Use iommu_group_ref_get to avoid ref leak Changes in v6: Add clk names, and modify all iommu nodes in all existing rockchip dts Fix

[PATCH v7 02/14] iommu/rockchip: Fix error handling in probe

Add missing iommu_device_sysfs_remove in error path. Signed-off-by: Jeffy Chen Reviewed-by: Tomasz Figa --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None

Re: [RESEND PATCH v6 09/14] dt-bindings: iommu/rockchip: Add clock property

Hi Rob, Thanks for your reply. On 03/06/2018 10:27 AM, Rob Herring wrote: On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote: Add clock property, since we are going to control clocks in rockchip iommu driver. Signed-off-by: Jeffy Chen --- Changes in v6:

Re: [RESEND PATCH v6 09/14] dt-bindings: iommu/rockchip: Add clock property

On Thu, Mar 01, 2018 at 06:18:32PM +0800, Jeffy Chen wrote: > Add clock property, since we are going to control clocks in rockchip > iommu driver. > > Signed-off-by: Jeffy Chen > --- > > Changes in v6: None Really? There was a different number of clocks before. >

Re: [RESEND PATCH v6 13/14] iommu/rockchip: Add runtime PM support

Hi Tomasz, Thanks for your reply. On 03/05/2018 09:49 PM, Tomasz Figa wrote: > struct rk_iommudata { >+ struct device_link *link; /* runtime PM link from IOMMU to master */ Kerneldoc comment for the struct could be added instead. i saw this in the kerneldoc: * An MMU device exists

Re: [PATCH 07/37] iommu: Add a page fault handler

On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote: > +static struct workqueue_struct *iommu_fault_queue; Is there anyway we can make this fault queue per struct device? Since this is common code, I think it needs some care. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate

Re: [PATCH 07/37] iommu: Add a page fault handler

On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote: > +static int iommu_queue_fault(struct iommu_domain *domain, struct device *dev, > + struct iommu_fault_event *evt) > +{ > + struct iommu_fault_group *group; > + struct iommu_fault_context *fault, *next; > + > +

Re: [PATCH 5/8] dt-bindings: iommu/ipmmu-vmsa: Add R-Car M3-N (R8A77965)

On Mon, Feb 26, 2018 at 06:57:13PM +0100, Jacopo Mondi wrote: > Add Renesas R-Car M3-N (R8A77965) compat string to IPMMU DT bindings > documentation. > > Signed-off-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 1 + > 1 file

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

On 05/03/18 18:39, Christoph Hellwig wrote: On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote: Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the same sort of thing as

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

On Mon, Mar 05, 2018 at 03:48:32PM +, Robin Murphy wrote: > Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's > software-discoverable and the only thing described in DT is the bus "host", > thus we need the same sort of thing as for PCI to map from the child >

Re: Using dma-ranges with iommu to limit range of iova

Hi Robin, On 3/5/2018 5:46 PM, Robin Murphy wrote: Hi Vivek, On 05/03/18 09:06, Vivek Gautam wrote: Hi all, I have a question regarding usage of 'dma-ranges', can someone point me in the right direction? On qcom soc, few of the master devices with iommu attached to them, have limitations

[PATCH 12/13] swiotlb: remove swiotlb_set_mem_attributes

Now that set_memory_decrypted is always available we can just call it directly. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/mm/mem_encrypt.c | 9 - lib/swiotlb.c | 12 ++-- 3 files changed,

[PATCH 13/13] swiotlb: remove swiotlb_{alloc,free}_coherent

Unused now that everyone uses swiotlb_{alloc,free}. Signed-off-by: Christoph Hellwig --- include/linux/swiotlb.h | 8 lib/swiotlb.c | 38 -- 2 files changed, 46 deletions(-) diff --git a/include/linux/swiotlb.h

[PATCH 11/13] dma-direct: handle the memory encryption bit in common code

Give the basic phys_to_dma and dma_to_phys helpers a __-prefix and add the memory encryption mask to the non-prefixed versions. Use the __-prefixed versions directly instead of clearing the mask again in various places. With that in place the generic dma-direct routines can be used to allocate

use generic dma-direct and swiotlb code for x86

Hi all, this series switches the x86 code the the dma-direct implementation for direct (non-iommu) dma and the generic swiotlb ops. This includes getting rid of the special ops for the AMD memory encryption case and the STA2x11 SOC. The generic implementations are based on the x86 code, so they

[PATCH 10/13] set_memory.h: provide set_memory_{en,de}crypted stubs

Signed-off-by: Christoph Hellwig --- include/linux/set_memory.h | 12 1 file changed, 12 insertions(+) diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h index e5140648f638..da5178216da5 100644 --- a/include/linux/set_memory.h +++

[PATCH 07/13] iommu/amd_iommu: use dma_direct_{alloc,free}

This cleans up the code a lot by removing duplicate logic. Signed-off-by: Christoph Hellwig --- drivers/iommu/Kconfig | 1 + drivers/iommu/amd_iommu.c | 68 +++ 2 files changed, 22 insertions(+), 47 deletions(-) diff --git

[PATCH 02/13] x86: remove dma_alloc_coherent_mask

These days all devices (including the ISA fallback device) have a coherent DMA mask set, so remove the workaround. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 18 ++ arch/x86/kernel/pci-dma.c | 10 --

[PATCH 08/13] iommu/intel-iommu: cleanup intel_{alloc,free}_coherent

Use the dma_direct_* helpers and cleanup the code flow. Signed-off-by: Christoph Hellwig --- drivers/iommu/Kconfig | 1 + drivers/iommu/intel-iommu.c | 62 - 2 files changed, 17 insertions(+), 46 deletions(-) diff --git

[PATCH 09/13] x86: remove dma_alloc_coherent_gfp_flags

All dma_ops implementations used on x86 now take care of setting their own required GFP_ masks for the allocation. And given that the common code now clears harmful flags itself that means we can stop the flags in all the iommu implementations as well. Signed-off-by: Christoph Hellwig

[PATCH 01/13] x86: remove X86_PPRO_FENCE

There were only a few Pentium Pro multiprocessors systems where this errata applied. They are more than 20 years old now, and we've slowly dropped places where put the workarounds in and discouraged anyone from enabling the workaround. Get rid of it for good. Signed-off-by: Christoph Hellwig

[PATCH 03/13] x86: use dma-direct

The generic dma-direct implementation is now functionally equivalent to the x86 nommu dma_map implementation, so switch over to using it. Note that the various iommu drivers are switched from x86_dma_supported to dma_direct_supported to provide identical functionality, although the checks looks

[PATCH 06/13] x86/amd_gart: use dma_direct_{alloc,free}

This gains support for CMA allocations for the force_iommu case, and cleans up the code a bit. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/amd_gart_64.c | 36 ++-- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git

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

Hi Tomasz, On 3/5/2018 6:55 PM, Tomasz Figa wrote: Hi Vivek, On Fri, Mar 2, 2018 at 7:10 PM, Vivek Gautam 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

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Monday, March 05, 2018 21:07 > To: Nipun Gupta ; will.dea...@arm.com; > mark.rutl...@arm.com; catalin.mari...@arm.com > Cc: iommu@lists.linux-foundation.org; robh...@kernel.org;

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

On 05/03/18 15:08, Christoph Hellwig wrote: We should not add any new hardocded busses here. Please mark them in OF/ACPI. Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's software-discoverable and the only thing described in DT is the bus "host", thus we need the

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

On Sat, Mar 03, 2018 at 07:19:06PM +0100, Fredrik Noring wrote: > Christoph, Alan, > > > If it is allocating / freeing this memory all the time in the hot path > > it should really use a dma pool (see include/ilinux/dmapool.h). > > The dma coherent APIs aren't really built for being called in the

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

We should not add any new hardocded busses here. Please mark them in OF/ACPI. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Monday, March 05, 2018 20:23 > To: Nipun Gupta ; will.dea...@arm.com; > mark.rutl...@arm.com; catalin.mari...@arm.com > Cc: iommu@lists.linux-foundation.org; robh...@kernel.org;

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

Hi Joerg, What do you think about v3? It looks like, I can solve my softlookups with just a bit more proper ratelimiting.. On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote: > There is a ratelimit for printing, but it's incremented each time the > cpu recives dmar fault interrupt. While

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

On 05/03/18 14:29, Nipun Gupta wrote: The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a binding for mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Given that allowing "msi-parent" for #msi-cells > 1

[bug report] iommu/arm-smmu: Make use of the iommu_register interface

Hello Joerg Roedel, This is a semi-automatic email about new static checker warnings. The patch 9648cbc9625b: "iommu/arm-smmu: Make use of the iommu_register interface" from Feb 1, 2017, leads to the following Smatch complaint: ./drivers/iommu/arm-smmu-v3.c:1957 arm_smmu_remove_device()

Re: [RESEND PATCH v6 13/14] iommu/rockchip: Add runtime PM support

On Mon, Mar 5, 2018 at 11:13 PM, Robin Murphy wrote: > On 05/03/18 13:49, Tomasz Figa wrote: > [...] >>> >>> @@ -518,7 +520,12 @@ static irqreturn_t rk_iommu_irq(int irq, void >>> *dev_id) >>> u32 int_status; >>> dma_addr_t iova; >>> irqreturn_t

[PATCH 5/6] dma-mapping: support fsl-mc bus

Signed-off-by: Nipun Gupta --- drivers/base/dma-mapping.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 3b11835..2279c4d 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@

[PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

Signed-off-by: Nipun Gupta --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi index f3a40af..1f15492

[PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver

The dma setup for fsl-mc devices is being done from device_add() function. So, no need to call in mc bus driver. Signed-off-by: Nipun Gupta --- drivers/bus/fsl-mc/fsl-mc-bus.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus

Implement bus specific support for the fsl-mc bus including registering arm_smmu_ops and bus specific device add operations. Signed-off-by: Nipun Gupta --- drivers/iommu/arm-smmu.c | 7 +++ drivers/iommu/iommu.c| 21 + include/linux/fsl/mc.h |

[PATCH 2/6] iommu: support iommu configuration for fsl-mc devices

Signed-off-by: Nipun Gupta --- drivers/iommu/of_iommu.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 5c36a8b..cc2fb9c 100644 --- a/drivers/iommu/of_iommu.c +++

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

The existing IOMMU bindings cannot be used to specify the relationship between fsl-mc devices and IOMMUs. This patch adds a binding for mapping fsl-mc devices to IOMMUs, using a new iommu-parent property. Signed-off-by: Nipun Gupta ---

[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. These patches - Define the new property 'iommu-parent' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3) - Adds the dma-mapping support

Re: [RESEND PATCH v6 13/14] iommu/rockchip: Add runtime PM support

On 05/03/18 13:49, Tomasz Figa wrote: [...] @@ -518,7 +520,12 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id) u32 int_status; dma_addr_t iova; irqreturn_t ret = IRQ_NONE; - int i; + int i, err, need_runtime_put; nit: need_runtime_put could be a

Re: [RESEND PATCH v6 13/14] iommu/rockchip: Add runtime PM support

Hi Jeffy, On Thu, Mar 1, 2018 at 7:18 PM, Jeffy Chen wrote: > When the power domain is powered off, the IOMMU cannot be accessed and > register programming must be deferred until the power domain becomes > enabled. > > Add runtime PM support, and use runtime PM device

Re: [RESEND PATCH v6 03/14] iommu/rockchip: Request irqs in rk_iommu_probe()

Hi Jeffy, On Thu, Mar 1, 2018 at 7:18 PM, Jeffy Chen wrote: > Move request_irq to the end of rk_iommu_probe(). > > Suggested-by: Robin Murphy > Signed-off-by: Jeffy Chen > --- > > Changes in v6: None > Changes in v5:

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

Hi Vivek, On Fri, Mar 2, 2018 at 7:10 PM, Vivek Gautam 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 smmu's > runtime

Re: [PATCH 35/37] iommu/arm-smmu-v3: Add support for PRI

On 05/03/18 12:29, Dongdong Liu wrote: >> >> +static int arm_smmu_enable_pri(struct arm_smmu_master_data *master) >> +{ >> +int ret, pos; >> +struct pci_dev *pdev; >> +/* >> + * TODO: find a good inflight PPR number. We should divide the PRI queue >> + * by the number of

Re: [PATCH 35/37] iommu/arm-smmu-v3: Add support for PRI

+static int arm_smmu_enable_pri(struct arm_smmu_master_data *master) +{ + int ret, pos; + struct pci_dev *pdev; + /* +* TODO: find a good inflight PPR number. We should divide the PRI queue +* by the number of PRI-capable devices, but it's impossible to know +

Re: Using dma-ranges with iommu to limit range of iova

Hi Vivek, On 05/03/18 09:06, Vivek Gautam wrote: Hi all, I have a question regarding usage of 'dma-ranges', can someone point me in the right direction? On qcom soc, few of the master devices with iommu attached to them, have limitations in using the iova address range. They can allow the

Using dma-ranges with iommu to limit range of iova

Hi all, I have a question regarding usage of 'dma-ranges', can someone point me in the right direction? On qcom soc, few of the master devices with iommu attached to them, have limitations in using the iova address range. They can allow the iova to be only in a certain range, e.g. video codec