Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support

[Bibek Kumar Patro]

On 6/18/2026 2:58 PM, Konrad Dybcio wrote:
> On 6/17/26 4:26 PM, Bibek Kumar Patro wrote:
> > 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
>
> (you used decimal 1000)

It's my bad, i meant 1000 only
(I'll check on the icc_bw calculation to get clarity on the values)

> > can evaluate if this could be moved to a Qualcomm-specific
> > implementation.
>
> Add a vendor hook to arm_smmu_runtime_suspend/resume and handle it within
> the QC driver

Just curious, wouldn't this apply for all the arm-smmu users in addition 
to Qualcomm devices as i mentioned here [1].
Vendor hook would make it Qualcomm specific.

[1]: 
https://lore.kernel.org/all/984ff9c7-3eef-463c-a330-bf7acd063667@xxxxxxxxxxxxxxxx/

Thanks & regards,
Bibek

> Konrad