| Message ID | 1386964779-29457-1-git-send-email-tomasz.figa@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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 > -- 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
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 -- 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
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.
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 -- 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
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 -- 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
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 -- 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
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
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.