mbox series

[0/5] Add missing OPP tables for Venus on qcom/arm64

Message ID 20250531-topic-venus_opp_arm64-v1-0-54c6c417839f@oss.qualcomm.com
Headers show
Series Add missing OPP tables for Venus on qcom/arm64 | expand

Message

Konrad Dybcio May 31, 2025, 12:27 p.m. UTC
Sparked by <20250530-add-venus-for-qcs615-v8-0-c0092ac616d0@quicinc.com>

No external dependencies

Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Konrad Dybcio (5):
      arm64: dts: qcom: msm8916: Add Venus OPP table
      arm64: dts: qcom: msm8996: Add Venus OPP table
      arm64: dts: qcom: msm8998: Add Venus OPP table
      arm64: dts: qcom: sdm630: Add Venus OPP table
      arm64: dts: qcom: sdm845: Fix Venus OPP entries

 arch/arm64/boot/dts/qcom/msm8916.dtsi | 20 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 39 ++++++++++++++++++++++++++++-------
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 30 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sdm630.dtsi  | 35 +++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 24 ++++++++++-----------
 5 files changed, 128 insertions(+), 20 deletions(-)
---
base-commit: 2a628f951ed54c30a232230b5b58349d2a8dbb11
change-id: 20250531-topic-venus_opp_arm64-378e98bf6071

Best regards,

Comments

Stephan Gerhold June 2, 2025, 8:09 a.m. UTC | #1
On Sat, May 31, 2025 at 02:27:18PM +0200, Konrad Dybcio wrote:
> Sparked by <20250530-add-venus-for-qcs615-v8-0-c0092ac616d0@quicinc.com>
> 
> No external dependencies
> 

Are you sure?

> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Konrad Dybcio (5):
>       arm64: dts: qcom: msm8916: Add Venus OPP table
>       arm64: dts: qcom: msm8996: Add Venus OPP table
>       arm64: dts: qcom: msm8998: Add Venus OPP table
>       arm64: dts: qcom: sdm630: Add Venus OPP table

None of these platforms has a power domain that supports performance
states specified in the venus node of the DT, and the venus GDSC does
not have any parent either. I think you will need to update the venus
bindings and add

	.opp_pmdomain = (const char *[]) { "cx" /*???*/ },

for all these in the venus driver (plus backwards compat if not already
there). And then add that power domain additionally in the DT.

This series is also introducing new dtbs_check failures :/

qcom/apq8016-sbc.dtb: video-codec@1d00000: Unevaluated properties are not allowed ('operating-points-v2', 'opp-table' were unexpected)                                               
        from schema $id: http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#         
qcom/apq8096-db820c.dtb: video-codec@c00000: Unevaluated properties are not allowed ('operating-points-v2', 'opp-table' were unexpected)                                             
        from schema $id: http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#     
qcom/msm8998-lenovo-miix-630.dtb: video-codec@cc00000: Unevaluated properties are not allowed ('operating-points-v2', 'opp-table' were unexpected)                                   
        from schema $id: http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#       

>       arm64: dts: qcom: sdm845: Fix Venus OPP entries

This one has .opp_pmdomain and "cx" in the bindings, so it's probably
fine (didn't check if the current OPPs are really wrong).

Thanks,
Stephan
Konrad Dybcio June 11, 2025, 8:46 p.m. UTC | #2
On 6/11/25 10:43 PM, Konrad Dybcio wrote:
> On 6/2/25 10:09 AM, Stephan Gerhold wrote:
>> On Sat, May 31, 2025 at 02:27:18PM +0200, Konrad Dybcio wrote:
>>> Sparked by <20250530-add-venus-for-qcs615-v8-0-c0092ac616d0@quicinc.com>
>>>
>>> No external dependencies
>>>
>>
>> Are you sure?
>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> ---
>>> Konrad Dybcio (5):
>>>       arm64: dts: qcom: msm8916: Add Venus OPP table
>>>       arm64: dts: qcom: msm8996: Add Venus OPP table
>>>       arm64: dts: qcom: msm8998: Add Venus OPP table
>>>       arm64: dts: qcom: sdm630: Add Venus OPP table
>>
>> None of these platforms has a power domain that supports performance
>> states specified in the venus node of the DT, and the venus GDSC does
>> not have any parent either. I think you will need to update the venus
>> bindings and add
>>
>> 	.opp_pmdomain = (const char *[]) { "cx" /*???*/ },
>>
>> for all these in the venus driver (plus backwards compat if not already
>> there). And then add that power domain additionally in the DT.
> 
> Making use of these tables would certainly be welcome.. This patchset
> was aimed at pushing them to fdt, so that we can debate dropping the
> hardcoded values in the driver in the future.

I don't think we can just plug them in to the driver right now, as
it would also happen to break backwards compat (since
devm_pm_domain_attach_list() seems to not be particularly happy about
missing resources) - though arguments can be made both ways: "it
could have never *really* worked" vs "don't poke at the old driver for
old hardware too much, as it's gonna break"

Konrad