From: m.szyprowski@samsung•com (Marek Szyprowski)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping
Date: Thu, 05 Mar 2015 15:31:04 +0100 [thread overview]
Message-ID: <54F868A8.7070103@samsung.com> (raw)
In-Reply-To: <cover.1421086706.git.robin.murphy@arm.com>
Hello,
On 2015-01-12 21:48, Robin Murphy wrote:
> Hi all,
>
> Whilst it's a long way off perfect, this has reached the point of being
> functional and stable enough to be useful, so here it is. The core
> consists of the meat of the arch/arm implementation modified to remove
> the assumption of PAGE_SIZE pages and ported over to the Intel IOVA
> allocator instead of the bitmap-based one. For that, this series depends
> on my "Genericise the IOVA allocator" series posted earlier[1].
I've tested your patches on Exynos 5433 based system and I have a few
comments. To get them working I had to do some fixes. Most of them
are already reported in this thread, the remaining I will send in a few
minutes.
Do you plan to send an updated patchset?
> There are plenty of obvious things still to do, including:
>
> * Domain and group handling is all wrong, but that's a bigger problem.
> For the moment it does more or less the same thing as the arch/arm
> code, which at least works for the one-IOMMU-per-device situation.
> * IOMMU domains and IOVA domains probably want to be better integrated
> with devices and each other, rather than having a proliferation of
> arch-specific structs.
> * The temporary map_sg implementation - I have a 'proper' iommu_map_sg
> based one in progress, but since the simple one works it's not been
> as high a priority.
Well, for ARM arch this was the main feature of IOMMU and DMA-mapping
integration. It is heavily used by some multimedia devices and dma-buf
realted stuff to get a scattered buffer mapped into contiguous IO address
space.
> * Port arch/arm over to it. I'd guess it might be preferable to merge
> this through arm64 first, though, rather than overcomplicate matters.
I think that the code in arch/arm is already quite well tested and can be
almost directly reused for common dma-mapping helpers.
> * There may well be scope for streamlining and tidying up the copied
> parts - In general I've simply avoided touching anything I don't
> fully understand.
> * In the same vein, I'm sure lots of it is fairly ARM-specific, so will
> need longer-term work to become truly generic.
>
> [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8208
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2015-03-05 14:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 20:48 [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 1/5] arm64: Combine coherent and non-coherent swiotlb dma_ops Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 2/5] arm64: implement generic IOMMU configuration Robin Murphy
2015-01-12 20:48 ` [RFC PATCH 3/5] iommu: implement common IOMMU ops for DMA mapping Robin Murphy
2015-01-23 17:42 ` Laura Abbott
2015-01-23 18:14 ` Robin Murphy
2015-01-27 0:21 ` Joerg Roedel
2015-01-27 12:27 ` Robin Murphy
2015-01-27 12:38 ` Joerg Roedel
2015-01-28 13:53 ` Will Deacon
2015-01-12 20:48 ` [RFC PATCH 4/5] arm64: add IOMMU dma_ops Robin Murphy
2015-01-23 15:26 ` Will Deacon
2015-01-23 17:33 ` Robin Murphy
2015-01-26 3:25 ` Joseph Lo
2015-01-27 17:30 ` Robin Murphy
2015-01-26 9:10 ` Joseph Lo
2015-01-28 2:22 ` Joseph Lo
2015-03-05 14:31 ` Marek Szyprowski
2015-01-12 20:48 ` [RFC PATCH 5/5] arm64: hook up " Robin Murphy
2015-01-13 8:02 ` [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping Yingjoe Chen
2015-01-13 12:07 ` Robin Murphy
2015-01-15 18:35 ` Robin Murphy
2015-01-16 7:21 ` Yong Wu
2015-01-16 20:12 ` Robin Murphy
2015-01-13 11:08 ` Stefano Stabellini
2015-01-13 11:45 ` Robin Murphy
2015-01-23 16:47 ` Catalin Marinas
2015-01-23 17:41 ` Robin Murphy
2015-03-05 14:31 ` Marek Szyprowski [this message]
2015-03-05 16:42 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F868A8.7070103@samsung.com \
--to=m.szyprowski@samsung$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox