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.
Best regards,
Krzysztof
