Message ID | 1354045994-8977-1-git-send-email-dianders@chromium.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Tue, Nov 27, 2012 at 11:53 AM, Doug Anderson <dianders@chromium.org> wrote: > The recent commit "ARM: EXYNOS: add support for EXYNOS5440 SoC" broke > support for exynos5250 because of_machine_is_compatible() was used too > early in the boot process. It also probably meant that the exynos5440 > failed to use the proper iotable. Switch to use > of_flat_dt_is_compatible() in both of these cases. > > The failure I was seeing in exynos5250 because of this was: > Division by zero in kernel. > [<80015ed4>] (unwind_backtrace+0x0/0xec) from [<8045c7a4>] (dump_stack+0x20/0x24) > [<8045c7a4>] (dump_stack+0x20/0x24) from [<80012990>] (__div0+0x20/0x28) > [<80012990>] (__div0+0x20/0x28) from [<8021ab04>] (Ldiv0_64+0x8/0x18) > [<8021ab04>] (Ldiv0_64+0x8/0x18) from [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) > [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) from [<8006865c>] (__clocksource_register_scale+0x1c/0x54) > [<8006865c>] (__clocksource_register_scale+0x1c/0x54) from [<80612a18>] (exynos_timer_init+0x100/0x1e8) > [<80612a18>] (exynos_timer_init+0x100/0x1e8) from [<8060d184>] (time_init+0x28/0x38) > [<8060d184>] (time_init+0x28/0x38) from [<8060a754>] (start_kernel+0x1e0/0x3c8) > [<8060a754>] (start_kernel+0x1e0/0x3c8) from [<40008078>] (0x40008078) > > Signed-off-by: Doug Anderson <dianders@chromium.org> Thanks Doug. Kukjin, I'll apply this directly on top of the previous branch in arm-soc, if that's OK with you. -Olof
On 11/28/12 07:11, Olof Johansson wrote: > On Tue, Nov 27, 2012 at 11:53 AM, Doug Anderson<dianders@chromium.org> wrote: >> The recent commit "ARM: EXYNOS: add support for EXYNOS5440 SoC" broke >> support for exynos5250 because of_machine_is_compatible() was used too >> early in the boot process. It also probably meant that the exynos5440 >> failed to use the proper iotable. Switch to use >> of_flat_dt_is_compatible() in both of these cases. >> >> The failure I was seeing in exynos5250 because of this was: >> Division by zero in kernel. >> [<80015ed4>] (unwind_backtrace+0x0/0xec) from [<8045c7a4>] (dump_stack+0x20/0x24) >> [<8045c7a4>] (dump_stack+0x20/0x24) from [<80012990>] (__div0+0x20/0x28) >> [<80012990>] (__div0+0x20/0x28) from [<8021ab04>] (Ldiv0_64+0x8/0x18) >> [<8021ab04>] (Ldiv0_64+0x8/0x18) from [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) >> [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) from [<8006865c>] (__clocksource_register_scale+0x1c/0x54) >> [<8006865c>] (__clocksource_register_scale+0x1c/0x54) from [<80612a18>] (exynos_timer_init+0x100/0x1e8) >> [<80612a18>] (exynos_timer_init+0x100/0x1e8) from [<8060d184>] (time_init+0x28/0x38) >> [<8060d184>] (time_init+0x28/0x38) from [<8060a754>] (start_kernel+0x1e0/0x3c8) >> [<8060a754>] (start_kernel+0x1e0/0x3c8) from [<40008078>] (0x40008078) >> >> Signed-off-by: Doug Anderson<dianders@chromium.org> > > Thanks Doug. > > Kukjin, I'll apply this directly on top of the previous branch in > arm-soc, if that's OK with you. > Sure, go ahead with my ack if you want, Acked-by: Kukjin Kim <kgene.kim@samsung.com> Note, actually there was a fix which uses soc_is_exynos5440() in my local :-) I'm not sure which one is better at this moment, but I'm OK on this. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
On Tue, Nov 27, 2012 at 2:27 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 11/28/12 07:11, Olof Johansson wrote: >> >> On Tue, Nov 27, 2012 at 11:53 AM, Doug Anderson<dianders@chromium.org> >> wrote: >>> >>> The recent commit "ARM: EXYNOS: add support for EXYNOS5440 SoC" broke >>> support for exynos5250 because of_machine_is_compatible() was used too >>> early in the boot process. It also probably meant that the exynos5440 >>> failed to use the proper iotable. Switch to use >>> of_flat_dt_is_compatible() in both of these cases. >>> >>> The failure I was seeing in exynos5250 because of this was: >>> Division by zero in kernel. >>> [<80015ed4>] (unwind_backtrace+0x0/0xec) from [<8045c7a4>] >>> (dump_stack+0x20/0x24) >>> [<8045c7a4>] (dump_stack+0x20/0x24) from [<80012990>] >>> (__div0+0x20/0x28) >>> [<80012990>] (__div0+0x20/0x28) from [<8021ab04>] (Ldiv0_64+0x8/0x18) >>> [<8021ab04>] (Ldiv0_64+0x8/0x18) from [<80068560>] >>> (__clocksource_updatefreq_scale+0x54/0x134) >>> [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) from >>> [<8006865c>] (__clocksource_register_scale+0x1c/0x54) >>> [<8006865c>] (__clocksource_register_scale+0x1c/0x54) from >>> [<80612a18>] (exynos_timer_init+0x100/0x1e8) >>> [<80612a18>] (exynos_timer_init+0x100/0x1e8) from [<8060d184>] >>> (time_init+0x28/0x38) >>> [<8060d184>] (time_init+0x28/0x38) from [<8060a754>] >>> (start_kernel+0x1e0/0x3c8) >>> [<8060a754>] (start_kernel+0x1e0/0x3c8) from [<40008078>] (0x40008078) >>> >>> Signed-off-by: Doug Anderson<dianders@chromium.org> >> >> >> Thanks Doug. >> >> Kukjin, I'll apply this directly on top of the previous branch in >> arm-soc, if that's OK with you. >> > Sure, go ahead with my ack if you want, > > Acked-by: Kukjin Kim <kgene.kim@samsung.com> > > Note, actually there was a fix which uses soc_is_exynos5440() in my local > :-) I'm not sure which one is better at this moment, but I'm OK on this. Ok, applied. Thanks all. -Olof
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c index 73b940f..b919f5f 100644 --- a/arch/arm/mach-exynos/common.c +++ b/arch/arm/mach-exynos/common.c @@ -18,6 +18,7 @@ #include <linux/sched.h> #include <linux/serial_core.h> #include <linux/of.h> +#include <linux/of_fdt.h> #include <linux/of_irq.h> #include <linux/export.h> #include <linux/irqdomain.h> @@ -335,8 +336,10 @@ void __init exynos_init_late(void) void __init exynos_init_io(struct map_desc *mach_desc, int size) { + unsigned long root = of_get_flat_dt_root(); + /* initialize the io descriptors we need for initialization */ - if (of_machine_is_compatible("samsung,exynos5440")) + if (of_flat_dt_is_compatible(root, "samsung,exynos5440")) iotable_init(exynos5440_iodesc, ARRAY_SIZE(exynos5440_iodesc)); else iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc)); diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c index 67fa3c2..7b76c3f 100644 --- a/arch/arm/mach-exynos/mach-exynos5-dt.c +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c @@ -122,9 +122,11 @@ static const struct of_dev_auxdata exynos5440_auxdata_lookup[] __initconst = { static void __init exynos5_dt_map_io(void) { + unsigned long root = of_get_flat_dt_root(); + exynos_init_io(NULL, 0); - if (of_machine_is_compatible("samsung,exynos5250")) + if (of_flat_dt_is_compatible(root, "samsung,exynos5250")) s3c24xx_init_clocks(24000000); }
The recent commit "ARM: EXYNOS: add support for EXYNOS5440 SoC" broke support for exynos5250 because of_machine_is_compatible() was used too early in the boot process. It also probably meant that the exynos5440 failed to use the proper iotable. Switch to use of_flat_dt_is_compatible() in both of these cases. The failure I was seeing in exynos5250 because of this was: Division by zero in kernel. [<80015ed4>] (unwind_backtrace+0x0/0xec) from [<8045c7a4>] (dump_stack+0x20/0x24) [<8045c7a4>] (dump_stack+0x20/0x24) from [<80012990>] (__div0+0x20/0x28) [<80012990>] (__div0+0x20/0x28) from [<8021ab04>] (Ldiv0_64+0x8/0x18) [<8021ab04>] (Ldiv0_64+0x8/0x18) from [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) from [<8006865c>] (__clocksource_register_scale+0x1c/0x54) [<8006865c>] (__clocksource_register_scale+0x1c/0x54) from [<80612a18>] (exynos_timer_init+0x100/0x1e8) [<80612a18>] (exynos_timer_init+0x100/0x1e8) from [<8060d184>] (time_init+0x28/0x38) [<8060d184>] (time_init+0x28/0x38) from [<8060a754>] (start_kernel+0x1e0/0x3c8) [<8060a754>] (start_kernel+0x1e0/0x3c8) from [<40008078>] (0x40008078) Signed-off-by: Doug Anderson <dianders@chromium.org> --- arch/arm/mach-exynos/common.c | 5 ++++- arch/arm/mach-exynos/mach-exynos5-dt.c | 4 +++- 2 files changed, 7 insertions(+), 2 deletions(-)