Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro
Date: Wed Jun 17 2026 - 12:42:59 EST
On 6/16/2026 5:52 AM, Dmitry Baryshkov wrote:
On Mon, Jun 15, 2026 at 06:55:45PM +0530, Bibek Kumar Patro wrote:
On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
On some SoCs the SMMU registers require an active interconnect
bandwidth vote to be accessible. While other clients typically
satisfy this requirement implicitly, certain corner cases (e.g.
during sleep/wakeup transitions) can leave the SMMU without a
vote, causing intermittent register access failures.
Add support for an optional interconnect path to the arm-smmu
driver and vote for bandwidth while the SMMU is active. The path
is acquired from DT if present and ignored otherwise.
The bandwidth vote is enabled before accessing SMMU registers
during probe and runtime resume, and released during runtime
suspend and on error paths.
Generally, from an architectural perspective, GEM_NOC and DDR are
expected to have an active vote whenever the adreno_smmu block is
powered on. In most common use cases, this requirement is implicitly
satisfied because other GPU-related clients (for example, the GMU
device) already hold a GEM_NOC vote when adreno_smmu is enabled.
However, there are certain corner cases, such as during sleep/wakeup
transitions, where the GEM_NOC vote can be removed before adreno_smmu
is powered down. If adreno_smmu is then accessed while the interconnect
vote is missing, it can lead to the observed failures. Because of the
precise ordering involved, this scenario is difficult to reproduce
consistently.
(also GDSC is involved in adreno usecases can have an independent vote)
Signed-off-by: Bibek Kumar Patro <bibek.patro@xxxxxxxxxxxxxxxx>
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
2 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -53,6 +53,11 @@
#define MSI_IOVA_BASE 0x8000000
#define MSI_IOVA_LENGTH 0x100000
+/* Interconnect bandwidth vote values for the SMMU register access path */
+#define ARM_SMMU_ICC_AVG_BW 0
+#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
totally random numbers, which might be different for non-Qualcomm platform.
+#define ARM_SMMU_ICC_PEAK_BW_LOW 0
+
static int force_stage;
module_param(force_stage, int, S_IRUGO);
MODULE_PARM_DESC(force_stage,
@@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
}
}
+static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
+{
+ smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
Is there always only one bus / path in question?
<Apologies, missed to respond to this query>
Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
while accessing the DDR in downstream path (client->TCU->DDR), which we are
addressing here.
Hence it's only one icc path in question here.
Again, you are describing Qualcomm platform, while the code part is
generic.
ah yes, single icc path is specific to Qualcomm platforms as of now.
As per my assumption, it's possible for other vendors/ARM-SMMU users to
have one or more than one icc path to reach DDR in downstream flow
(similar to clocks).
I will revisit the logic for icc_voting to check for possibility on
additional icc path as well, so the generic code can cater to other arm-
smmu users.
Thanks & regards,
Bibek