[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Sangbeom Kim]

This patch adds CPUFREQ for S5PV210/S5PC110.

Changes since v1:

- Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in CPUFREQ driver.
- Removed hardcoding of DRAM refresh counter.
- Added to calculate refresh counter function based on DRAM operation freq.

[PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC access
[PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
[PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
[PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
[PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
[PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting CPUFREQ driver

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Sangbeom Kim]

This patch adds CPUFREQ for S5PV210/S5PC110.

Changes since v1:

- Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in CPUFREQ driver.
- Removed hardcoding of DRAM refresh counter.
- Added to calculate refresh counter function based on DRAM operation freq.

[PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC access
[PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
[PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
[PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
[PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
[PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting CPUFREQ driver

[PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC access

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds DMC(DRAM Memory Controller) map_desc table.
Because some driver such as CPUFREQ need to access DMC register.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/cpu.c              |   10 ++++++++++
 arch/arm/mach-s5pv210/include/mach/map.h |    3 +++
 arch/arm/plat-s5p/include/plat/map-s5p.h |    2 ++
 3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c
index c551ab1..aebbb7f 100644
--- a/arch/arm/mach-s5pv210/cpu.c
+++ b/arch/arm/mach-s5pv210/cpu.c
@@ -84,6 +84,16 @@ static struct map_desc s5pv210_iodesc[] __initdata = {
 		.pfn		= __phys_to_pfn(S5PV210_PA_SROMC),
 		.length		= SZ_4K,
 		.type		= MT_DEVICE,
+	}, {
+		.virtual	= (unsigned long)S5P_VA_DMC0,
+		.pfn		= __phys_to_pfn(S5PV210_PA_DMC0),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE,
+	}, {
+		.virtual	= (unsigned long)S5P_VA_DMC1,
+		.pfn		= __phys_to_pfn(S5PV210_PA_DMC1),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE,
 	}
 };
 
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-s5pv210/include/mach/map.h
index bd9afd5..3e89c22 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -96,6 +96,9 @@
 
 #define S5PV210_PA_ADC		(0xE1700000)
 
+#define S5PV210_PA_DMC0		(0xF0000000)
+#define S5PV210_PA_DMC1		(0xF1400000)
+
 /* compatibiltiy defines. */
 #define S3C_PA_UART		S5PV210_PA_UART
 #define S3C_PA_HSMMC0		S5PV210_PA_HSMMC(0)
diff --git a/arch/arm/plat-s5p/include/plat/map-s5p.h b/arch/arm/plat-s5p/include/plat/map-s5p.h
index c4ff88b..2472894 100644
--- a/arch/arm/plat-s5p/include/plat/map-s5p.h
+++ b/arch/arm/plat-s5p/include/plat/map-s5p.h
@@ -18,6 +18,8 @@
 #define S5P_VA_SYSTIMER		S3C_ADDR(0x01200000)
 #define S5P_VA_SROMC		S3C_ADDR(0x01100000)
 #define S5P_VA_SYSRAM		S3C_ADDR(0x01180000)
+#define S5P_VA_DMC0		S3C_ADDR(0x00A00000)
+#define S5P_VA_DMC1		S3C_ADDR(0x00A80000)
 
 #define S5P_VA_COMBINER_BASE	S3C_ADDR(0x00600000)
 #define S5P_VA_COMBINER(x)	(S5P_VA_COMBINER_BASE + ((x) >> 2) * 0x10)
-- 
1.6.2.5

[PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC access

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds DMC(DRAM Memory Controller) map_desc table.
Because some driver such as CPUFREQ need to access DMC register.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/cpu.c              |   10 ++++++++++
 arch/arm/mach-s5pv210/include/mach/map.h |    3 +++
 arch/arm/plat-s5p/include/plat/map-s5p.h |    2 ++
 3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c
index c551ab1..aebbb7f 100644
--- a/arch/arm/mach-s5pv210/cpu.c
+++ b/arch/arm/mach-s5pv210/cpu.c
@@ -84,6 +84,16 @@ static struct map_desc s5pv210_iodesc[] __initdata = {
 		.pfn		= __phys_to_pfn(S5PV210_PA_SROMC),
 		.length		= SZ_4K,
 		.type		= MT_DEVICE,
+	}, {
+		.virtual	= (unsigned long)S5P_VA_DMC0,
+		.pfn		= __phys_to_pfn(S5PV210_PA_DMC0),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE,
+	}, {
+		.virtual	= (unsigned long)S5P_VA_DMC1,
+		.pfn		= __phys_to_pfn(S5PV210_PA_DMC1),
+		.length		= SZ_4K,
+		.type		= MT_DEVICE,
 	}
 };
 
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach-s5pv210/include/mach/map.h
index bd9afd5..3e89c22 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -96,6 +96,9 @@
 
 #define S5PV210_PA_ADC		(0xE1700000)
 
+#define S5PV210_PA_DMC0		(0xF0000000)
+#define S5PV210_PA_DMC1		(0xF1400000)
+
 /* compatibiltiy defines. */
 #define S3C_PA_UART		S5PV210_PA_UART
 #define S3C_PA_HSMMC0		S5PV210_PA_HSMMC(0)
diff --git a/arch/arm/plat-s5p/include/plat/map-s5p.h b/arch/arm/plat-s5p/include/plat/map-s5p.h
index c4ff88b..2472894 100644
--- a/arch/arm/plat-s5p/include/plat/map-s5p.h
+++ b/arch/arm/plat-s5p/include/plat/map-s5p.h
@@ -18,6 +18,8 @@
 #define S5P_VA_SYSTIMER		S3C_ADDR(0x01200000)
 #define S5P_VA_SROMC		S3C_ADDR(0x01100000)
 #define S5P_VA_SYSRAM		S3C_ADDR(0x01180000)
+#define S5P_VA_DMC0		S3C_ADDR(0x00A00000)
+#define S5P_VA_DMC1		S3C_ADDR(0x00A80000)
 
 #define S5P_VA_COMBINER_BASE	S3C_ADDR(0x00600000)
 #define S5P_VA_COMBINER(x)	(S5P_VA_COMBINER_BASE + ((x) >> 2) * 0x10)
-- 
1.6.2.5

[PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

Current fout_apll has fixed rate value. So CPUFREQ driver gets
incorrect value when finding current CPU frequency. Because some
operation level need to change APLL.
Added get_rate function for fout_apll can give correct frequency
value when calling get_rate function.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/clock.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index d562670..e18e098 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -31,6 +31,8 @@
 #include <plat/clock-clksrc.h>
 #include <plat/s5pv210.h>
 
+static unsigned long xtal;
+
 static struct clksrc_clk clk_mout_apll = {
 	.clk	= {
 		.name		= "mout_apll",
@@ -268,6 +270,15 @@ static struct clk_ops clk_hclk_imem_ops = {
 	.get_rate	= s5pv210_clk_imem_get_rate,
 };
 
+static unsigned long s5pv210_clk_fout_apll_get_rate(struct clk *clk)
+{
+	return s5p_get_pll45xx(xtal, __raw_readl(S5P_APLL_CON), pll_4508);
+}
+
+static struct clk_ops clk_fout_apll_ops = {
+	.get_rate	= s5pv210_clk_fout_apll_get_rate,
+};
+
 static struct clk init_clocks_disable[] = {
 	{
 		.name		= "rot",
@@ -958,7 +969,6 @@ static struct clksrc_clk *sysclks[] = {
 void __init_or_cpufreq s5pv210_setup_clocks(void)
 {
 	struct clk *xtal_clk;
-	unsigned long xtal;
 	unsigned long vpllsrc;
 	unsigned long armclk;
 	unsigned long hclk_msys;
@@ -996,7 +1006,7 @@ void __init_or_cpufreq s5pv210_setup_clocks(void)
 	vpllsrc = clk_get_rate(&clk_vpllsrc.clk);
 	vpll = s5p_get_pll45xx(vpllsrc, __raw_readl(S5P_VPLL_CON), pll_4502);
 
-	clk_fout_apll.rate = apll;
+	clk_fout_apll.ops = &clk_fout_apll_ops;
 	clk_fout_mpll.rate = mpll;
 	clk_fout_epll.rate = epll;
 	clk_fout_vpll.rate = vpll;
-- 
1.6.2.5

[PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

Current fout_apll has fixed rate value. So CPUFREQ driver gets
incorrect value when finding current CPU frequency. Because some
operation level need to change APLL.
Added get_rate function for fout_apll can give correct frequency
value when calling get_rate function.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/clock.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index d562670..e18e098 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -31,6 +31,8 @@
 #include <plat/clock-clksrc.h>
 #include <plat/s5pv210.h>
 
+static unsigned long xtal;
+
 static struct clksrc_clk clk_mout_apll = {
 	.clk	= {
 		.name		= "mout_apll",
@@ -268,6 +270,15 @@ static struct clk_ops clk_hclk_imem_ops = {
 	.get_rate	= s5pv210_clk_imem_get_rate,
 };
 
+static unsigned long s5pv210_clk_fout_apll_get_rate(struct clk *clk)
+{
+	return s5p_get_pll45xx(xtal, __raw_readl(S5P_APLL_CON), pll_4508);
+}
+
+static struct clk_ops clk_fout_apll_ops = {
+	.get_rate	= s5pv210_clk_fout_apll_get_rate,
+};
+
 static struct clk init_clocks_disable[] = {
 	{
 		.name		= "rot",
@@ -958,7 +969,6 @@ static struct clksrc_clk *sysclks[] = {
 void __init_or_cpufreq s5pv210_setup_clocks(void)
 {
 	struct clk *xtal_clk;
-	unsigned long xtal;
 	unsigned long vpllsrc;
 	unsigned long armclk;
 	unsigned long hclk_msys;
@@ -996,7 +1006,7 @@ void __init_or_cpufreq s5pv210_setup_clocks(void)
 	vpllsrc = clk_get_rate(&clk_vpllsrc.clk);
 	vpll = s5p_get_pll45xx(vpllsrc, __raw_readl(S5P_VPLL_CON), pll_4502);
 
-	clk_fout_apll.rate = apll;
+	clk_fout_apll.ops = &clk_fout_apll_ops;
 	clk_fout_mpll.rate = mpll;
 	clk_fout_epll.rate = epll;
 	clk_fout_vpll.rate = vpll;
-- 
1.6.2.5

[PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock
in CPUFREQ driver.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/clock.c |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index e18e098..1b01120 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -261,6 +261,36 @@ static struct clksrc_clk clk_sclk_vpll = {
 	.reg_src	= { .reg = S5P_CLK_SRC0, .shift = 12, .size = 1 },
 };
 
+static struct clk *clkset_moutdmc0src_list[] = {
+	[0] = &clk_sclk_a2m.clk,
+	[1] = &clk_mout_mpll.clk,
+	[2] = NULL,
+	[3] = NULL,
+};
+
+static struct clksrc_sources clkset_moutdmc0src = {
+	.sources	= clkset_moutdmc0src_list,
+	.nr_sources	= ARRAY_SIZE(clkset_moutdmc0src_list),
+};
+
+static struct clksrc_clk clk_mout_dmc0 = {
+	.clk	= {
+		.name		= "mout_dmc0",
+		.id		= -1,
+	},
+	.sources	= &clkset_moutdmc0src,
+	.reg_src	= { .reg = S5P_CLK_SRC6, .shift = 24, .size = 2 },
+};
+
+static struct clksrc_clk clk_sclk_dmc0 = {
+	.clk	= {
+		.name		= "sclk_dmc0",
+		.id		= -1,
+		.parent		= &clk_mout_dmc0.clk,
+	},
+	.reg_div	= { .reg = S5P_CLK_DIV6, .shift = 28, .size = 4 },
+};
+
 static unsigned long s5pv210_clk_imem_get_rate(struct clk *clk)
 {
 	return clk_get_rate(clk->parent) / 2;
@@ -964,6 +994,8 @@ static struct clksrc_clk *sysclks[] = {
 	&clk_sclk_dac,
 	&clk_sclk_pixel,
 	&clk_sclk_hdmi,
+	&clk_mout_dmc0,
+	&clk_sclk_dmc0,
 };
 
 void __init_or_cpufreq s5pv210_setup_clocks(void)
-- 
1.6.2.5

[PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock
in CPUFREQ driver.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/clock.c |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index e18e098..1b01120 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -261,6 +261,36 @@ static struct clksrc_clk clk_sclk_vpll = {
 	.reg_src	= { .reg = S5P_CLK_SRC0, .shift = 12, .size = 1 },
 };
 
+static struct clk *clkset_moutdmc0src_list[] = {
+	[0] = &clk_sclk_a2m.clk,
+	[1] = &clk_mout_mpll.clk,
+	[2] = NULL,
+	[3] = NULL,
+};
+
+static struct clksrc_sources clkset_moutdmc0src = {
+	.sources	= clkset_moutdmc0src_list,
+	.nr_sources	= ARRAY_SIZE(clkset_moutdmc0src_list),
+};
+
+static struct clksrc_clk clk_mout_dmc0 = {
+	.clk	= {
+		.name		= "mout_dmc0",
+		.id		= -1,
+	},
+	.sources	= &clkset_moutdmc0src,
+	.reg_src	= { .reg = S5P_CLK_SRC6, .shift = 24, .size = 2 },
+};
+
+static struct clksrc_clk clk_sclk_dmc0 = {
+	.clk	= {
+		.name		= "sclk_dmc0",
+		.id		= -1,
+		.parent		= &clk_mout_dmc0.clk,
+	},
+	.reg_div	= { .reg = S5P_CLK_DIV6, .shift = 28, .size = 4 },
+};
+
 static unsigned long s5pv210_clk_imem_get_rate(struct clk *clk)
 {
 	return clk_get_rate(clk->parent) / 2;
@@ -964,6 +994,8 @@ static struct clksrc_clk *sysclks[] = {
 	&clk_sclk_dac,
 	&clk_sclk_pixel,
 	&clk_sclk_hdmi,
+	&clk_mout_dmc0,
+	&clk_sclk_dmc0,
 };
 
 void __init_or_cpufreq s5pv210_setup_clocks(void)
-- 
1.6.2.5

[PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds some CMU(Clock Management Unit) registers for
supporting CPUFREQ and some drivers.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/include/mach/regs-clock.h |   31 ++++++++++++++++++++++-
 1 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 499aef7..336b1cf 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -67,11 +67,28 @@
 #define S5P_CLKGATE_BUS1	S5P_CLKREG(0x488)
 #define S5P_CLK_OUT		S5P_CLKREG(0x500)
 
+/* DIV/MUX STATUS */
+#define S5P_CLKDIV_STAT0	S5P_CLKREG(0x1000)
+#define S5P_CLKDIV_STAT1	S5P_CLKREG(0x1004)
+#define S5P_CLKMUX_STAT0	S5P_CLKREG(0x1100)
+#define S5P_CLKMUX_STAT1	S5P_CLKREG(0x1104)
+
 /* CLKSRC0 */
-#define S5P_CLKSRC0_MUX200_MASK		(0x1<<16)
+#define S5P_CLKSRC0_MUX200_SHIFT	(16)
+#define S5P_CLKSRC0_MUX200_MASK		(0x1 << S5P_CLKSRC0_MUX200_SHIFT)
 #define S5P_CLKSRC0_MUX166_MASK		(0x1<<20)
 #define S5P_CLKSRC0_MUX133_MASK		(0x1<<24)
 
+/* CLKSRC2 */
+#define S5P_CLKSRC2_G3D_SHIFT           (0)
+#define S5P_CLKSRC2_G3D_MASK            (0x3 << S5P_CLKSRC2_G3D_SHIFT)
+#define S5P_CLKSRC2_MFC_SHIFT           (4)
+#define S5P_CLKSRC2_MFC_MASK            (0x3 << S5P_CLKSRC2_MFC_SHIFT)
+
+/* CLKSRC6*/
+#define S5P_CLKSRC6_ONEDRAM_SHIFT       (24)
+#define S5P_CLKSRC6_ONEDRAM_MASK        (0x3 << S5P_CLKSRC6_ONEDRAM_SHIFT)
+
 /* CLKDIV0 */
 #define S5P_CLKDIV0_APLL_SHIFT		(0)
 #define S5P_CLKDIV0_APLL_MASK		(0x7 << S5P_CLKDIV0_APLL_SHIFT)
@@ -90,8 +107,20 @@
 #define S5P_CLKDIV0_PCLK66_SHIFT	(28)
 #define S5P_CLKDIV0_PCLK66_MASK		(0x7 << S5P_CLKDIV0_PCLK66_SHIFT)
 
+/* CLKDIV2 */
+#define S5P_CLKDIV2_G3D_SHIFT           (0)
+#define S5P_CLKDIV2_G3D_MASK            (0xF << S5P_CLKDIV2_G3D_SHIFT)
+#define S5P_CLKDIV2_MFC_SHIFT           (4)
+#define S5P_CLKDIV2_MFC_MASK            (0xF << S5P_CLKDIV2_MFC_SHIFT)
+
+/* CLKDIV6 */
+#define S5P_CLKDIV6_ONEDRAM_SHIFT       (28)
+#define S5P_CLKDIV6_ONEDRAM_MASK        (0xF << S5P_CLKDIV6_ONEDRAM_SHIFT)
+
 #define S5P_SWRESET		S5P_CLKREG(0x2000)
 
+#define S5P_ARM_MCS_CON		S5P_CLKREG(0x6100)
+
 /* Registers related to power management */
 #define S5P_PWR_CFG		S5P_CLKREG(0xC000)
 #define S5P_EINT_WAKEUP_MASK	S5P_CLKREG(0xC004)
-- 
1.6.2.5

[PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds some CMU(Clock Management Unit) registers for
supporting CPUFREQ and some drivers.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/mach-s5pv210/include/mach/regs-clock.h |   31 ++++++++++++++++++++++-
 1 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 499aef7..336b1cf 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -67,11 +67,28 @@
 #define S5P_CLKGATE_BUS1	S5P_CLKREG(0x488)
 #define S5P_CLK_OUT		S5P_CLKREG(0x500)
 
+/* DIV/MUX STATUS */
+#define S5P_CLKDIV_STAT0	S5P_CLKREG(0x1000)
+#define S5P_CLKDIV_STAT1	S5P_CLKREG(0x1004)
+#define S5P_CLKMUX_STAT0	S5P_CLKREG(0x1100)
+#define S5P_CLKMUX_STAT1	S5P_CLKREG(0x1104)
+
 /* CLKSRC0 */
-#define S5P_CLKSRC0_MUX200_MASK		(0x1<<16)
+#define S5P_CLKSRC0_MUX200_SHIFT	(16)
+#define S5P_CLKSRC0_MUX200_MASK		(0x1 << S5P_CLKSRC0_MUX200_SHIFT)
 #define S5P_CLKSRC0_MUX166_MASK		(0x1<<20)
 #define S5P_CLKSRC0_MUX133_MASK		(0x1<<24)
 
+/* CLKSRC2 */
+#define S5P_CLKSRC2_G3D_SHIFT           (0)
+#define S5P_CLKSRC2_G3D_MASK            (0x3 << S5P_CLKSRC2_G3D_SHIFT)
+#define S5P_CLKSRC2_MFC_SHIFT           (4)
+#define S5P_CLKSRC2_MFC_MASK            (0x3 << S5P_CLKSRC2_MFC_SHIFT)
+
+/* CLKSRC6*/
+#define S5P_CLKSRC6_ONEDRAM_SHIFT       (24)
+#define S5P_CLKSRC6_ONEDRAM_MASK        (0x3 << S5P_CLKSRC6_ONEDRAM_SHIFT)
+
 /* CLKDIV0 */
 #define S5P_CLKDIV0_APLL_SHIFT		(0)
 #define S5P_CLKDIV0_APLL_MASK		(0x7 << S5P_CLKDIV0_APLL_SHIFT)
@@ -90,8 +107,20 @@
 #define S5P_CLKDIV0_PCLK66_SHIFT	(28)
 #define S5P_CLKDIV0_PCLK66_MASK		(0x7 << S5P_CLKDIV0_PCLK66_SHIFT)
 
+/* CLKDIV2 */
+#define S5P_CLKDIV2_G3D_SHIFT           (0)
+#define S5P_CLKDIV2_G3D_MASK            (0xF << S5P_CLKDIV2_G3D_SHIFT)
+#define S5P_CLKDIV2_MFC_SHIFT           (4)
+#define S5P_CLKDIV2_MFC_MASK            (0xF << S5P_CLKDIV2_MFC_SHIFT)
+
+/* CLKDIV6 */
+#define S5P_CLKDIV6_ONEDRAM_SHIFT       (28)
+#define S5P_CLKDIV6_ONEDRAM_MASK        (0xF << S5P_CLKDIV6_ONEDRAM_SHIFT)
+
 #define S5P_SWRESET		S5P_CLKREG(0x2000)
 
+#define S5P_ARM_MCS_CON		S5P_CLKREG(0x6100)
+
 /* Registers related to power management */
 #define S5P_PWR_CFG		S5P_CLKREG(0xC000)
 #define S5P_EINT_WAKEUP_MASK	S5P_CLKREG(0xC004)
-- 
1.6.2.5

[PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds CPUFREQ driver for supporting DFS(Dynamic Frequency Scaling).

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
Changes since v1:
- Removed hardcoding of DRAM refresh counter
- Added to calculate refresh counter function based on DRAM operation freq.

 arch/arm/mach-s5pv210/cpufreq.c |  484 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 484 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-s5pv210/cpufreq.c

diff --git a/arch/arm/mach-s5pv210/cpufreq.c b/arch/arm/mach-s5pv210/cpufreq.c
new file mode 100644
index 0000000..465ffe6
--- /dev/null
+++ b/arch/arm/mach-s5pv210/cpufreq.c
@@ -0,0 +1,484 @@
+/* linux/arch/arm/mach-s5pv210/cpufreq.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * CPU frequency scaling for S5PC110/S5PV210
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/cpufreq.h>
+
+#include <mach/map.h>
+#include <mach/regs-clock.h>
+
+static struct clk *cpu_clk;
+static struct clk *dmc0_clk;
+static struct clk *dmc1_clk;
+static struct cpufreq_freqs freqs;
+
+/* APLL M,P,S values for 1G/800Mhz */
+#define APLL_VAL_1000	((1 << 31) | (125 << 16) | (3 << 8) | 1)
+#define APLL_VAL_800	((1 << 31) | (100 << 16) | (3 << 8) | 1)
+
+/*
+ * DRAM configurations to calculate refresh counter for changing
+ * frequency of memory.
+ */
+struct dram_conf {
+	unsigned long freq;	/* HZ */
+	unsigned long refresh;	/* DRAM refresh counter * 1000 */
+};
+
+/* DRAM configuration (DMC0 and DMC1) */
+static struct dram_conf s5pv210_dram_conf[2];
+
+enum perf_level {
+	L0, L1, L2, L3, L4,
+};
+
+enum s5pv210_mem_type {
+	LPDDR	= 0x1,
+	LPDDR2	= 0x2,
+	DDR2	= 0x4,
+};
+
+enum s5pv210_dmc_port {
+	DMC0 = 0,
+	DMC1,
+};
+
+static struct cpufreq_frequency_table s5pv210_freq_table[] = {
+	{L0, 1000*1000},
+	{L1, 800*1000},
+	{L2, 400*1000},
+	{L3, 200*1000},
+	{L4, 100*1000},
+	{0, CPUFREQ_TABLE_END},
+};
+
+static u32 clkdiv_val[5][11] = {
+	/*
+	 * Clock divider value for following
+	 * { APLL, A2M, HCLK_MSYS, PCLK_MSYS,
+	 *   HCLK_DSYS, PCLK_DSYS, HCLK_PSYS, PCLK_PSYS,
+	 *   ONEDRAM, MFC, G3D }
+	 */
+
+	/* L0 : [1000/200/100][166/83][133/66][200/200] */
+	{0, 4, 4, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L1 : [800/200/100][166/83][133/66][200/200] */
+	{0, 3, 3, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L2 : [400/200/100][166/83][133/66][200/200] */
+	{1, 3, 1, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L3 : [200/200/100][166/83][133/66][200/200] */
+	{3, 3, 1, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L4 : [100/100/100][83/83][66/66][100/100] */
+	{7, 7, 0, 0, 7, 0, 9, 0, 7, 0, 0},
+};
+
+/*
+ * This function set DRAM refresh counter
+ * accoriding to operating frequency of DRAM
+ * ch: DMC port number 0 or 1
+ * freq: Operating frequency of DRAM(KHz)
+ */
+static void s5pv210_set_refresh(enum s5pv210_dmc_port ch, unsigned long freq)
+{
+	unsigned long tmp, tmp1;
+	void __iomem *reg = NULL;
+
+	if (ch == DMC0)
+		reg = (S5P_VA_DMC0 + 0x30);
+	else if (ch == DMC1)
+		reg = (S5P_VA_DMC1 + 0x30);
+	else
+		printk(KERN_ERR "Cannot find DMC port\n");
+
+	/* Find current DRAM frequency */
+	tmp = s5pv210_dram_conf[ch].freq;
+
+	do_div(tmp, freq);
+
+	tmp1 = s5pv210_dram_conf[ch].refresh;
+
+	do_div(tmp1, tmp);
+
+	__raw_writel(tmp1, reg);
+}
+
+int s5pv210_verify_speed(struct cpufreq_policy *policy)
+{
+	if (policy->cpu)
+		return -EINVAL;
+
+	return cpufreq_frequency_table_verify(policy, s5pv210_freq_table);
+}
+
+unsigned int s5pv210_getspeed(unsigned int cpu)
+{
+	if (cpu)
+		return 0;
+
+	return clk_get_rate(cpu_clk) / 1000;
+}
+
+static int s5pv210_target(struct cpufreq_policy *policy,
+		          unsigned int target_freq,
+		          unsigned int relation)
+{
+	unsigned long reg;
+	unsigned int index, priv_index;
+	unsigned int pll_changing = 0;
+	unsigned int bus_speed_changing = 0;
+
+	freqs.old = s5pv210_getspeed(0);
+
+	if (cpufreq_frequency_table_target(policy, s5pv210_freq_table,
+					   target_freq, relation, &index))
+		return -EINVAL;
+
+	freqs.new = s5pv210_freq_table[index].frequency;
+	freqs.cpu = 0;
+
+	if (freqs.new == freqs.old)
+		return 0;
+
+	/* Finding current running level index */
+	if (cpufreq_frequency_table_target(policy, s5pv210_freq_table,
+					   freqs.old, relation, &priv_index))
+		return -EINVAL;
+
+	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
+	if (freqs.new > freqs.old) {
+		/* Voltage up: will be implemented */
+	}
+
+	/* Check if there need to change PLL */
+	if ((index == L0) || (priv_index == L0))
+		pll_changing = 1;
+
+	/* Check if there need to change System bus clock */
+	if ((index == L4) || (priv_index == L4))
+		bus_speed_changing = 1;
+
+	if (bus_speed_changing) {
+		/*
+		 * Reconfigure DRAM refresh counter value for minimum
+		 * temporary clock while changing divider.
+		 * expected clock is 83Mhz : 7.8usec/(1/83Mhz) = 0x287
+		 */
+		if (pll_changing)
+			s5pv210_set_refresh(DMC1, 83000);
+		else
+			s5pv210_set_refresh(DMC1, 100000);
+
+		s5pv210_set_refresh(DMC0, 83000);
+	}
+
+	/*
+	 * APLL should be changed in this level
+	 * APLL -> MPLL(for stable transition) -> APLL
+	 * Some clock source's clock API are not prepared.
+	 * Do not use clock API in below code.
+	 */
+	if (pll_changing) {
+		/*
+		 * 1. Temporary Change divider for MFC and G3D
+		 * SCLKA2M(200/1=200)->(200/4=50)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_DIV2);
+		reg &= ~(S5P_CLKDIV2_G3D_MASK | S5P_CLKDIV2_MFC_MASK);
+		reg |= (3 << S5P_CLKDIV2_G3D_SHIFT) |
+			(3 << S5P_CLKDIV2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_DIV2);
+
+		/* For MFC, G3D dividing */
+		do {
+			reg = __raw_readl(S5P_CLKDIV_STAT0);
+		} while (reg & ((1 << 16) | (1 << 17)));
+
+		/*
+		 * 2. Change SCLKA2M(200Mhz)to SCLKMPLL in MFC_MUX, G3D MUX
+		 * (200/4=50)->(667/4=166)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_SRC2);
+		reg &= ~(S5P_CLKSRC2_G3D_MASK | S5P_CLKSRC2_MFC_MASK);
+		reg |= (1 << S5P_CLKSRC2_G3D_SHIFT) |
+			(1 << S5P_CLKSRC2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC2);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT1);
+		} while (reg & ((1 << 7) | (1 << 3)));
+
+		/*
+		 * 3. DMC1 refresh count for 133Mhz if (index == L4) is
+		 * true refresh counter is already programed in upper
+		 * code. 0x287@83Mhz
+		 */
+		if (!bus_speed_changing)
+			s5pv210_set_refresh(DMC1, 133000);
+
+		/* 4. SCLKAPLL -> SCLKMPLL */
+		reg = __raw_readl(S5P_CLK_SRC0);
+		reg &= ~(S5P_CLKSRC0_MUX200_MASK);
+		reg |= (0x1 << S5P_CLKSRC0_MUX200_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC0);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT0);
+		} while (reg & (0x1 << 18));
+
+	}
+
+	/* Change divider */
+	reg = __raw_readl(S5P_CLK_DIV0);
+
+	reg &= ~(S5P_CLKDIV0_APLL_MASK | S5P_CLKDIV0_A2M_MASK |
+		S5P_CLKDIV0_HCLK200_MASK | S5P_CLKDIV0_PCLK100_MASK |
+		S5P_CLKDIV0_HCLK166_MASK | S5P_CLKDIV0_PCLK83_MASK |
+		S5P_CLKDIV0_HCLK133_MASK | S5P_CLKDIV0_PCLK66_MASK);
+
+	reg |= ((clkdiv_val[index][0] << S5P_CLKDIV0_APLL_SHIFT) |
+		(clkdiv_val[index][1] << S5P_CLKDIV0_A2M_SHIFT) |
+		(clkdiv_val[index][2] << S5P_CLKDIV0_HCLK200_SHIFT) |
+		(clkdiv_val[index][3] << S5P_CLKDIV0_PCLK100_SHIFT) |
+		(clkdiv_val[index][4] << S5P_CLKDIV0_HCLK166_SHIFT) |
+		(clkdiv_val[index][5] << S5P_CLKDIV0_PCLK83_SHIFT) |
+		(clkdiv_val[index][6] << S5P_CLKDIV0_HCLK133_SHIFT) |
+		(clkdiv_val[index][7] << S5P_CLKDIV0_PCLK66_SHIFT));
+
+	__raw_writel(reg, S5P_CLK_DIV0);
+
+	do {
+		reg = __raw_readl(S5P_CLKDIV_STAT0);
+	} while (reg & 0xff);
+
+	/* ARM MCS value changed */
+	reg = __raw_readl(S5P_ARM_MCS_CON);
+	reg &= ~0x3;
+	if (index >= L3)
+		reg |= 0x3;
+	else
+		reg |= 0x1;
+
+	__raw_writel(reg, S5P_ARM_MCS_CON);
+
+	if (pll_changing) {
+		/* 5. Set Lock time = 30us*24Mhz = 0x2cf */
+		__raw_writel(0x2cf, S5P_APLL_LOCK);
+
+		/*
+		 * 6. Turn on APLL
+		 * 6-1. Set PMS values
+		 * 6-2. Wait untile the PLL is locked
+		 */
+		if (index == L0)
+			__raw_writel(APLL_VAL_1000, S5P_APLL_CON);
+		else
+			__raw_writel(APLL_VAL_800, S5P_APLL_CON);
+
+		do {
+			reg = __raw_readl(S5P_APLL_CON);
+		} while (!(reg & (0x1 << 29)));
+
+		/*
+		 * 7. Change souce clock from SCLKMPLL(667Mhz)
+		 * to SCLKA2M(200Mhz) in MFC_MUX and G3D MUX
+		 * (667/4=166)->(200/4=50)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_SRC2);
+		reg &= ~(S5P_CLKSRC2_G3D_MASK | S5P_CLKSRC2_MFC_MASK);
+		reg |= (0 << S5P_CLKSRC2_G3D_SHIFT) |
+			(0 << S5P_CLKSRC2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC2);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT1);
+		} while (reg & ((1 << 7) | (1 << 3)));
+
+		/*
+		 * 8. Change divider for MFC and G3D
+		 * (200/4=50)->(200/1=200)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_DIV2);
+		reg &= ~(S5P_CLKDIV2_G3D_MASK | S5P_CLKDIV2_MFC_MASK);
+		reg |= (clkdiv_val[index][10] << S5P_CLKDIV2_G3D_SHIFT) |
+			(clkdiv_val[index][9] << S5P_CLKDIV2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_DIV2);
+
+		/* For MFC, G3D dividing */
+		do {
+			reg = __raw_readl(S5P_CLKDIV_STAT0);
+		} while (reg & ((1 << 16) | (1 << 17)));
+
+		/* 9. Change MPLL to APLL in MSYS_MUX */
+		reg = __raw_readl(S5P_CLK_SRC0);
+		reg &= ~(S5P_CLKSRC0_MUX200_MASK);
+		reg |= (0x0 << S5P_CLKSRC0_MUX200_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC0);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT0);
+		} while (reg & (0x1 << 18));
+
+		/*
+		 * 10. DMC1 refresh counter
+		 * L4 : DMC1 = 100Mhz 7.8us/(1/100) = 0x30c
+		 * Others : DMC1 = 200Mhz 7.8us/(1/200) = 0x618
+		 */
+		if (!bus_speed_changing)
+			s5pv210_set_refresh(DMC1, 200000);
+	}
+
+	/*
+	 * L4 level need to change memory bus speed, hence onedram clock divier
+	 * and memory refresh parameter should be changed
+	 */
+	if (bus_speed_changing) {
+		reg = __raw_readl(S5P_CLK_DIV6);
+		reg &= ~S5P_CLKDIV6_ONEDRAM_MASK;
+		reg |= (clkdiv_val[index][8] << S5P_CLKDIV6_ONEDRAM_SHIFT);
+		__raw_writel(reg, S5P_CLK_DIV6);
+
+		do {
+			reg = __raw_readl(S5P_CLKDIV_STAT1);
+		} while (reg & (1 << 15));
+
+		/* Reconfigure DRAM refresh counter value */
+		if (index != L4) {
+			/*
+			 * DMC0 : 166Mhz
+			 * DMC1 : 200Mhz
+			 */
+			s5pv210_set_refresh(DMC0, 166000);
+			s5pv210_set_refresh(DMC1, 200000);
+		} else {
+			/*
+			 * DMC0 : 83Mhz
+			 * DMC1 : 100Mhz
+			 */
+			s5pv210_set_refresh(DMC0, 83000);
+			s5pv210_set_refresh(DMC1, 100000);
+		}
+	}
+
+	if (freqs.new < freqs.old) {
+		/* Voltage down: will be implemented */
+	}
+
+	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+	printk(KERN_DEBUG "Perf changed[L%d]\n", index);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int s5pv210_cpufreq_suspend(struct cpufreq_policy *policy,
+				   pm_message_t pmsg)
+{
+	return 0;
+}
+
+static int s5pv210_cpufreq_resume(struct cpufreq_policy *policy)
+{
+	return 0;
+}
+#endif
+
+static int check_mem_type(void __iomem *dmc_reg)
+{
+	unsigned long val;
+
+	val = __raw_readl(dmc_reg + 0x4);
+	val = (val & (0xf << 8));
+
+	return val >> 8;
+}
+
+static int __init s5pv210_cpu_init(struct cpufreq_policy *policy)
+{
+	unsigned long mem_type;
+
+	cpu_clk = clk_get(NULL, "armclk");
+	if (IS_ERR(cpu_clk))
+		return PTR_ERR(cpu_clk);
+
+	dmc0_clk = clk_get(NULL, "sclk_dmc0");
+	if (IS_ERR(dmc0_clk)) {
+		clk_put(cpu_clk);
+		return PTR_ERR(dmc0_clk);
+	}
+
+	dmc1_clk = clk_get(NULL, "hclk_msys");
+	if (IS_ERR(dmc1_clk)) {
+		clk_put(dmc0_clk);
+		clk_put(cpu_clk);
+		return PTR_ERR(dmc1_clk);
+	}
+
+	if (policy->cpu != 0)
+		return -EINVAL;
+
+	/*
+	 * check_mem_type : This driver only support LPDDR & LPDDR2.
+	 * other memory type is not supported.
+	 */
+	mem_type = check_mem_type(S5P_VA_DMC0);
+
+	if ((mem_type != LPDDR) && (mem_type != LPDDR2)) {
+		printk(KERN_ERR "CPUFreq doesn't support this memory type\n");
+		return -EINVAL;
+	}
+
+	/* Find current refresh counter and frequency each DMC */
+	s5pv210_dram_conf[0].refresh = (__raw_readl(S5P_VA_DMC0 + 0x30) * 1000);
+	s5pv210_dram_conf[0].freq = clk_get_rate(dmc0_clk);
+
+	s5pv210_dram_conf[1].refresh = (__raw_readl(S5P_VA_DMC1 + 0x30) * 1000);
+	s5pv210_dram_conf[1].freq = clk_get_rate(dmc1_clk);
+
+	policy->cur = policy->min = policy->max = s5pv210_getspeed(0);
+
+	cpufreq_frequency_table_get_attr(s5pv210_freq_table, policy->cpu);
+
+	policy->cpuinfo.transition_latency = 40000;
+
+	return cpufreq_frequency_table_cpuinfo(policy, s5pv210_freq_table);
+}
+
+static struct cpufreq_driver s5pv210_driver = {
+	.flags		= CPUFREQ_STICKY,
+	.verify		= s5pv210_verify_speed,
+	.target		= s5pv210_target,
+	.get		= s5pv210_getspeed,
+	.init		= s5pv210_cpu_init,
+	.name		= "s5pv210",
+#ifdef CONFIG_PM
+	.suspend	= s5pv210_cpufreq_suspend,
+	.resume		= s5pv210_cpufreq_resume,
+#endif
+};
+
+static int __init s5pv210_cpufreq_init(void)
+{
+	return cpufreq_register_driver(&s5pv210_driver);
+}
+
+late_initcall(s5pv210_cpufreq_init);
-- 
1.6.2.5

[PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds CPUFREQ driver for supporting DFS(Dynamic Frequency Scaling).

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
Changes since v1:
- Removed hardcoding of DRAM refresh counter
- Added to calculate refresh counter function based on DRAM operation freq.

 arch/arm/mach-s5pv210/cpufreq.c |  484 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 484 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-s5pv210/cpufreq.c

diff --git a/arch/arm/mach-s5pv210/cpufreq.c b/arch/arm/mach-s5pv210/cpufreq.c
new file mode 100644
index 0000000..465ffe6
--- /dev/null
+++ b/arch/arm/mach-s5pv210/cpufreq.c
@@ -0,0 +1,484 @@
+/* linux/arch/arm/mach-s5pv210/cpufreq.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * CPU frequency scaling for S5PC110/S5PV210
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/cpufreq.h>
+
+#include <mach/map.h>
+#include <mach/regs-clock.h>
+
+static struct clk *cpu_clk;
+static struct clk *dmc0_clk;
+static struct clk *dmc1_clk;
+static struct cpufreq_freqs freqs;
+
+/* APLL M,P,S values for 1G/800Mhz */
+#define APLL_VAL_1000	((1 << 31) | (125 << 16) | (3 << 8) | 1)
+#define APLL_VAL_800	((1 << 31) | (100 << 16) | (3 << 8) | 1)
+
+/*
+ * DRAM configurations to calculate refresh counter for changing
+ * frequency of memory.
+ */
+struct dram_conf {
+	unsigned long freq;	/* HZ */
+	unsigned long refresh;	/* DRAM refresh counter * 1000 */
+};
+
+/* DRAM configuration (DMC0 and DMC1) */
+static struct dram_conf s5pv210_dram_conf[2];
+
+enum perf_level {
+	L0, L1, L2, L3, L4,
+};
+
+enum s5pv210_mem_type {
+	LPDDR	= 0x1,
+	LPDDR2	= 0x2,
+	DDR2	= 0x4,
+};
+
+enum s5pv210_dmc_port {
+	DMC0 = 0,
+	DMC1,
+};
+
+static struct cpufreq_frequency_table s5pv210_freq_table[] = {
+	{L0, 1000*1000},
+	{L1, 800*1000},
+	{L2, 400*1000},
+	{L3, 200*1000},
+	{L4, 100*1000},
+	{0, CPUFREQ_TABLE_END},
+};
+
+static u32 clkdiv_val[5][11] = {
+	/*
+	 * Clock divider value for following
+	 * { APLL, A2M, HCLK_MSYS, PCLK_MSYS,
+	 *   HCLK_DSYS, PCLK_DSYS, HCLK_PSYS, PCLK_PSYS,
+	 *   ONEDRAM, MFC, G3D }
+	 */
+
+	/* L0 : [1000/200/100][166/83][133/66][200/200] */
+	{0, 4, 4, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L1 : [800/200/100][166/83][133/66][200/200] */
+	{0, 3, 3, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L2 : [400/200/100][166/83][133/66][200/200] */
+	{1, 3, 1, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L3 : [200/200/100][166/83][133/66][200/200] */
+	{3, 3, 1, 1, 3, 1, 4, 1, 3, 0, 0},
+
+	/* L4 : [100/100/100][83/83][66/66][100/100] */
+	{7, 7, 0, 0, 7, 0, 9, 0, 7, 0, 0},
+};
+
+/*
+ * This function set DRAM refresh counter
+ * accoriding to operating frequency of DRAM
+ * ch: DMC port number 0 or 1
+ * freq: Operating frequency of DRAM(KHz)
+ */
+static void s5pv210_set_refresh(enum s5pv210_dmc_port ch, unsigned long freq)
+{
+	unsigned long tmp, tmp1;
+	void __iomem *reg = NULL;
+
+	if (ch == DMC0)
+		reg = (S5P_VA_DMC0 + 0x30);
+	else if (ch == DMC1)
+		reg = (S5P_VA_DMC1 + 0x30);
+	else
+		printk(KERN_ERR "Cannot find DMC port\n");
+
+	/* Find current DRAM frequency */
+	tmp = s5pv210_dram_conf[ch].freq;
+
+	do_div(tmp, freq);
+
+	tmp1 = s5pv210_dram_conf[ch].refresh;
+
+	do_div(tmp1, tmp);
+
+	__raw_writel(tmp1, reg);
+}
+
+int s5pv210_verify_speed(struct cpufreq_policy *policy)
+{
+	if (policy->cpu)
+		return -EINVAL;
+
+	return cpufreq_frequency_table_verify(policy, s5pv210_freq_table);
+}
+
+unsigned int s5pv210_getspeed(unsigned int cpu)
+{
+	if (cpu)
+		return 0;
+
+	return clk_get_rate(cpu_clk) / 1000;
+}
+
+static int s5pv210_target(struct cpufreq_policy *policy,
+		          unsigned int target_freq,
+		          unsigned int relation)
+{
+	unsigned long reg;
+	unsigned int index, priv_index;
+	unsigned int pll_changing = 0;
+	unsigned int bus_speed_changing = 0;
+
+	freqs.old = s5pv210_getspeed(0);
+
+	if (cpufreq_frequency_table_target(policy, s5pv210_freq_table,
+					   target_freq, relation, &index))
+		return -EINVAL;
+
+	freqs.new = s5pv210_freq_table[index].frequency;
+	freqs.cpu = 0;
+
+	if (freqs.new == freqs.old)
+		return 0;
+
+	/* Finding current running level index */
+	if (cpufreq_frequency_table_target(policy, s5pv210_freq_table,
+					   freqs.old, relation, &priv_index))
+		return -EINVAL;
+
+	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
+	if (freqs.new > freqs.old) {
+		/* Voltage up: will be implemented */
+	}
+
+	/* Check if there need to change PLL */
+	if ((index == L0) || (priv_index == L0))
+		pll_changing = 1;
+
+	/* Check if there need to change System bus clock */
+	if ((index == L4) || (priv_index == L4))
+		bus_speed_changing = 1;
+
+	if (bus_speed_changing) {
+		/*
+		 * Reconfigure DRAM refresh counter value for minimum
+		 * temporary clock while changing divider.
+		 * expected clock is 83Mhz : 7.8usec/(1/83Mhz) = 0x287
+		 */
+		if (pll_changing)
+			s5pv210_set_refresh(DMC1, 83000);
+		else
+			s5pv210_set_refresh(DMC1, 100000);
+
+		s5pv210_set_refresh(DMC0, 83000);
+	}
+
+	/*
+	 * APLL should be changed in this level
+	 * APLL -> MPLL(for stable transition) -> APLL
+	 * Some clock source's clock API are not prepared.
+	 * Do not use clock API in below code.
+	 */
+	if (pll_changing) {
+		/*
+		 * 1. Temporary Change divider for MFC and G3D
+		 * SCLKA2M(200/1=200)->(200/4=50)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_DIV2);
+		reg &= ~(S5P_CLKDIV2_G3D_MASK | S5P_CLKDIV2_MFC_MASK);
+		reg |= (3 << S5P_CLKDIV2_G3D_SHIFT) |
+			(3 << S5P_CLKDIV2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_DIV2);
+
+		/* For MFC, G3D dividing */
+		do {
+			reg = __raw_readl(S5P_CLKDIV_STAT0);
+		} while (reg & ((1 << 16) | (1 << 17)));
+
+		/*
+		 * 2. Change SCLKA2M(200Mhz)to SCLKMPLL in MFC_MUX, G3D MUX
+		 * (200/4=50)->(667/4=166)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_SRC2);
+		reg &= ~(S5P_CLKSRC2_G3D_MASK | S5P_CLKSRC2_MFC_MASK);
+		reg |= (1 << S5P_CLKSRC2_G3D_SHIFT) |
+			(1 << S5P_CLKSRC2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC2);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT1);
+		} while (reg & ((1 << 7) | (1 << 3)));
+
+		/*
+		 * 3. DMC1 refresh count for 133Mhz if (index == L4) is
+		 * true refresh counter is already programed in upper
+		 * code. 0x287@83Mhz
+		 */
+		if (!bus_speed_changing)
+			s5pv210_set_refresh(DMC1, 133000);
+
+		/* 4. SCLKAPLL -> SCLKMPLL */
+		reg = __raw_readl(S5P_CLK_SRC0);
+		reg &= ~(S5P_CLKSRC0_MUX200_MASK);
+		reg |= (0x1 << S5P_CLKSRC0_MUX200_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC0);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT0);
+		} while (reg & (0x1 << 18));
+
+	}
+
+	/* Change divider */
+	reg = __raw_readl(S5P_CLK_DIV0);
+
+	reg &= ~(S5P_CLKDIV0_APLL_MASK | S5P_CLKDIV0_A2M_MASK |
+		S5P_CLKDIV0_HCLK200_MASK | S5P_CLKDIV0_PCLK100_MASK |
+		S5P_CLKDIV0_HCLK166_MASK | S5P_CLKDIV0_PCLK83_MASK |
+		S5P_CLKDIV0_HCLK133_MASK | S5P_CLKDIV0_PCLK66_MASK);
+
+	reg |= ((clkdiv_val[index][0] << S5P_CLKDIV0_APLL_SHIFT) |
+		(clkdiv_val[index][1] << S5P_CLKDIV0_A2M_SHIFT) |
+		(clkdiv_val[index][2] << S5P_CLKDIV0_HCLK200_SHIFT) |
+		(clkdiv_val[index][3] << S5P_CLKDIV0_PCLK100_SHIFT) |
+		(clkdiv_val[index][4] << S5P_CLKDIV0_HCLK166_SHIFT) |
+		(clkdiv_val[index][5] << S5P_CLKDIV0_PCLK83_SHIFT) |
+		(clkdiv_val[index][6] << S5P_CLKDIV0_HCLK133_SHIFT) |
+		(clkdiv_val[index][7] << S5P_CLKDIV0_PCLK66_SHIFT));
+
+	__raw_writel(reg, S5P_CLK_DIV0);
+
+	do {
+		reg = __raw_readl(S5P_CLKDIV_STAT0);
+	} while (reg & 0xff);
+
+	/* ARM MCS value changed */
+	reg = __raw_readl(S5P_ARM_MCS_CON);
+	reg &= ~0x3;
+	if (index >= L3)
+		reg |= 0x3;
+	else
+		reg |= 0x1;
+
+	__raw_writel(reg, S5P_ARM_MCS_CON);
+
+	if (pll_changing) {
+		/* 5. Set Lock time = 30us*24Mhz = 0x2cf */
+		__raw_writel(0x2cf, S5P_APLL_LOCK);
+
+		/*
+		 * 6. Turn on APLL
+		 * 6-1. Set PMS values
+		 * 6-2. Wait untile the PLL is locked
+		 */
+		if (index == L0)
+			__raw_writel(APLL_VAL_1000, S5P_APLL_CON);
+		else
+			__raw_writel(APLL_VAL_800, S5P_APLL_CON);
+
+		do {
+			reg = __raw_readl(S5P_APLL_CON);
+		} while (!(reg & (0x1 << 29)));
+
+		/*
+		 * 7. Change souce clock from SCLKMPLL(667Mhz)
+		 * to SCLKA2M(200Mhz) in MFC_MUX and G3D MUX
+		 * (667/4=166)->(200/4=50)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_SRC2);
+		reg &= ~(S5P_CLKSRC2_G3D_MASK | S5P_CLKSRC2_MFC_MASK);
+		reg |= (0 << S5P_CLKSRC2_G3D_SHIFT) |
+			(0 << S5P_CLKSRC2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC2);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT1);
+		} while (reg & ((1 << 7) | (1 << 3)));
+
+		/*
+		 * 8. Change divider for MFC and G3D
+		 * (200/4=50)->(200/1=200)Mhz
+		 */
+		reg = __raw_readl(S5P_CLK_DIV2);
+		reg &= ~(S5P_CLKDIV2_G3D_MASK | S5P_CLKDIV2_MFC_MASK);
+		reg |= (clkdiv_val[index][10] << S5P_CLKDIV2_G3D_SHIFT) |
+			(clkdiv_val[index][9] << S5P_CLKDIV2_MFC_SHIFT);
+		__raw_writel(reg, S5P_CLK_DIV2);
+
+		/* For MFC, G3D dividing */
+		do {
+			reg = __raw_readl(S5P_CLKDIV_STAT0);
+		} while (reg & ((1 << 16) | (1 << 17)));
+
+		/* 9. Change MPLL to APLL in MSYS_MUX */
+		reg = __raw_readl(S5P_CLK_SRC0);
+		reg &= ~(S5P_CLKSRC0_MUX200_MASK);
+		reg |= (0x0 << S5P_CLKSRC0_MUX200_SHIFT);
+		__raw_writel(reg, S5P_CLK_SRC0);
+
+		do {
+			reg = __raw_readl(S5P_CLKMUX_STAT0);
+		} while (reg & (0x1 << 18));
+
+		/*
+		 * 10. DMC1 refresh counter
+		 * L4 : DMC1 = 100Mhz 7.8us/(1/100) = 0x30c
+		 * Others : DMC1 = 200Mhz 7.8us/(1/200) = 0x618
+		 */
+		if (!bus_speed_changing)
+			s5pv210_set_refresh(DMC1, 200000);
+	}
+
+	/*
+	 * L4 level need to change memory bus speed, hence onedram clock divier
+	 * and memory refresh parameter should be changed
+	 */
+	if (bus_speed_changing) {
+		reg = __raw_readl(S5P_CLK_DIV6);
+		reg &= ~S5P_CLKDIV6_ONEDRAM_MASK;
+		reg |= (clkdiv_val[index][8] << S5P_CLKDIV6_ONEDRAM_SHIFT);
+		__raw_writel(reg, S5P_CLK_DIV6);
+
+		do {
+			reg = __raw_readl(S5P_CLKDIV_STAT1);
+		} while (reg & (1 << 15));
+
+		/* Reconfigure DRAM refresh counter value */
+		if (index != L4) {
+			/*
+			 * DMC0 : 166Mhz
+			 * DMC1 : 200Mhz
+			 */
+			s5pv210_set_refresh(DMC0, 166000);
+			s5pv210_set_refresh(DMC1, 200000);
+		} else {
+			/*
+			 * DMC0 : 83Mhz
+			 * DMC1 : 100Mhz
+			 */
+			s5pv210_set_refresh(DMC0, 83000);
+			s5pv210_set_refresh(DMC1, 100000);
+		}
+	}
+
+	if (freqs.new < freqs.old) {
+		/* Voltage down: will be implemented */
+	}
+
+	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+	printk(KERN_DEBUG "Perf changed[L%d]\n", index);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int s5pv210_cpufreq_suspend(struct cpufreq_policy *policy,
+				   pm_message_t pmsg)
+{
+	return 0;
+}
+
+static int s5pv210_cpufreq_resume(struct cpufreq_policy *policy)
+{
+	return 0;
+}
+#endif
+
+static int check_mem_type(void __iomem *dmc_reg)
+{
+	unsigned long val;
+
+	val = __raw_readl(dmc_reg + 0x4);
+	val = (val & (0xf << 8));
+
+	return val >> 8;
+}
+
+static int __init s5pv210_cpu_init(struct cpufreq_policy *policy)
+{
+	unsigned long mem_type;
+
+	cpu_clk = clk_get(NULL, "armclk");
+	if (IS_ERR(cpu_clk))
+		return PTR_ERR(cpu_clk);
+
+	dmc0_clk = clk_get(NULL, "sclk_dmc0");
+	if (IS_ERR(dmc0_clk)) {
+		clk_put(cpu_clk);
+		return PTR_ERR(dmc0_clk);
+	}
+
+	dmc1_clk = clk_get(NULL, "hclk_msys");
+	if (IS_ERR(dmc1_clk)) {
+		clk_put(dmc0_clk);
+		clk_put(cpu_clk);
+		return PTR_ERR(dmc1_clk);
+	}
+
+	if (policy->cpu != 0)
+		return -EINVAL;
+
+	/*
+	 * check_mem_type : This driver only support LPDDR & LPDDR2.
+	 * other memory type is not supported.
+	 */
+	mem_type = check_mem_type(S5P_VA_DMC0);
+
+	if ((mem_type != LPDDR) && (mem_type != LPDDR2)) {
+		printk(KERN_ERR "CPUFreq doesn't support this memory type\n");
+		return -EINVAL;
+	}
+
+	/* Find current refresh counter and frequency each DMC */
+	s5pv210_dram_conf[0].refresh = (__raw_readl(S5P_VA_DMC0 + 0x30) * 1000);
+	s5pv210_dram_conf[0].freq = clk_get_rate(dmc0_clk);
+
+	s5pv210_dram_conf[1].refresh = (__raw_readl(S5P_VA_DMC1 + 0x30) * 1000);
+	s5pv210_dram_conf[1].freq = clk_get_rate(dmc1_clk);
+
+	policy->cur = policy->min = policy->max = s5pv210_getspeed(0);
+
+	cpufreq_frequency_table_get_attr(s5pv210_freq_table, policy->cpu);
+
+	policy->cpuinfo.transition_latency = 40000;
+
+	return cpufreq_frequency_table_cpuinfo(policy, s5pv210_freq_table);
+}
+
+static struct cpufreq_driver s5pv210_driver = {
+	.flags		= CPUFREQ_STICKY,
+	.verify		= s5pv210_verify_speed,
+	.target		= s5pv210_target,
+	.get		= s5pv210_getspeed,
+	.init		= s5pv210_cpu_init,
+	.name		= "s5pv210",
+#ifdef CONFIG_PM
+	.suspend	= s5pv210_cpufreq_suspend,
+	.resume		= s5pv210_cpufreq_resume,
+#endif
+};
+
+static int __init s5pv210_cpufreq_init(void)
+{
+	return cpufreq_register_driver(&s5pv210_driver);
+}
+
+late_initcall(s5pv210_cpufreq_init);
-- 
1.6.2.5

[PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting CPUFREQ driver

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds ARCH_HAS_CPUFREQ in arch/arm/Kconfig for S5PV210,
and updates mach-s5pv210/Makefile for supporting build CPUFREQ driver.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/Kconfig               |    1 +
 arch/arm/mach-s5pv210/Makefile |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bce9193..7bff1d2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -721,6 +721,7 @@ config ARCH_S5PV210
 	select GENERIC_GPIO
 	select HAVE_CLK
 	select ARM_L1_CACHE_SHIFT_6
+	select ARCH_HAS_CPUFREQ
 	select ARCH_USES_GETTIMEOFFSET
 	select HAVE_S3C2410_I2C
 	select HAVE_S3C_RTC
diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile
index 7045489..833d803 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -14,6 +14,7 @@ obj-				:=
 
 obj-$(CONFIG_CPU_S5PV210)	+= cpu.o init.o clock.o dma.o gpiolib.o
 obj-$(CONFIG_CPU_S5PV210)	+= setup-i2c0.o
+obj-$(CONFIG_CPU_FREQ)		+= cpufreq.o
 
 # machine support
 
-- 
1.6.2.5

[PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting CPUFREQ driver

[Sangbeom Kim]

From: Jaecheol Lee <jc.lee@samsung.com>

This patch adds ARCH_HAS_CPUFREQ in arch/arm/Kconfig for S5PV210,
and updates mach-s5pv210/Makefile for supporting build CPUFREQ driver.

Signed-off-by: Jaecheol Lee <jc.lee@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
---
 arch/arm/Kconfig               |    1 +
 arch/arm/mach-s5pv210/Makefile |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bce9193..7bff1d2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -721,6 +721,7 @@ config ARCH_S5PV210
 	select GENERIC_GPIO
 	select HAVE_CLK
 	select ARM_L1_CACHE_SHIFT_6
+	select ARCH_HAS_CPUFREQ
 	select ARCH_USES_GETTIMEOFFSET
 	select HAVE_S3C2410_I2C
 	select HAVE_S3C_RTC
diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile
index 7045489..833d803 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -14,6 +14,7 @@ obj-				:=
 
 obj-$(CONFIG_CPU_S5PV210)	+= cpu.o init.o clock.o dma.o gpiolib.o
 obj-$(CONFIG_CPU_S5PV210)	+= setup-i2c0.o
+obj-$(CONFIG_CPU_FREQ)		+= cpufreq.o
 
 # machine support
 
-- 
1.6.2.5

RE: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Sangbeom Kim]

Hi all,
I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
But, That patchset seems to have unclear part.
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/023626.htm
l
The part of 'CONFIG_PM' is unclear and still have PM support part.
So, I think that this patch is more suitable for S5PV210/S5PC110 CPUFREQ in
the mainline.
because this patch implemented basic pm functionality and already tested on
smdkv210 board.

Thanks and regards,
S.B. Kim

> on Monday, September 20, 2010 3:05 PM, Sangbeom Kim <sbkim73@samsung.com>
wrote:
> 
> This patch adds CPUFREQ for S5PV210/S5PC110.
> 
> Changes since v1:
> 
> - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in CPUFREQ
> driver.
> - Removed hardcoding of DRAM refresh counter.
> - Added to calculate refresh counter function based on DRAM operation
freq.
> 
> [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC
> access
> [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
> [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
> [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
> [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
> [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting
> CPUFREQ driver
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Sangbeom Kim]

Hi all,
I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
But, That patchset seems to have unclear part.
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/023626.htm
l
The part of 'CONFIG_PM' is unclear and still have PM support part.
So, I think that this patch is more suitable for S5PV210/S5PC110 CPUFREQ in
the mainline.
because this patch implemented basic pm functionality and already tested on
smdkv210 board.

Thanks and regards,
S.B. Kim

> on Monday, September 20, 2010 3:05 PM, Sangbeom Kim <sbkim73@samsung.com>
wrote:
> 
> This patch adds CPUFREQ for S5PV210/S5PC110.
> 
> Changes since v1:
> 
> - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in CPUFREQ
> driver.
> - Removed hardcoding of DRAM refresh counter.
> - Added to calculate refresh counter function based on DRAM operation
freq.
> 
> [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC
> access
> [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
> [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
> [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
> [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
> [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting
> CPUFREQ driver
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Kukjin Kim]

Sangbeom Kim wrote:
> 
> Hi all,
> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
> But, That patchset seems to have unclear part.
>
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/023626.htm
> l
> The part of 'CONFIG_PM' is unclear and still have PM support part.
> So, I think that this patch is more suitable for S5PV210/S5PC110 CPUFREQ
in
> the mainline.
> because this patch implemented basic pm functionality and already tested
on
> smdkv210 board.
> 
Hi,

So...I'd like to merge this for this merge window.

Mr. Ham, how do you think?
If any problems or opinions, please let me know.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

> Thanks and regards,
> S.B. Kim
> 
> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
> <sbkim73@samsung.com>
> wrote:
> >
> > This patch adds CPUFREQ for S5PV210/S5PC110.
> >
> > Changes since v1:
> >
> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
> CPUFREQ
> > driver.
> > - Removed hardcoding of DRAM refresh counter.
> > - Added to calculate refresh counter function based on DRAM operation
> freq.
> >
> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC
> > access
> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting
> > CPUFREQ driver
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> > soc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Kukjin Kim]

Sangbeom Kim wrote:
> 
> Hi all,
> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
> But, That patchset seems to have unclear part.
>
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/023626.htm
> l
> The part of 'CONFIG_PM' is unclear and still have PM support part.
> So, I think that this patch is more suitable for S5PV210/S5PC110 CPUFREQ
in
> the mainline.
> because this patch implemented basic pm functionality and already tested
on
> smdkv210 board.
> 
Hi,

So...I'd like to merge this for this merge window.

Mr. Ham, how do you think?
If any problems or opinions, please let me know.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

> Thanks and regards,
> S.B. Kim
> 
> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
> <sbkim73@samsung.com>
> wrote:
> >
> > This patch adds CPUFREQ for S5PV210/S5PC110.
> >
> > Changes since v1:
> >
> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
> CPUFREQ
> > driver.
> > - Removed hardcoding of DRAM refresh counter.
> > - Added to calculate refresh counter function based on DRAM operation
> freq.
> >
> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC
> > access
> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting
> > CPUFREQ driver
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> > soc" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[MyungJoo Ham]

Hello,

On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Sangbeom Kim wrote:
>>
>> Hi all,
>> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
>> But, That patchset seems to have unclear part.
>>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/023626.htm
>> l
>> The part of 'CONFIG_PM' is unclear and still have PM support part.
>> So, I think that this patch is more suitable for S5PV210/S5PC110 CPUFREQ
> in
>> the mainline.
>> because this patch implemented basic pm functionality and already tested
> on
>> smdkv210 board.
>>
> Hi,
>
> So...I'd like to merge this for this merge window.
>
> Mr. Ham, how do you think?
> If any problems or opinions, please let me know.


You can go ahead as long as this patch include features that the
another addresses.


Anyway, the part that is under "CONFIG_PM" is intended to block
frequency changing while PM is doing something. For example, when the
system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
not turned off during sleep) while the frequency is reset to 800MHz
(by the bootloader), which requires, let's say, 1.1V. Such
inconsistency may lead to system hang and we have observed such cases
a few times. I intended to refuse any CPUFREQ requests at the
/mach-s5pv210/cpufreq.c when PM seems to start.

It may seem that such feature is not needed if the voltage is not
optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
and if the voltage changes properly according to the frequency, such
feature is required anyway.


ps. Anyway, such feature is also not included in my patch, either. :(
(tried to included, but the code was excluded at the patch patching
the patch.)

>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>> Thanks and regards,
>> S.B. Kim
>>
>> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
>> <sbkim73@samsung.com>
>> wrote:
>> >
>> > This patch adds CPUFREQ for S5PV210/S5PC110.
>> >
>> > Changes since v1:
>> >
>> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
>> CPUFREQ
>> > driver.
>> > - Removed hardcoding of DRAM refresh counter.
>> > - Added to calculate refresh counter function based on DRAM operation
>> freq.
>> >
>> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC
>> > access
>> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
>> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
>> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
>> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
>> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting
>> > CPUFREQ driver
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
>> > soc" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[MyungJoo Ham]

Hello,

On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Sangbeom Kim wrote:
>>
>> Hi all,
>> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
>> But, That patchset seems to have unclear part.
>>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/023626.htm
>> l
>> The part of 'CONFIG_PM' is unclear and still have PM support part.
>> So, I think that this patch is more suitable for S5PV210/S5PC110 CPUFREQ
> in
>> the mainline.
>> because this patch implemented basic pm functionality and already tested
> on
>> smdkv210 board.
>>
> Hi,
>
> So...I'd like to merge this for this merge window.
>
> Mr. Ham, how do you think?
> If any problems or opinions, please let me know.


You can go ahead as long as this patch include features that the
another addresses.


Anyway, the part that is under "CONFIG_PM" is intended to block
frequency changing while PM is doing something. For example, when the
system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
not turned off during sleep) while the frequency is reset to 800MHz
(by the bootloader), which requires, let's say, 1.1V. Such
inconsistency may lead to system hang and we have observed such cases
a few times. I intended to refuse any CPUFREQ requests at the
/mach-s5pv210/cpufreq.c when PM seems to start.

It may seem that such feature is not needed if the voltage is not
optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
and if the voltage changes properly according to the frequency, such
feature is required anyway.


ps. Anyway, such feature is also not included in my patch, either. :(
(tried to included, but the code was excluded at the patch patching
the patch.)

>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>> Thanks and regards,
>> S.B. Kim
>>
>> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
>> <sbkim73@samsung.com>
>> wrote:
>> >
>> > This patch adds CPUFREQ for S5PV210/S5PC110.
>> >
>> > Changes since v1:
>> >
>> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
>> CPUFREQ
>> > driver.
>> > - Removed hardcoding of DRAM refresh counter.
>> > - Added to calculate refresh counter function based on DRAM operation
>> freq.
>> >
>> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting DMC
>> > access
>> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
>> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
>> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
>> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
>> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for supporting
>> > CPUFREQ driver
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
>> > soc" in
>> > the body of a message to majordomo at vger.kernel.org
>> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
MyungJoo Ham (???), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

RE: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Sangbeom Kim]

On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham <myungjoo.ham@samsung.com> wrote:
> 
> Hello,
> 
> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> > Sangbeom Kim wrote:
> >>
> >> Hi all,
> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
> >> But, That patchset seems to have unclear part.
> >>
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
> August/023626.htm
> >> l
> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
> >> So, I think that this patch is more suitable for S5PV210/S5PC110
> CPUFREQ
> > in
> >> the mainline.
> >> because this patch implemented basic pm functionality and already
> tested
> > on
> >> smdkv210 board.
> >>
> > Hi,
> >
> > So...I'd like to merge this for this merge window.
> >
> > Mr. Ham, how do you think?
> > If any problems or opinions, please let me know.
> 
> 
> You can go ahead as long as this patch include features that the
> another addresses.
> 
> 
> Anyway, the part that is under "CONFIG_PM" is intended to block
> frequency changing while PM is doing something. For example, when the
> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
> not turned off during sleep) while the frequency is reset to 800MHz
> (by the bootloader), which requires, let's say, 1.1V. Such
> inconsistency may lead to system hang and we have observed such cases
> a few times. I intended to refuse any CPUFREQ requests at the
> /mach-s5pv210/cpufreq.c when PM seems to start.
> 

We knew already that issue, 
So we have a plan to implement with other solution. 
(using regulator suspend feature)

> It may seem that such feature is not needed if the voltage is not
> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
> and if the voltage changes properly according to the frequency, such
> feature is required anyway.

Currently, there is no max8698 regulator driver on mainline.
After submission that driver, we can add voltage scaling feature.

Both issues have dependency on regulator driver.

> 
> 
> ps. Anyway, such feature is also not included in my patch, either. :(
> (tried to included, but the code was excluded at the patch patching
> the patch.)
> 
> >
> > Thanks.
> >
> > Best regards,
> > Kgene.
> > --
> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> > SW Solution Development Team, Samsung Electronics Co., Ltd.
> >
> >> Thanks and regards,
> >> S.B. Kim
> >>
> >> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
> >> <sbkim73@samsung.com>
> >> wrote:
> >> >
> >> > This patch adds CPUFREQ for S5PV210/S5PC110.
> >> >
> >> > Changes since v1:
> >> >
> >> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
> >> CPUFREQ
> >> > driver.
> >> > - Removed hardcoding of DRAM refresh counter.
> >> > - Added to calculate refresh counter function based on DRAM operation
> >> freq.
> >> >
> >> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting
> DMC
> >> > access
> >> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
> >> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
> >> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
> >> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
> >> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for
> supporting
> >> > CPUFREQ driver
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe linux-
> samsung-
> >> > soc" in
> >> > the body of a message to majordomo@vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 
> 
> 
> --
> MyungJoo Ham (함명주), Ph.D.
> Mobile Software Platform Lab,
> Digital Media and Communications (DMC) Business
> Samsung Electronics
> cell: 82-10-6714-2858
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Sangbeom Kim]

On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham <myungjoo.ham@samsung.com> wrote:
> 
> Hello,
> 
> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> > Sangbeom Kim wrote:
> >>
> >> Hi all,
> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
> >> But, That patchset seems to have unclear part.
> >>
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
> August/023626.htm
> >> l
> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
> >> So, I think that this patch is more suitable for S5PV210/S5PC110
> CPUFREQ
> > in
> >> the mainline.
> >> because this patch implemented basic pm functionality and already
> tested
> > on
> >> smdkv210 board.
> >>
> > Hi,
> >
> > So...I'd like to merge this for this merge window.
> >
> > Mr. Ham, how do you think?
> > If any problems or opinions, please let me know.
> 
> 
> You can go ahead as long as this patch include features that the
> another addresses.
> 
> 
> Anyway, the part that is under "CONFIG_PM" is intended to block
> frequency changing while PM is doing something. For example, when the
> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
> not turned off during sleep) while the frequency is reset to 800MHz
> (by the bootloader), which requires, let's say, 1.1V. Such
> inconsistency may lead to system hang and we have observed such cases
> a few times. I intended to refuse any CPUFREQ requests at the
> /mach-s5pv210/cpufreq.c when PM seems to start.
> 

We knew already that issue, 
So we have a plan to implement with other solution. 
(using regulator suspend feature)

> It may seem that such feature is not needed if the voltage is not
> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
> and if the voltage changes properly according to the frequency, such
> feature is required anyway.

Currently, there is no max8698 regulator driver on mainline.
After submission that driver, we can add voltage scaling feature.

Both issues have dependency on regulator driver.

> 
> 
> ps. Anyway, such feature is also not included in my patch, either. :(
> (tried to included, but the code was excluded at the patch patching
> the patch.)
> 
> >
> > Thanks.
> >
> > Best regards,
> > Kgene.
> > --
> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> > SW Solution Development Team, Samsung Electronics Co., Ltd.
> >
> >> Thanks and regards,
> >> S.B. Kim
> >>
> >> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
> >> <sbkim73@samsung.com>
> >> wrote:
> >> >
> >> > This patch adds CPUFREQ for S5PV210/S5PC110.
> >> >
> >> > Changes since v1:
> >> >
> >> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
> >> CPUFREQ
> >> > driver.
> >> > - Removed hardcoding of DRAM refresh counter.
> >> > - Added to calculate refresh counter function based on DRAM operation
> >> freq.
> >> >
> >> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting
> DMC
> >> > access
> >> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
> >> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
> >> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
> >> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
> >> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for
> supporting
> >> > CPUFREQ driver
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe linux-
> samsung-
> >> > soc" in
> >> > the body of a message to majordomo at vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 
> 
> 
> --
> MyungJoo Ham (???), Ph.D.
> Mobile Software Platform Lab,
> Digital Media and Communications (DMC) Business
> Samsung Electronics
> cell: 82-10-6714-2858
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[MyungJoo Ham]

On Mon, Oct 11, 2010 at 5:04 PM, Sangbeom Kim <sbkim73@samsung.com> wrote:
> On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham <myungjoo.ham@samsung.com> wrote:
>>
>> Hello,
>>
>> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> > Sangbeom Kim wrote:
>> >>
>> >> Hi all,
>> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
>> >> But, That patchset seems to have unclear part.
>> >>
>> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
>> August/023626.htm
>> >> l
>> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
>> >> So, I think that this patch is more suitable for S5PV210/S5PC110
>> CPUFREQ
>> > in
>> >> the mainline.
>> >> because this patch implemented basic pm functionality and already
>> tested
>> > on
>> >> smdkv210 board.
>> >>
>> > Hi,
>> >
>> > So...I'd like to merge this for this merge window.
>> >
>> > Mr. Ham, how do you think?
>> > If any problems or opinions, please let me know.
>>
>>
>> You can go ahead as long as this patch include features that the
>> another addresses.
>>
>>
>> Anyway, the part that is under "CONFIG_PM" is intended to block
>> frequency changing while PM is doing something. For example, when the
>> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
>> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
>> not turned off during sleep) while the frequency is reset to 800MHz
>> (by the bootloader), which requires, let's say, 1.1V. Such
>> inconsistency may lead to system hang and we have observed such cases
>> a few times. I intended to refuse any CPUFREQ requests at the
>> /mach-s5pv210/cpufreq.c when PM seems to start.
>>
>
> We knew already that issue,
> So we have a plan to implement with other solution.
> (using regulator suspend feature)
>
>> It may seem that such feature is not needed if the voltage is not
>> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
>> and if the voltage changes properly according to the frequency, such
>> feature is required anyway.
>
> Currently, there is no max8698 regulator driver on mainline.
> After submission that driver, we can add voltage scaling feature.
>
> Both issues have dependency on regulator driver.

Nope. it does not need to depend on any regulator drivers. We can
simply stop changing frequency (or hold at a specific frequency) after
suspend-to-mem is called. (probably at ".begin" stage). This depends
on PM, but does NOT depend on REGULATOR.

The approach in the removed patch was to set a flag at the .begin PM
ops and deflag it at .end PM ops and let target function of CPUFREQ to
read the flag to decide whether to accept the frequency change request
and to set at the default frequency (i.e., 800MHz) when .begin ops is
called and restore the frequency when .end ops is called.


>
>>
>>
>> ps. Anyway, such feature is also not included in my patch, either. :(
>> (tried to included, but the code was excluded at the patch patching
>> the patch.)
>>
>> >
>> > Thanks.
>> >
>> > Best regards,
>> > Kgene.
>> > --
>> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
>> > SW Solution Development Team, Samsung Electronics Co., Ltd.
>> >
>> >> Thanks and regards,
>> >> S.B. Kim
>> >>
>> >> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
>> >> <sbkim73@samsung.com>
>> >> wrote:
>> >> >
>> >> > This patch adds CPUFREQ for S5PV210/S5PC110.
>> >> >
>> >> > Changes since v1:
>> >> >
>> >> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
>> >> CPUFREQ
>> >> > driver.
>> >> > - Removed hardcoding of DRAM refresh counter.
>> >> > - Added to calculate refresh counter function based on DRAM operation
>> >> freq.
>> >> >
>> >> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting
>> DMC
>> >> > access
>> >> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
>> >> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
>> >> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
>> >> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
>> >> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for
>> supporting
>> >> > CPUFREQ driver
>> >> > --
>> >> > To unsubscribe from this list: send the line "unsubscribe linux-
>> samsung-
>> >> > soc" in
>> >> > the body of a message to majordomo@vger.kernel.org
>> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >
>>
>>
>>
>> --
>> MyungJoo Ham (함명주), Ph.D.
>> Mobile Software Platform Lab,
>> Digital Media and Communications (DMC) Business
>> Samsung Electronics
>> cell: 82-10-6714-2858
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[MyungJoo Ham]

On Mon, Oct 11, 2010 at 5:04 PM, Sangbeom Kim <sbkim73@samsung.com> wrote:
> On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham <myungjoo.ham@samsung.com> wrote:
>>
>> Hello,
>>
>> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> > Sangbeom Kim wrote:
>> >>
>> >> Hi all,
>> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
>> >> But, That patchset seems to have unclear part.
>> >>
>> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
>> August/023626.htm
>> >> l
>> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
>> >> So, I think that this patch is more suitable for S5PV210/S5PC110
>> CPUFREQ
>> > in
>> >> the mainline.
>> >> because this patch implemented basic pm functionality and already
>> tested
>> > on
>> >> smdkv210 board.
>> >>
>> > Hi,
>> >
>> > So...I'd like to merge this for this merge window.
>> >
>> > Mr. Ham, how do you think?
>> > If any problems or opinions, please let me know.
>>
>>
>> You can go ahead as long as this patch include features that the
>> another addresses.
>>
>>
>> Anyway, the part that is under "CONFIG_PM" is intended to block
>> frequency changing while PM is doing something. For example, when the
>> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
>> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
>> not turned off during sleep) while the frequency is reset to 800MHz
>> (by the bootloader), which requires, let's say, 1.1V. Such
>> inconsistency may lead to system hang and we have observed such cases
>> a few times. I intended to refuse any CPUFREQ requests at the
>> /mach-s5pv210/cpufreq.c when PM seems to start.
>>
>
> We knew already that issue,
> So we have a plan to implement with other solution.
> (using regulator suspend feature)
>
>> It may seem that such feature is not needed if the voltage is not
>> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
>> and if the voltage changes properly according to the frequency, such
>> feature is required anyway.
>
> Currently, there is no max8698 regulator driver on mainline.
> After submission that driver, we can add voltage scaling feature.
>
> Both issues have dependency on regulator driver.

Nope. it does not need to depend on any regulator drivers. We can
simply stop changing frequency (or hold at a specific frequency) after
suspend-to-mem is called. (probably at ".begin" stage). This depends
on PM, but does NOT depend on REGULATOR.

The approach in the removed patch was to set a flag at the .begin PM
ops and deflag it at .end PM ops and let target function of CPUFREQ to
read the flag to decide whether to accept the frequency change request
and to set at the default frequency (i.e., 800MHz) when .begin ops is
called and restore the frequency when .end ops is called.


>
>>
>>
>> ps. Anyway, such feature is also not included in my patch, either. :(
>> (tried to included, but the code was excluded at the patch patching
>> the patch.)
>>
>> >
>> > Thanks.
>> >
>> > Best regards,
>> > Kgene.
>> > --
>> > Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
>> > SW Solution Development Team, Samsung Electronics Co., Ltd.
>> >
>> >> Thanks and regards,
>> >> S.B. Kim
>> >>
>> >> > on Monday, September 20, 2010 3:05 PM, Sangbeom Kim
>> >> <sbkim73@samsung.com>
>> >> wrote:
>> >> >
>> >> > This patch adds CPUFREQ for S5PV210/S5PC110.
>> >> >
>> >> > Changes since v1:
>> >> >
>> >> > - Added MOUT_DMC0 and SCLK_DMC0 for checking the dmc0 clock in
>> >> CPUFREQ
>> >> > driver.
>> >> > - Removed hardcoding of DRAM refresh counter.
>> >> > - Added to calculate refresh counter function based on DRAM operation
>> >> freq.
>> >> >
>> >> > [PATCH v2 1/6] ARM: S5PV210: Add DMC map_desc table for supporting
>> DMC
>> >> > access
>> >> > [PATCH v2 2/6] ARM: S5PV210: Add struct clk_ops for clk_fout_apll
>> >> > [PATCH v2 3/6] ARM: S5PV210: Add MOUT_DMC0 and SCLK_DMC0 clocks
>> >> > [PATCH v2 4/6] ARM: S5PV210: Add Register definition for CMU
>> >> > [PATCH v2 5/6] ARM: S5PV210: Add support CPUFREQ
>> >> > [PATCH v2 6/6] ARM: S5PV210: Update Kconfig and Makefile for
>> supporting
>> >> > CPUFREQ driver
>> >> > --
>> >> > To unsubscribe from this list: send the line "unsubscribe linux-
>> samsung-
>> >> > soc" in
>> >> > the body of a message to majordomo at vger.kernel.org
>> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >
>>
>>
>>
>> --
>> MyungJoo Ham (???), Ph.D.
>> Mobile Software Platform Lab,
>> Digital Media and Communications (DMC) Business
>> Samsung Electronics
>> cell: 82-10-6714-2858
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
MyungJoo Ham (???), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

RE: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Kukjin Kim]

MyungJoo Ham wrote:
> 
> On Mon, Oct 11, 2010 at 5:04 PM, Sangbeom Kim <sbkim73@samsung.com>
> wrote:
> > On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham
> <myungjoo.ham@samsung.com> wrote:
> >>
> >> Hello,
> >>
> >> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com>
wrote:
> >> > Sangbeom Kim wrote:
> >> >>
> >> >> Hi all,
> >> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
> >> >> But, That patchset seems to have unclear part.
> >> >>
> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
> >> August/023626.htm
> >> >> l
> >> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
> >> >> So, I think that this patch is more suitable for S5PV210/S5PC110
> >> CPUFREQ
> >> > in
> >> >> the mainline.
> >> >> because this patch implemented basic pm functionality and already
> >> tested
> >> > on
> >> >> smdkv210 board.
> >> >>
> >> > Hi,
> >> >
> >> > So...I'd like to merge this for this merge window.
> >> >
> >> > Mr. Ham, how do you think?
> >> > If any problems or opinions, please let me know.
> >>
> >>
> >> You can go ahead as long as this patch include features that the
> >> another addresses.
> >>
> >>
> >> Anyway, the part that is under "CONFIG_PM" is intended to block
> >> frequency changing while PM is doing something. For example, when the
> >> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
> >> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
> >> not turned off during sleep) while the frequency is reset to 800MHz
> >> (by the bootloader), which requires, let's say, 1.1V. Such
> >> inconsistency may lead to system hang and we have observed such cases
> >> a few times. I intended to refuse any CPUFREQ requests at the
> >> /mach-s5pv210/cpufreq.c when PM seems to start.
> >>
> >
> > We knew already that issue,
> > So we have a plan to implement with other solution.
> > (using regulator suspend feature)
> >
> >> It may seem that such feature is not needed if the voltage is not
> >> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
> >> and if the voltage changes properly according to the frequency, such
> >> feature is required anyway.
> >
> > Currently, there is no max8698 regulator driver on mainline.
> > After submission that driver, we can add voltage scaling feature.
> >
> > Both issues have dependency on regulator driver.
> 
> Nope. it does not need to depend on any regulator drivers. We can
> simply stop changing frequency (or hold at a specific frequency) after
> suspend-to-mem is called. (probably at ".begin" stage). This depends
> on PM, but does NOT depend on REGULATOR.
> 
> The approach in the removed patch was to set a flag at the .begin PM
> ops and deflag it at .end PM ops and let target function of CPUFREQ to
> read the flag to decide whether to accept the frequency change request
> and to set at the default frequency (i.e., 800MHz) when .begin ops is
> called and restore the frequency when .end ops is called.
> 

Hi all,

Both looks reasonable to me, in my opinion, need to decide one thing.

As I said, I'd like to apply basic functionality of CPUFREQ, Jaecheol Lee's
patch in this merge window.
It would be better if could keep going update its other functionality next
time.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[Kukjin Kim]

MyungJoo Ham wrote:
> 
> On Mon, Oct 11, 2010 at 5:04 PM, Sangbeom Kim <sbkim73@samsung.com>
> wrote:
> > On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham
> <myungjoo.ham@samsung.com> wrote:
> >>
> >> Hello,
> >>
> >> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com>
wrote:
> >> > Sangbeom Kim wrote:
> >> >>
> >> >> Hi all,
> >> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
> >> >> But, That patchset seems to have unclear part.
> >> >>
> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
> >> August/023626.htm
> >> >> l
> >> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
> >> >> So, I think that this patch is more suitable for S5PV210/S5PC110
> >> CPUFREQ
> >> > in
> >> >> the mainline.
> >> >> because this patch implemented basic pm functionality and already
> >> tested
> >> > on
> >> >> smdkv210 board.
> >> >>
> >> > Hi,
> >> >
> >> > So...I'd like to merge this for this merge window.
> >> >
> >> > Mr. Ham, how do you think?
> >> > If any problems or opinions, please let me know.
> >>
> >>
> >> You can go ahead as long as this patch include features that the
> >> another addresses.
> >>
> >>
> >> Anyway, the part that is under "CONFIG_PM" is intended to block
> >> frequency changing while PM is doing something. For example, when the
> >> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
> >> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
> >> not turned off during sleep) while the frequency is reset to 800MHz
> >> (by the bootloader), which requires, let's say, 1.1V. Such
> >> inconsistency may lead to system hang and we have observed such cases
> >> a few times. I intended to refuse any CPUFREQ requests at the
> >> /mach-s5pv210/cpufreq.c when PM seems to start.
> >>
> >
> > We knew already that issue,
> > So we have a plan to implement with other solution.
> > (using regulator suspend feature)
> >
> >> It may seem that such feature is not needed if the voltage is not
> >> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
> >> and if the voltage changes properly according to the frequency, such
> >> feature is required anyway.
> >
> > Currently, there is no max8698 regulator driver on mainline.
> > After submission that driver, we can add voltage scaling feature.
> >
> > Both issues have dependency on regulator driver.
> 
> Nope. it does not need to depend on any regulator drivers. We can
> simply stop changing frequency (or hold at a specific frequency) after
> suspend-to-mem is called. (probably at ".begin" stage). This depends
> on PM, but does NOT depend on REGULATOR.
> 
> The approach in the removed patch was to set a flag at the .begin PM
> ops and deflag it at .end PM ops and let target function of CPUFREQ to
> read the flag to decide whether to accept the frequency change request
> and to set at the default frequency (i.e., 800MHz) when .begin ops is
> called and restore the frequency when .end ops is called.
> 

Hi all,

Both looks reasonable to me, in my opinion, need to decide one thing.

As I said, I'd like to apply basic functionality of CPUFREQ, Jaecheol Lee's
patch in this merge window.
It would be better if could keep going update its other functionality next
time.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

Re: [PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[MyungJoo Ham]

On Tue, Oct 12, 2010 at 9:15 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> MyungJoo Ham wrote:
>>
>> On Mon, Oct 11, 2010 at 5:04 PM, Sangbeom Kim <sbkim73@samsung.com>
>> wrote:
>> > On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham
>> <myungjoo.ham@samsung.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com>
> wrote:
>> >> > Sangbeom Kim wrote:
>> >> >>
>> >> >> Hi all,
>> >> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
>> >> >> But, That patchset seems to have unclear part.
>> >> >>
>> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
>> >> August/023626.htm
>> >> >> l
>> >> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
>> >> >> So, I think that this patch is more suitable for S5PV210/S5PC110
>> >> CPUFREQ
>> >> > in
>> >> >> the mainline.
>> >> >> because this patch implemented basic pm functionality and already
>> >> tested
>> >> > on
>> >> >> smdkv210 board.
>> >> >>
>> >> > Hi,
>> >> >
>> >> > So...I'd like to merge this for this merge window.
>> >> >
>> >> > Mr. Ham, how do you think?
>> >> > If any problems or opinions, please let me know.
>> >>
>> >>
>> >> You can go ahead as long as this patch include features that the
>> >> another addresses.
>> >>
>> >>
>> >> Anyway, the part that is under "CONFIG_PM" is intended to block
>> >> frequency changing while PM is doing something. For example, when the
>> >> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
>> >> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
>> >> not turned off during sleep) while the frequency is reset to 800MHz
>> >> (by the bootloader), which requires, let's say, 1.1V. Such
>> >> inconsistency may lead to system hang and we have observed such cases
>> >> a few times. I intended to refuse any CPUFREQ requests at the
>> >> /mach-s5pv210/cpufreq.c when PM seems to start.
>> >>
>> >
>> > We knew already that issue,
>> > So we have a plan to implement with other solution.
>> > (using regulator suspend feature)
>> >
>> >> It may seem that such feature is not needed if the voltage is not
>> >> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
>> >> and if the voltage changes properly according to the frequency, such
>> >> feature is required anyway.
>> >
>> > Currently, there is no max8698 regulator driver on mainline.
>> > After submission that driver, we can add voltage scaling feature.
>> >
>> > Both issues have dependency on regulator driver.
>>
>> Nope. it does not need to depend on any regulator drivers. We can
>> simply stop changing frequency (or hold at a specific frequency) after
>> suspend-to-mem is called. (probably at ".begin" stage). This depends
>> on PM, but does NOT depend on REGULATOR.
>>
>> The approach in the removed patch was to set a flag at the .begin PM
>> ops and deflag it at .end PM ops and let target function of CPUFREQ to
>> read the flag to decide whether to accept the frequency change request
>> and to set at the default frequency (i.e., 800MHz) when .begin ops is
>> called and restore the frequency when .end ops is called.
>>
>
> Hi all,
>
> Both looks reasonable to me, in my opinion, need to decide one thing.
>
> As I said, I'd like to apply basic functionality of CPUFREQ, Jaecheol Lee's
> patch in this merge window.
> It would be better if could keep going update its other functionality next
> time.
>
> Thanks.

Yes, we can focus on the basic functionality for now and add
additional features later.

However, if we implement "stop changing voltage in suspend ops of
regulator", there is a risk of "changing frequency in suspend routine"
while "voltage is not changing" depending on when it stops changing
the voltage. Note that "suspend" function of regulator driver would be
too soon because cpufreq may keep running at that time. Because the
duration between cpu enters wfi and running suspend ops of regulator
driver is very short, the system may seem reliable, but there still
exists a risk (like one fail every 10,000 sleeps?) Besides, utilizing
regulator_suspend_prepare() would be not a good solution either:
running regulator_suspend_prepare() before device suspend loop makes
devices fail (regulators turned off too soon) and running it after the
loop would make cpufreq fail.


Cheers!

- MyungJoo
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858

[PATCH v2 0/6] ARM: S5PV210: Add support S5PV210/S5PC110 CPUFREQ

[MyungJoo Ham]

On Tue, Oct 12, 2010 at 9:15 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> MyungJoo Ham wrote:
>>
>> On Mon, Oct 11, 2010 at 5:04 PM, Sangbeom Kim <sbkim73@samsung.com>
>> wrote:
>> > On Monday, Oct 11, 2010 9:12 AM, MyungJoo Ham
>> <myungjoo.ham@samsung.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Fri, Oct 8, 2010 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com>
> wrote:
>> >> > Sangbeom Kim wrote:
>> >> >>
>> >> >> Hi all,
>> >> >> I know that there is another S5PV210 CPUFREQ patch from Mr. Ham.
>> >> >> But, That patchset seems to have unclear part.
>> >> >>
>> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-
>> >> August/023626.htm
>> >> >> l
>> >> >> The part of 'CONFIG_PM' is unclear and still have PM support part.
>> >> >> So, I think that this patch is more suitable for S5PV210/S5PC110
>> >> CPUFREQ
>> >> > in
>> >> >> the mainline.
>> >> >> because this patch implemented basic pm functionality and already
>> >> tested
>> >> > on
>> >> >> smdkv210 board.
>> >> >>
>> >> > Hi,
>> >> >
>> >> > So...I'd like to merge this for this merge window.
>> >> >
>> >> > Mr. Ham, how do you think?
>> >> > If any problems or opinions, please let me know.
>> >>
>> >>
>> >> You can go ahead as long as this patch include features that the
>> >> another addresses.
>> >>
>> >>
>> >> Anyway, the part that is under "CONFIG_PM" is intended to block
>> >> frequency changing while PM is doing something. For example, when the
>> >> system enters a sleep, if CPUFREQ somehow enters "100MHz/0.95V" just
>> >> before the sleep and wakes up, the voltage may stay at 0.95V (PMIC is
>> >> not turned off during sleep) while the frequency is reset to 800MHz
>> >> (by the bootloader), which requires, let's say, 1.1V. Such
>> >> inconsistency may lead to system hang and we have observed such cases
>> >> a few times. I intended to refuse any CPUFREQ requests at the
>> >> /mach-s5pv210/cpufreq.c when PM seems to start.
>> >>
>> >
>> > We knew already that issue,
>> > So we have a plan to implement with other solution.
>> > (using regulator suspend feature)
>> >
>> >> It may seem that such feature is not needed if the voltage is not
>> >> optimized, however, CPUFREQ is useless if the voltage stays at 1.2V
>> >> and if the voltage changes properly according to the frequency, such
>> >> feature is required anyway.
>> >
>> > Currently, there is no max8698 regulator driver on mainline.
>> > After submission that driver, we can add voltage scaling feature.
>> >
>> > Both issues have dependency on regulator driver.
>>
>> Nope. it does not need to depend on any regulator drivers. We can
>> simply stop changing frequency (or hold at a specific frequency) after
>> suspend-to-mem is called. (probably at ".begin" stage). This depends
>> on PM, but does NOT depend on REGULATOR.
>>
>> The approach in the removed patch was to set a flag at the .begin PM
>> ops and deflag it at .end PM ops and let target function of CPUFREQ to
>> read the flag to decide whether to accept the frequency change request
>> and to set at the default frequency (i.e., 800MHz) when .begin ops is
>> called and restore the frequency when .end ops is called.
>>
>
> Hi all,
>
> Both looks reasonable to me, in my opinion, need to decide one thing.
>
> As I said, I'd like to apply basic functionality of CPUFREQ, Jaecheol Lee's
> patch in this merge window.
> It would be better if could keep going update its other functionality next
> time.
>
> Thanks.

Yes, we can focus on the basic functionality for now and add
additional features later.

However, if we implement "stop changing voltage in suspend ops of
regulator", there is a risk of "changing frequency in suspend routine"
while "voltage is not changing" depending on when it stops changing
the voltage. Note that "suspend" function of regulator driver would be
too soon because cpufreq may keep running at that time. Because the
duration between cpu enters wfi and running suspend ops of regulator
driver is very short, the system may seem reliable, but there still
exists a risk (like one fail every 10,000 sleeps?) Besides, utilizing
regulator_suspend_prepare() would be not a good solution either:
running regulator_suspend_prepare() before device suspend loop makes
devices fail (regulators turned off too soon) and running it after the
loop would make cpufreq fail.


Cheers!

- MyungJoo
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



-- 
MyungJoo Ham (???), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858