Fixup register offsets to support per core L3 DCVS
Subsystems (5)
cover Fixup register offsets to support per core L3 DCVS
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(-)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH 1/4 dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
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.
--- Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt +5 -1
@@ -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
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
Quoted 10 lines · 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 <[email protected]>--- Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Re: [PATCH 1/4] dt-bindings: cpufreq: cpufreq-qcom-hw: Add compatible for SM8250/8350
In reply to Sibi SankarQuoting Sibi Sankar (2021-07-29 11:04:42)
Quoted 7 lines
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 <[email protected]>---
PATCH 2/4 cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
In reply to Sibi SankarQualcomm 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.
--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
drivers/cpufreq/qcom-cpufreq-hw.c +19 -4
@@ -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);
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
Quoting Sibi Sankar (2021-07-29 11:04:43)
Quoted 2 lines
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?
Quoted 56 lines
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 <[email protected]>--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)drivers/cpufreq/qcom-cpufreq-hw.c +13
-0@@ -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);
drivers/cpufreq/qcom-cpufreq-hw.c static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) · line 349
Quoted 3 lines
drivers/cpufreq/qcom-cpufreq-hw.c +0
-0@@ -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?
Quoted 12 lines
drivers/cpufreq/qcom-cpufreq-hw.c +6
-4-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; + } }
Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
Stephen,
Thanks for taking time to review the series.
Quoted 6 lines · Stephen Boyd
Quoting Sibi Sankar (2021-07-29 11:04:43)
Quoted 2 lines
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.
Quoted 63 lines
Quoted 63 lines
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 <[email protected]>--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)drivers/cpufreq/qcom-cpufreq-hw.c +13
-0@@ -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);drivers/cpufreq/qcom-cpufreq-hw.c +0
-0@@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) data->res = res;
Quoted 4 lines
drivers/cpufreq/qcom-cpufreq-hw.c static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) · line 349
Quoted 1 line
drivers/cpufreq/qcom-cpufreq-hw.c +0
-0/* 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.
Quoted 17 lines
Quoted 17 lines
drivers/cpufreq/qcom-cpufreq-hw.c +2
-4-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);drivers/cpufreq/qcom-cpufreq-hw.c +3
-0+ ret = -ENODEV ; + goto error; + } }
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
Quoting Sibi Sankar (2021-08-05 10:47:20)
Quoted 14 lines
Stephen,
Thanks for taking time to review the series.
Quoted 7 lines · Stephen Boyd
Quoting Sibi Sankar (2021-07-29 11:04:43)
Quoted 3 lines
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?
Quoted 6 lines
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?
Quoted 6 lines
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.
Quoted 72 lines
Quoted 67 lines
Quoted 67 lines
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 <[email protected]>--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)drivers/cpufreq/qcom-cpufreq-hw.c +13
-0@@ -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);drivers/cpufreq/qcom-cpufreq-hw.c +0
-0@@ -334,10 +347,12 @@ static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) data->res = res;Quoted 4 lines
drivers/cpufreq/qcom-cpufreq-hw.c static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy) · line 349
Quoted 1 line
drivers/cpufreq/qcom-cpufreq-hw.c +0
-0/* 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?
Quoted 5 lines
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.
Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
Quoted 15 lines · Stephen Boyd
Quoting Sibi Sankar (2021-08-05 10:47:20)
Quoted 14 lines
Stephen,
Thanks for taking time to review the series.
Quoted 7 lines · Stephen Boyd
Quoting Sibi Sankar (2021-07-29 11:04:43)
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
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/[email protected]/
GPU was supposed to be one of the
other clients that would vote for
l3.
Quoted 82 lines
Quoted 7 lines
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.
Quoted 72 lines
Quoted 71 lines
Quoted 64 lines
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 <[email protected]>--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)drivers/cpufreq/qcom-cpufreq-hw.c +13
-0@@ -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);drivers/cpufreq/qcom-cpufreq-hw.c static int qcom_cpufreq_hw_cpu_init(struct · line 350
Quoted 4 lines
drivers/cpufreq/qcom-cpufreq-hw.c +0
-0@@ -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?
Quoted 8 lines
Quoted 5 lines
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.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
In reply to Sibi SankarQuoted 17 lines · 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 <[email protected]>--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)drivers/cpufreq/qcom-cpufreq-hw.c +0
-0
drivers/cpufreq/qcom-cpufreq-hw.c struct qcom_cpufreq_soc_data { · line 31
Quoted 4 lines
drivers/cpufreq/qcom-cpufreq-hw.c +1
-0@@ -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".
Quoted 6 lines
drivers/cpufreq/qcom-cpufreq-hw.c +0
-0};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,
drivers/cpufreq/qcom-cpufreq-hw.c static const struct qcom_cpufreq_soc_data qcom_soc_data = { · line 269
Quoted 10 lines
drivers/cpufreq/qcom-cpufreq-hw.c +6
-0.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
Quoted 40 lines
drivers/cpufreq/qcom-cpufreq-hw.c +12
-4+}; + +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);Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/4] cpufreq: qcom: Re-arrange register offsets to support per core L3 DCVS
Quoted 36 lines · Bjorn Andersson
Quoted 17 lines · 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 <[email protected]>--- drivers/cpufreq/qcom-cpufreq-hw.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)drivers/cpufreq/qcom-cpufreq-hw.c +0
-0drivers/cpufreq/qcom-cpufreq-hw.c struct qcom_cpufreq_soc_data { · line 31
Quoted 4 lines
drivers/cpufreq/qcom-cpufreq-hw.c +1
-0@@ -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".Quoted 10 lines
drivers/cpufreq/qcom-cpufreq-hw.c +1
-0};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, };
Quoted 9 lines
drivers/cpufreq/qcom-cpufreq-hw.c static const struct qcom_cpufreq_soc_data qcom_soc_data = { · line 269
Quoted 6 lines
drivers/cpufreq/qcom-cpufreq-hw.c +5
-0static 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
Quoted 43 lines
Regards,
BjornQuoted 40 lines
drivers/cpufreq/qcom-cpufreq-hw.c +12
-4+}; + +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);Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH 3/4 arm64: dts: qcom: sc7280: Fixup the cpufreq node
In reply to Sibi SankarFixup the register regions used by the cpufreq node on SC7280 SoC to support per core L3 DCVS.
--- arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/qcom/sc7280.dtsi +3 -3
@@ -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>;
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
Quoting Sibi Sankar (2021-07-29 11:04:44)
Quoted 6 lines
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 <[email protected]>---
Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
In reply to Sibi SankarQuoted 5 lines · 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 <[email protected]>
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/[email protected]/)
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.
Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
Quoted 7 lines · Matthias Kaehlcke
Quoted 5 lines · 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 <[email protected]>
Quoted 7 lines
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/[email protected]/)
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
Quoted 1 line
Sibi, please confirm or clarify that my concern is unwarranted.
Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
Quoted 20 lines · Bjorn Andersson
Quoted 7 lines · Matthias Kaehlcke
Quoted 5 lines · 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 <[email protected]>Quoted 7 lines
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/[email protected]/)
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.
Quoted 10 lines
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,
BjornQuoted 1 line
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.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 3/4] arm64: dts: qcom: sc7280: Fixup the cpufreq node
Hi,
Quoted 32 lines · Sibi Sankar
Quoted 30 lines · Bjorn Andersson
Quoted 7 lines · Matthias Kaehlcke
Quoted 5 lines · 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 <[email protected]>Quoted 11 lines
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/[email protected]/)
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.
Quoted 8 lines
Quoted 4 lines
Regards,
BjornQuoted 1 line
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
PATCH 4/4 arm64: dts: qcom: sm8350: Fixup the cpufreq node
In reply to Sibi SankarFixup the register regions used by the cpufreq node on SM8350 SoC to support per core L3 DCVS.
--- arch/arm64/boot/dts/qcom/sm8350.dtsi | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
arch/arm64/boot/dts/qcom/sm8350.dtsi +4 -5
@@ -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";
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
Quoted 3 lines · Sibi Sankar
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
Quoted 29 lines
Signed-off-by Sibi Sankar <[email protected]>--- arch/arm64/boot/dts/qcom/sm8350.dtsi | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)arch/arm64/boot/dts/qcom/sm8350.dtsi +4
-5@@ -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";Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
Quoted 9 lines · Bjorn Andersson
Quoted 3 lines · Sibi Sankar
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.
Re: [PATCH 4/4] arm64: dts: qcom: sm8350: Fixup the cpufreq node
Quoted 20 lines · Matthias Kaehlcke
Quoted 9 lines · Bjorn Andersson
Quoted 3 lines · Sibi Sankar
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.
Quoted 7 lines
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/[email protected]/
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.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.