* [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc @ 2025-11-05 7:53 Charan Teja Kalla 2025-11-05 9:14 ` Konrad Dybcio 0 siblings, 1 reply; 7+ messages in thread From: Charan Teja Kalla @ 2025-11-05 7:53 UTC (permalink / raw) To: robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel, Charan Teja Kalla Add ACTLR settings for the device nodes with below compatibility and is mainly targeted for sa8775p: 1) sa8775p-mdss 2) qcom,fastrpc-compute-cb As a side note, "qcom,fastrpc" compatibility is already defined but that seems inept as the devices that will be attached to the SMMU is going to be with "qcom,fastrpc-compute-cb" compat string. Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> --- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c index c21a401c71eb..c76f6076f487 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -47,6 +47,10 @@ static const struct of_device_id qcom_smmu_actlr_client_of_match[] = { .data = (const void *) (PREFETCH_SHALLOW | CPRE | CMTLB) }, { .compatible = "qcom,sm8550-mdss", .data = (const void *) (PREFETCH_DEFAULT | CMTLB) }, + { .compatible = "qcom,sa8775p-mdss", + .data = (const void *) (PREFETCH_DEFAULT | CMTLB) }, + { .compatible = "qcom,fastrpc-compute-cb", + .data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) }, { } }; -- 2.34.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc 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 0 siblings, 2 replies; 7+ messages in thread From: Konrad Dybcio @ 2025-11-05 9:14 UTC (permalink / raw) To: Charan Teja Kalla, robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel On 11/5/25 8:53 AM, Charan Teja Kalla wrote: > Add ACTLR settings for the device nodes with below compatibility > and is mainly targeted for sa8775p: The commit subject should mention it's the lemans MDSS specifically > 1) sa8775p-mdss > 2) qcom,fastrpc-compute-cb > > As a side note, "qcom,fastrpc" compatibility is already defined but that > seems inept as the devices that will be attached to the SMMU is going to > be with "qcom,fastrpc-compute-cb" compat string. If you say it's a NOP after all, please split the fastrpc change into a separate commit explaining the issue and removing the wrong entry > Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> > --- > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > index c21a401c71eb..c76f6076f487 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c > @@ -47,6 +47,10 @@ static const struct of_device_id qcom_smmu_actlr_client_of_match[] = { > .data = (const void *) (PREFETCH_SHALLOW | CPRE | CMTLB) }, > { .compatible = "qcom,sm8550-mdss", > .data = (const void *) (PREFETCH_DEFAULT | CMTLB) }, > + { .compatible = "qcom,sa8775p-mdss", > + .data = (const void *) (PREFETCH_DEFAULT | CMTLB) }, This list should be sorted alphanumerically > + { .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? Konrad ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc 2025-11-05 9:14 ` Konrad Dybcio @ 2025-11-11 7:56 ` Charan Teja Kalla 2025-11-11 14:02 ` Charan Teja Kalla 1 sibling, 0 replies; 7+ messages in thread From: Charan Teja Kalla @ 2025-11-11 7:56 UTC (permalink / raw) To: Konrad Dybcio, robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel On 11/5/2025 2:44 PM, Konrad Dybcio wrote: >> Add ACTLR settings for the device nodes with below compatibility >> and is mainly targeted for sa8775p: > The commit subject should mention it's the lemans MDSS specifically >> 1) sa8775p-mdss >> 2) qcom,fastrpc-compute-cb >> >> As a side note, "qcom,fastrpc" compatibility is already defined but that >> seems inept as the devices that will be attached to the SMMU is going to >> be with "qcom,fastrpc-compute-cb" compat string. > If you say it's a NOP after all, please split the fastrpc change into > a separate commit explaining the issue and removing the wrong entry > >> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> >> --- >> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c >> index c21a401c71eb..c76f6076f487 100644 >> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c >> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c >> @@ -47,6 +47,10 @@ static const struct of_device_id qcom_smmu_actlr_client_of_match[] = { >> .data = (const void *) (PREFETCH_SHALLOW | CPRE | CMTLB) }, >> { .compatible = "qcom,sm8550-mdss", >> .data = (const void *) (PREFETCH_DEFAULT | CMTLB) }, >> + { .compatible = "qcom,sa8775p-mdss", >> + .data = (const void *) (PREFETCH_DEFAULT | CMTLB) }, > This list should be sorted alphanumerically > >> + { .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? Let me separate out patches for mdss and w/ more details for fastrpc. Thanks, Charan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc 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 1 sibling, 1 reply; 7+ messages in thread From: Charan Teja Kalla @ 2025-11-11 14:02 UTC (permalink / raw) To: Konrad Dybcio, robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel, bibek.patro 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"; --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -49,7 +49,7 @@ static const struct of_device_id qcom_smmu_actlr_client_of_match[] = { + { .compatible = "qcom,fastrpc-compute-cb-actlr", .data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) }, { } or any other better way, please lmk. Thanks, Charan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc 2025-11-11 14:02 ` Charan Teja Kalla @ 2025-11-12 14:02 ` Konrad Dybcio 2025-11-27 11:14 ` Bibek Kumar Patro 0 siblings, 1 reply; 7+ messages in thread From: Konrad Dybcio @ 2025-11-12 14:02 UTC (permalink / raw) To: Charan Teja Kalla, robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel, bibek.patro 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.. 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. Konrad ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc 2025-11-12 14:02 ` Konrad Dybcio @ 2025-11-27 11:14 ` Bibek Kumar Patro 2025-12-18 12:02 ` Konrad Dybcio 0 siblings, 1 reply; 7+ messages in thread From: Bibek Kumar Patro @ 2025-11-27 11:14 UTC (permalink / raw) To: Konrad Dybcio, Charan Teja Kalla, robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] iommu/arm-smmu: add actlr settings for mdss and fastrpc 2025-11-27 11:14 ` Bibek Kumar Patro @ 2025-12-18 12:02 ` Konrad Dybcio 0 siblings, 0 replies; 7+ messages in thread From: Konrad Dybcio @ 2025-12-18 12:02 UTC (permalink / raw) To: Bibek Kumar Patro, Charan Teja Kalla, robin.clark, will, robin.murphy, joro, dmitry.baryshkov Cc: iommu, linux-arm-msm, linux-arm-kernel, linux-kernel On 11/27/25 12:14 PM, Bibek Kumar Patro wrote: > > > 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 for the detailed explanation. It feel quite impossible to keep track of all this in the current model. On the other hand, the approach where a third OF cell is introduced isn't my favorite thing in the world, and that seems to be the general sentiment. FWIW downstream solves this by carrying the list of <sid mask val> under the SMMU node. Perhaps that could be reconsidered, either as a storage for all the values, or as storage for non-default overrides.. Krzysztof, Bjorn, opinions? Konrad ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-12-18 12:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2025-12-18 12:02 ` Konrad Dybcio
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox