Clean up exposure of arch-internal code
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 of 18 patches 0 repliesNew
3 of 18 patches are in this archive. The cover letter announces 18.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 16/18 | iommu: tegra-smmu: get_use | +0 | 0 replies | |
| 17/18 | iommu: tegra-smmu: more cleanups | +0 | 0 replies | |
| 18/18 | iommu: tegra-smmu: remove cacheflush.h | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/18] Clean up exposure of arch-internal code
Quoted 30 lines · Russell King - ARM Linux
Quoted 29 lines · Thierry Reding
Quoted 27 lines · Russell King - ARM Linux
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()anddmac_unmap_area()prototypes out ofasm/cacheflush.hand intoarch/arm/mm.
(b) provide asecure_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.
Quoted 4 lines
Quoted 1 line
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. =)
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
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>