* [PATCH] cpufreq: exynos: allow disabling cpufreq drivers [not found] <201304191554.29679.arnd@arndb.de> @ 2013-04-19 16:51 ` Sylwester Nawrocki 2013-04-19 18:59 ` Arnd Bergmann 0 siblings, 1 reply; 7+ messages in thread From: Sylwester Nawrocki @ 2013-04-19 16:51 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: exynos: allow disabling cpufreq drivers 2013-04-19 16:51 ` [PATCH] cpufreq: exynos: allow disabling cpufreq drivers Sylwester Nawrocki @ 2013-04-19 18:59 ` Arnd Bergmann 2013-04-19 20:37 ` Sylwester Nawrocki 0 siblings, 1 reply; 7+ messages in thread From: Arnd Bergmann @ 2013-04-19 18:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: exynos: allow disabling cpufreq drivers 2013-04-19 18:59 ` Arnd Bergmann @ 2013-04-19 20:37 ` Sylwester Nawrocki 2013-04-19 20:43 ` Arnd Bergmann 2013-04-19 21:10 ` [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5 Arnd Bergmann 0 siblings, 2 replies; 7+ messages in thread From: Sylwester Nawrocki @ 2013-04-19 20:37 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: exynos: allow disabling cpufreq drivers 2013-04-19 20:37 ` Sylwester Nawrocki @ 2013-04-19 20:43 ` Arnd Bergmann 2013-04-19 21:12 ` Sylwester Nawrocki 2013-04-19 21:10 ` [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5 Arnd Bergmann 1 sibling, 1 reply; 7+ messages in thread From: Arnd Bergmann @ 2013-04-19 20:43 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] cpufreq: exynos: allow disabling cpufreq drivers 2013-04-19 20:43 ` Arnd Bergmann @ 2013-04-19 21:12 ` Sylwester Nawrocki 0 siblings, 0 replies; 7+ messages in thread From: Sylwester Nawrocki @ 2013-04-19 21:12 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5 2013-04-19 20:37 ` Sylwester Nawrocki 2013-04-19 20:43 ` Arnd Bergmann @ 2013-04-19 21:10 ` Arnd Bergmann 2013-04-19 21:17 ` Olof Johansson 1 sibling, 1 reply; 7+ messages in thread From: Arnd Bergmann @ 2013-04-19 21:10 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5 2013-04-19 21:10 ` [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5 Arnd Bergmann @ 2013-04-19 21:17 ` Olof Johansson 0 siblings, 0 replies; 7+ messages in thread From: Olof Johansson @ 2013-04-19 21:17 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-04-19 21:17 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <201304191554.29679.arnd@arndb.de>
2013-04-19 16:51 ` [PATCH] cpufreq: exynos: allow disabling cpufreq drivers Sylwester Nawrocki
2013-04-19 18:59 ` Arnd Bergmann
2013-04-19 20:37 ` Sylwester Nawrocki
2013-04-19 20:43 ` Arnd Bergmann
2013-04-19 21:12 ` Sylwester Nawrocki
2013-04-19 21:10 ` [PATCH] ARM: exynos: restore mach/regs-clock.h for exynos5 Arnd Bergmann
2013-04-19 21:17 ` Olof Johansson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).