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

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

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.

Thanks,
Imran