diff mbox

[CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

Message ID 1386964779-29457-1-git-send-email-tomasz.figa@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tomasz Figa Dec. 13, 2013, 7:59 p.m. UTC
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 <tomasz.figa@gmail.com>
---
 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.

Comments

Arnd Bergmann Dec. 14, 2013, 3 a.m. UTC | #1
On Friday 13 December 2013, Tomasz Figa 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 <tomasz.figa@gmail.com>

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

> diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> index 7eb9a10..2fddf38 100644
> --- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> +++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c

> @@ -48,15 +46,9 @@ static void __init s3c64xx_dt_map_io(void)
>  		panic("SoC is not S3C64xx!");
>  }
>  
> -static void __init s3c64xx_dt_init_irq(void)
> -{
> -	of_clk_init(NULL);
> -	samsung_wdt_reset_of_init();
> -	irqchip_init();
> -};
> -
>  static void __init s3c64xx_dt_init_machine(void)
>  {
> +	samsung_wdt_reset_of_init();
>  	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>  }
>  
> @@ -79,7 +71,6 @@ DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened Device Tree)")
>  	/* Maintainer: Tomasz Figa <tomasz.figa@gmail.com> */
>  	.dt_compat	= s3c64xx_dt_compat,
>  	.map_io		= s3c64xx_dt_map_io,
> -	.init_irq	= s3c64xx_dt_init_irq,
>  	.init_machine	= s3c64xx_dt_init_machine,
>  	.restart        = s3c64xx_dt_restart,
>  MACHINE_END
Olof Johansson Dec. 14, 2013, 5:50 a.m. UTC | #2
On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 13 December 2013, Tomasz Figa 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 <tomasz.figa@gmail.com>
>
> 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
Olof Johansson Dec. 14, 2013, 5:52 a.m. UTC | #3
On Fri, Dec 13, 2013 at 11:59 AM, Tomasz Figa <tomasz.figa@gmail.com> 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 <tomasz.figa@gmail.com>
> ---
>  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
Tomasz Figa Dec. 14, 2013, 12:41 p.m. UTC | #4
On Saturday 14 of December 2013 16:19:05 hua dillon wrote:
> hi olof:
> 
>   i think mini6410 from china is the board you want .

There were several cheap boards with S3C6410 available, but I'm not sure
how many of them are still on the market.

I guess Mini6410/Tiny6410 are, as I can at least see their prices there:
http://www.andahammer.com/mini6410-sdk/
http://www.andahammer.com/t6410sdk/

They are almost fully compatible, so they should be thought as just
a single Mini6410 board, but in different form factors. I do most of
my testing on the latter.

From other boards supported in mainline, there are:

 - A&W6410 (mach-anw6410) - I couldn't find any information on it
   anywhere,

 - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
   testing of audio codec AFAIK, but I'm not sure if you can get that
   anywhere.

 - HMT (mach-hmt), SmartQ 5/7 (mach-smartq*) - they are supposed to be
   some tablet-like products, but again I'm not sure if you can still
   get them,

 - SMDK6400/SMDK6410 are Samsung's official development boards for
   S3C6400/S3C6410 - I have access to one at the office; no idea if
   you can get one anywhere,

 - NCP - an abandoned Samsung's development board - you definitely
   can't get that anywhere; in fact I'd say that there is no more such
   board alive over the world and it just should be dropped from mainline.

That's all I can find at the moment. Anyway, I have copied Ben, maybe he
knows more than that.

Best regards,
Tomasz
Dillon Hua Dec. 14, 2013, 2:14 p.m. UTC | #5
Hi all

  Let's me give some information about s3c6410 dev board in china,all of them are very cheap.

Ok6410
http://www.witech.com.cn/product/FL6410.html

Ut6410
http://go.ppwan.com/?pp_mid=10&sid=33242

Real6410
Http://www.realarm.cn/pic/?76_451.html

Arm sys 6410
http://www.hzlitai.com.cn/product/ARM/ARM6410/ARMSYS6410-L43T42.html


???? iPad

> ? 2013?12?14????8:41?Tomasz Figa <tomasz.figa@gmail.com> ???
> 
>> On Saturday 14 of December 2013 16:19:05 hua dillon wrote:
>> hi olof:
>> 
>>  i think mini6410 from china is the board you want .
> 
> There were several cheap boards with S3C6410 available, but I'm not sure
> how many of them are still on the market.
> 
> I guess Mini6410/Tiny6410 are, as I can at least see their prices there:
> http://www.andahammer.com/mini6410-sdk/
> http://www.andahammer.com/t6410sdk/
> 
> They are almost fully compatible, so they should be thought as just
> a single Mini6410 board, but in different form factors. I do most of
> my testing on the latter.
> 
> From other boards supported in mainline, there are:
> 
> - A&W6410 (mach-anw6410) - I couldn't find any information on it
>   anywhere,
> 
> - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>   testing of audio codec AFAIK, but I'm not sure if you can get that
>   anywhere.
> 
> - HMT (mach-hmt), SmartQ 5/7 (mach-smartq*) - they are supposed to be
>   some tablet-like products, but again I'm not sure if you can still
>   get them,
> 
> - SMDK6400/SMDK6410 are Samsung's official development boards for
>   S3C6400/S3C6410 - I have access to one at the office; no idea if
>   you can get one anywhere,
> 
> - NCP - an abandoned Samsung's development board - you definitely
>   can't get that anywhere; in fact I'd say that there is no more such
>   board alive over the world and it just should be dropped from mainline.
> 
> That's all I can find at the moment. Anyway, I have copied Ben, maybe he
> knows more than that.
> 
> Best regards,
> Tomasz
>
Santosh Shilimkar Dec. 14, 2013, 5:28 p.m. UTC | #6
Arnd, Olof,

On Saturday 14 December 2013 12:50 AM, Olof Johansson wrote:
> On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Friday 13 December 2013, Tomasz Figa 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 <tomasz.figa@gmail.com>
>>
>> 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
Mark Brown Dec. 16, 2013, 9:09 p.m. UTC | #7
On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:

>  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>    testing of audio codec AFAIK, but I'm not sure if you can get that
>    anywhere.

Essentially no, though you could try asking nicely.  It's not suitable
for a test farm anyway without a SD mux as the only bootloader supported
is Qi which only boots from flash.

>  - SMDK6400/SMDK6410 are Samsung's official development boards for
>    S3C6400/S3C6410 - I have access to one at the office; no idea if
>    you can get one anywhere,

I believe they're no longer available though ICBW.  The cost for low
volume orders is likely to be a bit high too.
Charles Keepax Dec. 17, 2013, 3:14 p.m. UTC | #8
On Mon, Dec 16, 2013 at 09:09:15PM +0000, Mark Brown wrote:
> On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:
> 
> >  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
> >    testing of audio codec AFAIK, but I'm not sure if you can get that
> >    anywhere.
> 
> Essentially no, though you could try asking nicely.  It's not suitable
> for a test farm anyway without a SD mux as the only bootloader supported
> is Qi which only boots from flash.

Yeah, we don't have that many spare at the moment and whilst we
do use them fairly regularly we are not produce new boards
anymore.

Thanks,
Charles
Olof Johansson Dec. 17, 2013, 7:12 p.m. UTC | #9
On Tue, Dec 17, 2013 at 7:14 AM, Charles Keepax
<ckeepax@opensource.wolfsonmicro.com> wrote:
> On Mon, Dec 16, 2013 at 09:09:15PM +0000, Mark Brown wrote:
>> On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:
>>
>> >  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>> >    testing of audio codec AFAIK, but I'm not sure if you can get that
>> >    anywhere.
>>
>> Essentially no, though you could try asking nicely.  It's not suitable
>> for a test farm anyway without a SD mux as the only bootloader supported
>> is Qi which only boots from flash.
>
> Yeah, we don't have that many spare at the moment and whilst we
> do use them fairly regularly we are not produce new boards
> anymore.

Yeah, sounds unlikely to be a good fit.

Something like the tiny6410's would be useful. They seem to mostly be
available with LCD panels though, which ups the price a bit. I'll keep
an eye out for one.


-Olof
Olof Johansson June 10, 2014, 8:17 a.m. UTC | #10
On Tue, Dec 17, 2013 at 11:12 AM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Dec 17, 2013 at 7:14 AM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
>> On Mon, Dec 16, 2013 at 09:09:15PM +0000, Mark Brown wrote:
>>> On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:
>>>
>>> >  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>>> >    testing of audio codec AFAIK, but I'm not sure if you can get that
>>> >    anywhere.
>>>
>>> Essentially no, though you could try asking nicely.  It's not suitable
>>> for a test farm anyway without a SD mux as the only bootloader supported
>>> is Qi which only boots from flash.
>>
>> Yeah, we don't have that many spare at the moment and whilst we
>> do use them fairly regularly we are not produce new boards
>> anymore.
>
> Yeah, sounds unlikely to be a good fit.
>
> Something like the tiny6410's would be useful. They seem to mostly be
> available with LCD panels though, which ups the price a bit. I'll keep
> an eye out for one.

FWIW, I came across a store at Guang Hua Digital Plaza today that had
the tiny6410+SDK board on display, and ended up buying one. It'll take
me a little while to wire it up for testing.

Seems like there's no upstream u-boot support for the board, so
getting something onto it that can network boot seems to be a long
shot. We'll see what I can cobble together.


-Olof
diff mbox

Patch

diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
index 7eb9a10..2fddf38 100644
--- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -8,8 +8,6 @@ 
  * published by the Free Software Foundation.
 */
 
-#include <linux/clk-provider.h>
-#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 
 #include <asm/mach/arch.h>
@@ -48,15 +46,9 @@  static void __init s3c64xx_dt_map_io(void)
 		panic("SoC is not S3C64xx!");
 }
 
-static void __init s3c64xx_dt_init_irq(void)
-{
-	of_clk_init(NULL);
-	samsung_wdt_reset_of_init();
-	irqchip_init();
-};
-
 static void __init s3c64xx_dt_init_machine(void)
 {
+	samsung_wdt_reset_of_init();
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
@@ -79,7 +71,6 @@  DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened Device Tree)")
 	/* Maintainer: Tomasz Figa <tomasz.figa@gmail.com> */
 	.dt_compat	= s3c64xx_dt_compat,
 	.map_io		= s3c64xx_dt_map_io,
-	.init_irq	= s3c64xx_dt_init_irq,
 	.init_machine	= s3c64xx_dt_init_machine,
 	.restart        = s3c64xx_dt_restart,
 MACHINE_END