[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANqRtoRiZOPhCBo38zVLL6tQB2aBLy3uWWbqJJypxEFDXJwF1Q@mail.gmail.com>
Date: Tue, 15 Mar 2016 20:18:06 +0900
From: Magnus Damm <magnus.damm@...il.com>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: iommu@...ts.linux-foundation.org,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Inki Dae <inki.dae@...sung.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Heiko Stuebner <heiko@...ech.de>,
Arnd Bergmann <arnd@...db.de>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Catalin Marinas <catalin.marinas@....com>,
Joerg Roedel <joro@...tes.org>,
Will Deacon <will.deacon@....com>,
dri-devel@...ts.freedesktop.org, Tomasz Figa <tfiga@...omium.org>,
linaro-mm-sig@...ts.linaro.org, Sakari Ailus <sakari.ailus@....fi>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Mark Yao <mark.yao@...k-chips.com>,
Robin Murphy <robin.murphy@....com>
Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture
Hi Marek,
On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
<m.szyprowski@...sung.com> wrote:
> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
> side-effect of this change is a switch from bitmap-based IO address space
> management to tree-based code. There should be no functional changes
> for drivers, which rely on initialization from generic arch_setup_dna_ops()
> interface. Code, which used old arm_iommu_* functions must be updated to
> new interface.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
> ---
Thanks for your efforts and my apologies for late comments. Just FYI
I'll try your patch (and this series) with the ipmmu-vmsa.c driver on
32-bit ARM and see how it goes. Nice not to have to support multiple
interfaces depending on architecture!
One question that comes to mind is how to handle features.
For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS
while the shared code in drivers/iommu/dma-iommu.c does not. I assume
existing users may rely on such features so from my point of view it
probably makes sense to carry over features from the 32-bit ARM code
into the shared code before pulling the plug.
I also wonder if it is possible to do a step-by-step migration and
support both old and new interfaces in the same binary? That may make
things easier for multiplatform enablement. So far I've managed to
make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some
ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with
the shared code in drivers/iommu/dma-iommu.c may also be possible. And
probably involving even more ugly magic. =)
Cheers,
/ magnus
Powered by blists - more mailing lists