cpufreq: use generic cpufreq drivers for Exynos4210 platform
Subsystems (7)
cover cpufreq: use generic cpufreq drivers for Exynos4210 platform
In reply to a message not in the archiveHi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
It consists of a modified "[PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms" [1] patch series from Thomas Abraham. As there have not been updates of this patchset since November 2014 I decided to dust it off myself. I updated Thomas' patchset to current kernels, fixed bugs that I noticed and removed non-Exynos4210 support for now (to speed up inclusion in upstream kernel). Since some modifications were not trivial I dropped all Reviewed-by:, Tested-by: and Acked-by: tags. Please review/test this patchset and reply with revelant tag (Thank You!). I also plan to work on Exynos4x12 support next (which was missing in the original patchset) and then on Exynos5250/Exynos5420 one.
This patch series has been tested on Exynos4210 based Origen and Trats boards.
Depends on:
- next-20150330 branch of linux-next kernel tree
(mfd tree contains a crucial fix for MAX8997 PMIC support)
- "[PATCH] clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC" [2]
[1] https://www.marc.info/?l=linux-arm-kernel&m=141657611003803&w=2
[2] https://lkml.org/lkml/2015/3/27/568
Changes over Thomas' code:
- fixed issue with wrong dividers being setup by Common Clock Framework (by an addition of CLK_RECALC_NEW_RATES clock flag to mout_apll clock, without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board), this was probably meant to be workarounded by use of CLK_GET_RATE_NOCACHE and CLK_DIVIDER_READ_ONLY clock flags in the original patchset (in "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags") but using these flags is not sufficient to fix the issue observed
- fixed issue with setting lower dividers before the parent clock speed was lowered (the issue resulted in lockup on Exynos4210 SoC based Origen board when "ondemand" cpufreq governor was stress tested)
- fixed missing spin_unlock on error in exynos_cpuclk_post_rate_change() problem by moving cfg_data search outside of the spin locked area
- removed leftover kfree() in exynos_register_cpu_clock() that could result in dereferencing the NULL pointer on error
- moved spin_lock earlier in exynos_cpuclk_pre_rate_change() to cover reading of E4210_SRC_CPU and E4210_DIV_CPU1 registers
- added missing "last chance" checks to wait_until_divider_stable() and wait_until_mux_stable() (needed in case that IRQ handling took long time to proceed and resulted in function printing incorrect error message about timeout)
- moved E4210_CPU_DIV[0,1]() macros just before their only users, this resulted in moving them from patch #2 to patch #3/6 ("clk:
samsung: exynos4: add cpu clock configuration data and instantiate cpu clock")
- added my Copyrights to drivers/clk/samsung/clk-cpu.c
- updated exynos-cpufreq.[c,h]
- removed non-Exynos4210 support for now
- dropped "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags" altogether for now
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz (1):
clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
Thomas Abraham (5):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: exynos4: add cpu clock configuration data and
instantiate cpu clock
ARM: dts: Exynos4210: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
arch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 12 + arch/arm/mach-exynos/exynos.c | 21 +- drivers/clk/clk.c | 3 + drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 349 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 73 +++++ drivers/clk/samsung/clk-exynos4.c | 24 +- drivers/cpufreq/Kconfig.arm | 11 - drivers/cpufreq/Makefile | 1 - drivers/cpufreq/exynos-cpufreq.c | 5 +- drivers/cpufreq/exynos-cpufreq.h | 9 - drivers/cpufreq/exynos4210-cpufreq.c | 184 ------------ include/linux/clk-provider.h | 1 + 16 files changed, 495 insertions(+), 212 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
Signature · 1 line
1.7.9.5
PATCH 1/6 clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because clk_core_set_rate_nolock() calls clk_calc_new_rates(clk, rate) before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered for mout_apll clock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed by clk_change_rate(top). To workaround the problem CLK_RECALC_NEW_RATES flag is added and it is set for mout_apll clock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.
For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of CLK_GET_RATE_NOCACHE flag:
fout_apll rate: 1200000000
fout_apll_div_2 rate: 600000000
mout_clkout_cpu rate: 600000000
div_clkout_cpu rate: 600000000
clkout_cpu rate: 600000000
mout_apll rate: 1200000000
armclk rate: 1200000000
mout_hpm rate: 1200000000
div_copy rate: 300000000
div_hpm rate: 300000000
mout_core rate: 1200000000
div_core rate: 1200000000
div_core2 rate: 1200000000
arm_clk_div_2 rate: 600000000
div_corem0 rate: 300000000
div_corem1 rate: 150000000
div_periph rate: 300000000
div_atb rate: 300000000
div_pclk_dbg rate: 150000000
sclk_apll rate: 1200000000
sclk_apll_div_2 rate: 600000000With use of CLK_GET_RATE_NOCACHE flag:
fout_apll rate: 1200000000
fout_apll_div_2 rate: 600000000
mout_clkout_cpu rate: 600000000
div_clkout_cpu rate: 600000000
clkout_cpu rate: 600000000
mout_apll rate: 1200000000
armclk rate: 1200000000
mout_hpm rate: 1200000000
div_copy rate: 200000000
div_hpm rate: 200000000
mout_core rate: 1200000000
div_core rate: 1200000000
div_core2 rate: 1200000000
arm_clk_div_2 rate: 600000000
div_corem0 rate: 300000000
div_corem1 rate: 150000000
div_periph rate: 300000000
div_atb rate: 240000000
div_pclk_dbg rate: 120000000
sclk_apll rate: 150000000
sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of CLK_GET_RATE_NOCACHE and CLK_DIVIDER_READ_ONLY clock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.
--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)
drivers/clk/clk.c +3 -0
@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types.
include/linux/clk-provider.h +1 -0
@@ -31,6 +31,7 @@#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ struct clk_hw ;struct clk_core ;
Signature · 1 line
1.7.9.5
PATCH 2/6 clk: samsung: add infrastructure to register cpu clocks
In reply to Bartlomiej ZolnierkiewiczFrom: Thomas Abraham <[email protected]>
The CPU clock provider supplies the clock to the CPU clock domain. The composition and organization of the CPU clock provider could vary among Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers and gates. This patch defines a new clock type for CPU clock provider and adds infrastructure to register the CPU clock providers for Samsung platforms.
Changes by Bartlomiej:
- fixed issue with setting lower dividers before the parent clock speed was lowered (the issue resulted in lockup on Exynos4210 SoC based Origen board when "ondemand" cpufreq governor was stress tested)
- fixed missing spin_unlock on error in exynos_cpuclk_post_rate_change() problem by moving cfg_data search outside of the spin locked area
- removed leftover kfree() in exynos_register_cpu_clock() that could result in dereferencing the NULL pointer on error
- moved spin_lock earlier in exynos_cpuclk_pre_rate_change() to cover reading of E4210_SRC_CPU and E4210_DIV_CPU1 registers
- added missing "last chance" checks to wait_until_divider_stable() and wait_until_mux_stable() (needed in case that IRQ handling took long time to proceed and resulted in function printing incorrect error message about timeout)
- moved E4210_CPU_DIV[0,1]() macros just before their only users, this resulted in moving them from patch #2 to patch #3/6 ("clk:
samsung: exynos4: add cpu clock configuration data and instantiate cpu clock")
- removed E5250_CPU_DIV[0,1](), E5420_EGL_DIV0() and E5420_KFC_DIV() macros for now
- added my Copyrights to drivers/clk/samsung/clk-cpu.c
--- drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 349 +++++++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 73 +++++++++ 3 files changed, 423 insertions(+), 1 deletion(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h
drivers/clk/samsung/Makefile +1 -1
@@ -2,7 +2,7 @@ # Samsung Clock specific Makefile # -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS4415) += clk-exynos4415.o
drivers/clk/samsung/clk-cpu.c new file +349 -0
349 lines not on this page · raw message
drivers/clk/samsung/clk-cpu.h new file +73 -0
73 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 3/6 clk: samsung: exynos4: add cpu clock configuration data and instantiate cpu clock
In reply to Bartlomiej ZolnierkiewiczFrom: Thomas Abraham <[email protected]>
With the addition of the new Samsung specific cpu-clock type, the arm clock can be represented as a cpu-clock type. Add the CPU clock configuration data and instantiate the CPU clock type for Exynos4210.
Changes by Bartlomiej:
- fixed issue with wrong dividers being setup by Common Clock Framework (by an addition of CLK_RECALC_NEW_RATES clock flag to mout_apll clock, without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board), this was probably meant to be workarounded by use of CLK_GET_RATE_NOCACHE and CLK_DIVIDER_READ_ONLY clock flags in the original patchset (in "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags") but using these flags is not sufficient to fix the issue observed
- removed Exynos5250 and Exynos5420 support for now
--- drivers/clk/samsung/clk-exynos4.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
drivers/clk/samsung/clk-exynos4.c +23 -1
@@ -19,6 +19,7 @@#include <linux/syscore_ops.h> #include "clk.h" +#include "clk-cpu.h" /* Exynos4 clock controller register offsets */ #define SRC_LEFTBUS 0x4200
@@ -534,7 +535,8 @@ static struct samsung_fixed_factor_clock exynos4x12_fixed_factor_clks[] __initda/* list of mux clocks supported in all exynos4 soc's */ static struct samsung_mux_clock exynos4_mux_clks[]__initdata = {MUX_FA (CLK_MOUT_APLL ,"mout_apll" , mout_apll_p,SRC_CPU ,0 ,1 , -CLK_SET_RATE_PARENT ,0 ,"mout_apll" ), +CLK_SET_RATE_PARENT |CLK_RECALC_NEW_RATES ,0 , +"mout_apll" ),MUX (CLK_MOUT_HDMI ,"mout_hdmi" , mout_hdmi_p,SRC_TV ,0 ,1 ),MUX (0 ,"mout_mfc1" , sclk_evpll_p,SRC_MFC ,4 ,1 ),MUX (0 ,"mout_mfc" , mout_mfc_p,SRC_MFC ,8 ,1 ),
@@ -1378,6 +1380,22 @@ static void __init exynos4x12_core_down_clock(void)__raw_writel (0x0 , reg_base +E4X12_PWR_CTRL2 ); } +#define E4210_CPU_DIV0 (apll, pclk_dbg, atb, periph, corem1, corem0) \ + (((apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \ + ((periph) << 12) | ((corem1) << 8) | ((corem0) << 4)) +#define E4210_CPU_DIV1 (hpm, copy) \ + (((hpm) << 4) | ((copy) << 0)) + +static const struct exynos_cpuclk_cfg_data e4210_armclk_d[]__initconst = { + {1200000 ,E4210_CPU_DIV0 (7 ,1 ,4 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,5 ), }, + {1000000 ,E4210_CPU_DIV0 (7 ,1 ,4 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,4 ), }, + {800000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {500000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {400000 ,E4210_CPU_DIV0 (7 ,1 ,3 ,3 ,7 ,3 ),E4210_CPU_DIV1 (0 ,3 ), }, + {200000 ,E4210_CPU_DIV0 (0 ,1 ,1 ,1 ,3 ,1 ),E4210_CPU_DIV1 (0 ,3 ), }, + {0 }, +}; +/* register exynos4 clocks */ static void __init exynos4_clk_init (struct device_node *np,enum exynos4_soc soc)
@@ -1455,6 +1473,10 @@ static void __init exynos4_clk_init(struct device_node *np,samsung_clk_register_fixed_factor (ctx, exynos4210_fixed_factor_clks,ARRAY_SIZE (exynos4210_fixed_factor_clks)); +exynos_register_cpu_clock (ctx,CLK_ARM_CLK ,"armclk" , + mout_core_p4210[0 ], mout_core_p4210[1 ],0x14200 , + e4210_armclk_d,ARRAY_SIZE (e4210_armclk_d), +CLK_CPU_NEEDS_DEBUG_ALT_DIV |CLK_CPU_HAS_DIV1 ); }else {samsung_clk_register_mux (ctx, exynos4x12_mux_clks,ARRAY_SIZE (exynos4x12_mux_clks));
Signature · 1 line
1.7.9.5
PATCH 4/6 ARM: dts: Exynos4210: add CPU OPP and regulator supply property
In reply to Bartlomiej ZolnierkiewiczFrom: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for now
--- arch/arm/boot/dts/exynos4210-origen.dts | 4 ++++ arch/arm/boot/dts/exynos4210-trats.dts | 4 ++++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 ++++ arch/arm/boot/dts/exynos4210.dtsi | 12 ++++++++++++ 4 files changed, 24 insertions(+)
arch/arm/boot/dts/exynos4210-origen.dts +4 -0
@@ -335,3 +335,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&buck1_reg>; +};
arch/arm/boot/dts/exynos4210-trats.dts +4 -0
@@ -483,3 +483,7 @@ }; }; }; + +&cpu0 { + cpu0-supply = <&varm_breg>; +};
arch/arm/boot/dts/exynos4210-universal_c210.dts +4 -0
@@ -567,3 +567,7 @@ &mdma1 { reg = <0x12840000 0x1000>; }; + +&cpu0 { + cpu0-supply = <&vdd_arm_reg>; +};
arch/arm/boot/dts/exynos4210.dtsi +12 -0
@@ -40,6 +40,18 @@ device_type = "cpu"; compatible = "arm,cortex-a9"; reg = <0x900>; + clocks = <&clock CLK_ARM_CLK>; + clock-names = "cpu"; + clock-latency = <160000>; + + operating-points = < + 1200000 1250000 + 1000000 1150000 + 800000 1075000 + 500000 975000 + 400000 975000 + 200000 950000 + >; cooling-min-level = <4>; cooling-max-level = <2>; #cooling-cells = <2>; /* min followed by max */
Signature · 1 line
1.7.9.5
PATCH 5/6 ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
In reply to Bartlomiej ZolnierkiewiczFrom: Thomas Abraham <[email protected]>
The new CPU clock type allows the use of generic CPUfreq driver. Switch Exynos4210 to using generic cpufreq driver.
Changes by Bartlomiej:
- removed non-Exynos4210 support for now
--- arch/arm/mach-exynos/exynos.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
arch/arm/mach-exynos/exynos.c +20 -1
@@ -197,6 +197,25 @@ static void __init exynos_init_irq(void)exynos_map_pmu (); } +static const struct of_device_id exynos_cpufreq_matches[] = { + { .compatible ="samsung,exynos4210" , .data ="cpufreq-dt" }, + {/* sentinel */ } +}; + +static void __init exynos_cpufreq_init (void ) +{ +struct device_node *root =of_find_node_by_path ("/" ); +const struct of_device_id *match; + + match =of_match_node (exynos_cpufreq_matches, root); +if (!match) { +platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +return ; + } + +platform_device_register_simple (match->data,-1 ,NULL ,0 ); +} +static void __init exynos_dt_machine_init (void ) {/*
@@ -218,7 +237,7 @@ static void __init exynos_dt_machine_init(void) of_machine_is_compatible("samsung,exynos5250"))platform_device_register (&exynos_cpuidle); -platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +exynos_cpufreq_init ();of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); }
Signature · 1 line
1.7.9.5
PATCH 6/6 cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
In reply to Bartlomiej ZolnierkiewiczFrom: Thomas Abraham <[email protected]>
Exynos4210 based platforms have switched over to use generic cpufreq driver for cpufreq functionality. So the Exynos specific cpufreq support for these platforms can be removed.
Changes by Bartlomiej:
- dropped Exynos5250 support removal for now
- updated exynos-cpufreq.[c,h]
--- drivers/cpufreq/Kconfig.arm | 11 -- drivers/cpufreq/Makefile | 1 - drivers/cpufreq/exynos-cpufreq.c | 5 +- drivers/cpufreq/exynos-cpufreq.h | 9 -- drivers/cpufreq/exynos4210-cpufreq.c | 184 ---------------------------------- 5 files changed, 1 insertion(+), 209 deletions(-) delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
drivers/cpufreq/Kconfig.arm +0 -11
@@ -36,17 +36,6 @@ config ARM_EXYNOS_CPUFREQ If in doubt, say N. -config ARM_EXYNOS4210_CPUFREQ - bool "SAMSUNG EXYNOS4210" - depends on CPU_EXYNOS4210 - depends on ARM_EXYNOS_CPUFREQ - default y - help - This adds the CPUFreq driver for Samsung EXYNOS4210 - SoC (S5PV310 or S5PC210). - - If in doubt, say N. - config ARM_EXYNOS4X12_CPUFREQ bool "SAMSUNG EXYNOS4x12" depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
drivers/cpufreq/Makefile +0 -1
@@ -54,7 +54,6 @@ obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += arm-exynos-cpufreq.o arm-exynos-cpufreq-y := exynos-cpufreq.o -arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
drivers/cpufreq/exynos-cpufreq.c +1 -4
@@ -144,10 +144,7 @@ static int exynos_cpufreq_probe(struct platform_device *pdev) exynos_info->dev = &pdev->dev; -if (of_machine_is_compatible ("samsung,exynos4210" )) { - exynos_info->type =EXYNOS_SOC_4210 ; - ret =exynos4210_cpufreq_init (exynos_info); - }else if (of_machine_is_compatible ("samsung,exynos4212" )) { +if (of_machine_is_compatible ("samsung,exynos4212" )) { exynos_info->type =EXYNOS_SOC_4212 ; ret =exynos4x12_cpufreq_init (exynos_info); }else if (of_machine_is_compatible ("samsung,exynos4412" )) {
drivers/cpufreq/exynos-cpufreq.h +0 -9
@@ -18,7 +18,6 @@ enum cpufreq_level_index { };enum exynos_soc_type { -EXYNOS_SOC_4210 ,EXYNOS_SOC_4212 ,EXYNOS_SOC_4412 ,EXYNOS_SOC_5250 ,
@@ -52,14 +51,6 @@ struct exynos_dvfs_info {void __iomem *cmu_regs; }; -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ -extern int exynos4210_cpufreq_init (struct exynos_dvfs_info *); -#else -static inline int exynos4210_cpufreq_init (struct exynos_dvfs_info *info) -{ -return -EOPNOTSUPP ; -} -#endif #ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ extern int exynos4x12_cpufreq_init (struct exynos_dvfs_info *);#else
drivers/cpufreq/exynos4210-cpufreq.c deleted +0 -184
184 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Re: [PATCH 5/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
In reply to Bartlomiej Zolnierkiewicz2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 5 lines
From: Thomas Abraham <[email protected]>
The new CPU clock type allows the use of generic CPUfreq driver. Switch Exynos4210 to using generic cpufreq driver.
Quoted 8 lines
Changes by Bartlomiej:
- removed non-Exynos4210 support for nowCc Tomasz Figa <[email protected]>Cc Kukjin Kim <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
I know this is an old patch, it looks good. Just a minor nit below.
Quoted 19 lines
--- arch/arm/mach-exynos/exynos.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)arch/arm/mach-exynos/exynos.c +7
-0@@ -197,6 +197,25 @@ static void __init exynos_init_irq(void)exynos_map_pmu (); } +static const struct of_device_id exynos_cpufreq_matches[] = { + { .compatible ="samsung,exynos4210" , .data ="cpufreq-dt" }, + {/* sentinel */ } +}; + +static void __init exynos_cpufreq_init (void ) +{
arch/arm/mach-exynos/exynos.c static void __init exynos_init_irq(void) · line 216
Quoted 10 lines
arch/arm/mach-exynos/exynos.c +10
-0+struct device_node *root =of_find_node_by_path ("/" ); +const struct of_device_id *match; + + match =of_match_node (exynos_cpufreq_matches, root); +if (!match) { +platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +return ; + } + +platform_device_register_simple (match->data,-1 ,NULL ,0 );
How about something like:
const char *cpufreq_dev)name = "exynos-cpufreq";
if (match)
cpufreq_dev_name = match->data;platform_device_register_simple(cpufreq_dev_name -1, NULL, 0);
Less returns and one call to platform_device_register_simple(). Best regards,
Krzysztof
Quoted 22 lines
arch/arm/mach-exynos/exynos.c +3
-2+} +static void __init exynos_dt_machine_init (void ) {/* @@ -218,7 +237,7 @@ static void __init exynos_dt_machine_init(void) of_machine_is_compatible("samsung,exynos5250"))platform_device_register (&exynos_cpuidle); -platform_device_register_simple ("exynos-cpufreq" ,-1 ,NULL ,0 ); +exynos_cpufreq_init ();of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); } --1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
In reply to Bartlomiej Zolnierkiewicz2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for now
Quoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
Best regards,
Krzysztof
Hi,
Quoted 5 lines · Bartlomiej Zolnierkiewicz
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)? Also what is your preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Quoted 96 lines
It consists of a modified "[PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms" [1] patch series from Thomas Abraham. As there have not been updates of this patchset since November 2014 I decided to dust it off myself. I updated Thomas' patchset to current kernels, fixed bugs that I noticed and removed non-Exynos4210 support for now (to speed up inclusion in upstream kernel). Since some modifications were not trivial I dropped all Reviewed-by:, Tested-by: and Acked-by: tags. Please review/test this patchset and reply with revelant tag (Thank You!). I also plan to work on Exynos4x12 support next (which was missing in the original patchset) and then on Exynos5250/Exynos5420 one.
This patch series has been tested on Exynos4210 based Origen and Trats boards.
Depends on:
- next-20150330 branch of linux-next kernel tree
(mfd tree contains a crucial fix for MAX8997 PMIC support)
- "[PATCH] clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC" [2][1] https://www.marc.info/?l=linux-arm-kernel&m=141657611003803&w=2
[2] https://lkml.org/lkml/2015/3/27/568Changes over Thomas' code:
- fixed issue with wrong dividers being setup by Common Clock Framework (by an addition ofCLK_RECALC_NEW_RATESclock flag tomout_apllclock, without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board), this was probably meant to be workarounded by use ofCLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original patchset (in "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags") but using these flags is not sufficient to fix the issue observed
- fixed issue with setting lower dividers before the parent clock speed was lowered (the issue resulted in lockup on Exynos4210 SoC based Origen board when "ondemand" cpufreq governor was stress tested)
- fixed missingspin_unlockon error inexynos_cpuclk_post_rate_change()problem by movingcfg_datasearch outside of the spin locked area
- removed leftoverkfree()inexynos_register_cpu_clock()that could result in dereferencing the NULL pointer on error
- movedspin_lockearlier inexynos_cpuclk_pre_rate_change()to cover reading ofE4210_SRC_CPUandE4210_DIV_CPU1registers
- added missing "last chance" checks towait_until_divider_stable()andwait_until_mux_stable()(needed in case that IRQ handling took long time to proceed and resulted in function printing incorrect error message about timeout)
- moved E4210_CPU_DIV[0,1]() macros just before their only users, this resulted in moving them from patch #2 to patch #3/6 ("clk:
samsung: exynos4: add cpu clock configuration data and instantiate cpu clock")
- added my Copyrights todrivers/clk/samsung/clk-cpu.c
- updated exynos-cpufreq.[c,h]
- removed non-Exynos4210 support for now
- dropped "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags" altogether for nowBest regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung ElectronicsBartlomiej Zolnierkiewicz (1):
clk: addCLK_RECALC_NEW_RATESclock flag for Exynos cpu clock supportThomas Abraham (5):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: exynos4: add cpu clock configuration data and
instantiate cpu clock
ARM: dts: Exynos4210: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
cpufreq: exynos: remove Exynos4210 specific cpufreq driver supportarch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 12 + arch/arm/mach-exynos/exynos.c | 21 +- drivers/clk/clk.c | 3 + drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 349 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 73 +++++ drivers/clk/samsung/clk-exynos4.c | 24 +- drivers/cpufreq/Kconfig.arm | 11 - drivers/cpufreq/Makefile | 1 - drivers/cpufreq/exynos-cpufreq.c | 5 +- drivers/cpufreq/exynos-cpufreq.h | 9 - drivers/cpufreq/exynos4210-cpufreq.c | 184 ------------ include/linux/clk-provider.h | 1 + 16 files changed, 495 insertions(+), 212 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
Sylwester Nawrocki
maintainerRe: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
In reply to Bartlomiej ZolnierkiewiczQuoted 106 lines · Bartlomiej Zolnierkiewicz
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0@@ -31,6 +31,7 @@#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */
Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though. I thought about making the cpu clk notifier callback returning a specific error value, which would then trigger rate recalculation after __clk_notify() call in clk_change_rate() function. This way the trigger of the repeated rate recalculation would come from a notifier callback, rather than from a clock definition. But in general it would be difficult to handle multiple notification callbacks, each of which would attempt to trigger the rate recalculation.
Signature · 2 lines
Regards, Sylwester
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210platform
In reply to Bartlomiej ZolnierkiewiczQuoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 10 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?
I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
Thanks,
Kukjin
Quoted 102 lines
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung ElectronicsQuoted 96 lines
It consists of a modified "[PATCH v12 0/6] cpufreq: use generic cpufreq drivers for exynos platforms" [1] patch series from Thomas Abraham. As there have not been updates of this patchset since November 2014 I decided to dust it off myself. I updated Thomas' patchset to current kernels, fixed bugs that I noticed and removed non-Exynos4210 support for now (to speed up inclusion in upstream kernel). Since some modifications were not trivial I dropped all Reviewed-by:, Tested-by: and Acked-by: tags. Please review/test this patchset and reply with revelant tag (Thank You!). I also plan to work on Exynos4x12 support next (which was missing in the original patchset) and then on Exynos5250/Exynos5420 one.
This patch series has been tested on Exynos4210 based Origen and Trats boards.
Depends on:
- next-20150330 branch of linux-next kernel tree
(mfd tree contains a crucial fix for MAX8997 PMIC support)
- "[PATCH] clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC" [2][1] https://www.marc.info/?l=linux-arm-kernel&m=141657611003803&w=2
[2] https://lkml.org/lkml/2015/3/27/568Changes over Thomas' code:
- fixed issue with wrong dividers being setup by Common Clock Framework (by an addition ofCLK_RECALC_NEW_RATESclock flag tomout_apllclock, without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board), this was probably meant to be workarounded by use ofCLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original patchset (in "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags") but using these flags is not sufficient to fix the issue observed
- fixed issue with setting lower dividers before the parent clock speed was lowered (the issue resulted in lockup on Exynos4210 SoC based Origen board when "ondemand" cpufreq governor was stress tested)
- fixed missingspin_unlockon error inexynos_cpuclk_post_rate_change()problem by movingcfg_datasearch outside of the spin locked area
- removed leftoverkfree()inexynos_register_cpu_clock()that could result in dereferencing the NULL pointer on error
- movedspin_lockearlier inexynos_cpuclk_pre_rate_change()to cover reading ofE4210_SRC_CPUandE4210_DIV_CPU1registers
- added missing "last chance" checks towait_until_divider_stable()andwait_until_mux_stable()(needed in case that IRQ handling took long time to proceed and resulted in function printing incorrect error message about timeout)
- moved E4210_CPU_DIV[0,1]() macros just before their only users, this resulted in moving them from patch #2 to patch #3/6 ("clk:
samsung: exynos4: add cpu clock configuration data and instantiate cpu clock")
- added my Copyrights todrivers/clk/samsung/clk-cpu.c
- updated exynos-cpufreq.[c,h]
- removed non-Exynos4210 support for now
- dropped "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update clock flags" altogether for nowBest regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung ElectronicsBartlomiej Zolnierkiewicz (1):
clk: addCLK_RECALC_NEW_RATESclock flag for Exynos cpu clock supportThomas Abraham (5):
clk: samsung: add infrastructure to register cpu clocks
clk: samsung: exynos4: add cpu clock configuration data and
instantiate cpu clock
ARM: dts: Exynos4210: add CPU OPP and regulator supply property
ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
cpufreq: exynos: remove Exynos4210 specific cpufreq driver supportarch/arm/boot/dts/exynos4210-origen.dts | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 4 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 + arch/arm/boot/dts/exynos4210.dtsi | 12 + arch/arm/mach-exynos/exynos.c | 21 +- drivers/clk/clk.c | 3 + drivers/clk/samsung/Makefile | 2 +- drivers/clk/samsung/clk-cpu.c | 349 +++++++++++++++++++++++ drivers/clk/samsung/clk-cpu.h | 73 +++++ drivers/clk/samsung/clk-exynos4.c | 24 +- drivers/cpufreq/Kconfig.arm | 11 - drivers/cpufreq/Makefile | 1 - drivers/cpufreq/exynos-cpufreq.c | 5 +- drivers/cpufreq/exynos-cpufreq.h | 9 - drivers/cpufreq/exynos4210-cpufreq.c | 184 ------------ include/linux/clk-provider.h | 1 + 16 files changed, 495 insertions(+), 212 deletions(-) create mode 100644 drivers/clk/samsung/clk-cpu.c create mode 100644 drivers/clk/samsung/clk-cpu.h delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
Re: [PATCH 6/6] cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
In reply to Bartlomiej ZolnierkiewiczQuoted 14 lines · Bartlomiej Zolnierkiewicz
From: Thomas Abraham <[email protected]>
Exynos4210 based platforms have switched over to use generic cpufreq driver for cpufreq functionality. So the Exynos specific cpufreq support for these platforms can be removed.
Changes by Bartlomiej:
- dropped Exynos5250 support removal for now
- updated exynos-cpufreq.[c,h]Cc Viresh Kumar <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 8 lines
--- drivers/cpufreq/Kconfig.arm | 11 -- drivers/cpufreq/Makefile | 1 - drivers/cpufreq/exynos-cpufreq.c | 5 +- drivers/cpufreq/exynos-cpufreq.h | 9 -- drivers/cpufreq/exynos4210-cpufreq.c | 184 ---------------------------------- 5 files changed, 1 insertion(+), 209 deletions(-) delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c
Re: [PATCH 5/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
In reply to Bartlomiej ZolnierkiewiczQuoted 8 lines · Bartlomiej Zolnierkiewicz
From: Thomas Abraham <[email protected]>
The new CPU clock type allows the use of generic CPUfreq driver. Switch Exynos4210 to using generic cpufreq driver.
Changes by Bartlomiej:
- removed non-Exynos4210 support for now
Quoted 8 lines
Cc Tomasz Figa <[email protected]>Cc Kukjin Kim <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- arch/arm/mach-exynos/exynos.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
Viresh Kumar
maintainerRe: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210platform
In reply to Kukjin KimQuoted 16 lines · Kukjin Kim
Quoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 10 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now.
Quoted 8 lines
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?
Quoted 7 lines
I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
For cpufreq subsystem changes, you can take them in your tree.
Quoted 4 lines
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
One thing that looked wrong to me is the email id of Thomas.. I believe he has already left Samsung and his id wouldn't exist anymore. Right ?
Then I wouldn't recommend something that doesn't exist to get merged now. Probably use another email id of his.
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210platform
Quoted 14 lines · Viresh Kumar
Quoted 13 lines · Kukjin Kim
Quoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 7 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now.
Thanks!
Quoted 18 lines
Quoted 8 lines
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?Quoted 7 lines
I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
For cpufreq subsystem changes, you can take them in your tree.
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
One thing that looked wrong to me is the email id of Thomas.. I believe he has already left Samsung and his id wouldn't exist anymore. Right ?
This doesn't seem to be a case. His email doesn't bounce and his id exists (I've just checked this). I think that he is just very busy with some other work.
Quoted 2 lines
Then I wouldn't recommend something that doesn't exist to get merged now. Probably use another email id of his.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Viresh Kumar
maintainerRe: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210platform
Quoted 3 lines · Bartlomiej Zolnierkiewicz
This doesn't seem to be a case. His email doesn't bounce and his id exists (I've just checked this). I think that he is just very busy with some other work.
Looks like I was thinking about someone else and thought he was Thomas. Sorry Thomas. :)
Signature · 1 line
viresh
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers forExynos4210platform
In reply to Viresh KumarQuoted 35 lines · Viresh Kumar
Quoted 16 lines · Kukjin Kim
Quoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 10 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now.
Quoted 14 lines
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Quoted 4 lines
Quoted 1 line
Viresh and Mike, how do you think about that?
For cpufreq subsystem changes, you can take them in your tree.
Hi Viresh, OK, I will take the cpufreq changes with your ack. Thanks for your confirmation.
Hi Mike and Sylwester,
How can we handle this series well without any problems? hmm...
Quoted 11 lines
Quoted 4 lines
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
One thing that looked wrong to me is the email id of Thomas.. I believe he has already left Samsung and his id wouldn't exist anymore. Right ?
Then I wouldn't recommend something that doesn't exist to get merged now. Probably use another email id of his.
As Bart replied, Thomas is still Samsung guy, maybe you meant Tomasz? he moved to another company last year.
- Kukjin
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers forExynos4210platform
Quoted 38 lines · Kukjin Kim
Quoted 37 lines · Viresh Kumar
Quoted 16 lines · Kukjin Kim
Quoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 10 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now.
Quoted 15 lines
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
Quoted 8 lines
Quoted 2 lines
For cpufreq subsystem changes, you can take them in your tree.
Hi Viresh, OK, I will take the cpufreq changes with your ack. Thanks for your confirmation.
Hi Mike and Sylwester,
How can we handle this series well without any problems? hmm...
Still I need to get clock guys' ack or any comments on this series...
- Kukjin
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers forExynos4210platform
Hi,
Mike, could you please take a look at patches #1 and #2 (#1 is a 4 line change to a Common Clock Framework and #2 is ARM Exynos specific)?
This series has been waiting on your feedback since 3rd of April. :(
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Quoted 55 lines · Kukjin Kim
Quoted 38 lines · Kukjin Kim
Quoted 37 lines · Viresh Kumar
Quoted 16 lines · Kukjin Kim
Quoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 10 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now.
Quoted 15 lines
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
Quoted 8 lines
Quoted 2 lines
For cpufreq subsystem changes, you can take them in your tree.
Hi Viresh, OK, I will take the cpufreq changes with your ack. Thanks for your confirmation.
Hi Mike and Sylwester,
How can we handle this series well without any problems? hmm...Still I need to get clock guys' ack or any comments on this series...
- Kukjin
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers forExynos4210platform
Quoted 5 lines · Bartlomiej Zolnierkiewicz
Hi,
Mike, could you please take a look at patches #1 and #2 (#1 is a 4 line change to a Common Clock Framework and #2 is ARM Exynos specific)?
Oh, and patch #3 (which is also ARM Exynos specific).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Quoted 64 lines
This series has been waiting on your feedback since 3rd of April. :(
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung ElectronicsQuoted 55 lines · Kukjin Kim
Quoted 38 lines · Kukjin Kim
Quoted 37 lines · Viresh Kumar
Quoted 16 lines · Kukjin Kim
Quoted 3 lines · Bartlomiej Zolnierkiewicz
Hi,
Hi Bart,
Quoted 10 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
Hi,
This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform.
Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)?
Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now.
Quoted 15 lines
Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted.
Quoted 5 lines
Also what is your
preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)?I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
Quoted 8 lines
Quoted 2 lines
For cpufreq subsystem changes, you can take them in your tree.
Hi Viresh, OK, I will take the cpufreq changes with your ack. Thanks for your confirmation.
Hi Mike and Sylwester,
How can we handle this series well without any problems? hmm...Still I need to get clock guys' ack or any comments on this series...
- Kukjin
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)...
Sure, why not :-)
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
In reply to Sylwester NawrockiQuoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@
Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
Quoted 7 lines
I thought about making the cpu clk notifier callback returning a specific error value, which would then trigger rate recalculation after
__clk_notify()call inclk_change_rate()function. This way the trigger of the repeated rate recalculation would come from a notifier callback, rather than from a clock definition. But in general it would be difficult to handle multiple notification callbacks, each of which would attempt to trigger the rate recalculation.
The more complexity we add to the notifier callbacks the crazier things will get. For now I'd like to see Exynos continue to use the platform-specific CPUfreq drivers until the new coordinated clock rates infrastructure makes it possible to do this type of stuff without relying on the notifiers. I'm working on this feature Right Now. I never like putting dates on upstream stuff but I'd like to see this feature in 4.3 if possible.
Regards,
Mike
Quoted 4 lines
Signature · 3 lines
-- Regards, Sylwester
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
Hi,
Quoted 117 lines · Michael Turquette
Quoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
Quoted 3 lines
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
I'm very surprised by this. Clock changes using clock notifiers in Thomas' original patchset were Acked by you:
"[PATCH v12 1/6] clk: samsung: add infrastructure to register cpu clocks"
https://www.marc.info/?l=linux-arm-kernel&m=141657613203808&w=2
I've only fixed issues present within the original code (this 4 lines workaround/hack change to clock subsystem is a result of this), I have not changed it fundamentally.
Quoted 8 lines
Quoted 7 lines
I thought about making the cpu clk notifier callback returning a specific error value, which would then trigger rate recalculation after
__clk_notify()call inclk_change_rate()function. This way the trigger of the repeated rate recalculation would come from a notifier callback, rather than from a clock definition. But in general it would be difficult to handle multiple notification callbacks, each of which would attempt to trigger the rate recalculation.
Quoted 7 lines
The more complexity we add to the notifier callbacks the crazier things will get. For now I'd like to see Exynos continue to use the platform-specific CPUfreq drivers until the new coordinated clock rates infrastructure makes it possible to do this type of stuff without relying on the notifiers. I'm working on this feature Right Now. I never like putting dates on upstream stuff but I'd like to see this feature in 4.3 if possible.
So after 2.5 months of waiting on your feedback you're saying that the current patches (Acked by all other Maintainers and tested on affected platforms) should be just abandoned and we should wait with re-doing them on some not yet implemented feature of clock subsystem which would be available 2 months from now (at earliest)?
Also what should I do about CPUfreq support for SoCs that don't have platform specific CPUfreq drivers currently and that need current patches to work (I mean Exynos542x, Exynos5800 and Exynos5433 in the future)?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
Quoted 128 lines · Bartlomiej Zolnierkiewicz
Hi,
Quoted 117 lines · Michael Turquette
Quoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
Quoted 3 lines
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
I'm very surprised by this. Clock changes using clock notifiers in Thomas' original patchset were Acked by you:
Quoted 6 lines
"[PATCH v12 1/6] clk: samsung: add infrastructure to register cpu clocks"
https://www.marc.info/?l=linux-arm-kernel&m=141657613203808&w=2I've only fixed issues present within the original code (this 4 lines workaround/hack change to clock subsystem is a result of this), I have not changed it fundamentally.
Moreover similar changes for rockchip SoCs (which were explicitly based on Thomas' patches as noted in the code!) have already been merged in 3.18:
http://lkml.iu.edu/hypermail/linux/kernel/1410.1/02644.html
and are available in commit f6fba5f6967dbc062a7c138d67e2314220f5dd04 ("clk: rockchip: add new clock-type for the cpuclk").
I understand that my findings have uncovered some clock subsystem deficiencies which resulted in afterthought about fundamental design of cpu clocks but I have a feeling that our patches are now being unjustly punished for making these issues public.
I agree that current patches are not perfect (especially this patch) but they are good enough IMO. Please also understand that there were some serious work put into validating and reviewing them.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Quoted 31 lines
Quoted 8 lines
Quoted 7 lines
I thought about making the cpu clk notifier callback returning a specific error value, which would then trigger rate recalculation after
__clk_notify()call inclk_change_rate()function. This way the trigger of the repeated rate recalculation would come from a notifier callback, rather than from a clock definition. But in general it would be difficult to handle multiple notification callbacks, each of which would attempt to trigger the rate recalculation.Quoted 7 lines
The more complexity we add to the notifier callbacks the crazier things will get. For now I'd like to see Exynos continue to use the platform-specific CPUfreq drivers until the new coordinated clock rates infrastructure makes it possible to do this type of stuff without relying on the notifiers. I'm working on this feature Right Now. I never like putting dates on upstream stuff but I'd like to see this feature in 4.3 if possible.
So after 2.5 months of waiting on your feedback you're saying that the current patches (Acked by all other Maintainers and tested on affected platforms) should be just abandoned and we should wait with re-doing them on some not yet implemented feature of clock subsystem which would be available 2 months from now (at earliest)?
Also what should I do about CPUfreq support for SoCs that don't have platform specific CPUfreq drivers currently and that need current patches to work (I mean Exynos542x, Exynos5800 and Exynos5433 in the future)?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
PATCH 1/6 clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
Quoting Bartlomiej Zolnierkiewicz (2015-06-19 05:35:23)
Quoted 145 lines · Bartlomiej Zolnierkiewicz
Quoted 128 lines
Hi,
Quoted 117 lines · Michael Turquette
Quoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
Quoted 3 lines
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
I'm very surprised by this. Clock changes using clock notifiers in Thomas' original patchset were Acked by you:
Quoted 6 lines
"[PATCH v12 1/6] clk: samsung: add infrastructure to register cpu clocks"
https://www.marc.info/?l=linux-arm-kernel&m=141657613203808&w=2I've only fixed issues present within the original code (this 4 lines workaround/hack change to clock subsystem is a result of this), I have not changed it fundamentally.
Moreover similar changes for rockchip SoCs (which were explicitly based on Thomas' patches as noted in the code!) have already been merged in 3.18:
http://lkml.iu.edu/hypermail/linux/kernel/1410.1/02644.html
and are available in commit
f6fba5f6967dbc062a7c138d67e2314220f5dd04("clk: rockchip: add new clock-type for the cpuclk").
Quoted 8 lines
I understand that my findings have uncovered some clock subsystem deficiencies which resulted in afterthought about fundamental design of cpu clocks but I have a feeling that our patches are now being unjustly punished for making these issues public.
I agree that current patches are not perfect (especially this patch) but they are good enough IMO. Please also understand that there were some serious work put into validating and reviewing them.
You know what? You're right.
I don't really like this cpu-clock code (and similarly I don't like Tegra's EMC code which requires access to clk_hw_reparent). But I slept on this issue overnight and it doesn't seem right for me to hold back these patches when the better solution is currently vaporware (I have some code but it's far from ready).
It occurs to me that the best decision I can take is to merge it now and then force you guys to switch over when the new infrastructure is available. That is more reasonable than delaying the patches getting pulled.
So how to merge it? Viresh has given his Ack and is OK for the cpufreq changes to go through another tree. I can take the whole thing with Kukjin's Ack on the ARM dts patch, or we can set up an immutable branch.
If you really want to make my life easy you can send a pull request for these patches (and the other Exynos cpufreq/cpu-clock series).
Regards,
Mike
Quoted 39 lines
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung ElectronicsQuoted 31 lines
Quoted 8 lines
Quoted 7 lines
I thought about making the cpu clk notifier callback returning a specific error value, which would then trigger rate recalculation after
__clk_notify()call inclk_change_rate()function. This way the trigger of the repeated rate recalculation would come from a notifier callback, rather than from a clock definition. But in general it would be difficult to handle multiple notification callbacks, each of which would attempt to trigger the rate recalculation.Quoted 7 lines
The more complexity we add to the notifier callbacks the crazier things will get. For now I'd like to see Exynos continue to use the platform-specific CPUfreq drivers until the new coordinated clock rates infrastructure makes it possible to do this type of stuff without relying on the notifiers. I'm working on this feature Right Now. I never like putting dates on upstream stuff but I'd like to see this feature in 4.3 if possible.
So after 2.5 months of waiting on your feedback you're saying that the current patches (Acked by all other Maintainers and tested on affected platforms) should be just abandoned and we should wait with re-doing them on some not yet implemented feature of clock subsystem which would be available 2 months from now (at earliest)?
Also what should I do about CPUfreq support for SoCs that don't have platform specific CPUfreq drivers currently and that need current patches to work (I mean Exynos542x, Exynos5800 and Exynos5433 in the future)?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
W dniu 19.06.2015 o 23:53, Michael Turquette pisze:
Quoted 168 lines
Quoting Bartlomiej Zolnierkiewicz (2015-06-19 05:35:23)
Quoted 145 lines · Bartlomiej Zolnierkiewicz
Quoted 128 lines
Hi,
Quoted 117 lines · Michael Turquette
Quoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
Quoted 3 lines
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
I'm very surprised by this. Clock changes using clock notifiers in Thomas' original patchset were Acked by you:
Quoted 6 lines
"[PATCH v12 1/6] clk: samsung: add infrastructure to register cpu clocks"
https://www.marc.info/?l=linux-arm-kernel&m=141657613203808&w=2I've only fixed issues present within the original code (this 4 lines workaround/hack change to clock subsystem is a result of this), I have not changed it fundamentally.
Moreover similar changes for rockchip SoCs (which were explicitly based on Thomas' patches as noted in the code!) have already been merged in 3.18:
http://lkml.iu.edu/hypermail/linux/kernel/1410.1/02644.html
and are available in commit
f6fba5f6967dbc062a7c138d67e2314220f5dd04("clk: rockchip: add new clock-type for the cpuclk").Quoted 8 lines
I understand that my findings have uncovered some clock subsystem deficiencies which resulted in afterthought about fundamental design of cpu clocks but I have a feeling that our patches are now being unjustly punished for making these issues public.
I agree that current patches are not perfect (especially this patch) but they are good enough IMO. Please also understand that there were some serious work put into validating and reviewing them.
You know what? You're right.
I don't really like this cpu-clock code (and similarly I don't like Tegra's EMC code which requires access to
clk_hw_reparent). But I slept on this issue overnight and it doesn't seem right for me to hold back these patches when the better solution is currently vaporware (I have some code but it's far from ready).It occurs to me that the best decision I can take is to merge it now and then force you guys to switch over when the new infrastructure is available. That is more reasonable than delaying the patches getting pulled.
Quoted 4 lines
So how to merge it? Viresh has given his Ack and is OK for the cpufreq changes to go through another tree. I can take the whole thing with Kukjin's Ack on the ARM dts patch, or we can set up an immutable branch.
I already acked the DTS [0] patch and I'm fine with it. However there would be some conflicts if this went through tree different than Samsung. There are many Exynos4 DTS changes in the queue for 4.2.
Are there any objections for picking the DTS patch to Samsung tree?
Best regards,
Krzysztof
[0] https://lkml.org/lkml/2015/5/7/999
Quoted 4 lines
If you really want to make my life easy you can send a pull request for these patches (and the other Exynos cpufreq/cpu-clock series).
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
Quoting Krzysztof Kozlowski (2015-06-20 03:01:12)
Quoted 174 lines
W dniu 19.06.2015 o 23:53, Michael Turquette pisze:
Quoted 168 lines
Quoting Bartlomiej Zolnierkiewicz (2015-06-19 05:35:23)
Quoted 145 lines · Bartlomiej Zolnierkiewicz
Quoted 128 lines
Hi,
Quoted 117 lines · Michael Turquette
Quoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
Quoted 3 lines
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
I'm very surprised by this. Clock changes using clock notifiers in Thomas' original patchset were Acked by you:
Quoted 6 lines
"[PATCH v12 1/6] clk: samsung: add infrastructure to register cpu clocks"
https://www.marc.info/?l=linux-arm-kernel&m=141657613203808&w=2I've only fixed issues present within the original code (this 4 lines workaround/hack change to clock subsystem is a result of this), I have not changed it fundamentally.
Moreover similar changes for rockchip SoCs (which were explicitly based on Thomas' patches as noted in the code!) have already been merged in 3.18:
http://lkml.iu.edu/hypermail/linux/kernel/1410.1/02644.html
and are available in commit
f6fba5f6967dbc062a7c138d67e2314220f5dd04("clk: rockchip: add new clock-type for the cpuclk").Quoted 8 lines
I understand that my findings have uncovered some clock subsystem deficiencies which resulted in afterthought about fundamental design of cpu clocks but I have a feeling that our patches are now being unjustly punished for making these issues public.
I agree that current patches are not perfect (especially this patch) but they are good enough IMO. Please also understand that there were some serious work put into validating and reviewing them.
You know what? You're right.
I don't really like this cpu-clock code (and similarly I don't like Tegra's EMC code which requires access to
clk_hw_reparent). But I slept on this issue overnight and it doesn't seem right for me to hold back these patches when the better solution is currently vaporware (I have some code but it's far from ready).It occurs to me that the best decision I can take is to merge it now and then force you guys to switch over when the new infrastructure is available. That is more reasonable than delaying the patches getting pulled.
Quoted 4 lines
So how to merge it? Viresh has given his Ack and is OK for the cpufreq changes to go through another tree. I can take the whole thing with Kukjin's Ack on the ARM dts patch, or we can set up an immutable branch.
Quoted 5 lines
I already acked the DTS [0] patch and I'm fine with it. However there would be some conflicts if this went through tree different than Samsung. There are many Exynos4 DTS changes in the queue for 4.2.
Are there any objections for picking the DTS patch to Samsung tree?
That's fine with me. I don't foresee any build problems if I take patches 1-3 and 5-6. So I'll take those and you'll take #4, sound good?
Regards,
Mike
Quoted 10 lines
Best regards,
Krzysztof[0] https://lkml.org/lkml/2015/5/7/999
Quoted 4 lines
If you really want to make my life easy you can send a pull request for these patches (and the other Exynos cpufreq/cpu-clock series).
Re: [PATCH 1/6] clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
Quoted 175 lines · Michael Turquette
Quoting Krzysztof Kozlowski (2015-06-20 03:01:12)
Quoted 174 lines
W dniu 19.06.2015 o 23:53, Michael Turquette pisze:
Quoted 172 lines
Quoting Bartlomiej Zolnierkiewicz (2015-06-19 05:35:23)
Quoted 145 lines · Bartlomiej Zolnierkiewicz
Quoted 128 lines
Hi,
Quoted 117 lines · Michael Turquette
Quoting Sylwester Nawrocki (2015-05-13 07:13:13)
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 106 lines
This flag is needed to fix the issue with wrong dividers being setup by Common Clock Framework when using the new Exynos cpu clock support.
The issue happens because
clk_core_set_rate_nolock()callsclk_calc_new_rates(clk, rate)before both pre/post clock notifiers have a chance to run. In case of Exynos cpu clock support pre/post clock notifiers are registered formout_apllclock which is a parent of armclk cpu clock and dividers are modified in both pre and post clock notifier. This results in wrong dividers values being later programmed byclk_change_rate(top). To workaround the problemCLK_RECALC_NEW_RATESflag is added and it is set formout_apllclock later so the correct divider values are re-calculated after both pre and post clock notifiers had run.For example when using "performance" governor on Exynos4210 Origen board the cpufreq-dt driver requests to change the frequency from 1000MHz to 1200MHz and after the change state of the relevant clocks is following:
Without use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 300000000 div_hpm rate: 300000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 300000000 div_pclk_dbg rate: 150000000 sclk_apll rate: 1200000000 sclk_apll_div_2 rate: 600000000With use of
CLK_GET_RATE_NOCACHEflag:
fout_apllrate: 1200000000fout_apll_div_2 rate: 600000000 mout_clkout_cpu rate: 600000000 div_clkout_cpu rate: 600000000 clkout_cpu rate: 600000000 mout_apll rate: 1200000000 armclk rate: 1200000000 mout_hpm rate: 1200000000 div_copy rate: 200000000 div_hpm rate: 200000000 mout_core rate: 1200000000 div_core rate: 1200000000 div_core2 rate: 1200000000 arm_clk_div_2 rate: 600000000 div_corem0 rate: 300000000 div_corem1 rate: 150000000 div_periph rate: 300000000 div_atb rate: 240000000 div_pclk_dbg rate: 120000000 sclk_apll rate: 150000000 sclk_apll_div_2 rate: 75000000Without this change cpufreq-dt driver showed ~10 mA larger energy consumption when compared to cpufreq-exynos one when "performance" cpufreq governor was used on Exynos4210 SoC based Origen board.
This issue was probably meant to be workarounded by use of
CLK_GET_RATE_NOCACHEandCLK_DIVIDER_READ_ONLYclock flags in the original Exynos cpu clock patchset (in "[PATCH v12 6/6] clk:
samsung: remove unused clock aliases and update clock flags" patch) but usage of these flags is not sufficient to fix the issue observed.Cc Thomas Abraham <[email protected]>Cc Tomasz Figa <[email protected]>Cc Mike Turquette <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>--- drivers/clk/clk.c | 3 +++ include/linux/clk-provider.h | 1 + 2 files changed, 4 insertions(+)drivers/clk/clk.c +3
-0@@ -1771,6 +1771,9 @@ static void clk_change_rate(struct clk_core *clk)if (clk->notifier_count && old_rate != clk->rate)__clk_notify (clk,POST_RATE_CHANGE , old_rate, clk->rate); +if (clk->flags &CLK_RECALC_NEW_RATES ) + (void )clk_calc_new_rates (clk, clk->new_rate); +/* * Use safe iteration, as change_rate can actually swap parents * for certain clock types. include/linux/clk-provider.h +0
-0@@ -31,6 +31,7 @@Quoted 8 lines
include/linux/clk-provider.h line 34
Quoted 4 lines
include/linux/clk-provider.h +1
-0#define CLK_GET_RATE_NOCACHE BIT(6)/* do not use the cached clk rate */ #define CLK_SET_RATE_NO_REPARENT BIT(7)/* don't re-parent on rate change */ #define CLK_GET_ACCURACY_NOCACHE BIT(8)/* do not use the cached clk accuracy */ +#define CLK_RECALC_NEW_RATES BIT(9)/* recalc rates after notifications */ Mike, Stephen, what do you think about this? I'm rather resistant to this new flag approach, it looks like a hack. I don't seem to have better ideas to address the missing rate recalculation issue though.
Quoted 3 lines
I also do not like it. The root of the problem is the use of clk notifiers to change clk rates. This is also a hack and it points towards some missing infrastructure in the clock framework.
I'm very surprised by this. Clock changes using clock notifiers in Thomas' original patchset were Acked by you:
Quoted 6 lines
"[PATCH v12 1/6] clk: samsung: add infrastructure to register cpu clocks"
https://www.marc.info/?l=linux-arm-kernel&m=141657613203808&w=2I've only fixed issues present within the original code (this 4 lines workaround/hack change to clock subsystem is a result of this), I have not changed it fundamentally.
Moreover similar changes for rockchip SoCs (which were explicitly based on Thomas' patches as noted in the code!) have already been merged in 3.18:
http://lkml.iu.edu/hypermail/linux/kernel/1410.1/02644.html
and are available in commit
f6fba5f6967dbc062a7c138d67e2314220f5dd04("clk: rockchip: add new clock-type for the cpuclk").Quoted 8 lines
I understand that my findings have uncovered some clock subsystem deficiencies which resulted in afterthought about fundamental design of cpu clocks but I have a feeling that our patches are now being unjustly punished for making these issues public.
I agree that current patches are not perfect (especially this patch) but they are good enough IMO. Please also understand that there were some serious work put into validating and reviewing them.
You know what? You're right.
I don't really like this cpu-clock code (and similarly I don't like Tegra's EMC code which requires access to
clk_hw_reparent). But I slept on this issue overnight and it doesn't seem right for me to hold back these patches when the better solution is currently vaporware (I have some code but it's far from ready).It occurs to me that the best decision I can take is to merge it now and then force you guys to switch over when the new infrastructure is available. That is more reasonable than delaying the patches getting pulled.
So how to merge it? Viresh has given his Ack and is OK for the cpufreq changes to go through another tree. I can take the whole thing with Kukjin's Ack on the ARM dts patch, or we can set up an immutable branch.
Quoted 8 lines
Quoted 5 lines
I already acked the DTS [0] patch and I'm fine with it. However there would be some conflicts if this went through tree different than Samsung. There are many Exynos4 DTS changes in the queue for 4.2.
Are there any objections for picking the DTS patch to Samsung tree?
That's fine with me. I don't foresee any build problems if I take patches 1-3 and 5-6. So I'll take those and you'll take #4, sound good?
Yes, sounds good.
Bartlomiej, let us know if you suspect any problems with such approach.
Best regards,
Krzysztof
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
In reply to Krzysztof Kozlowski2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Best regards,
Krzysztof
RE: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 21 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 18 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowCc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 5 lines
Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
Thanks,
Kukjin
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 22 lines · Kukjin Kim
Quoted 21 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 18 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowCc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Best regards,
Krzysztof
RE: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 26 lines · Krzysztof Kozlowski
Quoted 24 lines · Kukjin Kim
Quoted 23 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 21 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin
RE: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Is patch 4 going out for 4.2 or 4.3?
Regards,
Mike
Quoted 5 lines
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 40 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Quoted 7 lines
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd
Best regards,
Krzysztof
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980
Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.html
Quoted 7 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd
Best regards,
Krzysztof
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
In reply to Krzysztof KozlowskiHi,
Quoted 49 lines · Krzysztof Kozlowski
Quoted 40 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Quoted 7 lines
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Is patch 4 going out for 4.2 or 4.3?
Quoted 7 lines
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Taking all patches together would be a preferred solution from my POV.
It would also be great if it could happen in v4.2 (all code changes are practically limited to our Exynos4210 platform so I hope that it should be fine) as it would be easier to work on Exynos4x12, Exynos5250 and Exynos542x/5800 patch series.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Quoted 6 lines
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680ddBest regards,
Krzysztof
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
In reply to Krzysztof KozlowskiHi,
Quoted 48 lines · Krzysztof Kozlowski
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 16 lines
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.htmlQuoted 7 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd
This patch is needed for v4.2 as other changes has been already merged.
Krzysztof/Kukjin, could you please take care of it?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 65 lines
Hi,
Quoted 61 lines · Krzysztof Kozlowski
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.htmlQuoted 4 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680ddThis patch is needed for v4.2 as other changes has been already merged.
Krzysztof/Kukjin, could you please take care of it?
Of course! It is already in my queue. I'll send it later to Kukjin for 4.3 (unless he picks it also).
BTW for other patchsets you still need acks from Samsung clock maintainers. Did you poke Sylwester or Tomasz about it?
Best regards,
Krzysztof
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 70 lines · Krzysztof Kozlowski
2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 69 lines
Hi,
Quoted 64 lines · Krzysztof Kozlowski
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.htmlQuoted 7 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680dd
Quoted 7 lines
Quoted 4 lines
This patch is needed for v4.2 as other changes has been already merged.
Krzysztof/Kukjin, could you please take care of it?
Of course! It is already in my queue. I'll send it later to Kukjin for 4.3 (unless he picks it also).
It is in your queue for v4.3 but the patch is needed for v4.2, without it cpufreq support will not work for Exynos4210 platforms.
Quoted 2 lines
BTW for other patchsets you still need acks from Samsung clock maintainers. Did you poke Sylwester or Tomasz about it?
Sylwester, please review/ack Samsung specific clock changes in Exynos5250 cpufreq and Exynos4x12 cpufreq patch series.
Patch series:
* [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
(http://lkml.org/lkml/2015/7/1/311)
* [PATCH v2 0/7] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
(http://lkml.org/lkml/2015/7/9/419)
Samsung clock specific changes:
* [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
(http://lkml.org/lkml/2015/7/1/313)
* [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data and instantiate cpu clock
(http://lkml.org/lkml/2015/7/9/424)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
2015-07-13 20:20 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 74 lines · Krzysztof Kozlowski
Quoted 73 lines
2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 72 lines
Hi,
Quoted 48 lines · Krzysztof Kozlowski
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 16 lines
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.htmlQuoted 7 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680ddThis patch is needed for v4.2 as other changes has been already merged.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Krzysztof/Kukjin, could you please take care of it?
Of course! It is already in my queue. I'll send it later to Kukjin for 4.3 (unless he picks it also).
It is in your queue for v4.3 but the patch is needed for v4.2, without it cpufreq support will not work for Exynos4210 platforms.
Hmm... it makes sense to push it during this rc-cycle to bring back crippled feature.
Best regards,
Krzysztof
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
In reply to Bartlomiej ZolnierkiewiczQuoted 98 lines · Bartlomiej Zolnierkiewicz
Quoted 70 lines · Krzysztof Kozlowski
2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 69 lines
Hi,
Quoted 64 lines · Krzysztof Kozlowski
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 9 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU regulator supply properties for migrating from Exynos specific cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowQuoted 9 lines
Cc Kukjin Kim <[email protected]>Cc Doug Anderson <[email protected]>Cc Javier Martinez Canillas <[email protected]>Cc Andreas Faerber <[email protected]>Cc Sachin Kamat <[email protected]>Cc Andreas Farber <[email protected]>Cc Javier Martinez Canillas <[email protected]>Signed-off-by Thomas Abraham <[email protected]>Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.htmlQuoted 7 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680ddQuoted 7 lines
Quoted 4 lines
This patch is needed for v4.2 as other changes has been already merged.
Krzysztof/Kukjin, could you please take care of it?
Of course! It is already in my queue. I'll send it later to Kukjin for 4.3 (unless he picks it also).
It is in your queue for v4.3 but the patch is needed for v4.2, without it cpufreq support will not work for Exynos4210 platforms.
Quoted 2 lines
BTW for other patchsets you still need acks from Samsung clock maintainers. Did you poke Sylwester or Tomasz about it?
Sylwester, please review/ack Samsung specific clock changes in Exynos5250 cpufreq and Exynos4x12 cpufreq patch series.
Patch series:
* [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
(http://lkml.org/lkml/2015/7/1/311)* [PATCH v2 0/7] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
(http://lkml.org/lkml/2015/7/9/419)Samsung clock specific changes:
Quoted 7 lines
* [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
(http://lkml.org/lkml/2015/7/1/313)* [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data and instantiate cpu clock
(http://lkml.org/lkml/2015/7/9/424)
BTW corresponding changes for Exynos4210 has already been merged and 2 above patches are quite obvious so review should be very quick & simple.
[ Unfortunately Sylwester is currently very busy with a more priority work so
it may still take some time to get his ACKs. ]
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH 4/6] ARM: dts: Exynos4210: add CPU OPP and regulator supply property
Quoted 107 lines · Bartlomiej Zolnierkiewicz
Quoted 98 lines · Bartlomiej Zolnierkiewicz
Quoted 70 lines · Krzysztof Kozlowski
2015-07-13 20:02 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 69 lines
Hi,
Quoted 64 lines · Krzysztof Kozlowski
Quoted 47 lines · Krzysztof Kozlowski
Quoted 46 lines · Michael Turquette
Quoting Kukjin Kim (2015-06-21 18:46:26)
Quoted 30 lines
Quoted 29 lines · Krzysztof Kozlowski
Quoted 27 lines · Kukjin Kim
Quoted 26 lines · Krzysztof Kozlowski
2015-05-08 9:18 GMT+09:00 Krzysztof Kozlowski <[email protected]>:
Quoted 20 lines
2015-04-04 1:43 GMT+09:00 Bartlomiej Zolnierkiewicz <[email protected]>:
Quoted 18 lines
From: Thomas Abraham <[email protected]>
For Exynos4210 platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific
cpufreq driver to using generic cpufreq driver.Changes by Bartlomiej:
- removed Exynos5250 and Exynos5420 support for nowCc: Kukjin Kim <[email protected]>
Cc: Doug Anderson <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Andreas Faerber <[email protected]>
Cc: Sachin Kamat <[email protected]>
Cc: Andreas Farber <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Signed-off-by: Thomas Abraham <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>Quoted 1 line
Rebased and applied to my tree, I'll sent it later to Kukjin unless he picks it by himself from LKML.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Hi, as far as I know, this is for v4.2 not v4.1 so it will be applied based on v4.2-rc1 after v4.2-rc1 release.
You mean it is for v4.3, not v4.2?
Oops, yes v4.3.
Thanks for the correction.
Kukjin & Krzysztof,
I'm confused on this point. I was planning to take patches 1, 2, 3, 5 and 6 towards 4.2 (e.g. in the pull request that I'll send out this week).
Quoted 5 lines
Quoted 1 line
Is patch 4 going out for 4.2 or 4.3?
It is quite late for sending pull request to arm-soc for 4.2. For example SoCFPGA pull request from last week was rejected:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/417980Oh, that was wrong link. Here it is:
http://www.spinics.net/lists/arm-kernel/msg425911.htmlQuoted 7 lines
If you want to take it for 4.2 then I am fine with it but this will cause some easy but annoying conflicts. There aren't difficult - just most of nodes in board DTS changed their place.
Example of resolution (target file after merge, with cpu nodes reordered alphabetically):
https://github.com/krzk/linux/commit/2cec3cb48abaf44848c62f1c0836b772eb4680ddQuoted 7 lines
Quoted 4 lines
This patch is needed for v4.2 as other changes has been already merged.
Krzysztof/Kukjin, could you please take care of it?
Of course! It is already in my queue. I'll send it later to Kukjin for 4.3 (unless he picks it also).
It is in your queue for v4.3 but the patch is needed for v4.2, without it cpufreq support will not work for Exynos4210 platforms.
Quoted 2 lines
BTW for other patchsets you still need acks from Samsung clock maintainers. Did you poke Sylwester or Tomasz about it?
Sylwester, please review/ack Samsung specific clock changes in Exynos5250 cpufreq and Exynos4x12 cpufreq patch series.
Patch series:
* [PATCH v3 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
(http://lkml.org/lkml/2015/7/1/311)* [PATCH v2 0/7] cpufreq: use generic cpufreq drivers for Exynos4x12 platform
(http://lkml.org/lkml/2015/7/9/419)Samsung clock specific changes:
Quoted 7 lines
* [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
(http://lkml.org/lkml/2015/7/1/313)* [PATCH v2 4/7] clk: samsung: exynos4x12: add cpu clock configuration data and instantiate cpu clock
(http://lkml.org/lkml/2015/7/9/424)
Quoted 5 lines
BTW corresponding changes for Exynos4210 has already been merged and 2 above patches are quite obvious so review should be very quick & simple.
[ Unfortunately Sylwester is currently very busy with a more priority work so
it may still take some time to get his ACKs. ]
The review would be fast and already Javier or me provided such.
Anyway if you want to merge it through different tree it would be expected to get an ack from bypassed maintainer.
Especially that the distance between you and the bypassed maintainer was ~1 meter for the most of the time :) .
It is much longer distance between you and me now!
Best regards,
Krzysztof