[PATCH 0/2] Add cpufreq scaling support for Qualcomm Shikra SoC

[PATCH 0/2] Add cpufreq scaling support for Qualcomm Shikra SoC

[Imran Shaik]

This series adds cpufreq scaling support on Qualcomm Shikra SoC.

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
Imran Shaik (1):
      dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware

Taniya Das (1):
      cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC

 .../bindings/cpufreq/cpufreq-qcom-hw.yaml          |  7 +++++++
 drivers/cpufreq/qcom-cpufreq-hw.c                  | 23 +++++++++++++++++++---
 2 files changed, 27 insertions(+), 3 deletions(-)
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260430-shikra-cpufreq-scaling-aff690130063

Best regards,
-- 
Imran Shaik <imran.shaik@oss.qualcomm.com>

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

[Imran Shaik]

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.

Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
index 98eb36bff1727dfe78e77a7f725d1dcab438c3d0..a04f0556dff88615a5b5ee759008c43342f49e11 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
@@ -54,6 +54,12 @@ properties:
               - qcom,sm8650-cpufreq-epss
           - const: qcom,cpufreq-epss
 
+      - description: EPSS lite CPUFREQ HW
+        items:
+          - enum:
+              - qcom,shikra-cpufreq-epss-lite
+          - const: qcom,cpufreq-epss-lite
+
   reg:
     minItems: 1
     items:
@@ -144,6 +150,7 @@ allOf:
               - qcom,sc8280xp-cpufreq-epss
               - qcom,sdm670-cpufreq-hw
               - qcom,sdm845-cpufreq-hw
+              - qcom,shikra-cpufreq-epss-lite
               - qcom,sm4450-cpufreq-epss
               - qcom,sm6115-cpufreq-hw
               - qcom,sm6350-cpufreq-hw

-- 
2.34.1

[PATCH 2/2] cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC

[Imran Shaik]

From: Taniya Das <taniya.das@oss.qualcomm.com>

The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
but supports only up to 12 frequency lookup table (LUT) entries. Hence,
add epss_lite_soc_data that reuses EPSS configuration with the appropriate
LUT entries limit.

Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index ea9a20d27b8fdceb9341ee53e5fa27b7a6d92483..92e1256c6457046927625136077c69f8d56644aa 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
  */
 
 #include <linux/bitfield.h>
@@ -40,6 +41,7 @@ struct qcom_cpufreq_soc_data {
 	u32 reg_intr_clr;
 	u32 reg_current_vote;
 	u32 reg_perf_state;
+	u32 lut_max_entries;
 	u8 lut_row_size;
 };
 
@@ -156,7 +158,7 @@ static unsigned int qcom_cpufreq_get_freq(struct cpufreq_policy *policy)
 	soc_data = qcom_cpufreq.soc_data;
 
 	index = readl_relaxed(data->base + soc_data->reg_perf_state);
-	index = min(index, LUT_MAX_ENTRIES - 1);
+	index = min(index, soc_data->lut_max_entries - 1);
 
 	return policy->freq_table[index].frequency;
 }
@@ -211,7 +213,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 	struct qcom_cpufreq_data *drv_data = policy->driver_data;
 	const struct qcom_cpufreq_soc_data *soc_data = qcom_cpufreq.soc_data;
 
-	table = kzalloc_objs(*table, LUT_MAX_ENTRIES + 1);
+	table = kzalloc_objs(*table, soc_data->lut_max_entries + 1);
 	if (!table)
 		return -ENOMEM;
 
@@ -236,7 +238,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 		icc_scaling_enabled = false;
 	}
 
-	for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+	for (i = 0; i < soc_data->lut_max_entries; i++) {
 		data = readl_relaxed(drv_data->base + soc_data->reg_freq_lut +
 				      i * soc_data->lut_row_size);
 		src = FIELD_GET(LUT_SRC, data);
@@ -405,6 +407,7 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
 	.reg_current_vote = 0x704,
 	.reg_perf_state = 0x920,
 	.lut_row_size = 32,
+	.lut_max_entries = LUT_MAX_ENTRIES,
 };
 
 static const struct qcom_cpufreq_soc_data epss_soc_data = {
@@ -416,11 +419,25 @@ static const struct qcom_cpufreq_soc_data epss_soc_data = {
 	.reg_intr_clr = 0x308,
 	.reg_perf_state = 0x320,
 	.lut_row_size = 4,
+	.lut_max_entries = LUT_MAX_ENTRIES,
+};
+
+static const struct qcom_cpufreq_soc_data epss_lite_soc_data = {
+	.reg_enable = 0x0,
+	.reg_domain_state = 0x20,
+	.reg_dcvs_ctrl = 0xb0,
+	.reg_freq_lut = 0x100,
+	.reg_volt_lut = 0x200,
+	.reg_intr_clr = 0x308,
+	.reg_perf_state = 0x320,
+	.lut_row_size = 4,
+	.lut_max_entries = 12,
 };
 
 static const struct of_device_id qcom_cpufreq_hw_match[] = {
 	{ .compatible = "qcom,cpufreq-hw", .data = &qcom_soc_data },
 	{ .compatible = "qcom,cpufreq-epss", .data = &epss_soc_data },
+	{ .compatible = "qcom,cpufreq-epss-lite", .data = &epss_lite_soc_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);

-- 
2.34.1

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

[Krzysztof Kozlowski]

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

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

[Imran Shaik]

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

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

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof