linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/4] Fixup register offsets to support per core L3 DCVS
@ 2021-07-29 18:04 Sibi Sankar
  2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Sibi Sankar @ 2021-07-29 18:04 UTC (permalink / raw)
  To: sboyd, bjorn.andersson, robh+dt, mka
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas, Sibi Sankar

Qualcomm SoCs (starting with SM8350) support per core voting for L3 cache
frequency. The patch series re-arranges the cpufreq register offsets to
allow access for the L3 interconnect to implement per core control i.e.
the first 0x100 is now accessed by the L3 interconnect driver instead.

L3 interconnect provider node on SC7280 SoC:
epss_l3: interconnect@18590000 {
	compatible = "qcom,sc7280-epss-l3";
        reg = <0 0x18590000 0 0x1000>, <0 0x18591000 0 0x100>,
	      <0 0x18592000 0 0x100>, <0 0x18593000 0 0x100>;
	...
};

CPUFREQ node on SC7280 SoC:
cpufreq_hw: cpufreq@18591000 {
	compatible = "qcom,cpufreq-epss";
	reg = <0 0x18591100 0 0x900>,
	      <0 0x18592100 0 0x900>,
	      <0 0x18593100 0 0x900>;
	...
};

The patch series also prevents binding breakage by using the
SM8250/SM8350 EPSS compatible.

Sibi Sankar (4):
  dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
  cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  arm64: dts: qcom: sc7280: Fixup the cpufreq node
  arm64: dts: qcom: sm8350: Fixup the cpufreq node

 .../bindings/cpufreq/cpufreq-qcom-hw.txt           |  6 +++++-
 arch/arm64/boot/dts/qcom/sc7280.dtsi               |  6 +++---
 arch/arm64/boot/dts/qcom/sm8350.dtsi               |  9 ++++-----
 drivers/cpufreq/qcom-cpufreq-hw.c                  | 23 ++++++++++++++++++----
 4 files changed, 31 insertions(+), 13 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
  2021-07-29 18:04 [PATCH 0/4] Fixup register offsets to support per core L3 DCVS Sibi Sankar
@ 2021-07-29 18:04 ` Sibi Sankar
  2021-08-03 19:23   ` Rob Herring
  2021-08-04 18:56   ` Stephen Boyd
  2021-07-29 18:04 ` [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS Sibi Sankar
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 21+ messages in thread
From: Sibi Sankar @ 2021-07-29 18:04 UTC (permalink / raw)
  To: sboyd, bjorn.andersson, robh+dt, mka
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas, Sibi Sankar

Re-arranging the register regions to support per core L3 DCVS would lead
to bindings breakage when using an older dt with a newer kernel. So,
document the EPSS compatible for SM8250/SM8350 SoCs and use them in the
CPUFreq-hw driver to prevent such breakages.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
index 9299028ee712..ee52fd8d3c9a 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
@@ -8,7 +8,11 @@ Properties:
 - compatible
 	Usage:		required
 	Value type:	<string>
-	Definition:	must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss".
+	Definition:	must be one of:
+			"qcom,cpufreq-epss"
+			"qcom,cpufreq-hw"
+			"qcom,sm8250-cpufreq-epss"
+			"qcom,sm8350-cpufreq-epss"
 
 - clocks
 	Usage:		required
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-07-29 18:04 [PATCH 0/4] Fixup register offsets to support per core L3 DCVS Sibi Sankar
  2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
@ 2021-07-29 18:04 ` Sibi Sankar
  2021-08-04 19:01   ` Stephen Boyd
  2021-08-04 23:11   ` Bjorn Andersson
  2021-07-29 18:04 ` [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node Sibi Sankar
  2021-07-29 18:04 ` [PATCH 4/4] arm64: dts: qcom: sm8350: " Sibi Sankar
  3 siblings, 2 replies; 21+ messages in thread
From: Sibi Sankar @ 2021-07-29 18:04 UTC (permalink / raw)
  To: sboyd, bjorn.andersson, robh+dt, mka
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas, Sibi Sankar

Qualcomm SoCs (starting with SM8350) support per core voting for L3 cache
frequency. So, re-arrange the cpufreq register offsets to allow access for
the L3 interconnect to implement per core control. Also prevent binding
breakage caused by register offset shuffling by using the SM8250/SM8350
EPSS compatible.

Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index f86859bf76f1..74ef3b38343b 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
 	u32 reg_volt_lut;
 	u32 reg_perf_state;
 	u8 lut_row_size;
+	bool skip_enable;
 };
 
 struct qcom_cpufreq_data {
@@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
 	.reg_volt_lut = 0x114,
 	.reg_perf_state = 0x920,
 	.lut_row_size = 32,
+	.skip_enable = false,
 };
 
 static const struct qcom_cpufreq_soc_data epss_soc_data = {
+	.reg_freq_lut = 0x0,
+	.reg_volt_lut = 0x100,
+	.reg_perf_state = 0x220,
+	.lut_row_size = 4,
+	.skip_enable = true,
+};
+
+static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
 	.reg_enable = 0x0,
 	.reg_freq_lut = 0x100,
 	.reg_volt_lut = 0x200,
 	.reg_perf_state = 0x320,
 	.lut_row_size = 4,
+	.skip_enable = false,
 };
 
 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,sm8250-cpufreq-epss", .data = &epss_sm8250_soc_data },
+	{ .compatible = "qcom,sm8350-cpufreq-epss", .data = &epss_sm8250_soc_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
@@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
 	data->res = res;
 
 	/* HW should be in enabled state to proceed */
-	if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
-		dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
-		ret = -ENODEV;
-		goto error;
+	if (!data->soc_data->skip_enable) {
+		if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
+			dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
+			ret = -ENODEV;
+			goto error;
+		}
 	}
 
 	qcom_get_related_cpus(index, policy->cpus);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
  2021-07-29 18:04 [PATCH 0/4] Fixup register offsets to support per core L3 DCVS Sibi Sankar
  2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
  2021-07-29 18:04 ` [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS Sibi Sankar
@ 2021-07-29 18:04 ` Sibi Sankar
  2021-08-04 18:57   ` Stephen Boyd
  2021-08-31 15:30   ` Matthias Kaehlcke
  2021-07-29 18:04 ` [PATCH 4/4] arm64: dts: qcom: sm8350: " Sibi Sankar
  3 siblings, 2 replies; 21+ messages in thread
From: Sibi Sankar @ 2021-07-29 18:04 UTC (permalink / raw)
  To: sboyd, bjorn.andersson, robh+dt, mka
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas, Sibi Sankar

Fixup the register regions used by the cpufreq node on SC7280 SoC to
support per core L3 DCVS.

Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 5764c5b5cae1..ddb8697aff9f 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -1829,9 +1829,9 @@
 
 		cpufreq_hw: cpufreq@18591000 {
 			compatible = "qcom,cpufreq-epss";
-			reg = <0 0x18591000 0 0x1000>,
-			      <0 0x18592000 0 0x1000>,
-			      <0 0x18593000 0 0x1000>;
+			reg = <0 0x18591100 0 0x900>,
+			      <0 0x18592100 0 0x900>,
+			      <0 0x18593100 0 0x900>;
 			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
 			clock-names = "xo", "alternate";
 			#freq-domain-cells = <1>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
  2021-07-29 18:04 [PATCH 0/4] Fixup register offsets to support per core L3 DCVS Sibi Sankar
                   ` (2 preceding siblings ...)
  2021-07-29 18:04 ` [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node Sibi Sankar
@ 2021-07-29 18:04 ` Sibi Sankar
  2021-08-04 22:59   ` Bjorn Andersson
  3 siblings, 1 reply; 21+ messages in thread
From: Sibi Sankar @ 2021-07-29 18:04 UTC (permalink / raw)
  To: sboyd, bjorn.andersson, robh+dt, mka
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas, Sibi Sankar

Fixup the register regions used by the cpufreq node on SM8350 SoC to
support per core L3 DCVS.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index a631d58166b1..d0a5a5568602 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -967,11 +967,10 @@
 		};
 
 		cpufreq_hw: cpufreq@18591000 {
-			compatible = "qcom,sm8350-cpufreq-epss", "qcom,cpufreq-epss";
-			reg = <0 0x18591000 0 0x1000>,
-			      <0 0x18592000 0 0x1000>,
-			      <0 0x18593000 0 0x1000>;
-			reg-names = "freq-domain0", "freq-domain1", "freq-domain2";
+			compatible = "qcom,cpufreq-epss";
+			reg = <0 0x18591100 0 0x900>,
+			      <0 0x18592100 0 0x900>,
+			      <0 0x18593100 0 0x900>;
 
 			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
 			clock-names = "xo", "alternate";
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
  2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
@ 2021-08-03 19:23   ` Rob Herring
  2021-08-04 18:56   ` Stephen Boyd
  1 sibling, 0 replies; 21+ messages in thread
From: Rob Herring @ 2021-08-03 19:23 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: mka, bjorn.andersson, linux-pm, agross, rjw, dianders,
	linux-arm-msm, sboyd, tdas, devicetree, viresh.kumar,
	linux-kernel, robh+dt

On Thu, 29 Jul 2021 23:34:42 +0530, Sibi Sankar wrote:
> Re-arranging the register regions to support per core L3 DCVS would lead
> to bindings breakage when using an older dt with a newer kernel. So,
> document the EPSS compatible for SM8250/SM8350 SoCs and use them in the
> CPUFreq-hw driver to prevent such breakages.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
  2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
  2021-08-03 19:23   ` Rob Herring
@ 2021-08-04 18:56   ` Stephen Boyd
  1 sibling, 0 replies; 21+ messages in thread
From: Stephen Boyd @ 2021-08-04 18:56 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, mka, robh+dt
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas

Quoting Sibi Sankar (2021-07-29 11:04:42)
> Re-arranging the register regions to support per core L3 DCVS would lead
> to bindings breakage when using an older dt with a newer kernel. So,
> document the EPSS compatible for SM8250/SM8350 SoCs and use them in the
> CPUFreq-hw driver to prevent such breakages.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
  2021-07-29 18:04 ` [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node Sibi Sankar
@ 2021-08-04 18:57   ` Stephen Boyd
  2021-08-31 15:30   ` Matthias Kaehlcke
  1 sibling, 0 replies; 21+ messages in thread
From: Stephen Boyd @ 2021-08-04 18:57 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, mka, robh+dt
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas

Quoting Sibi Sankar (2021-07-29 11:04:44)
> Fixup the register regions used by the cpufreq node on SC7280 SoC to
> support per core L3 DCVS.
>
> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-07-29 18:04 ` [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS Sibi Sankar
@ 2021-08-04 19:01   ` Stephen Boyd
  2021-08-05 17:47     ` Sibi Sankar
  2021-08-04 23:11   ` Bjorn Andersson
  1 sibling, 1 reply; 21+ messages in thread
From: Stephen Boyd @ 2021-08-04 19:01 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, mka, robh+dt
  Cc: viresh.kumar, agross, rjw, linux-arm-msm, devicetree,
	linux-kernel, linux-pm, dianders, tdas

Quoting Sibi Sankar (2021-07-29 11:04:43)
> Qualcomm SoCs (starting with SM8350) support per core voting for L3 cache
> frequency.

And the L3 cache frequency voting code can't be put into this cpufreq
driver?

> So, re-arrange the cpufreq register offsets to allow access for
> the L3 interconnect to implement per core control. Also prevent binding
> breakage caused by register offset shuffling by using the SM8250/SM8350
> EPSS compatible.
>
> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index f86859bf76f1..74ef3b38343b 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
>         u32 reg_volt_lut;
>         u32 reg_perf_state;
>         u8 lut_row_size;
> +       bool skip_enable;
>  };
>
>  struct qcom_cpufreq_data {
> @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
>         .reg_volt_lut = 0x114,
>         .reg_perf_state = 0x920,
>         .lut_row_size = 32,
> +       .skip_enable = false,
>  };
>
>  static const struct qcom_cpufreq_soc_data epss_soc_data = {
> +       .reg_freq_lut = 0x0,
> +       .reg_volt_lut = 0x100,
> +       .reg_perf_state = 0x220,
> +       .lut_row_size = 4,
> +       .skip_enable = true,
> +};
> +
> +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
>         .reg_enable = 0x0,
>         .reg_freq_lut = 0x100,
>         .reg_volt_lut = 0x200,
>         .reg_perf_state = 0x320,
>         .lut_row_size = 4,
> +       .skip_enable = false,
>  };
>
>  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,sm8250-cpufreq-epss", .data = &epss_sm8250_soc_data },
> +       { .compatible = "qcom,sm8350-cpufreq-epss", .data = &epss_sm8250_soc_data },
>         {}
>  };
>  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
>         data->res = res;
>
>         /* HW should be in enabled state to proceed */

It looks odd that we're no longer making sure that the clk domain is
enabled when we probe the driver. Why is that OK?

> -       if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> -               dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> -               ret = -ENODEV;
> -               goto error;
> +       if (!data->soc_data->skip_enable) {
> +               if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> +                       dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> +                       ret = -ENODEV;
> +                       goto error;
> +               }
>         }
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
  2021-07-29 18:04 ` [PATCH 4/4] arm64: dts: qcom: sm8350: " Sibi Sankar
@ 2021-08-04 22:59   ` Bjorn Andersson
  2021-08-04 23:58     ` Matthias Kaehlcke
  0 siblings, 1 reply; 21+ messages in thread
From: Bjorn Andersson @ 2021-08-04 22:59 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: sboyd, robh+dt, mka, viresh.kumar, agross, rjw, linux-arm-msm,
	devicetree, linux-kernel, linux-pm, dianders, tdas

On Thu 29 Jul 13:04 CDT 2021, Sibi Sankar wrote:

> Fixup the register regions used by the cpufreq node on SM8350 SoC to
> support per core L3 DCVS.
> 

That sounds good, but why are you dropping the platform-specific
compatible?

Regards,
Bjorn

> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  arch/arm64/boot/dts/qcom/sm8350.dtsi | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index a631d58166b1..d0a5a5568602 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> @@ -967,11 +967,10 @@
>  		};
>  
>  		cpufreq_hw: cpufreq@18591000 {
> -			compatible = "qcom,sm8350-cpufreq-epss", "qcom,cpufreq-epss";
> -			reg = <0 0x18591000 0 0x1000>,
> -			      <0 0x18592000 0 0x1000>,
> -			      <0 0x18593000 0 0x1000>;
> -			reg-names = "freq-domain0", "freq-domain1", "freq-domain2";
> +			compatible = "qcom,cpufreq-epss";
> +			reg = <0 0x18591100 0 0x900>,
> +			      <0 0x18592100 0 0x900>,
> +			      <0 0x18593100 0 0x900>;
>  
>  			clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_GPLL0>;
>  			clock-names = "xo", "alternate";
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-07-29 18:04 ` [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS Sibi Sankar
  2021-08-04 19:01   ` Stephen Boyd
@ 2021-08-04 23:11   ` Bjorn Andersson
  2021-08-04 23:20     ` Bjorn Andersson
  1 sibling, 1 reply; 21+ messages in thread
From: Bjorn Andersson @ 2021-08-04 23:11 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: sboyd, robh+dt, mka, viresh.kumar, agross, rjw, linux-arm-msm,
	devicetree, linux-kernel, linux-pm, dianders, tdas

On Thu 29 Jul 13:04 CDT 2021, Sibi Sankar wrote:

> Qualcomm SoCs (starting with SM8350) support per core voting for L3 cache
> frequency. So, re-arrange the cpufreq register offsets to allow access for
> the L3 interconnect to implement per core control. Also prevent binding
> breakage caused by register offset shuffling by using the SM8250/SM8350
> EPSS compatible.
> 
> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index f86859bf76f1..74ef3b38343b 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
>  	u32 reg_volt_lut;
>  	u32 reg_perf_state;
>  	u8 lut_row_size;
> +	bool skip_enable;

This should probably be called "skip_enable_check".

>  };
>  
>  struct qcom_cpufreq_data {
> @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
>  	.reg_volt_lut = 0x114,
>  	.reg_perf_state = 0x920,
>  	.lut_row_size = 32,
> +	.skip_enable = false,
>  };
>  
>  static const struct qcom_cpufreq_soc_data epss_soc_data = {
> +	.reg_freq_lut = 0x0,
> +	.reg_volt_lut = 0x100,
> +	.reg_perf_state = 0x220,
> +	.lut_row_size = 4,
> +	.skip_enable = true,

This change is not compatible with existing DTBs.

Regards,
Bjorn

> +};
> +
> +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
>  	.reg_enable = 0x0,
>  	.reg_freq_lut = 0x100,
>  	.reg_volt_lut = 0x200,
>  	.reg_perf_state = 0x320,
>  	.lut_row_size = 4,
> +	.skip_enable = false,
>  };
>  
>  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,sm8250-cpufreq-epss", .data = &epss_sm8250_soc_data },
> +	{ .compatible = "qcom,sm8350-cpufreq-epss", .data = &epss_sm8250_soc_data },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
>  	data->res = res;
>  
>  	/* HW should be in enabled state to proceed */
> -	if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> -		dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> -		ret = -ENODEV;
> -		goto error;
> +	if (!data->soc_data->skip_enable) {
> +		if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> +			dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> +			ret = -ENODEV;
> +			goto error;
> +		}
>  	}
>  
>  	qcom_get_related_cpus(index, policy->cpus);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-08-04 23:11   ` Bjorn Andersson
@ 2021-08-04 23:20     ` Bjorn Andersson
  0 siblings, 0 replies; 21+ messages in thread
From: Bjorn Andersson @ 2021-08-04 23:20 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: sboyd, robh+dt, mka, viresh.kumar, agross, rjw, linux-arm-msm,
	devicetree, linux-kernel, linux-pm, dianders, tdas

On Wed 04 Aug 18:11 CDT 2021, Bjorn Andersson wrote:

> On Thu 29 Jul 13:04 CDT 2021, Sibi Sankar wrote:
> 
> > Qualcomm SoCs (starting with SM8350) support per core voting for L3 cache
> > frequency. So, re-arrange the cpufreq register offsets to allow access for
> > the L3 interconnect to implement per core control. Also prevent binding
> > breakage caused by register offset shuffling by using the SM8250/SM8350
> > EPSS compatible.
> > 
> > Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > ---
> >  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
> >  1 file changed, 19 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> > index f86859bf76f1..74ef3b38343b 100644
> > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
> >  	u32 reg_volt_lut;
> >  	u32 reg_perf_state;
> >  	u8 lut_row_size;
> > +	bool skip_enable;
> 
> This should probably be called "skip_enable_check".
> 
> >  };
> >  
> >  struct qcom_cpufreq_data {
> > @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data qcom_soc_data = {
> >  	.reg_volt_lut = 0x114,
> >  	.reg_perf_state = 0x920,
> >  	.lut_row_size = 32,
> > +	.skip_enable = false,
> >  };
> >  
> >  static const struct qcom_cpufreq_soc_data epss_soc_data = {
> > +	.reg_freq_lut = 0x0,
> > +	.reg_volt_lut = 0x100,
> > +	.reg_perf_state = 0x220,
> > +	.lut_row_size = 4,
> > +	.skip_enable = true,
> 
> This change is not compatible with existing DTBs.
> 

Continued staring at this after I sent my response, and I'm confused.

You're say in the commit message that SM8350 and beyond needs access to
some registers in the first 0x100 bytes of the register space. So
therefor you're changing the fallback, which is only used for sc7280...

In other words, you break the compatibility with the existing sc7280
dtb and leave sm8350 unchanged - after saying that this change is for
the sake of sm8350.


Lastly, why is "the L3 frequency" an interconnect and not a clock? (And
why don't we make the cpufreq driver a clock-controller for the
platforms that has this?)

Regards,
Bjorn

> Regards,
> Bjorn
> 
> > +};
> > +
> > +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
> >  	.reg_enable = 0x0,
> >  	.reg_freq_lut = 0x100,
> >  	.reg_volt_lut = 0x200,
> >  	.reg_perf_state = 0x320,
> >  	.lut_row_size = 4,
> > +	.skip_enable = false,
> >  };
> >  
> >  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,sm8250-cpufreq-epss", .data = &epss_sm8250_soc_data },
> > +	{ .compatible = "qcom,sm8350-cpufreq-epss", .data = &epss_sm8250_soc_data },
> >  	{}
> >  };
> >  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> > @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
> >  	data->res = res;
> >  
> >  	/* HW should be in enabled state to proceed */
> > -	if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> > -		dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> > -		ret = -ENODEV;
> > -		goto error;
> > +	if (!data->soc_data->skip_enable) {
> > +		if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) {
> > +			dev_err(dev, "Domain-%d cpufreq hardware not enabled\n", index);
> > +			ret = -ENODEV;
> > +			goto error;
> > +		}
> >  	}
> >  
> >  	qcom_get_related_cpus(index, policy->cpus);
> > -- 
> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> > 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
  2021-08-04 22:59   ` Bjorn Andersson
@ 2021-08-04 23:58     ` Matthias Kaehlcke
  2021-08-30  6:47       ` Sibi Sankar
  0 siblings, 1 reply; 21+ messages in thread
From: Matthias Kaehlcke @ 2021-08-04 23:58 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Sibi Sankar, sboyd, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

On Wed, Aug 04, 2021 at 05:59:04PM -0500, Bjorn Andersson wrote:
> On Thu 29 Jul 13:04 CDT 2021, Sibi Sankar wrote:
> 
> > Fixup the register regions used by the cpufreq node on SM8350 SoC to
> > support per core L3 DCVS.
> > 
> 
> That sounds good, but why are you dropping the platform-specific
> compatible?
> 

I also stared at this and the patch that changes the code for a while.

My understanding is that removing the platform-specific compatible is part
of not breaking 'old' DTBs. Old DTBs for SM8350 contain the larger register
regions and must be paired with 'epss_sm8250_soc_data' (driver code) which
has the 'old' 'reg_perf_state' offset. New SM8350 DTs only have the
'qcom,cpufreq-epss' compatible, which pairs their smaller register regions
with 'epss_soc_data' with the new 'reg_perf_state' offset.

It is super-confusing that the platform-specific compatible string is
missing. The binding should probably mention that the two
platform-specific compatible strings are for backwards compatibility
only and should not be added to new or existing DT files that don't
have them already. Maybe a 'qcom,sm8350-cpufreq-epss-v2' or similar
should be added to avoid/reduce possible confusion and have to option
to add SM8350 specific code later.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-08-04 19:01   ` Stephen Boyd
@ 2021-08-05 17:47     ` Sibi Sankar
  2021-08-05 18:25       ` Stephen Boyd
  0 siblings, 1 reply; 21+ messages in thread
From: Sibi Sankar @ 2021-08-05 17:47 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: bjorn.andersson, mka, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

Stephen,

Thanks for taking time to review
the series.

On 2021-08-05 00:31, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-07-29 11:04:43)
>> Qualcomm SoCs (starting with SM8350) support per core voting for L3 
>> cache
>> frequency.
> 
> And the L3 cache frequency voting code can't be put into this cpufreq
> driver?

Yes, it could have gone either into
the cpufreq driver or l3 interconnect
provider driver. Taniya/Odelu preferred
the latter, because of the need for other
clients to vote for l3 frequencies in
the future. The other option to prevent
register re-arrangement would involve
using syscons from the cpufreq node, which
really wasn't necessary since there
wasn't any register overlap between the
two drivers.

> 
>> So, re-arrange the cpufreq register offsets to allow access for
>> the L3 interconnect to implement per core control. Also prevent 
>> binding
>> breakage caused by register offset shuffling by using the 
>> SM8250/SM8350
>> EPSS compatible.
>> 
>> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
>> b/drivers/cpufreq/qcom-cpufreq-hw.c
>> index f86859bf76f1..74ef3b38343b 100644
>> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>> @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
>>         u32 reg_volt_lut;
>>         u32 reg_perf_state;
>>         u8 lut_row_size;
>> +       bool skip_enable;
>>  };
>> 
>>  struct qcom_cpufreq_data {
>> @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data 
>> qcom_soc_data = {
>>         .reg_volt_lut = 0x114,
>>         .reg_perf_state = 0x920,
>>         .lut_row_size = 32,
>> +       .skip_enable = false,
>>  };
>> 
>>  static const struct qcom_cpufreq_soc_data epss_soc_data = {
>> +       .reg_freq_lut = 0x0,
>> +       .reg_volt_lut = 0x100,
>> +       .reg_perf_state = 0x220,
>> +       .lut_row_size = 4,
>> +       .skip_enable = true,
>> +};
>> +
>> +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
>>         .reg_enable = 0x0,
>>         .reg_freq_lut = 0x100,
>>         .reg_volt_lut = 0x200,
>>         .reg_perf_state = 0x320,
>>         .lut_row_size = 4,
>> +       .skip_enable = false,
>>  };
>> 
>>  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,sm8250-cpufreq-epss", .data = 
>> &epss_sm8250_soc_data },
>> +       { .compatible = "qcom,sm8350-cpufreq-epss", .data = 
>> &epss_sm8250_soc_data },
>>         {}
>>  };
>>  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
>> @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct 
>> cpufreq_policy *policy)
>>         data->res = res;
>> 
>>         /* HW should be in enabled state to proceed */
> 
> It looks odd that we're no longer making sure that the clk domain is
> enabled when we probe the driver. Why is that OK?

On newer EPSS hw it's no longer
required to perform the additional
hw enable check. IIRC we don't do
that on corresponding downstream
kernels as well.

> 
>> -       if (!(readl_relaxed(base + data->soc_data->reg_enable) & 0x1)) 
>> {
>> -               dev_err(dev, "Domain-%d cpufreq hardware not 
>> enabled\n", index);
>> -               ret = -ENODEV;
>> -               goto error;
>> +       if (!data->soc_data->skip_enable) {
>> +               if (!(readl_relaxed(base + data->soc_data->reg_enable) 
>> & 0x1)) {
>> +                       dev_err(dev, "Domain-%d cpufreq hardware not 
>> enabled\n", index);
>> +                       ret = -ENODEV;
>> +                       goto error;
>> +               }
>>         }
>> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-08-05 17:47     ` Sibi Sankar
@ 2021-08-05 18:25       ` Stephen Boyd
  2021-08-06  6:42         ` Sibi Sankar
  0 siblings, 1 reply; 21+ messages in thread
From: Stephen Boyd @ 2021-08-05 18:25 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, mka, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

Quoting Sibi Sankar (2021-08-05 10:47:20)
> Stephen,
>
> Thanks for taking time to review
> the series.
>
> On 2021-08-05 00:31, Stephen Boyd wrote:
> > Quoting Sibi Sankar (2021-07-29 11:04:43)
> >> Qualcomm SoCs (starting with SM8350) support per core voting for L3
> >> cache
> >> frequency.
> >
> > And the L3 cache frequency voting code can't be put into this cpufreq
> > driver?
>
> Yes, it could have gone either into
> the cpufreq driver or l3 interconnect
> provider driver. Taniya/Odelu preferred
> the latter, because of the need for other
> clients to vote for l3 frequencies in
> the future.

What other clients are those?

> The other option to prevent
> register re-arrangement would involve
> using syscons from the cpufreq node, which
> really wasn't necessary since there
> wasn't any register overlap between the
> two drivers.

Let's not do that.

>
> >
> >> So, re-arrange the cpufreq register offsets to allow access for
> >> the L3 interconnect to implement per core control. Also prevent
> >> binding
> >> breakage caused by register offset shuffling by using the
> >> SM8250/SM8350
> >> EPSS compatible.
> >>
> >> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> >> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> >> ---
> >>  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
> >>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> >> b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> index f86859bf76f1..74ef3b38343b 100644
> >> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> >> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> >> @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
> >>         u32 reg_volt_lut;
> >>         u32 reg_perf_state;
> >>         u8 lut_row_size;
> >> +       bool skip_enable;
> >>  };
> >>
> >>  struct qcom_cpufreq_data {
> >> @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data
> >> qcom_soc_data = {
> >>         .reg_volt_lut = 0x114,
> >>         .reg_perf_state = 0x920,
> >>         .lut_row_size = 32,
> >> +       .skip_enable = false,
> >>  };
> >>
> >>  static const struct qcom_cpufreq_soc_data epss_soc_data = {
> >> +       .reg_freq_lut = 0x0,
> >> +       .reg_volt_lut = 0x100,
> >> +       .reg_perf_state = 0x220,
> >> +       .lut_row_size = 4,
> >> +       .skip_enable = true,
> >> +};
> >> +
> >> +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
> >>         .reg_enable = 0x0,
> >>         .reg_freq_lut = 0x100,
> >>         .reg_volt_lut = 0x200,
> >>         .reg_perf_state = 0x320,
> >>         .lut_row_size = 4,
> >> +       .skip_enable = false,
> >>  };
> >>
> >>  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,sm8250-cpufreq-epss", .data =
> >> &epss_sm8250_soc_data },
> >> +       { .compatible = "qcom,sm8350-cpufreq-epss", .data =
> >> &epss_sm8250_soc_data },
> >>         {}
> >>  };
> >>  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
> >> @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct
> >> cpufreq_policy *policy)
> >>         data->res = res;
> >>
> >>         /* HW should be in enabled state to proceed */
> >
> > It looks odd that we're no longer making sure that the clk domain is
> > enabled when we probe the driver. Why is that OK?
>
> On newer EPSS hw it's no longer
> required to perform the additional
> hw enable check. IIRC we don't do
> that on corresponding downstream
> kernels as well.

It's fairly clear that we no longer perform the additional check. The
question is why that's OK.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
  2021-08-05 18:25       ` Stephen Boyd
@ 2021-08-06  6:42         ` Sibi Sankar
  0 siblings, 0 replies; 21+ messages in thread
From: Sibi Sankar @ 2021-08-06  6:42 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: bjorn.andersson, mka, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

On 2021-08-05 23:55, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-08-05 10:47:20)
>> Stephen,
>> 
>> Thanks for taking time to review
>> the series.
>> 
>> On 2021-08-05 00:31, Stephen Boyd wrote:
>> > Quoting Sibi Sankar (2021-07-29 11:04:43)
>> >> Qualcomm SoCs (starting with SM8350) support per core voting for L3
>> >> cache
>> >> frequency.
>> >
>> > And the L3 cache frequency voting code can't be put into this cpufreq
>> > driver?
>> 
>> Yes, it could have gone either into
>> the cpufreq driver or l3 interconnect
>> provider driver. Taniya/Odelu preferred
>> the latter, because of the need for other
>> clients to vote for l3 frequencies in
>> the future.
> 
> What other clients are those?

https://lore.kernel.org/lkml/20190814152116.GB28465@jcrouse1-lnx.qualcomm.com/

GPU was supposed to be one of the
other clients that would vote for
l3.

> 
>> The other option to prevent
>> register re-arrangement would involve
>> using syscons from the cpufreq node, which
>> really wasn't necessary since there
>> wasn't any register overlap between the
>> two drivers.
> 
> Let's not do that.
> 
>> 
>> >
>> >> So, re-arrange the cpufreq register offsets to allow access for
>> >> the L3 interconnect to implement per core control. Also prevent
>> >> binding
>> >> breakage caused by register offset shuffling by using the
>> >> SM8250/SM8350
>> >> EPSS compatible.
>> >>
>> >> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
>> >> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> >> ---
>> >>  drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++----
>> >>  1 file changed, 19 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
>> >> b/drivers/cpufreq/qcom-cpufreq-hw.c
>> >> index f86859bf76f1..74ef3b38343b 100644
>> >> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>> >> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>> >> @@ -28,6 +28,7 @@ struct qcom_cpufreq_soc_data {
>> >>         u32 reg_volt_lut;
>> >>         u32 reg_perf_state;
>> >>         u8 lut_row_size;
>> >> +       bool skip_enable;
>> >>  };
>> >>
>> >>  struct qcom_cpufreq_data {
>> >> @@ -257,19 +258,31 @@ static const struct qcom_cpufreq_soc_data
>> >> qcom_soc_data = {
>> >>         .reg_volt_lut = 0x114,
>> >>         .reg_perf_state = 0x920,
>> >>         .lut_row_size = 32,
>> >> +       .skip_enable = false,
>> >>  };
>> >>
>> >>  static const struct qcom_cpufreq_soc_data epss_soc_data = {
>> >> +       .reg_freq_lut = 0x0,
>> >> +       .reg_volt_lut = 0x100,
>> >> +       .reg_perf_state = 0x220,
>> >> +       .lut_row_size = 4,
>> >> +       .skip_enable = true,
>> >> +};
>> >> +
>> >> +static const struct qcom_cpufreq_soc_data epss_sm8250_soc_data = {
>> >>         .reg_enable = 0x0,
>> >>         .reg_freq_lut = 0x100,
>> >>         .reg_volt_lut = 0x200,
>> >>         .reg_perf_state = 0x320,
>> >>         .lut_row_size = 4,
>> >> +       .skip_enable = false,
>> >>  };
>> >>
>> >>  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,sm8250-cpufreq-epss", .data =
>> >> &epss_sm8250_soc_data },
>> >> +       { .compatible = "qcom,sm8350-cpufreq-epss", .data =
>> >> &epss_sm8250_soc_data },
>> >>         {}
>> >>  };
>> >>  MODULE_DEVICE_TABLE(of, qcom_cpufreq_hw_match);
>> >> @@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct
>> >> cpufreq_policy *policy)
>> >>         data->res = res;
>> >>
>> >>         /* HW should be in enabled state to proceed */
>> >
>> > It looks odd that we're no longer making sure that the clk domain is
>> > enabled when we probe the driver. Why is that OK?
>> 
>> On newer EPSS hw it's no longer
>> required to perform the additional
>> hw enable check. IIRC we don't do
>> that on corresponding downstream
>> kernels as well.
> 
> It's fairly clear that we no longer perform the additional check. The
> question is why that's OK.

Taniya probably would know more
about the history behind the change.
I'll dig up more info regarding ^^
and update the thread.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
  2021-08-04 23:58     ` Matthias Kaehlcke
@ 2021-08-30  6:47       ` Sibi Sankar
  0 siblings, 0 replies; 21+ messages in thread
From: Sibi Sankar @ 2021-08-30  6:47 UTC (permalink / raw)
  To: Matthias Kaehlcke, Bjorn Andersson
  Cc: sboyd, robh+dt, viresh.kumar, agross, rjw, linux-arm-msm,
	devicetree, linux-kernel, linux-pm, dianders, tdas

On 2021-08-05 05:28, Matthias Kaehlcke wrote:
> On Wed, Aug 04, 2021 at 05:59:04PM -0500, Bjorn Andersson wrote:
>> On Thu 29 Jul 13:04 CDT 2021, Sibi Sankar wrote:
>> 
>> > Fixup the register regions used by the cpufreq node on SM8350 SoC to
>> > support per core L3 DCVS.
>> >
>> 
>> That sounds good, but why are you dropping the platform-specific
>> compatible?
>> 
> 
> I also stared at this and the patch that changes the code for a while.
> 
> My understanding is that removing the platform-specific compatible is 
> part
> of not breaking 'old' DTBs. Old DTBs for SM8350 contain the larger 
> register
> regions and must be paired with 'epss_sm8250_soc_data' (driver code) 
> which
> has the 'old' 'reg_perf_state' offset. New SM8350 DTs only have the
> 'qcom,cpufreq-epss' compatible, which pairs their smaller register 
> regions
> with 'epss_soc_data' with the new 'reg_perf_state' offset.
> 
> It is super-confusing that the platform-specific compatible string is
> missing. The binding should probably mention that the two
> platform-specific compatible strings are for backwards compatibility
> only and should not be added to new or existing DT files that don't
> have them already. Maybe a 'qcom,sm8350-cpufreq-epss-v2' or similar
> should be added to avoid/reduce possible confusion and have to option
> to add SM8350 specific code later.

Bjorn,

https://patchwork.kernel.org/project/linux-arm-msm/cover/1629458622-4915-1-git-send-email-okukatla@codeaurora.org/

This series affects the design of the l3
provider support for sc7280 which will be
in a position to land in ~1-2 respins. So,
please share an early ACK or NACK regarding
the register re-ordering series so that we
can plan to get alternate acceptable versions
out faster on the list.


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
  2021-07-29 18:04 ` [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node Sibi Sankar
  2021-08-04 18:57   ` Stephen Boyd
@ 2021-08-31 15:30   ` Matthias Kaehlcke
  2021-08-31 17:04     ` Bjorn Andersson
  1 sibling, 1 reply; 21+ messages in thread
From: Matthias Kaehlcke @ 2021-08-31 15:30 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: sboyd, bjorn.andersson, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

On Thu, Jul 29, 2021 at 11:34:44PM +0530, Sibi Sankar wrote:
> Fixup the register regions used by the cpufreq node on SC7280 SoC to
> support per core L3 DCVS.
> 
> Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

This patch landed in the Bjorn's tree, however the corresponding driver
change ("cpufreq: qcom: Re-arrange register offsets to support per core
L3 DCVS" / https://patchwork.kernel.org/project/linux-arm-msm/patch/1627581885-32165-3-git-send-email-sibis@codeaurora.org/)
did not land in any maintainer tree yet AFAIK. IIUC the DT change alone
breaks cpufreq since the changed register regions require the changed
offset in the cpufreq driver.

Sibi, please confirm or clarify that my concern is unwarranted.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
  2021-08-31 15:30   ` Matthias Kaehlcke
@ 2021-08-31 17:04     ` Bjorn Andersson
  2021-09-06  3:20       ` Sibi Sankar
  0 siblings, 1 reply; 21+ messages in thread
From: Bjorn Andersson @ 2021-08-31 17:04 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: Sibi Sankar, sboyd, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

On Tue 31 Aug 08:30 PDT 2021, Matthias Kaehlcke wrote:

> On Thu, Jul 29, 2021 at 11:34:44PM +0530, Sibi Sankar wrote:
> > Fixup the register regions used by the cpufreq node on SC7280 SoC to
> > support per core L3 DCVS.
> > 
> > Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> 
> This patch landed in the Bjorn's tree, however the corresponding driver
> change ("cpufreq: qcom: Re-arrange register offsets to support per core
> L3 DCVS" / https://patchwork.kernel.org/project/linux-arm-msm/patch/1627581885-32165-3-git-send-email-sibis@codeaurora.org/)
> did not land in any maintainer tree yet AFAIK. IIUC the DT change alone
> breaks cpufreq since the changed register regions require the changed
> offset in the cpufreq driver.
> 

Thanks for the note Matthias, it must have slipped by as I scraped the
inbox for things that looked ready.

I'm actually not in favor of splitting these memory blocks in DT to
facilitate the Linux implementation of splitting that in multiple
drivers...

But I've not been following up on that discussion.

Regards,
Bjorn

> Sibi, please confirm or clarify that my concern is unwarranted.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
  2021-08-31 17:04     ` Bjorn Andersson
@ 2021-09-06  3:20       ` Sibi Sankar
  2021-09-07 19:14         ` Doug Anderson
  0 siblings, 1 reply; 21+ messages in thread
From: Sibi Sankar @ 2021-09-06  3:20 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Matthias Kaehlcke, sboyd, robh+dt, viresh.kumar, agross, rjw,
	linux-arm-msm, devicetree, linux-kernel, linux-pm, dianders,
	tdas

On 2021-08-31 22:34, Bjorn Andersson wrote:
> On Tue 31 Aug 08:30 PDT 2021, Matthias Kaehlcke wrote:
> 
>> On Thu, Jul 29, 2021 at 11:34:44PM +0530, Sibi Sankar wrote:
>> > Fixup the register regions used by the cpufreq node on SC7280 SoC to
>> > support per core L3 DCVS.
>> >
>> > Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
>> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> 
>> This patch landed in the Bjorn's tree, however the corresponding 
>> driver
>> change ("cpufreq: qcom: Re-arrange register offsets to support per 
>> core
>> L3 DCVS" / 
>> https://patchwork.kernel.org/project/linux-arm-msm/patch/1627581885-32165-3-git-send-email-sibis@codeaurora.org/)
>> did not land in any maintainer tree yet AFAIK. IIUC the DT change 
>> alone
>> breaks cpufreq since the changed register regions require the changed
>> offset in the cpufreq driver.
>> 
> 
> Thanks for the note Matthias, it must have slipped by as I scraped the
> inbox for things that looked ready.
> 
> I'm actually not in favor of splitting these memory blocks in DT to
> facilitate the Linux implementation of splitting that in multiple
> drivers...
> 
> But I've not been following up on that discussion.
> 
> Regards,
> Bjorn
> 
>> Sibi, please confirm or clarify that my concern is unwarranted.

Let's drop the patch asap as it breaks
SC7280 cpufreq on lnext without the driver
changes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
  2021-09-06  3:20       ` Sibi Sankar
@ 2021-09-07 19:14         ` Doug Anderson
  0 siblings, 0 replies; 21+ messages in thread
From: Doug Anderson @ 2021-09-07 19:14 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Matthias Kaehlcke, Stephen Boyd, Rob Herring,
	Viresh Kumar, Andy Gross, Rafael J. Wysocki, linux-arm-msm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
	Linux PM, Taniya Das

Hi,

On Sun, Sep 5, 2021 at 8:20 PM Sibi Sankar <sibis@codeaurora.org> wrote:
>
> On 2021-08-31 22:34, Bjorn Andersson wrote:
> > On Tue 31 Aug 08:30 PDT 2021, Matthias Kaehlcke wrote:
> >
> >> On Thu, Jul 29, 2021 at 11:34:44PM +0530, Sibi Sankar wrote:
> >> > Fixup the register regions used by the cpufreq node on SC7280 SoC to
> >> > support per core L3 DCVS.
> >> >
> >> > Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
> >> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> >>
> >> This patch landed in the Bjorn's tree, however the corresponding
> >> driver
> >> change ("cpufreq: qcom: Re-arrange register offsets to support per
> >> core
> >> L3 DCVS" /
> >> https://patchwork.kernel.org/project/linux-arm-msm/patch/1627581885-32165-3-git-send-email-sibis@codeaurora.org/)
> >> did not land in any maintainer tree yet AFAIK. IIUC the DT change
> >> alone
> >> breaks cpufreq since the changed register regions require the changed
> >> offset in the cpufreq driver.
> >>
> >
> > Thanks for the note Matthias, it must have slipped by as I scraped the
> > inbox for things that looked ready.
> >
> > I'm actually not in favor of splitting these memory blocks in DT to
> > facilitate the Linux implementation of splitting that in multiple
> > drivers...
> >
> > But I've not been following up on that discussion.
> >
> > Regards,
> > Bjorn
> >
> >> Sibi, please confirm or clarify that my concern is unwarranted.
>
> Let's drop the patch asap as it breaks
> SC7280 cpufreq on lnext without the driver
> changes.

It's already landed so we need a revert:

https://lore.kernel.org/r/20210907121220.1.I08460f490473b70de0d768db45f030a4d5c17828@changeid/

-Doug

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2021-09-07 19:14 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-29 18:04 [PATCH 0/4] Fixup register offsets to support per core L3 DCVS Sibi Sankar
2021-07-29 18:04 ` [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350 Sibi Sankar
2021-08-03 19:23   ` Rob Herring
2021-08-04 18:56   ` Stephen Boyd
2021-07-29 18:04 ` [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS Sibi Sankar
2021-08-04 19:01   ` Stephen Boyd
2021-08-05 17:47     ` Sibi Sankar
2021-08-05 18:25       ` Stephen Boyd
2021-08-06  6:42         ` Sibi Sankar
2021-08-04 23:11   ` Bjorn Andersson
2021-08-04 23:20     ` Bjorn Andersson
2021-07-29 18:04 ` [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node Sibi Sankar
2021-08-04 18:57   ` Stephen Boyd
2021-08-31 15:30   ` Matthias Kaehlcke
2021-08-31 17:04     ` Bjorn Andersson
2021-09-06  3:20       ` Sibi Sankar
2021-09-07 19:14         ` Doug Anderson
2021-07-29 18:04 ` [PATCH 4/4] arm64: dts: qcom: sm8350: " Sibi Sankar
2021-08-04 22:59   ` Bjorn Andersson
2021-08-04 23:58     ` Matthias Kaehlcke
2021-08-30  6:47       ` Sibi Sankar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).