[PATCH] cpufreq: exynos: allow disabling cpufreq drivers

[PATCH] cpufreq: exynos: allow disabling cpufreq drivers

[Sylwester Nawrocki]

On 04/19/2013 03:54 PM, Arnd Bergmann wrote:
> Commit 6e6aac7590 "ARM: EXYNOS: Migrate clock support to common
> clock framework" broke support for the exynos cpufreq drivers.
> While we're waiting for a fix for this, let's get back to a state
> where the kernel builds again with the cpufreq subsystem enabled
> but ARM_EXYNOS_CPUFREQ disabled. I assume that this was the intention
> behind this Kconfig symbol anyway.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Tomasz Figa <t.figa@samsung.com>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: cpufreq at vger.kernel.org
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> Rafael, I'm putting this patch into the arm-soc tree now to avoid
> a bug based on a patch that I got from Kukjin. If you have any
> objections, please let me know so I can revert it again.
> 
> Everyone else: Why does 6e6aac7590 have your "Tested-by" and
> "Signed-off-by" tags on it when it's obviously broken? Who is
> fixing this? Having no working exynos cpufreq support in 3.10
> would be a serious regression.

Not sure what happened here, but my and Tomasz's Tested-by were given 
for v5 of the patch series including 6e6aac7590, while it seems v6 
has been applied. And the patch is not same in both series.

There could be some differences in the base tree I used when testing 
this [1] series, as it was hard to determine against what tag it was 
created exactly. Also I didn't test in on all platforms, only 
Exynos4412.

And the cpufreq really needs to get fixed, as it now modifies registers
which belong to the clock driver...

[1] http://www.spinics.net/lists/arm-kernel/msg214149.html

Thanks,
Sylwester

[PATCH] cpufreq: exynos: allow disabling cpufreq drivers

[Arnd Bergmann]

On Friday 19 April 2013, Sylwester Nawrocki wrote:
> Not sure what happened here, but my and Tomasz's Tested-by were given 
> for v5 of the patch series including 6e6aac7590, while it seems v6 
> has been applied. And the patch is not same in both series.

I see.

> There could be some differences in the base tree I used when testing 
> this [1] series, as it was hard to determine against what tag it was 
> created exactly. Also I didn't test in on all platforms, only 
> Exynos4412.

Maybe you just didn't have CPUFREQ enabled? I also didn't notice this
bug at first because it is turned off in the defconfigs.

It could also be working by chance on EXYNOS4, since the register
definitions were not actually removed from the regs-clk.h header
for those.

	Arnd

[PATCH] cpufreq: exynos: allow disabling cpufreq drivers

[Sylwester Nawrocki]

On 04/19/2013 08:59 PM, Arnd Bergmann wrote:
> Maybe you just didn't have CPUFREQ enabled? I also didn't notice this
> bug at first because it is turned off in the defconfigs.

I certainly had it enabled. Since I remember I needed to turn it off
temporarily after someone has introduced an incorrect change to the clock
tree definition and cpufreq was unexpectedly switching parents of one of
the root clocks at run time, which was causing malfunction of the camera
image processing chain.

Anyway this wasn't a clean mainline kernel, as there have been recently lot
of stuff pending upstream needed to have complete system with dt support.
I assume after 3.10 release the situation is going to be much better.

> It could also be working by chance on EXYNOS4, since the register
> definitions were not actually removed from the regs-clk.h header
> for those.

That's most likely what happened.


Thanks,
Sylwester

[PATCH] cpufreq: exynos: allow disabling cpufreq drivers

[Arnd Bergmann]

On Friday 19 April 2013, Sylwester Nawrocki wrote:
> > It could also be working by chance on EXYNOS4, since the register
> > definitions were not actually removed from the regs-clk.h header
> > for those.
> 
> That's most likely what happened.

Ok. I think I see the bigger picture now. The EXYNOS5 cpufreq driver was
actually just merged now, so I assume that by the time Thomas did the clock
changes, the register definitions for EXYNOS5 were actually unused and he
subsequently removed them from the kernel.

Since the driver now depends on them, I think the only way forward for 3.10
is to revert the change that removed the definitions and put them back in
place.

We really should use the clock API from all the exynos cpufreq drivers, but it's
too late for that change now in 3.10 and we will have to do it for 3.11 then.

This are not looking so good for exynos multiplatform support in 3.10 now, but
if we get it in, that will mean we have to disable cpufreq when building
multiplatform, but it can remain for the classic single-platform configurations.

	Arnd

[PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5

[Arnd Bergmann]

Commit 6e6aac75 "ARM: EXYNOS: Migrate clock support to common
clock framework" from Thomas Abraham removed the Exynos5 specific
register definitions as they were unused at the time, but the
cpufreq driver actually still uses them.

Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
8<----

I'd apply this one on next/drivers to fix the build error, unless
someone has concerns.

diff --git a/arch/arm/mach-exynos/include/mach/regs-clock.h b/arch/arm/mach-exynos/include/mach/regs-clock.h
index 20fbbdd..d36ad76 100644
--- a/arch/arm/mach-exynos/include/mach/regs-clock.h
+++ b/arch/arm/mach-exynos/include/mach/regs-clock.h
@@ -256,6 +256,113 @@
 #define EXYNOS4_CLKDIV_CAM1_JPEG_SHIFT		(0)
 #define EXYNOS4_CLKDIV_CAM1_JPEG_MASK		(0xf << EXYNOS4_CLKDIV_CAM1_JPEG_SHIFT)
 
+/* For EXYNOS5250 */
+
+#define EXYNOS5_APLL_LOCK			EXYNOS_CLKREG(0x00000)
+#define EXYNOS5_APLL_CON0			EXYNOS_CLKREG(0x00100)
+#define EXYNOS5_CLKSRC_CPU			EXYNOS_CLKREG(0x00200)
+#define EXYNOS5_CLKMUX_STATCPU			EXYNOS_CLKREG(0x00400)
+#define EXYNOS5_CLKDIV_CPU0			EXYNOS_CLKREG(0x00500)
+#define EXYNOS5_CLKDIV_CPU1			EXYNOS_CLKREG(0x00504)
+#define EXYNOS5_CLKDIV_STATCPU0			EXYNOS_CLKREG(0x00600)
+#define EXYNOS5_CLKDIV_STATCPU1			EXYNOS_CLKREG(0x00604)
+
+#define EXYNOS5_PWR_CTRL1			EXYNOS_CLKREG(0x01020)
+#define EXYNOS5_PWR_CTRL2			EXYNOS_CLKREG(0x01024)
+
+#define EXYNOS5_MPLL_CON0			EXYNOS_CLKREG(0x04100)
+#define EXYNOS5_CLKSRC_CORE1			EXYNOS_CLKREG(0x04204)
+
+#define EXYNOS5_CLKGATE_IP_CORE			EXYNOS_CLKREG(0x04900)
+
+#define EXYNOS5_CLKDIV_ACP			EXYNOS_CLKREG(0x08500)
+
+#define EXYNOS5_EPLL_CON0			EXYNOS_CLKREG(0x10130)
+#define EXYNOS5_EPLL_CON1			EXYNOS_CLKREG(0x10134)
+#define EXYNOS5_EPLL_CON2			EXYNOS_CLKREG(0x10138)
+#define EXYNOS5_VPLL_CON0			EXYNOS_CLKREG(0x10140)
+#define EXYNOS5_VPLL_CON1			EXYNOS_CLKREG(0x10144)
+#define EXYNOS5_VPLL_CON2			EXYNOS_CLKREG(0x10148)
+#define EXYNOS5_CPLL_CON0			EXYNOS_CLKREG(0x10120)
+
+#define EXYNOS5_CLKSRC_TOP0			EXYNOS_CLKREG(0x10210)
+#define EXYNOS5_CLKSRC_TOP1			EXYNOS_CLKREG(0x10214)
+#define EXYNOS5_CLKSRC_TOP2			EXYNOS_CLKREG(0x10218)
+#define EXYNOS5_CLKSRC_TOP3			EXYNOS_CLKREG(0x1021C)
+#define EXYNOS5_CLKSRC_GSCL			EXYNOS_CLKREG(0x10220)
+#define EXYNOS5_CLKSRC_DISP1_0			EXYNOS_CLKREG(0x1022C)
+#define EXYNOS5_CLKSRC_MAUDIO			EXYNOS_CLKREG(0x10240)
+#define EXYNOS5_CLKSRC_FSYS			EXYNOS_CLKREG(0x10244)
+#define EXYNOS5_CLKSRC_PERIC0			EXYNOS_CLKREG(0x10250)
+#define EXYNOS5_CLKSRC_PERIC1			EXYNOS_CLKREG(0x10254)
+#define EXYNOS5_SCLK_SRC_ISP			EXYNOS_CLKREG(0x10270)
+
+#define EXYNOS5_CLKSRC_MASK_TOP			EXYNOS_CLKREG(0x10310)
+#define EXYNOS5_CLKSRC_MASK_GSCL		EXYNOS_CLKREG(0x10320)
+#define EXYNOS5_CLKSRC_MASK_DISP1_0		EXYNOS_CLKREG(0x1032C)
+#define EXYNOS5_CLKSRC_MASK_MAUDIO		EXYNOS_CLKREG(0x10334)
+#define EXYNOS5_CLKSRC_MASK_FSYS		EXYNOS_CLKREG(0x10340)
+#define EXYNOS5_CLKSRC_MASK_PERIC0		EXYNOS_CLKREG(0x10350)
+#define EXYNOS5_CLKSRC_MASK_PERIC1		EXYNOS_CLKREG(0x10354)
+
+#define EXYNOS5_CLKDIV_TOP0			EXYNOS_CLKREG(0x10510)
+#define EXYNOS5_CLKDIV_TOP1			EXYNOS_CLKREG(0x10514)
+#define EXYNOS5_CLKDIV_GSCL			EXYNOS_CLKREG(0x10520)
+#define EXYNOS5_CLKDIV_DISP1_0			EXYNOS_CLKREG(0x1052C)
+#define EXYNOS5_CLKDIV_GEN			EXYNOS_CLKREG(0x1053C)
+#define EXYNOS5_CLKDIV_MAUDIO			EXYNOS_CLKREG(0x10544)
+#define EXYNOS5_CLKDIV_FSYS0			EXYNOS_CLKREG(0x10548)
+#define EXYNOS5_CLKDIV_FSYS1			EXYNOS_CLKREG(0x1054C)
+#define EXYNOS5_CLKDIV_FSYS2			EXYNOS_CLKREG(0x10550)
+#define EXYNOS5_CLKDIV_FSYS3			EXYNOS_CLKREG(0x10554)
+#define EXYNOS5_CLKDIV_PERIC0			EXYNOS_CLKREG(0x10558)
+#define EXYNOS5_CLKDIV_PERIC1			EXYNOS_CLKREG(0x1055C)
+#define EXYNOS5_CLKDIV_PERIC2			EXYNOS_CLKREG(0x10560)
+#define EXYNOS5_CLKDIV_PERIC3			EXYNOS_CLKREG(0x10564)
+#define EXYNOS5_CLKDIV_PERIC4			EXYNOS_CLKREG(0x10568)
+#define EXYNOS5_CLKDIV_PERIC5			EXYNOS_CLKREG(0x1056C)
+#define EXYNOS5_SCLK_DIV_ISP			EXYNOS_CLKREG(0x10580)
+
+#define EXYNOS5_CLKGATE_IP_ACP			EXYNOS_CLKREG(0x08800)
+#define EXYNOS5_CLKGATE_IP_ISP0			EXYNOS_CLKREG(0x0C800)
+#define EXYNOS5_CLKGATE_IP_ISP1			EXYNOS_CLKREG(0x0C804)
+#define EXYNOS5_CLKGATE_IP_GSCL			EXYNOS_CLKREG(0x10920)
+#define EXYNOS5_CLKGATE_IP_DISP1		EXYNOS_CLKREG(0x10928)
+#define EXYNOS5_CLKGATE_IP_MFC			EXYNOS_CLKREG(0x1092C)
+#define EXYNOS5_CLKGATE_IP_G3D			EXYNOS_CLKREG(0x10930)
+#define EXYNOS5_CLKGATE_IP_GEN			EXYNOS_CLKREG(0x10934)
+#define EXYNOS5_CLKGATE_IP_FSYS			EXYNOS_CLKREG(0x10944)
+#define EXYNOS5_CLKGATE_IP_GPS			EXYNOS_CLKREG(0x1094C)
+#define EXYNOS5_CLKGATE_IP_PERIC		EXYNOS_CLKREG(0x10950)
+#define EXYNOS5_CLKGATE_IP_PERIS		EXYNOS_CLKREG(0x10960)
+#define EXYNOS5_CLKGATE_BLOCK			EXYNOS_CLKREG(0x10980)
+
+#define EXYNOS5_BPLL_CON0			EXYNOS_CLKREG(0x20110)
+#define EXYNOS5_CLKSRC_CDREX			EXYNOS_CLKREG(0x20200)
+#define EXYNOS5_CLKDIV_CDREX			EXYNOS_CLKREG(0x20500)
+
+#define EXYNOS5_PLL_DIV2_SEL			EXYNOS_CLKREG(0x20A24)
+
+#define EXYNOS5_EPLL_LOCK			EXYNOS_CLKREG(0x10030)
+
+#define EXYNOS5_EPLLCON0_LOCKED_SHIFT		(29)
+
+#define PWR_CTRL1_CORE2_DOWN_RATIO		(7 << 28)
+#define PWR_CTRL1_CORE1_DOWN_RATIO		(7 << 16)
+#define PWR_CTRL1_DIV2_DOWN_EN			(1 << 9)
+#define PWR_CTRL1_DIV1_DOWN_EN			(1 << 8)
+#define PWR_CTRL1_USE_CORE1_WFE			(1 << 5)
+#define PWR_CTRL1_USE_CORE0_WFE			(1 << 4)
+#define PWR_CTRL1_USE_CORE1_WFI			(1 << 1)
+#define PWR_CTRL1_USE_CORE0_WFI			(1 << 0)
+
+#define PWR_CTRL2_DIV2_UP_EN			(1 << 25)
+#define PWR_CTRL2_DIV1_UP_EN			(1 << 24)
+#define PWR_CTRL2_DUR_STANDBY2_VAL		(1 << 16)
+#define PWR_CTRL2_DUR_STANDBY1_VAL		(1 << 8)
+#define PWR_CTRL2_CORE2_UP_RATIO		(1 << 4)
+#define PWR_CTRL2_CORE1_UP_RATIO		(1 << 0)
+
 /* Compatibility defines and inclusion */
 
 #include <mach/regs-pmu.h>

[PATCH] cpufreq: exynos: allow disabling cpufreq drivers

[Sylwester Nawrocki]

On 04/19/2013 10:43 PM, Arnd Bergmann wrote:
> On Friday 19 April 2013, Sylwester Nawrocki wrote:
>>> It could also be working by chance on EXYNOS4, since the register
>>> definitions were not actually removed from the regs-clk.h header
>>> for those.
>>
>> That's most likely what happened.
>
> Ok. I think I see the bigger picture now. The EXYNOS5 cpufreq driver was
> actually just merged now, so I assume that by the time Thomas did the clock
> changes, the register definitions for EXYNOS5 were actually unused and he
> subsequently removed them from the kernel.
>
> Since the driver now depends on them, I think the only way forward for 3.10
> is to revert the change that removed the definitions and put them back in
> place.

Yes, it sounds like a best thing to do. I was also considering that.

> We really should use the clock API from all the exynos cpufreq drivers, but it's
> too late for that change now in 3.10 and we will have to do it for 3.11 then.

Yes, the changes required to make the cpufreq driver using the clocks 
API would
be rather significant.

> This are not looking so good for exynos multiplatform support in 3.10 now, but
> if we get it in, that will mean we have to disable cpufreq when building
> multiplatform, but it can remain for the classic single-platform configurations.

Alright, let's hope eventually we get at least a minimum booting system. ;)

Thanks,
Sylwester

[PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5

[Olof Johansson]

On Fri, Apr 19, 2013 at 2:10 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Commit 6e6aac75 "ARM: EXYNOS: Migrate clock support to common
> clock framework" from Thomas Abraham removed the Exynos5 specific
> register definitions as they were unused at the time, but the
> cpufreq driver actually still uses them.
>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Tomasz Figa <t.figa@samsung.com>
> Cc: Thomas Abraham <thomas.abraham@linaro.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 8<----
>
> I'd apply this one on next/drivers to fix the build error, unless
> someone has concerns.

Acked-by: Olof Johansson <olof@lixom.net>