Re: [PATCH 5/9] iommu: add qcom_iommu

On 3/30/2017 7:16 PM, Rob Clark wrote: On Thu, Mar 30, 2017 at 2:19 AM, Archit Taneja wrote: Hi, On 03/14/2017 08:48 PM, Rob Clark wrote: An iommu driver for Qualcomm "B" family devices which do not completely implement the ARM SMMU spec. These devices have

Re: [PATCH 2/7] iommu/iova: cut down judgement times

On 2017/3/23 20:11, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Below judgement can only be satisfied at the last time, which produced 2N >> judgements(suppose N times failed, 0 or 1 time successed) in vain. >> >> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) { >>

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

Because the problem of my email-server, all patches sent to Joerg Roedel failed. So I repost this email again. On 2017/3/24 11:43, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 21:01, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>> Reserve the first granule

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 2017/3/24 10:27, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 19:42, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>> Keep these four variables type consistent with the paramters of function >>> __alloc_and_insert_iova_range and the members of struct iova: >>> >>> 1. static

[PATCH v2 6/7] iommu/iova: move the caculation of pad mask out of loop

I'm not sure whether the compiler can optimize it, but move it out will be better. At least, it does not require lock protection. Signed-off-by: Zhen Lei --- drivers/iommu/iova.c | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff

[PATCH v2 2/7] iommu/iova: cut down judgement times

Below judgement can only be satisfied at the last time, which produced 2N judgements(suppose N times failed, 0 or 1 time successed) in vain. if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) { return iova; } Signed-off-by: Zhen Lei --- drivers/iommu/iova.c

[PATCH v2 1/7] iommu/iova: fix incorrect variable types

Keep these four variables type consistent with the paramters of function __alloc_and_insert_iova_range and the members of struct iova: 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad, unsigned long size, unsigned long limit_pfn, 2. struct iova {

[PATCH v2 7/7] iommu/iova: fix iovad->dma_32bit_pfn as the last pfn of dma32

To make sure iovad->cached32_node and iovad->cached64_node can exactly control dma32 and dma64 area. It also help us to remove the parameter pfn_32bit of init_iova_domain. Signed-off-by: Zhen Lei --- drivers/iommu/amd_iommu.c| 7 ++-

[PATCH v2 0/7] iommu/iova: improve the allocation performance of dma64

v1 -> v2: Because the problem of my email-server, all patches sent to Joerg Roedel failed. So I repost all these patches again, there is no changes. v1: 64 bits devices is very common now. But currently we only defined a cached32_node to optimize the allocation performance of

[PATCH v2 3/7] iommu/iova: insert start_pfn boundary of dma32

Reserve the first granule size memory(start at start_pfn) as boundary iova, to make sure that iovad->cached32_node can not be NULL in future. Meanwhile, changed the assignment of iovad->cached32_node from rb_next to rb_prev of >node in function __cached_rbnode_delete_update. Signed-off-by: Zhen

[PATCH v2 5/7] iommu/iova: to optimize the allocation performance of dma64

Currently we always search free iova space for dma64 begin at the last node of iovad rb-tree. In the worst case, there maybe too many nodes exist at the tail, so that we should traverse many times for the first loop in __alloc_and_insert_iova_range. As we traced, more than 10K times for the case

[PATCH v2 4/7] iommu/iova: adjust __cached_rbnode_insert_update

For case 2 and 3, adjust cached32_node to the new place, case 1 keep no change. For example: case1: (the right part was allocated) |--| |<-free>|<--new_iova-->| | | cached32_node case2: (all was allocated)

Re: [PATCH v2 4/4] iommu/arm-smmu: Poll for TLB sync completion more effectively

On Thu, Mar 30, 2017 at 05:56:32PM +0100, Robin Murphy wrote: > On relatively slow development platforms and software models, the > inefficiency of our TLB sync loop tends not to show up - for instance on > a Juno r1 board I typically see the TLBI has completed of its own accord > by the time we

Re: [PATCH v2 2/4] iommu/arm-smmu: Tidy up context bank indexing

On Thu, Mar 30, 2017 at 05:56:30PM +0100, Robin Murphy wrote: > ARM_AMMU_CB() is calculated relative to ARM_SMMU_CB_BASE(), but the > latter is never of use on its own, and what we end up with is the same > ARM_SMMU_CB_BASE() + ARM_AMMU_CB() expression being duplicated at every > callsite. Folding

Re: [PATCH v2 1/4] iommu/arm-smmu: Simplify ASID/VMID handling

On Thu, Mar 30, 2017 at 05:56:29PM +0100, Robin Murphy wrote: > Calculating ASIDs/VMIDs dynamically from arm_smmu_cfg was a neat trick, > but the global uniqueness workaround makes it somewhat more awkward, and > means we end up having to pass extra state around in certain cases just > to keep a

[PATCH v2 1/4] iommu/arm-smmu: Simplify ASID/VMID handling

Calculating ASIDs/VMIDs dynamically from arm_smmu_cfg was a neat trick, but the global uniqueness workaround makes it somewhat more awkward, and means we end up having to pass extra state around in certain cases just to keep a handle on the offset. We already have 16 bits going spare in

[PATCH v2 4/4] iommu/arm-smmu: Poll for TLB sync completion more effectively

On relatively slow development platforms and software models, the inefficiency of our TLB sync loop tends not to show up - for instance on a Juno r1 board I typically see the TLBI has completed of its own accord by the time we get to the sync, such that the latter finishes instantly. However, on

[PATCH v2 2/4] iommu/arm-smmu: Tidy up context bank indexing

ARM_AMMU_CB() is calculated relative to ARM_SMMU_CB_BASE(), but the latter is never of use on its own, and what we end up with is the same ARM_SMMU_CB_BASE() + ARM_AMMU_CB() expression being duplicated at every callsite. Folding the two together gives us a self-contained context bank accessor

[PATCH v2 3/4] iommu/arm-smmu: Use per-context TLB sync as appropriate

TLB synchronisation typically involves the SMMU blocking all incoming transactions until the TLBs report completion of all outstanding operations. In the common SMMUv2 configuration of a single distributed SMMU serving multiple peripherals, that means that a single unmap request has the potential

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

Hi Will, 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. Robin. Robin Murphy (4): iommu/arm-smmu: Simplify ASID/VMID handling

Re: [PATCH 4/4] iommu/arm-smmu: Use per-context TLB sync as appropriate

On 30/03/17 15:37, Will Deacon wrote: > Hi Robin, > > This mostly looks great, but I have a couple of minor comments below. > > On Tue, Mar 07, 2017 at 06:09:07PM +, Robin Murphy wrote: >> TLB synchronisation typically involves the SMMU blocking all incoming >> transactions until the TLBs

RE: [PATCH] iommu/amd: flush IOTLB for specific domains only

>-Original Message- >From: Daniel Drake [mailto:dr...@endlessm.com] >Sent: Thursday, March 30, 2017 7:15 PM >To: Nath, Arindam >Cc: j...@8bytes.org; Deucher, Alexander; Bridgman, John; amd- >g...@lists.freedesktop.org; iommu@lists.linux-foundation.org; Suthikulpanit, >Suravee; Linux

Re: [PATCH 0/4] ARM SMMU per-context TLB sync

On Tue, Mar 07, 2017 at 06:09:03PM +, Robin Murphy wrote: > The discussion around context-level access for Qualcomm SMMUs reminded > me to dig up this patch I started ages ago and finish it off. As it's > ended up, it's now a mini-series, with some new preparatory cleanup > manifesting as

Re: [PATCH 5/4] iommu/arm-smmu: Poll for TLB sync completion more effectively

On Thu, Mar 23, 2017 at 05:59:40PM +, Robin Murphy wrote: > On relatively slow development platforms and software models, the > inefficiency of our TLB sync loop tends not to show up - for instance on > a Juno r1 board I typically see the TLBI has completed of its own accord > by the time we

Re: [PATCH 4/4] iommu/arm-smmu: Use per-context TLB sync as appropriate

Hi Robin, This mostly looks great, but I have a couple of minor comments below. On Tue, Mar 07, 2017 at 06:09:07PM +, Robin Murphy wrote: > TLB synchronisation typically involves the SMMU blocking all incoming > transactions until the TLBs report completion of all outstanding > operations.

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

On 30/03/17 12:53, Geert Uytterhoeven wrote: > Hi Robin, > > On Thu, Mar 30, 2017 at 1:46 PM, Robin Murphy wrote: >> On 30/03/17 12:16, Andrzej Hajda wrote: >> [...] >>> I guess Geert's proposition to create pages permanently is also not >>> acceptable[2]. So how to

Re: [PATCH 1/4] iommu/arm-smmu: Handle size mismatches better

Hi Robin, On Tue, Mar 07, 2017 at 06:09:04PM +, Robin Murphy wrote: > We currently warn if the firmware-described region size differs from the > SMMU address space size reported by the hardware, but continue to use > the former to calculate where our context bank base should be, > effectively

Re: [PATCH 5/9] iommu: add qcom_iommu

On Thu, Mar 30, 2017 at 2:19 AM, Archit Taneja wrote: > Hi, > > On 03/14/2017 08:48 PM, Rob Clark wrote: >> >> An iommu driver for Qualcomm "B" family devices which do not completely >> implement the ARM SMMU spec. These devices have context-bank register >> layout that

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

Hi Robin, On Thu, Mar 30, 2017 at 1:46 PM, Robin Murphy wrote: > On 30/03/17 12:16, Andrzej Hajda wrote: > [...] >> I guess Geert's proposition to create pages permanently is also not >> acceptable[2]. So how to fix crashes which appeared after patch adding > If

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

On 30/03/17 12:16, Andrzej Hajda wrote: [...] > I guess Geert's proposition to create pages permanently is also not > acceptable[2]. So how to fix crashes which appeared after patch adding If I'm not mistaken, creating the pages permanently is what the !DMA_ATTR_FORCE_CONTIGUOUS

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

Hi Robin, On 30.03.2017 12:44, Robin Murphy wrote: > On 30/03/17 09:30, Andrzej Hajda wrote: >> On 30.03.2017 09:40, Geert Uytterhoeven wrote: >>> Hi Andrzej, >>> >>> On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote: On 29.03.2017 17:33, Robin Murphy wrote: > On

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

On 30/03/17 09:30, Andrzej Hajda wrote: > On 30.03.2017 09:40, Geert Uytterhoeven wrote: >> Hi Andrzej, >> >> On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote: >>> On 29.03.2017 17:33, Robin Murphy wrote: On 29/03/17 16:12, Andrzej Hajda wrote: > On 29.03.2017

Re: [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask

On Tue, Mar 28, 2017 at 7:43 PM, Rob Herring wrote: > On Tue, Mar 28, 2017 at 12:27 AM, Oza Oza wrote: >> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote: >>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep >>>

Re: [RFC PATCH] of: Fix DMA configuration for non-DT masters

On Thu, Mar 30, 2017 at 8:51 AM, Oza Oza wrote: > On Wed, Mar 29, 2017 at 11:12 PM, Robin Murphy wrote: >> On 29/03/17 06:46, Oza Oza wrote: >>> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza wrote: On Wed, Mar 29, 2017 at 12:27

[RFC PATCH 1/2] of/pci: implement inbound dma-ranges for PCI

current device frmework and of framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. dma-ranges: (child-bus-address, parent-bus-address, length). but iproc based SOCs and other SOCs(rcar) have PCI world dma-ranges. dma-ranges = <0x4300 0x00

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

On 30.03.2017 09:40, Geert Uytterhoeven wrote: > Hi Andrzej, > > On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote: >> On 29.03.2017 17:33, Robin Murphy wrote: >>> On 29/03/17 16:12, Andrzej Hajda wrote: On 29.03.2017 14:55, Robin Murphy wrote: > On 29/03/17

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

Hi Andrzej, On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote: > On 29.03.2017 17:33, Robin Murphy wrote: >> On 29/03/17 16:12, Andrzej Hajda wrote: >>> On 29.03.2017 14:55, Robin Murphy wrote: On 29/03/17 11:05, Andrzej Hajda wrote: > In case of

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

On 29.03.2017 17:33, Robin Murphy wrote: > On 29/03/17 16:12, Andrzej Hajda wrote: >> On 29.03.2017 14:55, Robin Murphy wrote: >>> On 29/03/17 11:05, Andrzej Hajda wrote: In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages is invalid. __iommu_mmap_attrs and

RE: [PATCH] iommu/amd: flush IOTLB for specific domains only

>-Original Message- >From: Nath, Arindam >Sent: Monday, March 27, 2017 5:57 PM >To: 'Daniel Drake' >Cc: j...@8bytes.org; Deucher, Alexander; Bridgman, John; amd- >g...@lists.freedesktop.org; iommu@lists.linux-foundation.org; Suthikulpanit, >Suravee; Linux Upstreaming Team >Subject: RE:

Re: [PATCH 5/9] iommu: add qcom_iommu

Hi, On 03/14/2017 08:48 PM, Rob Clark wrote: An iommu driver for Qualcomm "B" family devices which do not completely implement the ARM SMMU spec. These devices have context-bank register layout that is similar to ARM SMMU, but no global register space (or at least not one that is accessible).