From: Tomasz Figa <hidden> Date: 2013-12-13 19:59:39
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.
This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.
Signed-off-by: Tomasz Figa <redacted>
---
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
NOTE: This is a critical boot regression fix for mach-s3c64xx that
should be merged for next 3.13-rc release.
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.
This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.
Signed-off-by: Tomasz Figa <redacted>
I see of_clk_init(NULL) getting called on two other ARM platforms:
$ git grep -w of_clk_init arch/arm
arch/arm/kernel/time.c: of_clk_init(NULL);
arch/arm/mach-keystone/pm_domain.c: of_clk_init(NULL);
arch/arm/mach-mvebu/armada-370-xp.c: of_clk_init(NULL);
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c: of_clk_init(NULL);
Are the other two platforms ok here?
I assume that mvebu is fine since Sebastian would have noticed breaking
that one and it has a custom init_time function, but keystone seems
broken in the same way as s3c64xx. Santosh, can you have a look?
Arnd
From: Olof Johansson <hidden> Date: 2013-12-14 05:50:29
On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann [off-list ref] wrote:
On Friday 13 December 2013, Tomasz Figa wrote:
quoted
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.
This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.
Signed-off-by: Tomasz Figa <redacted>
I see of_clk_init(NULL) getting called on two other ARM platforms:
$ git grep -w of_clk_init arch/arm
arch/arm/kernel/time.c: of_clk_init(NULL);
arch/arm/mach-keystone/pm_domain.c: of_clk_init(NULL);
arch/arm/mach-mvebu/armada-370-xp.c: of_clk_init(NULL);
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c: of_clk_init(NULL);
Are the other two platforms ok here?
I assume that mvebu is fine since Sebastian would have noticed breaking
that one and it has a custom init_time function, but keystone seems
broken in the same way as s3c64xx. Santosh, can you have a look?
Yeah, and Free Electrons also sent two systems to Kevin so he has them
in his boot test setup, and they're still happy there. Keystone lacks
such coverage though, so Santosh will need to check.
-Olof
Arnd, Olof,
On Saturday 14 December 2013 12:50 AM, Olof Johansson wrote:
On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 13 December 2013, Tomasz Figa wrote:
quoted
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.
This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.
Signed-off-by: Tomasz Figa <redacted>
I see of_clk_init(NULL) getting called on two other ARM platforms:
$ git grep -w of_clk_init arch/arm
arch/arm/kernel/time.c: of_clk_init(NULL);
arch/arm/mach-keystone/pm_domain.c: of_clk_init(NULL);
arch/arm/mach-mvebu/armada-370-xp.c: of_clk_init(NULL);
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c: of_clk_init(NULL);
Are the other two platforms ok here?
I assume that mvebu is fine since Sebastian would have noticed breaking
that one and it has a custom init_time function, but keystone seems
broken in the same way as s3c64xx. Santosh, can you have a look?
Yeah, and Free Electrons also sent two systems to Kevin so he has them
in his boot test setup, and they're still happy there. Keystone lacks
such coverage though, so Santosh will need to check.
Keystone isn't broken as such but some warnings are produced because of
the change. This was noticed on keystone quite a while back and a
patch[1] is already in my queue. It didn't click me that other
machines might have been also affected at that point of time.
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg288578.html
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.
This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.
Signed-off-by: Tomasz Figa <redacted>
Thomas,
thanks for catching this and sorry for the inconvenience. Either I
simply missed s3c64xx or it went in with that global of_clk_init
patch.
I see of_clk_init(NULL) getting called on two other ARM platforms:
$ git grep -w of_clk_init arch/arm
arch/arm/kernel/time.c: of_clk_init(NULL);
arch/arm/mach-keystone/pm_domain.c: of_clk_init(NULL);
arch/arm/mach-mvebu/armada-370-xp.c: of_clk_init(NULL);
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c: of_clk_init(NULL);
Are the other two platforms ok here?
mvebu is fine as long as it has its own .init_time callback (which it
has).
I assume that mvebu is fine since Sebastian would have noticed breaking
that one and it has a custom init_time function, but keystone seems
broken in the same way as s3c64xx. Santosh, can you have a look?
I also had a look at keystone and guess it is broken, too.
of_clk_init(NULL) is called in keystone_pm_runtime_init() which is
set as subsys_initcall. Simply removing the extra of_clk_init call
in keystone_pm_runtime_init should be enough here:
From 4ef4720c0d7ca9be57b06dc7ab1483c77a5ada1d Mon Sep 17 00:00:00 2001
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Sat, 14 Dec 2013 12:21:01 +0100
Subject: [PATCH] ARM: keystone: remove call to of_clk_init
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init(NULL) from default time_init callback.
This causes double clock initialization on keystone, leading to boot
failures.
This patch fixes boot failure on keystone by dropping the call to
of_clk_init(NULL) in keystone_pm_runtime_init(), which is set as
subsys_initcall and therefore called after arch-wide .init_time callback.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
arch/arm/mach-keystone/pm_domain.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-keystone/pm_domain.c
b/arch/arm/mach-keystone/pm_domain.c
index 2962523..3f17e16 100644
On Saturday 14 December 2013 06:47 AM, Sebastian Hesselbarth wrote:
[..]
From 4ef4720c0d7ca9be57b06dc7ab1483c77a5ada1d Mon Sep 17 00:00:00 2001
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Sat, 14 Dec 2013 12:21:01 +0100
Subject: [PATCH] ARM: keystone: remove call to of_clk_init
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init(NULL) from default time_init callback.
This causes double clock initialization on keystone, leading to boot
failures.
This patch fixes boot failure on keystone by dropping the call to
of_clk_init(NULL) in keystone_pm_runtime_init(), which is set as
subsys_initcall and therefore called after arch-wide .init_time callback.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
From: Olof Johansson <hidden> Date: 2013-12-14 05:52:11
On Fri, Dec 13, 2013 at 11:59 AM, Tomasz Figa [off-list ref] wrote:
Commit
4178bac ARM: call of_clk_init from default time_init handler
added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.
This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.
Signed-off-by: Tomasz Figa <redacted>
---
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
NOTE: This is a critical boot regression fix for mach-s3c64xx that
should be merged for next 3.13-rc release.
Applied to fixes. We sent a batch of fixes just the other day so this
will likely go in sometime next week, but it'll be in linux-next as of
the next release.
Hm, it'd be nice to get better coverage of 64xx as well as exynos 4.
Are there any cheap 64xx development boards out there?
-Olof