Renesas ipmmu-vmsa: Miscellaneous cleanups and fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 9 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 9 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/9] Renesas ipmmu-vmsa: Miscellaneous cleanups and fixes
Quoted 1 line · Laurent Pinchart
Hello,
Hi Laurent,
Quoted 9 lines
This patch set cleans up and fixes small issues in the ipmmu-vmsa driver. The patches are based on top of "[PATCH v3] iommu: Add driver for Renesas VMSA-compatible IPMMU" that adds the ipmmu-vmsa driver.
The most interesting part of this series is the rewrite of the page table management code. The IOMMU core guarantees that the map and unmap operations will always be called only with page sizes advertised by the driver. We can use that assumption to remove loops of PGD and PMD entries, simplifying the code.
Hmm, interesting. We still have to handle the case where a mapping created with one page-size could be unmapped with another though (in particular, unmapping part of the range).
Quoted 3 lines
Will, would it make sense to perform the same cleanup for the arm-smmu driver, or is there a reason to keep loops over PGD and PMD entries ? Removing them makes the implementation of 68kB and 2MB pages easier.
Is this an assumption that's relied on by other IOMMU drivers? It certainly makes mapping of large ranges less efficient than it could be, so I'm more inclined to set all the bits > PAGE_SIZE in pgsize_bitmap if it's only used to determine the granularity at which map/unmap are called (which is unrelated to what the hardware can actually do).
Will