From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Charan Teja Kalla <charan.kalla@oss.qualcomm.com>,
robin.clark@oss.qualcomm.com, will@kernel.org,
robin.murphy@arm.com, joro@8bytes.org,
dmitry.baryshkov@oss.qualcomm.com
Cc: iommu@lists.linux.dev, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc
Date: Thu, 27 Nov 2025 16:44:15 +0530 [thread overview]
Message-ID: <9b4c895a-c822-40e6-bb92-8fdcd09c82d3@oss.qualcomm.com> (raw)
In-Reply-To: <02d7c0a9-0d24-4fd8-980a-da9d7307588a@oss.qualcomm.com>
On 11/12/2025 7:32 PM, Konrad Dybcio wrote:
> On 11/11/25 3:02 PM, Charan Teja Kalla wrote:
>>
>>
>> On 11/5/2025 2:44 PM, Konrad Dybcio wrote:
>>>> + { .compatible = "qcom,fastrpc-compute-cb",
>>>> + .data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
>>> This will be globally applied to all smmu-v2 targets with fastrpc,
>>> starting from MSM8996 ending at Kaanapali and everything inbetween
>>>
>>> Are these settings always valid?
>> Oops, you are correct...this settings are not always applicable it seems.
>>
>> Example: lpass compute and cdsp compute node uses the
>> "qcom,fastrpc-compute-cb", but it is for the later that ACTLR settings
>> are valid.
>>
>> Then for these cases, should we be extending the actlr match array with
>> additional compatible string and then add them in all the device nodes
>> that require actlr setting? example:
>>
>> @@ -3119,7 +3119,8 @@ fastrpc {
>> compute-cb@1 {
>> - compatible = "qcom,fastrpc-compute-cb";
>> + compatible = "qcom,fastrpc-compute-cb",
>> + "qcom,fastrpc-compute-cb-actlr";
>
> dt-bindings (and especially compatible strings) must not be altered solely
> to work around a driver being suboptimal
>
> But because you reported that these settings can change both between
> platforms and instances of the same devices on these platforms, we could
> possibly reconsider adding ACTRL settings to the consumer device nodes
> where they stray away from the otherwise seemingly reasonable baseline
> we have in the driver so far..
>
During initial discussion of ACTLR design phase, It was concluded that
prefetch alike QoS settings are not hardware definitions, and device
tree would not be the right place to store such configurable/tunable
settings [1]. So it might be contradicting to add it in consumer nodes.
For fastrpc client, there are 2 hiccups:
1. For a particular SoC, Different SIDs of compute client are using the
same compatible "qcom,fastrpc-compute-cb" but can have different
prefetch settings <refer table below> e.g. CDSP and ADSP have same
compat string "qcom,fastrpc-compute-cb" with different labels.
e.g.
fastrpc {
compatible = "qcom,fastrpc";
qcom,glink-channels = "fastrpcglink-apps-dsp";
label = "adsp"; /*---different label: adsp---*/
compute-cb@3 {
compatible = "qcom,fastrpc-compute-cb";
reg = <3>;
/*---Prefetch Default---*/
iommus = <&apps_smmu 0x1003 0x80>,
<&apps_smmu 0x1063 0x0>;
dma-coherent;
fastrpc {
compatible = "qcom,fastrpc";
qcom,glink-channels = "fastrpcglink-apps-dsp";
label = "cdsp"; /*---Different Label: cdsp---*/
qcom,non-secure-domain;
#address-cells = <1>;
#size-cells = <0>;
compute-cb@1 {
compatible = "qcom,fastrpc-compute-cb";
reg = <1>;
/*---Prefetch DEEP----*/
iommus = <&apps_smmu 0x1961 0x0>,
<&apps_smmu 0x0c01 0x20>,
<&apps_smmu 0x19c1 0x10>;
2. Different SoCs having the same compatible string and same label but
different prefetch settings.
e.g:
in below table sm6550, sm8250 and sm8550
compat string = "qcom,fastrpc-compute-cb" and label = "cdsp"
but prefetch settings are different
As per my idea both the above cases could be resolved by compat string
addition,
case 1 : compatible = "qcom,fastrpc-compute-cb-cdsp";
case 2 : compatible = "qcom,sm8550-fastrpc-compute-cb-cdsp"
This discrpeancy is not applicable for other clients, except fastrpc.
One way both the above cases could be resolved by additional fastrpc
compat string with below format:
compatible = "qcom,<soc_name>-fastrpc-compute-cb-<label_name>"
e.g: "qcom,sm8550-fastrpc-compute-cb-cdsp",
"qcom,sm6550-fastrpc-compute-cb-adsp"
This should handle both case 1 & case 2.
But as you mentioned previously this might need change alteration of DT
bindings addition which might not be allowed or favoured always.
[1]:
https://lore.kernel.org/all/a01e7e60-6ead-4a9e-ba90-22a8a6bbd03f@quicinc.com/
> Or we could introduce some more bespoke matching logic.
>
> I would like to know more about the scope of this issue, i.e. the matrix
> of (soc, device, actlr_val) that needs special handling.
>
+---------+-----------------------------------------------+----------+
| SoC | Description | Prefetch |
+---------+-----------------------------------------------+----------+
| sc7180 | qcom,fastrpc-compute-cb | label = cdsp | DEEP |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sc7280 | qcom,fastrpc-compute-cb | label = cdsp | DEEP |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sm6115 | qcom,fastrpc-compute-cb | label = cdsp | DEFAULT |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sm6125 | qcom,fastrpc-compute-cb (NA upstream) | |
+---------+-----------------------------------------------+----------+
| sm6350 | qcom,fastrpc-compute-cb | label = cdsp | SHALLOW |
| | qcom,fastrpc-compute-cb | label = adsp | SHALLOW |
+---------+-----------------------------------------------+----------+
| sm8250 | qcom,fastrpc-compute-cb | label = cdsp | DEFAULT |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
| | qcom,fastrpc-compute-cb | label = sdsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sm8350 | qcom,fastrpc-compute-cb | label = cdsp | DEEP |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
| | qcom,fastrpc-compute-cb | label = sdsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sm8450 | qcom,fastrpc-compute-cb | label = cdsp | DEEP |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
| | qcom,fastrpc-compute-cb | label = sdsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sm8550 | qcom,fastrpc-compute-cb | label = cdsp | DEEP |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
+---------+-----------------------------------------------+----------+
| sm8650 | qcom,fastrpc-compute-cb | label = cdsp | DEEP |
| | qcom,fastrpc-compute-cb | label = adsp | DEFAULT |
+---------+-----------------------------------------------+----------+
Thanks & regards,
Bibek
> Konrad
next prev parent reply other threads:[~2025-11-27 11:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 7:53 [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc Charan Teja Kalla
2025-11-05 9:14 ` Konrad Dybcio
2025-11-11 7:56 ` Charan Teja Kalla
2025-11-11 14:02 ` Charan Teja Kalla
2025-11-12 14:02 ` Konrad Dybcio
2025-11-27 11:14 ` Bibek Kumar Patro [this message]
2025-12-18 12:02 ` Konrad Dybcio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b4c895a-c822-40e6-bb92-8fdcd09c82d3@oss.qualcomm.com \
--to=bibek.patro@oss.qualcomm.com \
--cc=charan.kalla@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox