On 14/08/2019 19:05, Will Deacon wrote:
On Fri, Aug 09, 2019 at 06:07:41PM +0100, Robin Murphy wrote:
To keep register-access quirks manageable, we want to structure things
to avoid needing too many individual overrides. It seems fairly clean to
have a single interface which handles both global and context registers
in terms of the architectural pages, so the first preparatory step is to
rework cb_base into a page number rather than an absolute address.
Signed-off-by: Robin Murphy <robin.mur...@arm.com>
---
drivers/iommu/arm-smmu.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index d9a93e5f422f..463bc8d98adb 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -95,7 +95,7 @@
#endif
/* Translation context bank */
-#define ARM_SMMU_CB(smmu, n) ((smmu)->cb_base + ((n) << (smmu)->pgshift))
+#define ARM_SMMU_CB(smmu, n) ((smmu)->base + (((smmu)->cb_base + (n)) <<
(smmu)->pgshift))
#define MSI_IOVA_BASE 0x8000000
#define MSI_IOVA_LENGTH 0x100000
@@ -168,8 +168,8 @@ struct arm_smmu_device {
struct device *dev;
void __iomem *base;
- void __iomem *cb_base;
- unsigned long pgshift;
+ unsigned int cb_base;
I think this is now a misnomer. Would you be able to rename it cb_pfn or
something, please?
Good point; in the architectural terms (section 8.1 of the spec),
SMMU_CB_BASE is strictly a byte offset from SMMU_BASE, and the quantity
we now have here is actually NUMPAGE. I've renamed it as such and
tweaked the comments to be a bit more useful too.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
