On 26.10.2024 1:28 PM, Krzysztof Kozlowski wrote:
> On 25/10/2024 17:38, Raviteja Laggyshetty wrote:
>>
>>
>> On 9/6/2024 10:00 PM, Krzysztof Kozlowski wrote:
>>> On 06/09/2024 17:32, Raviteja Laggyshetty wrote:
>>>>
>>>> On 9/4/2024 11:52 PM, Krzysztof Kozlowski wrote:
>>>>> On 04/09/2024 19:12, Raviteja Laggyshetty wrote:
>>>>>> +
>>>>>> static const struct qcom_osm_l3_desc epss_l3_l3_vote = {
>>>>>> .nodes = epss_l3_nodes,
>>>>>> .num_nodes = ARRAY_SIZE(epss_l3_nodes),
>>>>>> @@ -284,6 +307,10 @@ static const struct of_device_id osm_l3_of_match[] = {
>>>>>> { .compatible = "qcom,sm8150-osm-l3", .data = &osm_l3 },
>>>>>> { .compatible = "qcom,sc8180x-osm-l3", .data = &osm_l3 },
>>>>>> { .compatible = "qcom,sm8250-epss-l3", .data = &epss_l3_perf_state },
>>>>>> + { .compatible = "qcom,sa8775p-epss-l3-cl0",
>>>>>> + .data = &epss_l3_perf_state },
>>>>> Don't grow it but express compatibility.
>>>> ok. Will rename compatible from "qcom,sa8775p-epss-l3-cl0" to "qcom,sa8775p-epss-l3".
>>>
>>> This won't solve the problem. You still grow the table, right?
>>
>> Falling back to "qcom,epss-l3" won't work because we need to vote into perf state register.
>> I am introducing a new fallback compatible "qcom,epss-l3-perf" for perf voting, which can be used for upcoming qcs8300.
>
> Maybe, no clue, this was 1.5 months ago. I don't have original patches
> in the inbox anymore.
>
> Just choose something sensible following writing bindings guideline.
You can see that qcom,sm8250-epss-l3 uses the same match data, so that
sounds like a good fit
Konrad
