Re: [PATCH v18 0/5] iommu/arm-smmu: introduction of ACTLR implementation for Qualcomm SoCs

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 11/13/25 2:55 PM, Charan Teja Kalla wrote:
> 
> 
> On 11/12/2025 7:04 PM, Konrad Dybcio wrote:
>>> Hi Eric,
>>>
>>> If a device has multiple SIDs, all serving the same functionality and grouped under the same "iommus" field, for example:
>>>
>>> iommus = <&apps_smmu, 0x2141, 0x0>,
>>>           <&apps_smmu, 0x25c1, 0x0>,
>>>           <&apps_smmu, 0x2161, 0x0>;
>>>
>>> In this case, all the SIDs will be associated with the same context bank. Even if the three SIDs have different ACTLR settings, since SMMU_CB_ACTLR is per CB setting, all SIDs attached to that bank will share the same ACTLR configuration. This is why we designed it to be "per device / per compatible".
>> Does that suggest the settings may be slightly suboptimal?

I don't understand your question

> Or it is limitation to use the ACTLR?
> 
>> There's some work being done to allow more granular association of
>> the passed SIDs:
>>
>> https://lore.kernel.org/linux-arm-msm/20250928171718.436440-1-
>> charan.kalla@oss.qualcomm.com/
> Sorry, I am unable to link this limitation for actlr setting with the
> work. Can you elaborate please?

Because your email client is misconfigured and it broke the line.. If
it's thunderbird, pretty sure we have a "change these configs" type
section on go/upstream, please take a look

> IIUC, unless the SIDs are totally separated per actlr settings and
> attached to CB(which are limited), this can't be achieved...but may be a
> question here to check is it really a __valid__ to associate a different
> actlr settings SID to use the same CB?

The last question you asked is certainly a valid one

But I was wondering if iommu-map could be useful to resolve this, where
we choose an abstract set of function IDs and then handle the IOMMU
configuration manually, based on the func_id-delimited sets:

iommu-map = <FUNC_ID0 &iommu_phandle CELL0 ... CELLN-1>,
	    <FUNC_ID0 &iommu_phandle CELL0 ... CELLN-1>,
	    <FUNC_ID1 &iommu_phandle CELL0 ... CELLN-1>,
	    <FUNC_ID2 &iommu_phandle CELL0 ... CELLN-1>;

But perhaps that's more useful from the driver-that-handles-the-device
perspective

Konrad