Re: [PATCH 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware

[Imran Shaik <imran.shaik@oss.qualcomm.com>]

On 05-05-2026 02:23 pm, Krzysztof Kozlowski wrote:
> On 05/05/2026 10:50, Imran Shaik wrote:
>>
>>
>> On 04-05-2026 03:53 pm, Krzysztof Kozlowski wrote:
>>> On Fri, May 01, 2026 at 12:45:44PM +0530, Imran Shaik wrote:
>>>> The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
>>>> but supports only up to 12 frequency lookup table (LUT) entries. Introduce
>>>> qcom,cpufreq-epss-lite to represent this constrained EPSS variant.
>>>
>>> The entire point of having a generic compatible is that it MUST match
>>> all devices. If it does not, then it is pointless to push that generic
>>> compatible.
>>>
>>> I am speaking about qcom,cpufreq-epss.
>>>
>>> That's nothing new, I was arguing about it already, but now you have
>>> confirmation of the mess introduced by generic compatibles. Solution is
>>> not to add more generic compatibles, because what will be next?
>>> qcom,cpufreq-epss-lighter?
>>> qcom,cpufreq-epss-more-lite?
>>> qcom,cpufreq-epss-high?
>>>
>>> Same was here:
>>> https://lore.kernel.org/all/20240828203721.2751904-17-quic_nkela@quicinc.com/
>>>
>>> So that's second time I object and do object for every new instance. No
>>> to generic compatibles, they are proven to be wrong at least for
>>> Qualcomm.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> Hi Krzysztof,
>>
>> There is no functional change to the latest EPSS hardware
>> (qcom,cpufreq-epss) in this case. The Shikra platform uses the CPU
>> frequency scaling block, which is a predecessor of EPSS and is referred
>> to as EPSS‑lite. The only difference between EPSS‑lite and EPSS is the
>> maximum number of frequency look up table (LUT) entries.
>>
>> This constrained EPSS block is not specific to Shikra and can be reused
>> by other SoCs that implement the same hardware. Hence, we have added a
>> separate epss-lite compatible and reused the existing bindings, as all
>> other aspects of the hardware behavior and interface remain identical.
> 
> I don't understand how any of this is relevant to my comment. I know
> what you did.
> 

Hi Krzysztof,

The intent behind proposing an epss-lite compatible was to describe a 
common hardware variant and avoid introducing SoC‑specific handling in 
the cpufreq driver.

While reviewing existing upstream targets, I noticed that SM6375 also 
appears to use this constrained EPSS hardware variant, which is 
currently not represented accurately and would require a similar fix.

Since both Shikra and SM6375 share this hardware variant, would it be 
acceptable to use a common epss-lite compatible for these targets?

Please let me know your thoughts on this.

Thanks,
Imran

> Best regards,
> Krzysztof