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

[Imran Shaik]

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@xxxxxxxxxxx/
> > >
> > > 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