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

2015-07-28 Thread Will Deacon
Hi Joerg, Robin,

On Mon, Jul 20, 2015 at 06:23:35PM +0100, Robin Murphy wrote:
> On 20/07/15 16:26, Joerg Roedel wrote:
> > On Thu, Jul 16, 2015 at 07:40:11PM +0100, Robin Murphy wrote:
> >>   arch/arm64/Kconfig   |   1 +
> >>   arch/arm64/include/asm/dma-mapping.h |  15 +-
> >>   arch/arm64/mm/dma-mapping.c  | 452 +
> >
> > What happened to the plan to merge this with the existing iommu-based
> > dma-api implementation for 32 bit ARM?
> 
> The issue currently is that there are a bunch of drivers using the 
> exported arm_iommu_* functions directly. From what I can tell, they seem 
> like they could probably all be converted to using default domains 
> and/or the new domain type abstractions via the core IOMMU API, which 
> would then allow killing off dma_iommu_mapping and rewriting the 
> arch/arm implementation to use the new shared code. I don't currently 
> have any 32-bit platform to test with, so I'm a little dubious of taking 
> that all on myself right now.
> 
> In the meantime on arm64, DMA mapping ops are needed for SMMUv3 platform 
> device support, the Mediatek M4U patches and my own SMMUv2 work, so it 
> would be very useful to get the arm64 and common code in as a first 
> step, then look at cleaning up arch/arm for 4.4 without dangling 
> dependencies.

What's the plan with this? Do we need to port 32-bit ARM before it's a
candidate for merging, or can we push ahead with getting this up and
running for arm64 (which currently can't use an IOMMU for DMA)?

Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


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

2015-07-20 Thread Robin Murphy

Hi Joerg,

On 20/07/15 16:26, Joerg Roedel wrote:

On Thu, Jul 16, 2015 at 07:40:11PM +0100, Robin Murphy wrote:

  arch/arm64/Kconfig   |   1 +
  arch/arm64/include/asm/dma-mapping.h |  15 +-
  arch/arm64/mm/dma-mapping.c  | 452 +


What happened to the plan to merge this with the existing iommu-based
dma-api implementation for 32 bit ARM?


The issue currently is that there are a bunch of drivers using the 
exported arm_iommu_* functions directly. From what I can tell, they seem 
like they could probably all be converted to using default domains 
and/or the new domain type abstractions via the core IOMMU API, which 
would then allow killing off dma_iommu_mapping and rewriting the 
arch/arm implementation to use the new shared code. I don't currently 
have any 32-bit platform to test with, so I'm a little dubious of taking 
that all on myself right now.


In the meantime on arm64, DMA mapping ops are needed for SMMUv3 platform 
device support, the Mediatek M4U patches and my own SMMUv2 work, so it 
would be very useful to get the arm64 and common code in as a first 
step, then look at cleaning up arch/arm for 4.4 without dangling 
dependencies.


Robin.




Joerg



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


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

2015-07-20 Thread Joerg Roedel
On Thu, Jul 16, 2015 at 07:40:11PM +0100, Robin Murphy wrote:
>  arch/arm64/Kconfig   |   1 +
>  arch/arm64/include/asm/dma-mapping.h |  15 +-
>  arch/arm64/mm/dma-mapping.c  | 452 +

What happened to the plan to merge this with the existing iommu-based
dma-api implementation for 32 bit ARM?


Joerg

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[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 potential
  access the wrong side of clearing/freeing the pages.
- Made the unconditional clearing of allocations a bit more explicit.
- Made the default domain workaround more robust against the possibility
  of an IOMMU driver giving back the same domain for multiple devices.

Robin.

v3: http://thread.gmane.org/gmane.linux.kernel.iommu/10133
Updated branch at: git://linux-arm.org/linux-rm iommu/dma

Robin Murphy (4):
  iommu/iova: Avoid over-allocating when size-aligned
  iommu: Implement common IOMMU ops for DMA mapping
  arm64: Add IOMMU dma_ops
  arm64: Hook up IOMMU dma_ops

 arch/arm64/Kconfig   |   1 +
 arch/arm64/include/asm/dma-mapping.h |  15 +-
 arch/arm64/mm/dma-mapping.c  | 452 +
 drivers/iommu/Kconfig|   7 +
 drivers/iommu/Makefile   |   1 +
 drivers/iommu/dma-iommu.c| 538 +++
 drivers/iommu/intel-iommu.c  |   2 +
 drivers/iommu/iova.c |  23 +-
 include/linux/dma-iommu.h|  84 ++
 include/linux/iommu.h|   1 +
 10 files changed, 1099 insertions(+), 25 deletions(-)
 create mode 100644 drivers/iommu/dma-iommu.c
 create mode 100644 include/linux/dma-iommu.h

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu