Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro
Date: Wed Jun 17 2026 - 10:27:27 EST
On 6/16/2026 5:51 AM, Dmitry Baryshkov wrote:
On Mon, Jun 15, 2026 at 06:36:51PM +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.
Ideally, any non-zero value would be enough to keep the path active.
This is true for Qualcomm devices. However, you are adding this to a
generic code.
Here 1 Would be enough to keep the path active, but might be too small to
reliably keep the bus active.
Other is UINT_MAX, which will reliably keep the bus active but might cause a
power penalty.
#define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
seems to be suitable here to reliably keep the bus active by BCM
for both Qualcomm and non-Qualcomm platforms (with some power penalty).
LMK, if you feel otherwise.
Shift it to the qcom instance or provide platform-specific values? (My
preference would be towards the first solution).
To support platform-specific values, we may need to introduce a LUT-based approach in the driver. (Bandwidth voting values cannot be placed in device-tree property IIRC ?)
Currently, all Qualcomm platforms use 0x1000 for SMMU ICC voting. I
can evaluate if this could be moved to a Qualcomm-specific
implementation.
To clarify, this applies only to the bandwidth values.
Since the ICC path itself can remain part of struct arm_smmu_device, similar to clocks and IRQs, as it represents common infrastructure required for the SMMU device.
Thanks & regards,
Bibek
+#define ARM_SMMU_ICC_PEAK_BW_LOW 0
+
static int force_stage;
module_param(force_stage, int, S_IRUGO);
MODULE_PARM_DESC(force_stage,