On 26/10/2024 14:24, Konrad Dybcio wrote:
> 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
Yep, so probably this was obvious to me when I wrote above comment and I
just don't get why fallbacking to qcom,sa8775p-epss-l3...
Best regards,
Krzysztof
