Enable cpufreq for IPQ5332 & IPQ9574
Subsystems (7)
cover Enable cpufreq for IPQ5332 & IPQ9574
Depends On:
https://lore.kernel.org/linux-arm-msm/[email protected]/
https://lore.kernel.org/linux-arm-msm/[email protected]/
This patch series aims to enable cpufreq for IPQ5332 and IPQ9574. For IPQ5332, a minor enhancement to Stromer Plus ops and a safe source switch is needed before cpu freq can be enabled.
These are also included in this series. Posting this as a single series. Please let me know if this is not correct, will split in the subsequent revisions.
Passed the following DT related validations
make W=1 ARCH=arm64 -j16 DT_CHECKER_FLAGS='-v -m' dt_binding_check DT_SCHEMA_FILES=qcom make W=1 ARCH=arm64 -j16 CHECK_DTBS=y DT_SCHEMA_FILES=qcom dtbs_check
For IPQ5332:
~~~~~~~~~~~
* This patch series introduces stromer plus ops which builds on stromer ops and implements a different set_rate and determine_rate.
A different set_rate is needed since stromer plus PLLs do not support dynamic frequency scaling. To switch between frequencies, we have to shut down the PLL, configure the L and ALPHA values and turn on again. So introduce the separate set of ops for Stromer Plus PLL.
* Update ipq_pll_stromer_plus to use clk_alpha_pll_stromer_plus_ops instead of clk_alpha_pll_stromer_ops.
* Set 'l' value to a value that is supported on all SKUs.
* Provide safe source switch for a53pll
* Include IPQ5332 in cpufreq nvmem framework
* Add OPP details to device tree
For IPQ9574:
~~~~~~~~~~~
* Include IPQ9574 in cpufreq nvmem framework
* Add OPP details to device tree
Varadarajan Narayanan (10):
clk: qcom: clk-alpha-pll: introduce stromer plus ops
clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll
clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config
clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ5332
cpufreq: qti: Enable cpufreq for ipq53xx
arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ9574
cpufreq: qti: Introduce cpufreq for ipq95xx
arm64: dts: qcom: ipq9574: populate the opp table based on the eFuse
.../bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 2 + arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 ++++++++++- arch/arm64/boot/dts/qcom/ipq9574.dtsi | 38 +++++++++++- drivers/clk/qcom/apss-ipq-pll.c | 4 +- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++- drivers/clk/qcom/clk-alpha-pll.c | 68 ++++++++++++++++++++++ drivers/clk/qcom/clk-alpha-pll.h | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 2 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 35 +++++++++++ 9 files changed, 231 insertions(+), 7 deletions(-)
Signature · 1 line
2.7.4
PATCH 1/10 clk: qcom: clk-alpha-pll: introduce stromer plus ops
Stromer plus APSS PLL does not support dynamic frequency scaling. To switch between frequencies, we have to shut down the PLL, configure the L and ALPHA values and turn on again. So introduce the separate set of ops for Stromer Plus PLL.
--- drivers/clk/qcom/clk-alpha-pll.c | 68 ++++++++++++++++++++++++++++++++++++++++ drivers/clk/qcom/clk-alpha-pll.h | 1 + 2 files changed, 69 insertions(+)
drivers/clk/qcom/clk-alpha-pll.c +68 -0
@@ -2479,3 +2479,71 @@ const struct clk_ops clk_alpha_pll_stromer_ops = { .set_rate = clk_alpha_pll_stromer_set_rate, };EXPORT_SYMBOL_GPL (clk_alpha_pll_stromer_ops); + +static int clk_alpha_pll_stromer_plus_determine_rate (struct clk_hw *hw, +struct clk_rate_request *req) +{ +struct clk_alpha_pll *pll =to_clk_alpha_pll (hw); +u32 l, alpha_width =pll_alpha_width (pll); +u64 a; + + req->rate =alpha_pll_round_rate (req->rate, req->best_parent_rate, &l, + &a, alpha_width); +return 0 ; +} + +static int clk_alpha_pll_stromer_plus_set_rate (struct clk_hw *hw, +unsigned long rate, +unsigned long prate) +{ +struct clk_alpha_pll *pll =to_clk_alpha_pll (hw); +u32 l, alpha_width =pll_alpha_width (pll); +int ret; +u64 a; + + rate =alpha_pll_round_rate (rate, prate, &l, &a, alpha_width); + +regmap_write (pll->clkr.regmap,PLL_MODE (pll),0 ); + +/* Delay of 2 output clock ticks required until output is disabled */ +udelay (1 ); + +regmap_write (pll->clkr.regmap,PLL_L_VAL (pll), l); + +if (alpha_width >ALPHA_BITWIDTH ) + a <<= alpha_width -ALPHA_BITWIDTH ; + +regmap_write (pll->clkr.regmap,PLL_ALPHA_VAL (pll), a); +regmap_write (pll->clkr.regmap,PLL_ALPHA_VAL_U (pll), + a >>ALPHA_BITWIDTH ); + +regmap_write (pll->clkr.regmap,PLL_MODE (pll),PLL_BYPASSNL ); + +/* Wait five micro seconds or more */ +udelay (5 ); +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_RESET_N , +PLL_RESET_N ); + +/* The lock time should be less than 50 micro seconds worst case */ +udelay (50 ); + + ret =wait_for_pll_enable_lock (pll); +if (ret) { +pr_err ("alpha pll running in 800 MHz with source GPLL0\n" ); +return ret; + } +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_OUTCTRL , +PLL_OUTCTRL ); + +return 0 ; +} + +const struct clk_ops clk_alpha_pll_stromer_plus_ops = { + .enable = clk_alpha_pll_enable, + .disable = clk_alpha_pll_disable, + .is_enabled = clk_alpha_pll_is_enabled, + .recalc_rate = clk_alpha_pll_recalc_rate, + .determine_rate = clk_alpha_pll_stromer_plus_determine_rate, + .set_rate = clk_alpha_pll_stromer_plus_set_rate, +}; +EXPORT_SYMBOL_GPL (clk_alpha_pll_stromer_plus_ops);
drivers/clk/qcom/clk-alpha-pll.h +1 -0
@@ -152,6 +152,7 @@ extern const struct clk_ops clk_alpha_pll_postdiv_ops;extern const struct clk_ops clk_alpha_pll_huayra_ops;extern const struct clk_ops clk_alpha_pll_postdiv_ro_ops;extern const struct clk_ops clk_alpha_pll_stromer_ops; +extern const struct clk_ops clk_alpha_pll_stromer_plus_ops;extern const struct clk_ops clk_alpha_pll_fabia_ops;extern const struct clk_ops clk_alpha_pll_fixed_fabia_ops;
Signature · 1 line
2.7.4
Re: [PATCH v1 01/10] clk: qcom: clk-alpha-pll: introduce stromer plus ops
Quoted 23 lines · Varadarajan Narayanan
Stromer plus APSS PLL does not support dynamic frequency scaling. To switch between frequencies, we have to shut down the PLL, configure the L and ALPHA values and turn on again. So introduce the separate set of ops for Stromer Plus PLL.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/clk-alpha-pll.c | 68 ++++++++++++++++++++++++++++++++++++++++ drivers/clk/qcom/clk-alpha-pll.h | 1 + 2 files changed, 69 insertions(+)drivers/clk/qcom/clk-alpha-pll.c +2
-0@@ -2479,3 +2479,71 @@ const struct clk_ops clk_alpha_pll_stromer_ops = { .set_rate = clk_alpha_pll_stromer_set_rate, };EXPORT_SYMBOL_GPL (clk_alpha_pll_stromer_ops); + +static int clk_alpha_pll_stromer_plus_determine_rate(struct clk_hw *hw,
drivers/clk/qcom/clk-alpha-pll.c const struct clk_ops clk_alpha_pll_stromer_ops = { · line 2493
Quoted 10 lines
drivers/clk/qcom/clk-alpha-pll.c +10
-0+ struct clk_rate_request *req) +{ +struct clk_alpha_pll *pll =to_clk_alpha_pll (hw); +u32 l, alpha_width =pll_alpha_width (pll); +u64 a; + + req->rate =alpha_pll_round_rate (req->rate, req->best_parent_rate, &l, + &a, alpha_width); +return 0 ; +}
What is the plL_alpha_width on stromer_plus? Does clk_alpha_pll_stromer_determine_rate() work for you?
Quoted 71 lines
drivers/clk/qcom/clk-alpha-pll.c +56
-0+ +static int clk_alpha_pll_stromer_plus_set_rate (struct clk_hw *hw, +unsigned long rate, +unsigned long prate) +{ +struct clk_alpha_pll *pll =to_clk_alpha_pll (hw); +u32 l, alpha_width =pll_alpha_width (pll); +int ret; +u64 a; + + rate =alpha_pll_round_rate (rate, prate, &l, &a, alpha_width); + +regmap_write (pll->clkr.regmap,PLL_MODE (pll),0 ); + +/* Delay of 2 output clock ticks required until output is disabled */ +udelay (1 ); + +regmap_write (pll->clkr.regmap,PLL_L_VAL (pll), l); + +if (alpha_width >ALPHA_BITWIDTH ) + a <<= alpha_width -ALPHA_BITWIDTH ; + +regmap_write (pll->clkr.regmap,PLL_ALPHA_VAL (pll), a); +regmap_write (pll->clkr.regmap,PLL_ALPHA_VAL_U (pll), + a >>ALPHA_BITWIDTH ); + +regmap_write (pll->clkr.regmap,PLL_MODE (pll),PLL_BYPASSNL ); + +/* Wait five micro seconds or more */ +udelay (5 ); +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_RESET_N , +PLL_RESET_N ); + +/* The lock time should be less than 50 micro seconds worst case */ +udelay (50 ); + + ret =wait_for_pll_enable_lock (pll); +if (ret) { +pr_err ("alpha pll running in 800 MHz with source GPLL0\n" ); +return ret; + } +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_OUTCTRL , +PLL_OUTCTRL ); + +return 0 ; +} + +const struct clk_ops clk_alpha_pll_stromer_plus_ops = { + .enable = clk_alpha_pll_enable, + .disable = clk_alpha_pll_disable, + .is_enabled = clk_alpha_pll_is_enabled, + .recalc_rate = clk_alpha_pll_recalc_rate, + .determine_rate = clk_alpha_pll_stromer_plus_determine_rate, + .set_rate = clk_alpha_pll_stromer_plus_set_rate, +}; +EXPORT_SYMBOL_GPL (clk_alpha_pll_stromer_plus_ops);drivers/clk/qcom/clk-alpha-pll.h +1
-1@@ -152,6 +152,7 @@ extern const struct clk_ops clk_alpha_pll_postdiv_ops;extern const struct clk_ops clk_alpha_pll_huayra_ops;extern const struct clk_ops clk_alpha_pll_postdiv_ro_ops;extern const struct clk_ops clk_alpha_pll_stromer_ops; +extern const struct clk_ops clk_alpha_pll_stromer_plus_ops;extern const struct clk_ops clk_alpha_pll_fabia_ops;extern const struct clk_ops clk_alpha_pll_fixed_fabia_ops; --2.7.4
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 01/10] clk: qcom: clk-alpha-pll: introduce stromer plus ops
Quoted 30 lines · Dmitry Baryshkov
Quoted 28 lines · Varadarajan Narayanan
Stromer plus APSS PLL does not support dynamic frequency scaling. To switch between frequencies, we have to shut down the PLL, configure the L and ALPHA values and turn on again. So introduce the separate set of ops for Stromer Plus PLL.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/clk-alpha-pll.c | 68 ++++++++++++++++++++++++++++++++++++++++ drivers/clk/qcom/clk-alpha-pll.h | 1 + 2 files changed, 69 insertions(+)drivers/clk/qcom/clk-alpha-pll.c +7
-0@@ -2479,3 +2479,71 @@ const struct clk_ops clk_alpha_pll_stromer_ops = { .set_rate = clk_alpha_pll_stromer_set_rate, };EXPORT_SYMBOL_GPL (clk_alpha_pll_stromer_ops); + +static int clk_alpha_pll_stromer_plus_determine_rate (struct clk_hw *hw, +struct clk_rate_request *req) +{ +struct clk_alpha_pll *pll =to_clk_alpha_pll (hw); +u32 l, alpha_width =pll_alpha_width (pll); +u64 a;
Quoted 8 lines
drivers/clk/qcom/clk-alpha-pll.c const struct clk_ops clk_alpha_pll_stromer_ops = { · line 2493
Quoted 5 lines
drivers/clk/qcom/clk-alpha-pll.c +5
-0+ + req->rate =alpha_pll_round_rate (req->rate, req->best_parent_rate, &l, + &a, alpha_width); +return 0 ; +}What is the
plL_alpha_widthonstromer_plus? Doesclk_alpha_pll_stromer_determine_rate()work for you?
pll_alpha_width is 4. I tested with clk_alpha_pll_stromer_determine_rate() and it works. Will change and post a new version.
Thanks
Varada
Quoted 76 lines
Quoted 69 lines
drivers/clk/qcom/clk-alpha-pll.c +56
-0+ +static int clk_alpha_pll_stromer_plus_set_rate (struct clk_hw *hw, +unsigned long rate, +unsigned long prate) +{ +struct clk_alpha_pll *pll =to_clk_alpha_pll (hw); +u32 l, alpha_width =pll_alpha_width (pll); +int ret; +u64 a; + + rate =alpha_pll_round_rate (rate, prate, &l, &a, alpha_width); + +regmap_write (pll->clkr.regmap,PLL_MODE (pll),0 ); + +/* Delay of 2 output clock ticks required until output is disabled */ +udelay (1 ); + +regmap_write (pll->clkr.regmap,PLL_L_VAL (pll), l); + +if (alpha_width >ALPHA_BITWIDTH ) + a <<= alpha_width -ALPHA_BITWIDTH ; + +regmap_write (pll->clkr.regmap,PLL_ALPHA_VAL (pll), a); +regmap_write (pll->clkr.regmap,PLL_ALPHA_VAL_U (pll), + a >>ALPHA_BITWIDTH ); + +regmap_write (pll->clkr.regmap,PLL_MODE (pll),PLL_BYPASSNL ); + +/* Wait five micro seconds or more */ +udelay (5 ); +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_RESET_N , +PLL_RESET_N ); + +/* The lock time should be less than 50 micro seconds worst case */ +udelay (50 ); + + ret =wait_for_pll_enable_lock (pll); +if (ret) { +pr_err ("alpha pll running in 800 MHz with source GPLL0\n" ); +return ret; + } +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_OUTCTRL , +PLL_OUTCTRL ); + +return 0 ; +} + +const struct clk_ops clk_alpha_pll_stromer_plus_ops = { + .enable = clk_alpha_pll_enable, + .disable = clk_alpha_pll_disable, + .is_enabled = clk_alpha_pll_is_enabled, + .recalc_rate = clk_alpha_pll_recalc_rate, + .determine_rate = clk_alpha_pll_stromer_plus_determine_rate, + .set_rate = clk_alpha_pll_stromer_plus_set_rate, +}; +EXPORT_SYMBOL_GPL (clk_alpha_pll_stromer_plus_ops);drivers/clk/qcom/clk-alpha-pll.h +1
-1@@ -152,6 +152,7 @@ extern const struct clk_ops clk_alpha_pll_postdiv_ops;extern const struct clk_ops clk_alpha_pll_huayra_ops;extern const struct clk_ops clk_alpha_pll_postdiv_ro_ops;extern const struct clk_ops clk_alpha_pll_stromer_ops; +extern const struct clk_ops clk_alpha_pll_stromer_plus_ops;extern const struct clk_ops clk_alpha_pll_fabia_ops;extern const struct clk_ops clk_alpha_pll_fixed_fabia_ops; --Quoted 2 lines
2.7.4
--
With best wishes
Dmitry
Re: [PATCH v1 01/10] clk: qcom: clk-alpha-pll: introduce stromer plus ops
In reply to Varadarajan NarayananQuoted 8 lines · Varadarajan Narayanan
Stromer plus APSS PLL does not support dynamic frequency scaling. To switch between frequencies, we have to shut down the PLL, configure the L and ALPHA values and turn on again. So introduce the separate set of ops for Stromer Plus PLL.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>---
[...]
drivers/clk/qcom/clk-alpha-pll.c const struct clk_ops clk_alpha_pll_stromer_ops = { · line 2528
Quoted 8 lines
drivers/clk/qcom/clk-alpha-pll.c +8
-0+ +/* Wait five micro seconds or more */ +udelay (5 ); +regmap_update_bits (pll->clkr.regmap,PLL_MODE (pll),PLL_RESET_N , +PLL_RESET_N ); + +/* The lock time should be less than 50 micro seconds worst case */ +udelay (50 );
https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
drivers/clk/qcom/clk-alpha-pll.c const struct clk_ops clk_alpha_pll_stromer_ops = { · line 2534
Quoted 6 lines
drivers/clk/qcom/clk-alpha-pll.c +6
-0+ + ret =wait_for_pll_enable_lock (pll); +if (ret) { +pr_err ("alpha pll running in 800 MHz with source GPLL0\n" ); +return ret; + }
Would that not be SoC-specific information?
Konrad
PATCH 2/10 clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll
In reply to Varadarajan NarayananThe set rate and determine rate operations are different between Stromer and Stromer Plus PLLs. Hence, use stromer plus ops for ipq_pll_stromer_plus.
--- drivers/clk/qcom/apss-ipq-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/apss-ipq-pll.c +1 -1
@@ -68,7 +68,7 @@ static struct clk_alpha_pll ipq_pll_stromer_plus = { .fw_name = "xo", }, .num_parents = 1, - .ops = &clk_alpha_pll_stromer_ops, + .ops = &clk_alpha_pll_stromer_plus_ops, }, }, };
Signature · 1 line
2.7.4
Re: [PATCH v1 02/10] clk: qcom: apss-ipq-pll: Use stromer plus ops for stromer plus pll
Quoted 7 lines · Varadarajan Narayanan
The set rate and determine rate operations are different between Stromer and Stromer Plus PLLs. Hence, use stromer plus ops for
ipq_pll_stromer_plus.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>
Fixes tag?
Quoted 20 lines
--- drivers/clk/qcom/apss-ipq-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)drivers/clk/qcom/apss-ipq-pll.c +1
-2@@ -68,7 +68,7 @@ static struct clk_alpha_pll ipq_pll_stromer_plus = { .fw_name = "xo", }, .num_parents = 1, - .ops = &clk_alpha_pll_stromer_ops, + .ops = &clk_alpha_pll_stromer_plus_ops, }, }, }; --2.7.4
Signature · 2 lines
With best wishes Dmitry
PATCH 3/10 clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config
In reply to Varadarajan NarayananThe earlier 'l' value of 0x3e is for 1.5GHz. Not all SKUs support this frequency. Hence set it to 0x2d to get 1.1GHz which is supported in all SKUs.
--- drivers/clk/qcom/apss-ipq-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/apss-ipq-pll.c +1 -1
@@ -74,7 +74,7 @@ static struct clk_alpha_pll ipq_pll_stromer_plus = { };static const struct alpha_pll_config ipq5332_pll_config = { - .l =0x3e , + .l =0x2d , .config_ctl_val =0x4001075b , .config_ctl_hi_val =0x304 , .main_output_mask =BIT (0 ),
Signature · 1 line
2.7.4
Re: [PATCH v1 03/10] clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config
Quoted 8 lines · Varadarajan Narayanan
The earlier 'l' value of
0x3eis for 1.5GHz. Not all SKUs support this frequency. Hence set it to0x2dto get 1.1GHz which is supported in all SKUs.Fixes c7ef7fbb1ccf ("clk: qcom: apss-ipq-pll: add support for IPQ5332")Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 03/10] clk: qcom: apss-ipq-pll: Fix 'l' value for ipq5332_pll_config
In reply to Varadarajan NarayananQuoted 8 lines · Varadarajan Narayanan
The earlier 'l' value of
0x3eis for 1.5GHz. Not all SKUs support this frequency. Hence set it to0x2dto get 1.1GHz which is supported in all SKUs.Fixes c7ef7fbb1ccf ("clk: qcom: apss-ipq-pll: add support for IPQ5332")Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>---
Konrad
PATCH 4/10 clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
In reply to Varadarajan NarayananStromer Plus PLL found on IPQ53xx doesn't support dynamic frequency scaling. To achieve the same, we need to park the APPS PLL source to GPLL0, re configure the PLL and then switch the source to APSS_PLL_EARLY.
To support this, register a clock notifier to get the PRE_RATE and POST_RATE notification. Change the APSS PLL source to GPLL0 when PRE_RATE notification is received, then configure the PLL and then change back the source to APSS_PLL_EARLY.
--- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)
drivers/clk/qcom/apss-ipq6018.c +53 -1
@@ -9,8 +9,11 @@#include <linux/clk-provider.h> #include <linux/regmap.h> #include <linux/module.h> +#include <linux/clk.h> +#include <linux/soc/qcom/smem.h> #include <dt-bindings/clock/qcom,apss-ipq.h> +#include <dt-bindings/arm/qcom,ids.h> #include "common.h" #include "clk-regmap.h"
@@ -84,15 +87,64 @@ static const struct qcom_cc_desc apss_ipq6018_desc = { .num_clks = ARRAY_SIZE(apss_ipq6018_clks), }; +static int cpu_clk_notifier_fn (struct notifier_block *nb,unsigned long action, +void *data) +{ +u8 index; +int err; + +if (action ==PRE_RATE_CHANGE ) + index =P_GPLL0 ; +else if (action ==POST_RATE_CHANGE ) + index =P_APSS_PLL_EARLY ; +else +return 0 ; + + err = clk_rcg2_mux_closest_ops.set_parent (&apcs_alias0_clk_src.clkr.hw, + index); + +return notifier_from_errno (err); +} + +static struct notifier_block cpu_clk_notifier = { + .notifier_call = cpu_clk_notifier_fn, +}; +static int apss_ipq6018_probe (struct platform_device *pdev) {struct regmap *regmap; +u32 soc_id; +int ret; + + ret =qcom_smem_get_soc_id (&soc_id); +if (ret) +return ret; regmap =dev_get_regmap (pdev->dev.parent,NULL );if (!regmap)return -ENODEV ; -return qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); + ret =qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); +if (ret) +return ret; + +switch (soc_id) { +/* +* Only below variants of IPQ53xx support scaling +*/ +case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5300 : + ret =clk_notifier_register (apcs_alias0_clk_src.clkr.hw.clk, + &cpu_clk_notifier); +if (ret) +return ret; +break ; +default : +break ; + } + +return 0 ; }static struct platform_driver apss_ipq6018_driver = {
Signature · 1 line
2.7.4
kernel test robot
build botRe: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
kernel test robot noticed the following build errors:
Hi Varadarajan,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.5 next-20230907]
[If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Varadarajan-Narayanan/clk-qcom-clk-alpha-pll-introduce-stromer-plus-ops/20230907-132537 base: linus/master patch link: https://lore.kernel.org/r/5e3c29df2b42cceb8072b00546a78e1b99b2d374.1693996662.git.quic_varada%40quicinc.com patch subject: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll config: s390-randconfig-r031-20230907 (https://download.01.org/0day-ci/archive/20230907/[email protected]/config) compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20230907/[email protected]/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
In file included from drivers/clk/qcom/apss-ipq6018.c:10:
In file included from include/linux/regmap.h:20:
In file included from include/linux/iopoll.h:14:
In file included from include/linux/io.h:13:
In file included from arch/s390/include/asm/io.h:78:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __raw_readb(PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu'
#define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
^
include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16'
#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
^
In file included from drivers/clk/qcom/apss-ipq6018.c:10:
In file included from include/linux/regmap.h:20:
In file included from include/linux/iopoll.h:14:
In file included from include/linux/io.h:13:
In file included from arch/s390/include/asm/io.h:78:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
~~~~~~~~~~ ^
include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu'
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
^
include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
^
In file included from drivers/clk/qcom/apss-ipq6018.c:10:
In file included from include/linux/regmap.h:20:
In file included from include/linux/iopoll.h:14:
In file included from include/linux/io.h:13:
In file included from arch/s390/include/asm/io.h:78:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writeb(value, PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
__raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
~~~~~~~~~~ ^
include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsb(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsw(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:708:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
readsl(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:717:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesb(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:726:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesw(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
include/asm-generic/io.h:735:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
writesl(PCI_IOBASE + addr, buffer, count);
~~~~~~~~~~ ^
>> drivers/clk/qcom/apss-ipq6018.c:94:11: error: use of undeclared identifier 'P_GPLL0'
index = P_GPLL0;
^12 warnings and 1 error generated.
vim +/P_GPLL0 +94 drivers/clk/qcom/apss-ipq6018.c
86
87 static int cpu_clk_notifier_fn(struct notifier_block *nb, unsigned long action,
88 void *data)
89 {
90 u8 index;
91 int err;
92
93 if (action == PRE_RATE_CHANGE)
> 94 index = P_GPLL0;
95 else if (action == POST_RATE_CHANGE)
96 index = P_APSS_PLL_EARLY;
97 else
98 return 0;
99 100 err = clk_rcg2_mux_closest_ops.set_parent(&apcs_alias0_clk_src.clkr.hw,
101 index);
102
103 return notifier_from_errno(err);
104 }
105
Signature · 2 lines
0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
In reply to Varadarajan NarayananQuoted 41 lines · Varadarajan Narayanan
Stromer Plus PLL found on IPQ53xx doesn't support dynamic frequency scaling. To achieve the same, we need to park the APPS PLL source to GPLL0, re configure the PLL and then switch the source to
APSS_PLL_EARLY.To support this, register a clock notifier to get the
PRE_RATEandPOST_RATEnotification. Change the APSS PLL source to GPLL0 whenPRE_RATEnotification is received, then configure the PLL and then change back the source toAPSS_PLL_EARLY.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)drivers/clk/qcom/apss-ipq6018.c +8
-0@@ -9,8 +9,11 @@#include <linux/clk-provider.h> #include <linux/regmap.h> #include <linux/module.h> +#include <linux/clk.h> +#include <linux/soc/qcom/smem.h> #include <dt-bindings/clock/qcom,apss-ipq.h> +#include <dt-bindings/arm/qcom,ids.h> #include "common.h" #include "clk-regmap.h" @@ -84,15 +87,64 @@ static const struct qcom_cc_desc apss_ipq6018_desc = { .num_clks = ARRAY_SIZE(apss_ipq6018_clks), }; +static int cpu_clk_notifier_fn (struct notifier_block *nb,unsigned long action, +void *data) +{ +u8 index; +int err;
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 104
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c +10
-0+ +if (action ==PRE_RATE_CHANGE ) + index =P_GPLL0 ; +else if (action ==POST_RATE_CHANGE ) + index =P_APSS_PLL_EARLY ; +else +return 0 ; + + err = clk_rcg2_mux_closest_ops.set_parent (&apcs_alias0_clk_src.clkr.hw, + index);
Adding a variable for clk_hw within the apcs_alias0 clock would make this easier to digest, I think.
And if we wanna be even less error-prone, you can reference the ops of this clock in an indirect way.
Quoted 21 lines
drivers/clk/qcom/apss-ipq6018.c +14
-0+ +return notifier_from_errno (err); +} + +static struct notifier_block cpu_clk_notifier = { + .notifier_call = cpu_clk_notifier_fn, +}; +static int apss_ipq6018_probe (struct platform_device *pdev) {struct regmap *regmap; +u32 soc_id; +int ret; + + ret =qcom_smem_get_soc_id (&soc_id); +if (ret) +return ret; regmap =dev_get_regmap (pdev->dev.parent,NULL );if (!regmap)return -ENODEV ;
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 134
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c +8
-1-return qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); + ret =qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); +if (ret) +return ret; + +switch (soc_id) { +/* +* Only below variants of IPQ53xx support scaling +*/
1. /* Keep this in a 1-line comment */
2. why? explain the reasoning in the commit message
Konrad
Quoted 16 lines
drivers/clk/qcom/apss-ipq6018.c +13
-0+case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5300 : + ret =clk_notifier_register (apcs_alias0_clk_src.clkr.hw.clk, + &cpu_clk_notifier); +if (ret) +return ret; +break ; +default : +break ; + } + +return 0 ; }static struct platform_driver apss_ipq6018_driver = {
Re: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
Quoted 55 lines · Konrad Dybcio
Quoted 41 lines · Varadarajan Narayanan
Stromer Plus PLL found on IPQ53xx doesn't support dynamic frequency scaling. To achieve the same, we need to park the APPS PLL source to GPLL0, re configure the PLL and then switch the source to
APSS_PLL_EARLY.To support this, register a clock notifier to get the
PRE_RATEandPOST_RATEnotification. Change the APSS PLL source to GPLL0 whenPRE_RATEnotification is received, then configure the PLL and then change back the source toAPSS_PLL_EARLY.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)drivers/clk/qcom/apss-ipq6018.c +8
-0@@ -9,8 +9,11 @@#include <linux/clk-provider.h> #include <linux/regmap.h> #include <linux/module.h> +#include <linux/clk.h> +#include <linux/soc/qcom/smem.h> #include <dt-bindings/clock/qcom,apss-ipq.h> +#include <dt-bindings/arm/qcom,ids.h> #include "common.h" #include "clk-regmap.h" @@ -84,15 +87,64 @@ static const struct qcom_cc_desc apss_ipq6018_desc = { .num_clks = ARRAY_SIZE(apss_ipq6018_clks), }; +static int cpu_clk_notifier_fn (struct notifier_block *nb,unsigned long action, +void *data) +{ +u8 index; +int err;drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 104
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c +10
-0+ +if (action ==PRE_RATE_CHANGE ) + index =P_GPLL0 ; +else if (action ==POST_RATE_CHANGE ) + index =P_APSS_PLL_EARLY ; +else +return 0 ; + + err = clk_rcg2_mux_closest_ops.set_parent (&apcs_alias0_clk_src.clkr.hw, + index);Adding a variable for
clk_hwwithin theapcs_alias0clock would make this easier to digest, I think.
Quoted 2 lines
And if we wanna be even less error-prone, you can reference the ops of this clock in an indirect way.
Will change it as
struct clk_hw *hw; hw = &apcs_alias0_clk_src.clkr.hw; err = hw->init->ops->set_parent(hw, index);
Quoted 21 lines
Quoted 21 lines
drivers/clk/qcom/apss-ipq6018.c +13
-0+return notifier_from_errno (err); +} + +static struct notifier_block cpu_clk_notifier = { + .notifier_call = cpu_clk_notifier_fn, +}; +static int apss_ipq6018_probe (struct platform_device *pdev) {struct regmap *regmap; +u32 soc_id; +int ret; + + ret =qcom_smem_get_soc_id (&soc_id); +if (ret) +return ret; regmap =dev_get_regmap (pdev->dev.parent,NULL );if (!regmap)return -ENODEV ;
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 134
Quoted 9 lines
drivers/clk/qcom/apss-ipq6018.c +8
-1-return qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); + ret =qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); +if (ret) +return ret; + +switch (soc_id) { +/* +* Only below variants of IPQ53xx support scaling +*/ 1. /* Keep this in a 1-line comment */
Ok
Quoted 1 line
2. why? explain the reasoning in the commit message
Ok
Thanks
Varada
Quoted 16 lines
Quoted 16 lines
drivers/clk/qcom/apss-ipq6018.c +13
-0+case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5300 : + ret =clk_notifier_register (apcs_alias0_clk_src.clkr.hw.clk, + &cpu_clk_notifier); +if (ret) +return ret; +break ; +default : +break ; + } + +return 0 ; }static struct platform_driver apss_ipq6018_driver = {
Re: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
Quoted 60 lines · Varadarajan Narayanan
Quoted 55 lines · Konrad Dybcio
Quoted 41 lines · Varadarajan Narayanan
Stromer Plus PLL found on IPQ53xx doesn't support dynamic frequency scaling. To achieve the same, we need to park the APPS PLL source to GPLL0, re configure the PLL and then switch the source to
APSS_PLL_EARLY.To support this, register a clock notifier to get the
PRE_RATEandPOST_RATEnotification. Change the APSS PLL source to GPLL0 whenPRE_RATEnotification is received, then configure the PLL and then change back the source toAPSS_PLL_EARLY.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)drivers/clk/qcom/apss-ipq6018.c +8
-0@@ -9,8 +9,11 @@#include <linux/clk-provider.h> #include <linux/regmap.h> #include <linux/module.h> +#include <linux/clk.h> +#include <linux/soc/qcom/smem.h> #include <dt-bindings/clock/qcom,apss-ipq.h> +#include <dt-bindings/arm/qcom,ids.h> #include "common.h" #include "clk-regmap.h" @@ -84,15 +87,64 @@ static const struct qcom_cc_desc apss_ipq6018_desc = { .num_clks = ARRAY_SIZE(apss_ipq6018_clks), }; +static int cpu_clk_notifier_fn (struct notifier_block *nb,unsigned long action, +void *data) +{ +u8 index; +int err;drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 104
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c +10
-0+ +if (action ==PRE_RATE_CHANGE ) + index =P_GPLL0 ; +else if (action ==POST_RATE_CHANGE ) + index =P_APSS_PLL_EARLY ; +else +return 0 ; + + err = clk_rcg2_mux_closest_ops.set_parent (&apcs_alias0_clk_src.clkr.hw, + index);Adding a variable for
clk_hwwithin theapcs_alias0clock would make this easier to digest, I think.Quoted 2 lines
And if we wanna be even less error-prone, you can reference the ops of this clock in an indirect way.
Quoted 6 lines
Will change it as
struct clk_hw *hw; hw = &apcs_alias0_clk_src.clkr.hw; err = hw->init->ops->set_parent(hw, index);
You can not do this, hw->init is cleared during registration.
Quoted 58 lines
Quoted 22 lines
Quoted 22 lines
drivers/clk/qcom/apss-ipq6018.c +13
-0+return notifier_from_errno (err); +} + +static struct notifier_block cpu_clk_notifier = { + .notifier_call = cpu_clk_notifier_fn, +}; +static int apss_ipq6018_probe (struct platform_device *pdev) {struct regmap *regmap; +u32 soc_id; +int ret; + + ret =qcom_smem_get_soc_id (&soc_id); +if (ret) +return ret; regmap =dev_get_regmap (pdev->dev.parent,NULL );if (!regmap)return -ENODEV ;Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 134
Quoted 9 lines
drivers/clk/qcom/apss-ipq6018.c +8
-1-return qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); + ret =qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); +if (ret) +return ret; + +switch (soc_id) { +/* +* Only below variants of IPQ53xx support scaling +*/ 1. /* Keep this in a 1-line comment */
Ok
Quoted 1 line
2. why? explain the reasoning in the commit message
Ok
Thanks
VaradaQuoted 16 lines
Quoted 16 lines
drivers/clk/qcom/apss-ipq6018.c +13
-0+case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5300 : + ret =clk_notifier_register (apcs_alias0_clk_src.clkr.hw.clk, + &cpu_clk_notifier); +if (ret) +return ret; +break ; +default : +break ; + } + +return 0 ; }static struct platform_driver apss_ipq6018_driver = {
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
In reply to Varadarajan NarayananQuoted 10 lines · Varadarajan Narayanan
Stromer Plus PLL found on IPQ53xx doesn't support dynamic frequency scaling. To achieve the same, we need to park the APPS PLL source to GPLL0, re configure the PLL and then switch the source to
APSS_PLL_EARLY.To support this, register a clock notifier to get the
PRE_RATEandPOST_RATEnotification. Change the APSS PLL source to GPLL0 whenPRE_RATEnotification is received, then configure the PLL and then change back the source toAPSS_PLL_EARLY.
This means that we are changing the parents behind the back of CCF, which is not great.
Quoted 25 lines
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)drivers/clk/qcom/apss-ipq6018.c +3
-0@@ -9,8 +9,11 @@#include <linux/clk-provider.h> #include <linux/regmap.h> #include <linux/module.h> +#include <linux/clk.h> +#include <linux/soc/qcom/smem.h> #include <dt-bindings/clock/qcom,apss-ipq.h> +#include <dt-bindings/arm/qcom,ids.h> #include "common.h" #include "clk-regmap.h" @@ -84,15 +87,64 @@ static const struct qcom_cc_desc apss_ipq6018_desc = { .num_clks = ARRAY_SIZE(apss_ipq6018_clks),
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 97
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c +8
-0}; +static int cpu_clk_notifier_fn (struct notifier_block *nb,unsigned long action, +void *data) +{ +u8 index; +int err; + +if (action ==PRE_RATE_CHANGE ) + index =P_GPLL0 ;
I don't see P_GPLL0 being supported in the ipq6018 driver.
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 99
Quoted 2 lines
drivers/clk/qcom/apss-ipq6018.c +2
-0+else if (action ==POST_RATE_CHANGE ) + index =P_APSS_PLL_EARLY ;
You also have to handle ABORT_RATE_CHANGE here.
Quoted 29 lines
drivers/clk/qcom/apss-ipq6018.c +20
-1+else +return 0 ; + + err = clk_rcg2_mux_closest_ops.set_parent (&apcs_alias0_clk_src.clkr.hw, + index); + +return notifier_from_errno (err); +} + +static struct notifier_block cpu_clk_notifier = { + .notifier_call = cpu_clk_notifier_fn, +}; +static int apss_ipq6018_probe (struct platform_device *pdev) {struct regmap *regmap; +u32 soc_id; +int ret; + + ret =qcom_smem_get_soc_id (&soc_id); +if (ret) +return ret; regmap =dev_get_regmap (pdev->dev.parent,NULL );if (!regmap)return -ENODEV ; -return qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); + ret =qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap);
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 137
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c +10
-0+if (ret) +return ret; + +switch (soc_id) { +/* +* Only below variants of IPQ53xx support scaling +*/ +case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5300 :
Please use compat strings instead of using the soc-id.
Quoted 14 lines
drivers/clk/qcom/apss-ipq6018.c +10
-1+ ret =clk_notifier_register (apcs_alias0_clk_src.clkr.hw.clk, + &cpu_clk_notifier); +if (ret) +return ret; +break ; +default : +break ; + } + +return 0 ; }static struct platform_driver apss_ipq6018_driver = { --
Quoted 2 lines
2.7.4
--
With best wishes
Dmitry
Re: [PATCH v1 04/10] clk: qcom: apss-ipq6018: ipq5332: add safe source switch for a53pll
Quoted 8 lines · Dmitry Baryshkov
Quoted 6 lines · Varadarajan Narayanan
Stromer Plus PLL found on IPQ53xx doesn't support dynamic frequency scaling. To achieve the same, we need to park the APPS PLL source to GPLL0, re configure the PLL and then switch the source to
APSS_PLL_EARLY.
Quoted 7 lines
Quoted 4 lines
To support this, register a clock notifier to get the
PRE_RATEandPOST_RATEnotification. Change the APSS PLL source to GPLL0 whenPRE_RATEnotification is received, then configure the PLL and then change back the source toAPSS_PLL_EARLY.This means that we are changing the parents behind the back of CCF, which is not great.
Unfortunately, we are not aware of any other way to do this. Please let me know if there is a better way to do this, will implement that and post a revision.
Quoted 26 lines
Quoted 26 lines
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/clk/qcom/apss-ipq6018.c | 54 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)drivers/clk/qcom/apss-ipq6018.c +3
-0@@ -9,8 +9,11 @@#include <linux/clk-provider.h> #include <linux/regmap.h> #include <linux/module.h> +#include <linux/clk.h> +#include <linux/soc/qcom/smem.h> #include <dt-bindings/clock/qcom,apss-ipq.h> +#include <dt-bindings/arm/qcom,ids.h> #include "common.h" #include "clk-regmap.h" @@ -84,15 +87,64 @@ static const struct qcom_cc_desc apss_ipq6018_desc = { .num_clks = ARRAY_SIZE(apss_ipq6018_clks), };
Quoted 10 lines
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 97
Quoted 8 lines
drivers/clk/qcom/apss-ipq6018.c +8
-0+static int cpu_clk_notifier_fn (struct notifier_block *nb,unsigned long action, +void *data) +{ +u8 index; +int err; + +if (action ==PRE_RATE_CHANGE ) + index =P_GPLL0 ;I don't see
P_GPLL0being supported in the ipq6018 driver.
This comes from one of the dependency patches mentioned in the
cover letter [https://lore.kernel.org/linux-arm-msm/[email protected]/].
Please refer to patch https://lore.kernel.org/linux-arm-msm/[email protected]/.
Quoted 5 lines
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 99
Quoted 3 lines
drivers/clk/qcom/apss-ipq6018.c +2
-0+else if (action ==POST_RATE_CHANGE ) + index =P_APSS_PLL_EARLY ;You also have to handle
ABORT_RATE_CHANGEhere.
ok.
Quoted 27 lines
Quoted 27 lines
drivers/clk/qcom/apss-ipq6018.c +19
-0+else +return 0 ; + + err = clk_rcg2_mux_closest_ops.set_parent (&apcs_alias0_clk_src.clkr.hw, + index); + +return notifier_from_errno (err); +} + +static struct notifier_block cpu_clk_notifier = { + .notifier_call = cpu_clk_notifier_fn, +}; +static int apss_ipq6018_probe (struct platform_device *pdev) {struct regmap *regmap; +u32 soc_id; +int ret; + + ret =qcom_smem_get_soc_id (&soc_id); +if (ret) +return ret; regmap =dev_get_regmap (pdev->dev.parent,NULL );if (!regmap)return -ENODEV ;
Quoted 14 lines
drivers/clk/qcom/apss-ipq6018.c static const struct qcom_cc_desc apss_ipq6018_desc = { · line 137
Quoted 12 lines
drivers/clk/qcom/apss-ipq6018.c +11
-1-return qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); + ret =qcom_cc_really_probe (pdev, &apss_ipq6018_desc, regmap); +if (ret) +return ret; + +switch (soc_id) { +/* +* Only below variants of IPQ53xx support scaling +*/ +case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5300 :Please use compat strings instead of using the soc-id.
We have a common compatible string for all IPQ53xx CPUs across boards. The CPU variant is identified from fuse settings. Not sure how we can differentiate between the variants using compat strings. Can you kindly help.
Thanks
varada
Quoted 22 lines
Quoted 14 lines
drivers/clk/qcom/apss-ipq6018.c +10
-1+ ret =clk_notifier_register (apcs_alias0_clk_src.clkr.hw.clk, + &cpu_clk_notifier); +if (ret) +return ret; +break ; +default : +break ; + } + +return 0 ; }static struct platform_driver apss_ipq6018_driver = { --Quoted 2 lines
2.7.4
--
With best wishesDmitry
PATCH 5/10 dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ5332
In reply to Varadarajan NarayananDocument IPQ5332 compatible for Qcom NVMEM CPUFreq driver.
--- Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml +1 -0
@@ -27,6 +27,7 @@ select: enum: - qcom,apq8064 - qcom,apq8096 + - qcom,ipq5332 - qcom,ipq8064 - qcom,ipq8074 - qcom,msm8939
Signature · 1 line
2.7.4
Re: [PATCH v1 05/10] dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ5332
Quoted 4 lines · Varadarajan Narayanan
Document IPQ5332 compatible for Qcom NVMEM CPUFreq driver.
Signed-off-by Varadarajan Narayanan <[email protected]>---
Best regards,
Krzysztof
Re: [PATCH v1 05/10] dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ5332
Quoted 7 lines · Krzysztof Kozlowski
Quoted 4 lines · Varadarajan Narayanan
Document IPQ5332 compatible for Qcom NVMEM CPUFreq driver.
Signed-off-by Varadarajan Narayanan <[email protected]>---
Applied. Thanks.
Signature · 1 line
viresh
PATCH 6/10 cpufreq: qti: Enable cpufreq for ipq53xx
In reply to Varadarajan NarayananIPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Added support for ipq53xx on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit.
nvmem driver also creates the "cpufreq-dt" platform_device after passing the version matching data to the OPP framework so that the cpufreq-dt handles the actual cpufreq implementation.
--- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 +++++++++++++++ 2 files changed, 16 insertions(+)
drivers/cpufreq/cpufreq-dt-platdev.c +1 -0
@@ -178,6 +178,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "ti,am625", }, { .compatible = "ti,am62a7", }, + { .compatible = "qcom,ipq5332", }, { .compatible = "qcom,ipq8064", }, { .compatible = "qcom,apq8064", }, { .compatible = "qcom,msm8974", },
drivers/cpufreq/qcom-cpufreq-nvmem.c +15 -0
@@ -146,6 +146,20 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,return PTR_ERR (speedbin);switch (msm_id) { +case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5312 : +case QCOM_ID_IPQ5302 : +case QCOM_ID_IPQ5300 : +/* Fuse Value Freq BIT to set +* --------------------------------- +* 2’b00 No Limit BIT(0) +* 2’b01 1.5 GHz BIT(1) +* 2’b10 1.2 Ghz BIT(2) +* 2’b11 1.0 GHz BIT(3) +*/ + drv->versions =1 << (unsigned int )(*speedbin); +break ;case QCOM_ID_MSM8996 :case QCOM_ID_APQ8096 : drv->versions =1 << (unsigned int )(*speedbin);
@@ -359,6 +373,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { { .compatible = "qcom,apq8096", .data = &match_data_kryo }, { .compatible = "qcom,msm8996", .data = &match_data_kryo }, { .compatible = "qcom,qcs404", .data = &match_data_qcs404 }, + { .compatible = "qcom,ipq5332", .data = &match_data_kryo }, { .compatible = "qcom,ipq8064", .data = &match_data_krait }, { .compatible = "qcom,apq8064", .data = &match_data_krait }, { .compatible = "qcom,msm8974", .data = &match_data_krait },
Signature · 1 line
2.7.4
Re: [PATCH v1 06/10] cpufreq: qti: Enable cpufreq for ipq53xx
Quoted 38 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Added support for ipq53xx on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit.
nvmem driver also creates the "cpufreq-dt"
platform_deviceafter passing the version matching data to the OPP framework so that the cpufreq-dt handles the actual cpufreq implementation.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 +++++++++++++++ 2 files changed, 16 insertions(+)drivers/cpufreq/cpufreq-dt-platdev.c +1
-0@@ -178,6 +178,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "ti,am625", }, { .compatible = "ti,am62a7", }, + { .compatible = "qcom,ipq5332", }, { .compatible = "qcom,ipq8064", }, { .compatible = "qcom,apq8064", }, { .compatible = "qcom,msm8974", },drivers/cpufreq/qcom-cpufreq-nvmem.c +0
-0
drivers/cpufreq/qcom-cpufreq-nvmem.c static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev, · line 153
Quoted 8 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +5
-0@@ -146,6 +146,20 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,return PTR_ERR (speedbin);switch (msm_id) { +case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5312 : +case QCOM_ID_IPQ5302 : +case QCOM_ID_IPQ5300 :
msm8996 was bad enough. Can we use compat strings instead? Or make this a default for qcom_cpufreq_kryo_name_version()?
Quoted 23 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +10
-1+/* Fuse Value Freq BIT to set +* --------------------------------- +* 2’b00 No Limit BIT(0) +* 2’b01 1.5 GHz BIT(1) +* 2’b10 1.2 Ghz BIT(2) +* 2’b11 1.0 GHz BIT(3) +*/ + drv->versions =1 << (unsigned int )(*speedbin); +break ;case QCOM_ID_MSM8996 :case QCOM_ID_APQ8096 : drv->versions =1 << (unsigned int )(*speedbin);@@ -359,6 +373,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { { .compatible = "qcom,apq8096", .data = &match_data_kryo }, { .compatible = "qcom,msm8996", .data = &match_data_kryo }, { .compatible = "qcom,qcs404", .data = &match_data_qcs404 }, + { .compatible = "qcom,ipq5332", .data = &match_data_kryo }, { .compatible = "qcom,ipq8064", .data = &match_data_krait }, { .compatible = "qcom,apq8064", .data = &match_data_krait }, { .compatible = "qcom,msm8974", .data = &match_data_krait }, --2.7.4
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 06/10] cpufreq: qti: Enable cpufreq for ipq53xx
In reply to Varadarajan NarayananQuoted 44 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Added support for ipq53xx on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit.
nvmem driver also creates the "cpufreq-dt"
platform_deviceafter passing the version matching data to the OPP framework so that the cpufreq-dt handles the actual cpufreq implementation.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 +++++++++++++++ 2 files changed, 16 insertions(+)drivers/cpufreq/cpufreq-dt-platdev.c +1
-0@@ -178,6 +178,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "ti,am625", }, { .compatible = "ti,am62a7", }, + { .compatible = "qcom,ipq5332", }, { .compatible = "qcom,ipq8064", }, { .compatible = "qcom,apq8064", }, { .compatible = "qcom,msm8974", },drivers/cpufreq/qcom-cpufreq-nvmem.c +4
-0@@ -146,6 +146,20 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,return PTR_ERR (speedbin);switch (msm_id) { +case QCOM_ID_IPQ5332 : +case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5312 : +case QCOM_ID_IPQ5302 :
drivers/cpufreq/qcom-cpufreq-nvmem.c static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev, · line 162
Quoted 10 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +10
-0+case QCOM_ID_IPQ5300 : +/* Fuse Value Freq BIT to set +* --------------------------------- +* 2’b00 No Limit BIT(0) +* 2’b01 1.5 GHz BIT(1) +* 2’b10 1.2 Ghz BIT(2) +* 2’b11 1.0 GHz BIT(3) +*/ + drv->versions =1 << (unsigned int )(*speedbin); +break ;
I like that you've included a comment however, the switch is an ordered list and these values should come after QCOM_ID_APQ8096SG
#define QCOM_ID_MSM8996 246 #define QCOM_ID_APQ8096 291 #define QCOM_ID_MSM8996SG 305 #define QCOM_ID_APQ8096SG 312 #define QCOM_ID_IPQ5332 592
...
#define QCOM_ID_IPQ5300 624
drivers/cpufreq/qcom-cpufreq-nvmem.c static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { · line 379
Quoted 13 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +1
-0case QCOM_ID_MSM8996 :case QCOM_ID_APQ8096 : drv->versions =1 << (unsigned int )(*speedbin);@@ -359,6 +373,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { { .compatible = "qcom,apq8096", .data = &match_data_kryo }, { .compatible = "qcom,msm8996", .data = &match_data_kryo }, { .compatible = "qcom,qcs404", .data = &match_data_qcs404 }, + { .compatible = "qcom,ipq5332", .data = &match_data_kryo }, { .compatible = "qcom,ipq8064", .data = &match_data_krait }, { .compatible = "qcom,apq8064", .data = &match_data_krait }, { .compatible = "qcom,msm8974", .data = &match_data_krait },
Other than that.
---
bod
Re: [PATCH v1 06/10] cpufreq: qti: Enable cpufreq for ipq53xx
In reply to Varadarajan Narayanandrivers/cpufreq/cpufreq-dt-platdev.c
Quoted 24 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Added support for ipq53xx on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit.
nvmem driver also creates the "cpufreq-dt"
platform_deviceafter passing the version matching data to the OPP framework so that the cpufreq-dt handles the actual cpufreq implementation.Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 15 +++++++++++++++ 2 files changed, 16 insertions(+)drivers/cpufreq/cpufreq-dt-platdev.c +0
-0
Viresh probably picks up patches for both files, so it should be fine, but I'd say it's 'eeeh' to edit 2 separate drivers at once.
Quoted 17 lines
drivers/cpufreq/cpufreq-dt-platdev.c +1
-0@@ -178,6 +178,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "ti,am625", }, { .compatible = "ti,am62a7", }, + { .compatible = "qcom,ipq5332", }, { .compatible = "qcom,ipq8064", }, { .compatible = "qcom,apq8064", }, { .compatible = "qcom,msm8974", },drivers/cpufreq/qcom-cpufreq-nvmem.c +1
-0@@ -146,6 +146,20 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,return PTR_ERR (speedbin);switch (msm_id) { +case QCOM_ID_IPQ5332 :
drivers/cpufreq/qcom-cpufreq-nvmem.c static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev, · line 159
Quoted 10 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +10
-0+case QCOM_ID_IPQ5322 : +case QCOM_ID_IPQ5312 : +case QCOM_ID_IPQ5302 : +case QCOM_ID_IPQ5300 : +/* Fuse Value Freq BIT to set +* --------------------------------- +* 2’b00 No Limit BIT(0) +* 2’b01 1.5 GHz BIT(1) +* 2’b10 1.2 Ghz BIT(2) +* 2’b11 1.0 GHz BIT(3)
I think the last column is a bit excessive, it says exactly the same as the line below.
Actually, with this data being present in the devicetree, perhaps this comment could be entirely skipped.
Konrad
Quoted 14 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +4
-0+*/ + drv->versions =1 << (unsigned int )(*speedbin); +break ;case QCOM_ID_MSM8996 :case QCOM_ID_APQ8096 : drv->versions =1 << (unsigned int )(*speedbin);@@ -359,6 +373,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { { .compatible = "qcom,apq8096", .data = &match_data_kryo }, { .compatible = "qcom,msm8996", .data = &match_data_kryo }, { .compatible = "qcom,qcs404", .data = &match_data_qcs404 }, + { .compatible = "qcom,ipq5332", .data = &match_data_kryo }, { .compatible = "qcom,ipq8064", .data = &match_data_krait }, { .compatible = "qcom,apq8064", .data = &match_data_krait }, { .compatible = "qcom,msm8974", .data = &match_data_krait },
PATCH 7/10 arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
In reply to Varadarajan NarayananIPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/qcom/ipq5332.dtsi +31 -3
@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* + * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hw + * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */ + + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>; + opp-microvolt = <950000>; + opp-supported-hw = <0x3>; clock-latency-ns = <200000>; }; };
@@ -150,6 +173,11 @@ reg = <0x000a4000 0x721>; #address-cells = <1>; #size-cells = <1>; + + cpu_speed_bin: cpu_speed_bin@1d { + reg = <0x1d 0x2>; + bits = <7 2>; + }; }; rng: rng@e3000 {
Signature · 1 line
2.7.4
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
Quoted 28 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)arch/arm64/boot/dts/qcom/ipq5332.dtsi +5
-1@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /*
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 109
Quoted 10 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +10
-0+ * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hw + * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */
This can probably go to the commit message instead.
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 112
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +3
-0+ + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>;
But your table shows 1.0 GHz and 1.2 GHz instead of 1.1 GHz
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 119
Quoted 9 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-2+ opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>;
So, 1.488 GHz or 1.5 GHz?
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 120
Quoted 1 line
arch/arm64/boot/dts/qcom/ipq5332.dtsi +1
-0+ opp-microvolt = <950000>;
Which regulator is controlled by this microvolt?
Quoted 19 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-1+ opp-supported-hw = <0x3>; clock-latency-ns = <200000>; }; };@@ -150,6 +173,11 @@ reg = <0x000a4000 0x721>; #address-cells = <1>; #size-cells = <1>; + + cpu_speed_bin: cpu_speed_bin@1d { + reg = <0x1d 0x2>; + bits = <7 2>; + }; }; rng: rng@e3000 { --2.7.4
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
Quoted 34 lines · Dmitry Baryshkov
Quoted 32 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)arch/arm64/boot/dts/qcom/ipq5332.dtsi +9
-1@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* + * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hw
Quoted 8 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 109
Quoted 6 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-0+ * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */This can probably go to the commit message instead.
Ok
Quoted 5 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 112
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +3
-0+ + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>;But your table shows 1.0 GHz and 1.2 GHz instead of 1.1 GHz
Will update it.
Quoted 11 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 119
Quoted 9 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-2+ opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>;So, 1.488 GHz or 1.5 GHz?
1.5 GHz
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 120
Quoted 1 line
arch/arm64/boot/dts/qcom/ipq5332.dtsi +1
-0+ opp-microvolt = <950000>;Which regulator is controlled by this microvolt?
Based on the SKU, the XBL sets up the regulator to provide 950000uV on CPUs capable of running 1.5G and 850000uV on other SKUs. Linux doesn't control it.
Thanks
Varada
Quoted 24 lines
Quoted 17 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-1+ opp-supported-hw = <0x3>; clock-latency-ns = <200000>; }; };@@ -150,6 +173,11 @@ reg = <0x000a4000 0x721>; #address-cells = <1>; #size-cells = <1>; + + cpu_speed_bin: cpu_speed_bin@1d { + reg = <0x1d 0x2>; + bits = <7 2>; + }; }; rng: rng@e3000 { --Quoted 2 lines
2.7.4
--
With best wishes
Dmitry
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
Quoted 69 lines · Varadarajan Narayanan
Quoted 34 lines · Dmitry Baryshkov
Quoted 32 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)arch/arm64/boot/dts/qcom/ipq5332.dtsi +9
-1@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* + * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hwQuoted 8 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 109
Quoted 6 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-0+ * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */This can probably go to the commit message instead.
Ok
Quoted 5 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 112
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +3
-0+ + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>;But your table shows 1.0 GHz and 1.2 GHz instead of 1.1 GHz
Will update it.
Quoted 11 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 119
Quoted 9 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-2+ opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>;So, 1.488 GHz or 1.5 GHz?
1.5 GHz
Quoted 7 lines
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 120
Quoted 1 line
arch/arm64/boot/dts/qcom/ipq5332.dtsi +1
-0+ opp-microvolt = <950000>;Which regulator is controlled by this microvolt?
Based on the SKU, the XBL sets up the regulator to provide 950000uV on CPUs capable of running 1.5G and 850000uV on other SKUs. Linux doesn't control it.
Then why do you need this property here in the first place?
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
Quoted 73 lines · Dmitry Baryshkov
Quoted 71 lines · Varadarajan Narayanan
Quoted 34 lines · Dmitry Baryshkov
Quoted 32 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)arch/arm64/boot/dts/qcom/ipq5332.dtsi +9
-1@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* + * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hwQuoted 8 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 109
Quoted 6 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-0+ * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */This can probably go to the commit message instead.
Ok
Quoted 5 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 112
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +3
-0+ + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>;But your table shows 1.0 GHz and 1.2 GHz instead of 1.1 GHz
Will update it.
Quoted 11 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 119
Quoted 9 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-2+ opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>;So, 1.488 GHz or 1.5 GHz?
1.5 GHz
Quoted 2 lines
Quoted 1 line
arch/arm64/boot/dts/qcom/ipq5332.dtsi +1
-0+ opp-microvolt = <950000>;
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Which regulator is controlled by this microvolt?
Based on the SKU, the XBL sets up the regulator to provide 950000uV on CPUs capable of running 1.5G and 850000uV on other SKUs. Linux doesn't control it.
Then why do you need this property here in the first place?
I get these errors without this property
[ 1.018065] cpu cpu0: opp_parse_microvolt: opp-microvolt missing although OPP managing regulators [ 1.018074] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
Thanks
Varada
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
Quoted 81 lines · Varadarajan Narayanan
Quoted 79 lines · Dmitry Baryshkov
Quoted 76 lines · Varadarajan Narayanan
Quoted 34 lines · Dmitry Baryshkov
Quoted 32 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)arch/arm64/boot/dts/qcom/ipq5332.dtsi +9
-1@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* + * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hwQuoted 8 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 109
Quoted 6 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-0+ * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */This can probably go to the commit message instead.
Ok
Quoted 5 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 112
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +3
-0+ + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>;But your table shows 1.0 GHz and 1.2 GHz instead of 1.1 GHz
Will update it.
Quoted 11 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 119
Quoted 9 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-2+ opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>;So, 1.488 GHz or 1.5 GHz?
1.5 GHz
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 120
Quoted 1 line
arch/arm64/boot/dts/qcom/ipq5332.dtsi +1
-0+ opp-microvolt = <950000>;Which regulator is controlled by this microvolt?
Based on the SKU, the XBL sets up the regulator to provide 950000uV on CPUs capable of running 1.5G and 850000uV on other SKUs. Linux doesn't control it.
Quoted 5 lines
Quoted 1 line
Then why do you need this property here in the first place?
I get these errors without this property
[ 1.018065] cpu cpu0: opp_parse_microvolt: opp-microvolt missing although OPP managing regulators
But you have said that "Linux doesn't control it" [the regulator]!
Quoted 1 line
[ 1.018074] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
Signature · 2 lines
With best wishes Dmitry
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
Quoted 83 lines · Dmitry Baryshkov
Quoted 81 lines · Varadarajan Narayanan
Quoted 79 lines · Dmitry Baryshkov
Quoted 76 lines · Varadarajan Narayanan
Quoted 34 lines · Dmitry Baryshkov
Quoted 32 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- arch/arm64/boot/dts/qcom/ipq5332.dtsi | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)arch/arm64/boot/dts/qcom/ipq5332.dtsi +9
-1@@ -91,11 +91,34 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* + * Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hwQuoted 8 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 109
Quoted 6 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-0+ * 1.0GHz 1.2GHz 1.5GHz No Limit + * ------------------------------------------------------------ + * 1100000000 1 1 1 1 0xF + * 1500000000 0 0 1 1 0x3 + * ----------------------------------------------------------- + */This can probably go to the commit message instead.
Ok
Quoted 5 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 112
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +3
-0+ + opp-1100000000 { + opp-hz = /bits/ 64 <1100000000>;But your table shows 1.0 GHz and 1.2 GHz instead of 1.1 GHz
Will update it.
Quoted 11 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 119
Quoted 9 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +6
-2+ opp-microvolt = <850000>; + opp-supported-hw = <0xF>; + clock-latency-ns = <200000>; + }; - opp-1488000000 { - opp-hz = /bits/ 64 <1488000000>; + opp-1500000000 { + opp-hz = /bits/ 64 <1500000000>;So, 1.488 GHz or 1.5 GHz?
1.5 GHz
Quoted 3 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 120
Quoted 1 line
arch/arm64/boot/dts/qcom/ipq5332.dtsi +1
-0+ opp-microvolt = <950000>;Which regulator is controlled by this microvolt?
Based on the SKU, the XBL sets up the regulator to provide 950000uV on CPUs capable of running 1.5G and 850000uV on other SKUs. Linux doesn't control it.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Then why do you need this property here in the first place?
I get these errors without this property
[ 1.018065] cpu cpu0: opp_parse_microvolt: opp-microvolt missing although OPP managing regulatorsBut you have said that "Linux doesn't control it" [the regulator]!
Got confused between the ipq9574 and ipq5332 patches.
Have removed and addressed other comments too and
posted v2 - https://lore.kernel.org/linux-arm-msm/[email protected]/
Please take a look.
Thanks
Varada
Quoted 2 lines
Quoted 2 lines
[ 1.018074] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
Re: [PATCH v1 07/10] arm64: dts: qcom: ipq5332: populate the opp table based on the eFuse
In reply to Varadarajan NarayananQuoted 11 lines · Varadarajan Narayanan
IPQ53xx have different OPPs available for the CPU based on SoC variant. This can be determined through use of an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Signed-off-by Kathiravan T <[email protected]>arch/arm64/boot/dts/qcom/ipq5332.dtsi +0
-0};
arch/arm64/boot/dts/qcom/ipq5332.dtsi line 177
Quoted 5 lines
arch/arm64/boot/dts/qcom/ipq5332.dtsi +2
-0@@ -150,6 +173,11 @@ reg = <0x000a4000 0x721>; #address-cells = <1>; #size-cells = <1>; + + cpu_speed_bin: cpu_speed_bin@1d {
No underscores in node names. I am pretty sure I repeated it multiple times already...
Best regards,
Krzysztof
PATCH 8/10 dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ9574
In reply to Varadarajan NarayananDocument IPQ9574 compatible for Qcom NVMEM CPUFreq driver.
--- Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml +1 -0
@@ -30,6 +30,7 @@ select: - qcom,ipq5332 - qcom,ipq8064 - qcom,ipq8074 + - qcom,ipq9574 - qcom,msm8939 - qcom,msm8960 - qcom,msm8974
Signature · 1 line
2.7.4
Re: [PATCH v1 08/10] dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ9574
Quoted 6 lines · Varadarajan Narayanan
Document IPQ9574 compatible for Qcom NVMEM CPUFreq driver.
Signed-off-by Varadarajan Narayanan <[email protected]>--- Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 1 + 1 file changed, 1 insertion(+)
Best regards,
Krzysztof
Re: [PATCH v1 08/10] dt-bindings: cpufreq: qcom-cpufreq-nvmem: document IPQ9574
Quoted 10 lines · Krzysztof Kozlowski
Quoted 6 lines · Varadarajan Narayanan
Document IPQ9574 compatible for Qcom NVMEM CPUFreq driver.
Signed-off-by Varadarajan Narayanan <[email protected]>--- Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 1 + 1 file changed, 1 insertion(+)
Applied. Thanks.
Signature · 1 line
viresh
PATCH 9/10 cpufreq: qti: Introduce cpufreq for ipq95xx
In reply to Varadarajan NarayananIPQ95xx SoCs have different OPPs available for the CPU based on the SoC variant. This can be determined from an eFuse register present in the silicon.
Added support for ipq95xx on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit.
--- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)
drivers/cpufreq/cpufreq-dt-platdev.c +1 -0
@@ -180,6 +180,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "qcom,ipq5332", }, { .compatible = "qcom,ipq8064", }, + { .compatible = "qcom,ipq9574", }, { .compatible = "qcom,apq8064", }, { .compatible = "qcom,msm8974", }, { .compatible = "qcom,msm8960", },
drivers/cpufreq/qcom-cpufreq-nvmem.c +20 -0
@@ -168,6 +168,25 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,case QCOM_ID_APQ8096SG : drv->versions =1 << ((unsigned int )(*speedbin) +4 );break ; +case QCOM_ID_IPQ9514 : +case QCOM_ID_IPQ9550 : +case QCOM_ID_IPQ9554 : +case QCOM_ID_IPQ9570 : +case QCOM_ID_IPQ9574 : +/* Fuse Value Freq BIT to set +* --------------------------------- +* 2’b00 No Limit BIT(0) +* 2’b10 1.8 GHz BIT(1) +* 2’b01 1.5 Ghz BIT(2) +* 2’b11 1.2 GHz BIT(3) +*/ +if ((unsigned int )(*speedbin) ==2 ) + drv->versions =BIT (1 ); +else if ((unsigned int )(*speedbin) ==1 ) + drv->versions =BIT (2 ); +else + drv->versions =1 << (unsigned int )(*speedbin); +break ;default :BUG ();break ;
@@ -375,6 +394,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { { .compatible = "qcom,qcs404", .data = &match_data_qcs404 }, { .compatible = "qcom,ipq5332", .data = &match_data_kryo }, { .compatible = "qcom,ipq8064", .data = &match_data_krait }, + { .compatible = "qcom,ipq9574", .data = &match_data_kryo }, { .compatible = "qcom,apq8064", .data = &match_data_krait }, { .compatible = "qcom,msm8974", .data = &match_data_krait }, { .compatible = "qcom,msm8960", .data = &match_data_krait },
Signature · 1 line
2.7.4
Re: [PATCH v1 09/10] cpufreq: qti: Introduce cpufreq for ipq95xx
Quoted 46 lines · Varadarajan Narayanan
IPQ95xx SoCs have different OPPs available for the CPU based on the SoC variant. This can be determined from an eFuse register present in the silicon.
Added support for ipq95xx on nvmem driver which helps to determine OPPs at runtime based on the eFuse register which has the CPU frequency limits. opp-supported-hw dt binding can be used to indicate the available OPPs for each limit.
Signed-off-by Praveenkumar I <[email protected]>Signed-off-by Kathiravan T <[email protected]>Signed-off-by Varadarajan Narayanan <[email protected]>--- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)drivers/cpufreq/cpufreq-dt-platdev.c +1
-0@@ -180,6 +180,7 @@ static const struct of_device_id blocklist[] __initconst = { { .compatible = "qcom,ipq5332", }, { .compatible = "qcom,ipq8064", }, + { .compatible = "qcom,ipq9574", }, { .compatible = "qcom,apq8064", }, { .compatible = "qcom,msm8974", }, { .compatible = "qcom,msm8960", },drivers/cpufreq/qcom-cpufreq-nvmem.c +8
-0@@ -168,6 +168,25 @@ static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev,case QCOM_ID_APQ8096SG : drv->versions =1 << ((unsigned int )(*speedbin) +4 );break ; +case QCOM_ID_IPQ9514 : +case QCOM_ID_IPQ9550 : +case QCOM_ID_IPQ9554 : +case QCOM_ID_IPQ9570 : +case QCOM_ID_IPQ9574 : +/* Fuse Value Freq BIT to set +* --------------------------------- +* 2’b00 No Limit BIT(0)
drivers/cpufreq/qcom-cpufreq-nvmem.c static int qcom_cpufreq_kryo_name_version(struct device *cpu_dev, · line 188
Quoted 10 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +10
-0+* 2’b10 1.8 GHz BIT(1) +* 2’b01 1.5 Ghz BIT(2) +* 2’b11 1.2 GHz BIT(3) +*/ +if ((unsigned int )(*speedbin) ==2 ) + drv->versions =BIT (1 ); +else if ((unsigned int )(*speedbin) ==1 ) + drv->versions =BIT (2 ); +else + drv->versions =1 << (unsigned int )(*speedbin);
If you change the order of speedbins 1 and 2 in DT, you can use 1 << speedbin for all the kinds,
Quoted 15 lines
drivers/cpufreq/qcom-cpufreq-nvmem.c +2
-1+break ;default :BUG ();break ;@@ -375,6 +394,7 @@ static const struct of_device_id qcom_cpufreq_match_list[] __initconst = { { .compatible = "qcom,qcs404", .data = &match_data_qcs404 }, { .compatible = "qcom,ipq5332", .data = &match_data_kryo }, { .compatible = "qcom,ipq8064", .data = &match_data_krait }, + { .compatible = "qcom,ipq9574", .data = &match_data_kryo }, { .compatible = "qcom,apq8064", .data = &match_data_krait }, { .compatible = "qcom,msm8974", .data = &match_data_krait }, { .compatible = "qcom,msm8960", .data = &match_data_krait }, --2.7.4
Signature · 2 lines
With best wishes Dmitry
PATCH 10/10 arm64: dts: qcom: ipq9574: populate the opp table based on the eFuse
In reply to Varadarajan NarayananIPQ95xx SoCs have different OPPs available for the CPU based on SoC variant. This can be determined from an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
--- arch/arm64/boot/dts/qcom/ipq9574.dtsi | 38 ++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-)
arch/arm64/boot/dts/qcom/ipq9574.dtsi +37 -1
@@ -106,42 +106,73 @@ }; cpu_opp_table: opp-table-cpu { - compatible = "operating-points-v2"; + compatible = "operating-points-v2-kryo-cpu"; opp-shared; + nvmem-cells = <&cpu_speed_bin>; + nvmem-cell-names = "speed_bin"; + + /* Listed all supported CPU frequencies and opp-supported-hw + * values to select CPU frequencies based on the limits fused. + * ------------------------------------------------------------ + * Frequency BIT3 BIT2 BIT1 BIT0 opp-supported-hw + * 1.2GHz 1.5GHz 1.8GHz No Limit + * ------------------------------------------------------------ + * 936000000 1 1 1 1 0xF + * 1104000000 1 1 1 1 0xF + * 1200000000 1 0 0 0 0x8 + * 1416000000 0 1 1 1 0x7 + * 1488000000 0 1 0 0 0x4 + * 1800000000 0 0 1 1 0x3 + * 2208000000 0 0 0 1 0x1 + * ----------------------------------------------------------- + */ opp-936000000 { opp-hz = /bits/ 64 <936000000>; opp-microvolt = <725000>; + opp-supported-hw = <0xf>; clock-latency-ns = <200000>; }; opp-1104000000 { opp-hz = /bits/ 64 <1104000000>; opp-microvolt = <787500>; + opp-supported-hw = <0xf>; + clock-latency-ns = <200000>; + }; + + opp-1200000000 { + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt = <862500>; + opp-supported-hw = <0x8>; clock-latency-ns = <200000>; }; opp-1416000000 { opp-hz = /bits/ 64 <1416000000>; opp-microvolt = <862500>; + opp-supported-hw = <0x7>; clock-latency-ns = <200000>; }; opp-1488000000 { opp-hz = /bits/ 64 <1488000000>; opp-microvolt = <925000>; + opp-supported-hw = <0x7>; clock-latency-ns = <200000>; }; opp-1800000000 { opp-hz = /bits/ 64 <1800000000>; opp-microvolt = <987500>; + opp-supported-hw = <0x3>; clock-latency-ns = <200000>; }; opp-2208000000 { opp-hz = /bits/ 64 <2208000000>; opp-microvolt = <1062500>; + opp-supported-hw = <0x1>; clock-latency-ns = <200000>; }; };
@@ -223,6 +254,11 @@ reg = <0x000a4000 0x5a1>; #address-cells = <1>; #size-cells = <1>; + + cpu_speed_bin: cpu_speed_bin@15 { + reg = <0x15 0x2>; + bits = <7 2>; + }; }; cryptobam: dma-controller@704000 {
Signature · 1 line
2.7.4
Re: [PATCH v1 10/10] arm64: dts: qcom: ipq9574: populate the opp table based on the eFuse
Quoted 6 lines · Varadarajan Narayanan
IPQ95xx SoCs have different OPPs available for the CPU based on SoC variant. This can be determined from an eFuse register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
...
arch/arm64/boot/dts/qcom/ipq9574.dtsi line 258
Quoted 7 lines
arch/arm64/boot/dts/qcom/ipq9574.dtsi +2
-0};@@ -223,6 +254,11 @@ reg = <0x000a4000 0x5a1>; #address-cells = <1>; #size-cells = <1>; + + cpu_speed_bin: cpu_speed_bin@15 {
No underscores in node names
Best regards,
Krzysztof