From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Krzysztof Kozlowski
<k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
Bartlomiej Zolnierkiewicz
<b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture
Date: Thu, 25 Feb 2016 15:44:44 +0100 [thread overview]
Message-ID: <4895295.FP9RzJmAYS@wuerfel> (raw)
In-Reply-To: <56CEF2E9.5040706-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote:
> >> +}
> >> +
> >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
> >> + gfp_t flags);
> >> +extern bool arch_in_atomic_pool(void *start, size_t size);
> >> +extern int arch_free_from_atomic_pool(void *start, size_t size);
> >> +
> >> +
> > doesn't feel completely right yet. In particular the arch_flush_page()
> > interface is probably still too specific to ARM/ARM64 and won't work
> > that way on other architectures.
> >
> > I think it would be better to do this either more generic, or less generic:
> >
> > a) leave the iommu_dma_map_ops definition in the architecture specific
> > code, but make it call helper functions in the drivers/iommu to do all
> > of the really generic parts.
> >
> > b) clarify that this is only applicable to arch/arm and arch/arm64, and
> > unify things further between these two, as they have very similar
> > requirements in the CPU architecture.
>
> Some really generic parts are already in iommu/dma-iommu.c and one can build
> it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I
> also wanted to use that generic code on both ARM and ARM64, but it
> turned out
> that both archs, ARM and ARM64 will duplicate 99% of code, which use this
> 'generic' functions. This was the reason why I dedided to move all that
> common code from arch/{arm,arm64}/mm/dma-mapping.c to
> drivers/iommu/dma-iommu-ops.c
>
> I'm not sure if I can design all the changes that need to be made to
> drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will
> try to use that code with other, non-ARM architecture based arch glue code,
> a better abstraction can be developed. For now I would like to keep all this
> code in a common place so both arm and arm64 will benefit from improvements
> done there.
Fair enough. Let's stay with your approach then.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture
Date: Thu, 25 Feb 2016 15:44:44 +0100 [thread overview]
Message-ID: <4895295.FP9RzJmAYS@wuerfel> (raw)
In-Reply-To: <56CEF2E9.5040706@samsung.com>
On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote:
> >> +}
> >> +
> >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
> >> + gfp_t flags);
> >> +extern bool arch_in_atomic_pool(void *start, size_t size);
> >> +extern int arch_free_from_atomic_pool(void *start, size_t size);
> >> +
> >> +
> > doesn't feel completely right yet. In particular the arch_flush_page()
> > interface is probably still too specific to ARM/ARM64 and won't work
> > that way on other architectures.
> >
> > I think it would be better to do this either more generic, or less generic:
> >
> > a) leave the iommu_dma_map_ops definition in the architecture specific
> > code, but make it call helper functions in the drivers/iommu to do all
> > of the really generic parts.
> >
> > b) clarify that this is only applicable to arch/arm and arch/arm64, and
> > unify things further between these two, as they have very similar
> > requirements in the CPU architecture.
>
> Some really generic parts are already in iommu/dma-iommu.c and one can build
> it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I
> also wanted to use that generic code on both ARM and ARM64, but it
> turned out
> that both archs, ARM and ARM64 will duplicate 99% of code, which use this
> 'generic' functions. This was the reason why I dedided to move all that
> common code from arch/{arm,arm64}/mm/dma-mapping.c to
> drivers/iommu/dma-iommu-ops.c
>
> I'm not sure if I can design all the changes that need to be made to
> drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will
> try to use that code with other, non-ARM architecture based arch glue code,
> a better abstraction can be developed. For now I would like to keep all this
> code in a common place so both arm and arm64 will benefit from improvements
> done there.
Fair enough. Let's stay with your approach then.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
dri-devel@lists.freedesktop.org,
Will Deacon <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Joerg Roedel <joro@8bytes.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sakari Ailus <sakari.ailus@iki.fi>,
Mark Yao <mark.yao@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
Tomasz Figa <tfiga@chromium.org>, Inki Dae <inki.dae@samsung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Krzysztof Kozlowski <k.kozlowski@samsung.com>
Subject: Re: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture
Date: Thu, 25 Feb 2016 15:44:44 +0100 [thread overview]
Message-ID: <4895295.FP9RzJmAYS@wuerfel> (raw)
In-Reply-To: <56CEF2E9.5040706@samsung.com>
On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote:
> >> +}
> >> +
> >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
> >> + gfp_t flags);
> >> +extern bool arch_in_atomic_pool(void *start, size_t size);
> >> +extern int arch_free_from_atomic_pool(void *start, size_t size);
> >> +
> >> +
> > doesn't feel completely right yet. In particular the arch_flush_page()
> > interface is probably still too specific to ARM/ARM64 and won't work
> > that way on other architectures.
> >
> > I think it would be better to do this either more generic, or less generic:
> >
> > a) leave the iommu_dma_map_ops definition in the architecture specific
> > code, but make it call helper functions in the drivers/iommu to do all
> > of the really generic parts.
> >
> > b) clarify that this is only applicable to arch/arm and arch/arm64, and
> > unify things further between these two, as they have very similar
> > requirements in the CPU architecture.
>
> Some really generic parts are already in iommu/dma-iommu.c and one can build
> it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I
> also wanted to use that generic code on both ARM and ARM64, but it
> turned out
> that both archs, ARM and ARM64 will duplicate 99% of code, which use this
> 'generic' functions. This was the reason why I dedided to move all that
> common code from arch/{arm,arm64}/mm/dma-mapping.c to
> drivers/iommu/dma-iommu-ops.c
>
> I'm not sure if I can design all the changes that need to be made to
> drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will
> try to use that code with other, non-ARM architecture based arch glue code,
> a better abstraction can be developed. For now I would like to keep all this
> code in a common place so both arm and arm64 will benefit from improvements
> done there.
Fair enough. Let's stay with your approach then.
Arnd
next prev parent reply other threads:[~2016-02-25 14:44 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 8:22 [RFC 0/3] Unify IOMMU-based DMA-mapping code for ARM and ARM64 Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
[not found] ` <1455870164-25337-1-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-02-19 8:22 ` [RFC 1/3] drm/exynos: rewrite IOMMU support code Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-02-19 8:22 ` [RFC 2/3] iommu: dma-iommu: move IOMMU/DMA-mapping code from ARM64 arch to drivers Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-04-18 2:20 ` Mark yao
2016-04-18 2:20 ` Mark yao
2016-04-18 2:20 ` Mark yao
2016-02-19 8:22 ` [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-02-19 8:22 ` Marek Szyprowski
2016-02-19 10:30 ` Arnd Bergmann
2016-02-19 10:30 ` Arnd Bergmann
2016-02-19 10:30 ` Arnd Bergmann
2016-02-25 12:26 ` Marek Szyprowski
2016-02-25 12:26 ` Marek Szyprowski
2016-02-25 12:26 ` Marek Szyprowski
[not found] ` <56CEF2E9.5040706-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-02-25 14:44 ` Arnd Bergmann [this message]
2016-02-25 14:44 ` Arnd Bergmann
2016-02-25 14:44 ` Arnd Bergmann
2016-03-15 12:33 ` Robin Murphy
2016-03-15 12:33 ` Robin Murphy
2016-03-15 12:33 ` Robin Murphy
2016-03-15 11:18 ` Magnus Damm
2016-03-15 11:18 ` Magnus Damm
2016-03-15 11:18 ` Magnus Damm
[not found] ` <CANqRtoRiZOPhCBo38zVLL6tQB2aBLy3uWWbqJJypxEFDXJwF1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-15 11:45 ` Robin Murphy
2016-03-15 11:45 ` Robin Murphy
2016-03-15 11:45 ` Robin Murphy
2016-03-15 12:03 ` Marek Szyprowski
2016-03-15 12:03 ` Marek Szyprowski
2016-03-15 12:03 ` Marek Szyprowski
2016-04-18 2:20 ` Mark yao
2016-04-18 2:20 ` Mark yao
2016-04-18 2:20 ` Mark yao
2016-04-18 2:18 ` [RFC 0/3] Unify IOMMU-based DMA-mapping code for ARM and ARM64 Mark yao
2016-04-18 2:18 ` Mark yao
2016-04-18 2:18 ` Mark yao
2016-04-19 3:17 ` [PATCH] drm/rockchip: rewrite IOMMU support code Mark Yao
2016-04-19 3:17 ` Mark Yao
2016-04-19 3:17 ` Mark Yao
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=4895295.FP9RzJmAYS@wuerfel \
--to=arnd-r2ngtmty4d4@public.gmane.org \
--cc=b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=sakari.ailus-X3B1VOXEql0@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.