Hi Joerg,
On 01/10/15 20:13, Robin Murphy wrote:
Hi all,
Here's the latest, and hopefully last, revision of the initial arm64
IOMMU dma_ops support.
There are a couple of dependencies still currently in -next and the
intel-iommu tree[0]: "iommu: iova: Move iova cache management to the
iova library" is necessary for the rename of iova_cache_get(), and
"iommu/iova: Avoid over-allocating when size-aligned" will be needed
with some IOMMU drivers to prevent unmapping errors.
Changes from v5[1]:
- Change __iommu_dma_unmap() from BUG to WARN when things go wrong, and
prevent a NULL dereference on double-free.
- Fix iommu_dma_map_sg() to ensure segments can never inadvertently end
mapped across a segment boundary. As a result, we have to lose the
segment-merging optimisation from before (I might revisit that if
there's some evidence it's really worthwhile, though).
- Cleaned up the platform device workarounds for config order and
default domains, and removed the other hacks. Demanding that the IOMMU
drivers assign groups, and support IOMMU_DOMAIN_DMA via the methods
provided, keeps things bearable, and the behaviour should now be
consistent across all cases.
I realise there was one other point you raised which I never explicitly
addressed (I had to go off and do some investigation at the time) - the
domain detach/free in arch_teardown_dma_ops does currently get called if
the client device driver fails it probe (or asks to defer). This
prevents us leaking any of our own domains we had to create, and lets us
start from a clean slate if the device gets re-probed later.
Anyway, what are your thoughts on taking this for 4.4? Since the
dependencies are now in and we're at -rc5 already, I'm on the verge of
reposting a self-contained version to go through arm64, as we really
need to unblock all the follow-on development there (it's a shame that
of the people I'm aware want this, it's only me and the Mediatek/Chrome
guys here on the list saying so).
Yes, there's still plenty more to do in the OF/device layer for platform
device infrastructure as a whole (I hope my last reply[0] helped explain
why it has to look so upside-down compared to the nice simple x86 PCI
model), but I can only do it one chunk at a time ;)
Thanks,
Robin.
[0]:http://article.gmane.org/gmane.linux.kernel.iommu/10607
As a bonus, whilst the underlying of_iommu_configure() code only supports
platform devices at the moment, I can also say that this has now been
tested to work for PCI devices too, via some horrible hacks on a Juno r1.
Thanks,
Robin.
[0]:http://thread.gmane.org/gmane.linux.kernel.iommu/11033
[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/10439
Robin Murphy (3):
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 | 457 ++++++++++++++++++++++++++++++
drivers/iommu/Kconfig | 7 +
drivers/iommu/Makefile | 1 +
drivers/iommu/dma-iommu.c | 524 +++++++++++++++++++++++++++++++++++
include/linux/dma-iommu.h | 85 ++++++
include/linux/iommu.h | 1 +
8 files changed, 1083 insertions(+), 8 deletions(-)
create mode 100644 drivers/iommu/dma-iommu.c
create mode 100644 include/linux/dma-iommu.h
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
