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

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

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