Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro
Date: Mon Jun 08 2026 - 11:24:11 EST
On 6/8/2026 7:20 PM, Dmitry Baryshkov wrote:
On Mon, Jun 08, 2026 at 06:59:34PM +0530, Bibek Kumar Patro wrote:
...
---
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
+#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);
+ if (IS_ERR(smmu->icc_path)) {
+ int err = PTR_ERR(smmu->icc_path);
+
+ if (err == -ENODEV) {
+ smmu->icc_path = NULL;
+ return 0;
+ }
+ return dev_err_probe(smmu->dev, err,
+ "failed to get interconnect path\n");
+ }
+ return 0;
+}
+
+static void arm_smmu_icc_enable(struct arm_smmu_device *smmu)
+{
+ if (smmu->icc_path)
+ WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
+ ARM_SMMU_ICC_PEAK_BW_HIGH));
+}
+
+static void arm_smmu_icc_disable(struct arm_smmu_device *smmu)
+{
+ if (smmu->icc_path)
+ WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
+ ARM_SMMU_ICC_PEAK_BW_LOW));
+}
+
static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
{
/*
@@ -2189,6 +2224,17 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
if (err)
return err;
+ /*
+ * Acquire and vote the interconnect path before accessing any SMMU
+ * registers (including ARM_SMMU_GR0_ID0 in arm_smmu_device_cfg_probe).
+ */
+ err = arm_smmu_icc_get(smmu);
+ if (err) {
+ clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks);
+ return err;
+ }
+ arm_smmu_icc_enable(smmu);
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2273,8 +2319,10 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
if (pm_runtime_enabled(smmu->dev))
pm_runtime_force_suspend(smmu->dev);
- else
+ else {
clk_bulk_disable(smmu->num_clks, smmu->clks);
+ arm_smmu_icc_disable(smmu);
+ }
clk_bulk_unprepare(smmu->num_clks, smmu->clks);
}
@@ -2294,9 +2342,13 @@ static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
struct arm_smmu_device *smmu = dev_get_drvdata(dev);
int ret;
+ arm_smmu_icc_enable(smmu);
+
ret = clk_bulk_enable(smmu->num_clks, smmu->clks);
- if (ret)
+ if (ret) {
+ arm_smmu_icc_disable(smmu);
return ret;
+ }
arm_smmu_device_reset(smmu);
@@ -2308,6 +2360,7 @@ static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
struct arm_smmu_device *smmu = dev_get_drvdata(dev);
clk_bulk_disable(smmu->num_clks, smmu->clks);
+ arm_smmu_icc_disable(smmu);
return 0;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 26d2e33cd328b8278888585fc07a31485d9397e2..c00606a416b2f4bb44a35e5d67f6ef801df68e1c 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -15,6 +15,7 @@
#include <linux/bits.h>
#include <linux/clk.h>
#include <linux/device.h>
+#include <linux/interconnect.h>
#include <linux/io-64-nonatomic-hi-lo.h>
#include <linux/io-pgtable.h>
#include <linux/iommu.h>
@@ -335,6 +336,7 @@ struct arm_smmu_device {
int num_clks;
unsigned int *irqs;
struct clk_bulk_data *clks;
+ struct icc_path *icc_path;
spinlock_t global_sync_lock;
Any feedback or concerns on the interconnect voting approach proposed here?
This helps to address the kernel panic issue [1] reported for one of
Qualcomm platforms.
Please respond or tend the issues, pointed out by Sashiko.
Sure, I have addressed and replied to the Sashiko warnings on v1,
I'll check on the fresh warnings on V2 along with your suggestions on this patch.
< I was wondering if it's needed to respond to Sashiko comments earlier or silently address the relevant ones,
so thanks for confirming this as well :) >
Thanks,
Bibek
[1]: https://github.com/qualcomm-linux/kernel/issues/297
Thanks,
Bibek