From: thierry.reding@gmail•com (Thierry Reding)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 00/18] Clean up exposure of arch-internal code
Date: Mon, 27 Jul 2015 16:31:42 +0200 [thread overview]
Message-ID: <20150727143141.GA4774@ulmo.nvidia.com> (raw)
In-Reply-To: <20150727141654.GI7557@n2100.arm.linux.org.uk>
On Mon, Jul 27, 2015 at 03:16:54PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 27, 2015 at 04:09:06PM +0200, Thierry Reding wrote:
> > On Mon, Jul 27, 2015 at 01:28:24PM +0100, Russell King - ARM Linux wrote:
> > > This series of patches attempts to clean up the use of architecture
> > > internal functions in drivers, and removes some functions from view
> > > in the asm/ headers. I'm also considering whether we need to add
> > > some linker magic to hide symbols when building the built-in.o files.
> > >
> > > This was triggered by 3rd party drivers "going under the covers" of
> > > the DMA API and calling the dmac_*() functions directly, a practice
> > > which I have always refused to allow. This also breaks module
> > > building (which is the big hint that they're doing something wrong.)
> > >
> > > However, it also came to light that various drivers are using
> > > __cpuc_* functions directly, which are non-portable, and is another
> > > instance of "going under the covers" and tinkering with what should
> > > be kept as architecture implementation details.
> > >
> > > This series addresses some of these points. It:
> > >
> > > (a) moves dmac_map_area() and dmac_unmap_area() prototypes out of
> > > asm/cacheflush.h and into arch/arm/mm.
> > > (b) provide a secure_flush() call for the Qualcomm secure monitor
> > > code.
> > > (c) stop tegra smmu driver(s) from using __cpuc_flush_dcache_area,
> > > something which necessitates additional complexity to deal with
> > > the ARM vs ARM64 differences. It should be using the DMA API.
> > > However, the Tegra SMMU driver is in really bad shape, and this
> > > isn't a simple conversion - it requires a lot of additional
> > > fixes to bring the code up to scratch.
> >
> > Out of curiosity, did you have any hardware to test this on?
>
> Nope - it only got build-tested, and it's partly why there's soo many
> incremental small patches.
All the more impressive. =)
> > > It leaves the Rockchip IOMMU driver for the time being, but that is also
> > > something which needs cleaning up in the same way as the Tegra SMMU
> > > driver.
> >
> > From a cursory look, MSM, OMAP and Exynos are in the same boat as well.
>
> Yes. There is a question here though:
>
> Is it a good idea to use normal cacheable memory for the IOMMU page table
> entries, or would DMA coherent memory be better?
Currently I think coherent memory would do just as well as cacheable
memory, maybe even better given that we wouldn't need the cache
maintenance. However, I think cacheable memory might come in handy if
ever the ->map_sg() callback gets implemented, because it would allow us
to batch up a bunch of PTE writes and flush whole pages in one go.
Unfortunately I don't have the tools handy to provide any numbers, so
the above is really just guesswork. Cc'ing Rob Clark who, I think, did
performance measurements a while ago. Not sure if those included
coherent vs. cacheable memory, though.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150727/3cbb9673/attachment.sig>
next prev parent reply other threads:[~2015-07-27 14:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 12:28 [PATCH 00/18] Clean up exposure of arch-internal code Russell King - ARM Linux
2015-07-27 12:28 ` [PATCH 01/18] ARM: reduce visibility of dmac_* functions Russell King
2015-07-27 12:28 ` [PATCH 02/18] firmware: qcom_scm-32: replace open-coded call to __cpuc_flush_dcache_area() Russell King
2015-08-04 18:48 ` Andy Gross
2015-08-04 18:50 ` Stephen Boyd
2015-07-27 12:29 ` [PATCH 03/18] iommu: tegra-smmu: fix iova_to_phys() method Russell King
2015-07-27 12:29 ` [PATCH 04/18] iommu: tegra-smmu: fix unmap() method Russell King
2015-07-27 12:29 ` [PATCH 05/18] iommu: tegra-smmu: factor out common pte setting Russell King
2015-07-27 12:29 ` [PATCH 06/18] iommu: tegra-smmu: add iova_pd_index() and iova_pt_index() helpers Russell King
2015-07-27 12:29 ` [PATCH 07/18] iommu: tegra-smmu: fix page table lookup in unmap/iova_to_phys methods Russell King
2015-07-27 12:29 ` [PATCH 08/18] iommu: tegra-smmu: store struct page pointer for page tables Russell King
2015-07-27 12:29 ` [PATCH 09/18] iommu: tegra-smmu: use kcalloc() to allocate counter array Russell King
2015-07-27 12:29 ` [PATCH 10/18] iommu: tegra-smmu: move flush_dcache to tegra-smmu.c Russell King
2015-07-27 12:29 ` [PATCH 11/18] iommu: tegra-smmu: split smmu_flush_ptc() Russell King
2015-07-27 12:29 ` [PATCH 12/18] iommu: tegra-smmu: smmu_flush_ptc() wants device address Russell King
2015-07-27 12:29 ` [PATCH 13/18] iommu: tegra-smmu: convert to use DMA API Russell King
2015-07-27 12:29 ` [PATCH 14/18] iommu: tegra-smmu: remove PageReserved manipulation Russell King
2015-07-27 12:30 ` [PATCH 15/18] iommu: tegra-smmu: use __GFP_ZERO to allocate zeroed pages Russell King
2015-07-27 12:30 ` [PATCH 16/18] iommu: tegra-smmu: get_use Russell King
2015-07-27 14:11 ` Thierry Reding
2015-07-27 12:30 ` [PATCH 17/18] iommu: tegra-smmu: more cleanups Russell King
2015-07-27 14:12 ` Thierry Reding
2015-07-27 12:30 ` [PATCH 18/18] iommu: tegra-smmu: remove cacheflush.h Russell King
2015-07-27 14:13 ` Thierry Reding
2015-07-27 13:13 ` [PATCH 00/18] Clean up exposure of arch-internal code Joerg Roedel
2015-07-27 14:45 ` Heiko Stübner
2015-07-27 14:09 ` Thierry Reding
2015-07-27 14:16 ` Russell King - ARM Linux
2015-07-27 14:31 ` Thierry Reding [this message]
2015-08-03 11:33 ` Joerg Roedel
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=20150727143141.GA4774@ulmo.nvidia.com \
--to=thierry.reding@gmail$(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