| Message ID | 1379499113-20342-1-git-send-email-yuvaraj.cd@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
[adding lakml] On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote: > Without the "clock-frequency" property in arch timer node, could able > to see the below crash dump. Why does this cause the below crash specifically? What is CNTFRQ reading as? Your firmware or bootloader should set CNTFRQ -- setting the clock-frequency is a work-around for buggy firmware/bootloaders that should be avoided as far as possible. Is it not possible to fix your firmware or bootlaoder to set CNTFRQ? Thanks, Mark. > > [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14) > [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0) > [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18) > [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) > [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) > [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) > [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) > [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58) > [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c) > [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c) > > Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> > --- > arch/arm/boot/dts/exynos5250.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi > index 7d7cc77..668ce5d 100644 > --- a/arch/arm/boot/dts/exynos5250.dtsi > +++ b/arch/arm/boot/dts/exynos5250.dtsi > @@ -96,6 +96,7 @@ > <1 14 0xf08>, > <1 11 0xf08>, > <1 10 0xf08>; > + clock-frequency = <24000000>; > }; > > mct@101C0000 { > -- > 1.7.9.5 > > -- 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
Resending it as it bounced from kernel mailing group On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland <mark.rutland@arm.com> wrote: > [adding lakml] > > On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote: >> Without the "clock-frequency" property in arch timer node, could able >> to see the below crash dump. > > Why does this cause the below crash specifically? What is CNTFRQ reading > as? Return value of arch_timer_get_cntfrq() is 0 > > Your firmware or bootloader should set CNTFRQ -- setting the > clock-frequency is a work-around for buggy firmware/bootloaders that > should be avoided as far as possible. Why kernel should depend on bootloader/firmware to set CNTFRQ? Any specific reasons? Should'nt be indepenedent each other(kernel and bootloader/firmware)? > > Is it not possible to fix your firmware or bootlaoder to set CNTFRQ? > > Thanks, > Mark. > >> >> [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14) >> [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0) >> [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18) >> [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) >> [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) >> [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) >> [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) >> [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58) >> [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c) >> [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c) >> >> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> >> --- >> arch/arm/boot/dts/exynos5250.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi >> index 7d7cc77..668ce5d 100644 >> --- a/arch/arm/boot/dts/exynos5250.dtsi >> +++ b/arch/arm/boot/dts/exynos5250.dtsi >> @@ -96,6 +96,7 @@ >> <1 14 0xf08>, >> <1 11 0xf08>, >> <1 10 0xf08>; >> + clock-frequency = <24000000>; >> }; >> >> mct@101C0000 { >> -- >> 1.7.9.5 >> >> -- 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 20/09/13 05:57, Yuvaraj Kumar wrote: > Resending it as it bounced from kernel mailing group > > On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland <mark.rutland@arm.com> wrote: >> [adding lakml] >> >> On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote: >>> Without the "clock-frequency" property in arch timer node, could able >>> to see the below crash dump. >> >> Why does this cause the below crash specifically? What is CNTFRQ reading >> as? > Return value of arch_timer_get_cntfrq() is 0 >> >> Your firmware or bootloader should set CNTFRQ -- setting the >> clock-frequency is a work-around for buggy firmware/bootloaders that >> should be avoided as far as possible. > Why kernel should depend on bootloader/firmware to set CNTFRQ? Any > specific reasons? Because the kernel can't set it if running non-secure. Only secure mode can do this (see the ARM ARM for details). > Should'nt be indepenedent each other(kernel and bootloader/firmware)? In my book, the firmware is responsible for setting up the platform in a sane state. Leaving CNTFRQ in its UNKNOWN reset state is a bug, and your firmware should program it on each CPU. Same goes for CNTVOFF, which should be set to a common value (preferably zero). M.
On 09/20/2013 04:17 AM, Marc Zyngier wrote: > On 20/09/13 05:57, Yuvaraj Kumar wrote: >> Resending it as it bounced from kernel mailing group >> >> On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland <mark.rutland@arm.com> wrote: >>> [adding lakml] >>> >>> On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote: >>>> Without the "clock-frequency" property in arch timer node, could able >>>> to see the below crash dump. >>> >>> Why does this cause the below crash specifically? What is CNTFRQ reading >>> as? >> Return value of arch_timer_get_cntfrq() is 0 >>> >>> Your firmware or bootloader should set CNTFRQ -- setting the >>> clock-frequency is a work-around for buggy firmware/bootloaders that >>> should be avoided as far as possible. >> Why kernel should depend on bootloader/firmware to set CNTFRQ? Any >> specific reasons? > > Because the kernel can't set it if running non-secure. Only secure mode > can do this (see the ARM ARM for details). What software outside the kernel actually reads the CNTFRQ and why? Thanks, Christopher
On 20/09/13 15:55, Christopher Covington wrote: > On 09/20/2013 04:17 AM, Marc Zyngier wrote: >> On 20/09/13 05:57, Yuvaraj Kumar wrote: >>> Resending it as it bounced from kernel mailing group >>> >>> On Wed, Sep 18, 2013 at 3:53 PM, Mark Rutland <mark.rutland@arm.com> wrote: >>>> [adding lakml] >>>> >>>> On Wed, Sep 18, 2013 at 11:11:53AM +0100, Yuvaraj Kumar C D wrote: >>>>> Without the "clock-frequency" property in arch timer node, could able >>>>> to see the below crash dump. >>>> >>>> Why does this cause the below crash specifically? What is CNTFRQ reading >>>> as? >>> Return value of arch_timer_get_cntfrq() is 0 >>>> >>>> Your firmware or bootloader should set CNTFRQ -- setting the >>>> clock-frequency is a work-around for buggy firmware/bootloaders that >>>> should be avoided as far as possible. >>> Why kernel should depend on bootloader/firmware to set CNTFRQ? Any >>> specific reasons? >> >> Because the kernel can't set it if running non-secure. Only secure mode >> can do this (see the ARM ARM for details). > > What software outside the kernel actually reads the CNTFRQ and why? Your favourite virtual machine does, for the same reason the host kernel does. And as you can't guess the frequency from userspace, you cannot specify it in the guest's DT, getting whatever random number sits in CNTFRQ. As you would expect, things don't go smoothly when that happens. M.
Hi Yuvaraj, On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: > Without the "clock-frequency" property in arch timer node, could able > to see the below crash dump. [snip] > diff --git a/arch/arm/boot/dts/exynos5250.dtsi > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 > --- a/arch/arm/boot/dts/exynos5250.dtsi > +++ b/arch/arm/boot/dts/exynos5250.dtsi > @@ -96,6 +96,7 @@ > <1 14 0xf08>, > <1 11 0xf08>, > <1 10 0xf08>; > + clock-frequency = <24000000>; Shouldn't it rather come from some clock provided by some clock controller instead? The frequency would be then retrieved using clk_get_rate() on a clock received by clk_get(), specified in device tree using generic clock bindings. 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
On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: > Hi Yuvaraj, > > On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: > > Without the "clock-frequency" property in arch timer node, could able > > to see the below crash dump. > [snip] > > diff --git a/arch/arm/boot/dts/exynos5250.dtsi > > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 > > --- a/arch/arm/boot/dts/exynos5250.dtsi > > +++ b/arch/arm/boot/dts/exynos5250.dtsi > > @@ -96,6 +96,7 @@ > > <1 14 0xf08>, > > <1 11 0xf08>, > > <1 10 0xf08>; > > + clock-frequency = <24000000>; > > Shouldn't it rather come from some clock provided by some clock controller > instead? > > The frequency would be then retrieved using clk_get_rate() on a clock > received by clk_get(), specified in device tree using generic clock > bindings. If the bootloader has initialised the generic timer correctly, the CNTFRQ register should contain the clock frequency, independent of any external clock. Having the bootloader set CNTFRQ is by far the preferable solution, it is architected for this purpose. Thanks, Mark. -- 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
[Adding Tony, who reported a mainline booting issue, and Sean who helped me track this down] On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: >> Hi Yuvaraj, >> >> On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: >> > Without the "clock-frequency" property in arch timer node, could able >> > to see the below crash dump. >> [snip] >> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi >> > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 >> > --- a/arch/arm/boot/dts/exynos5250.dtsi >> > +++ b/arch/arm/boot/dts/exynos5250.dtsi >> > @@ -96,6 +96,7 @@ >> > <1 14 0xf08>, >> > <1 11 0xf08>, >> > <1 10 0xf08>; >> > + clock-frequency = <24000000>; >> >> Shouldn't it rather come from some clock provided by some clock controller >> instead? >> >> The frequency would be then retrieved using clk_get_rate() on a clock >> received by clk_get(), specified in device tree using generic clock >> bindings. > > If the bootloader has initialised the generic timer correctly, the > CNTFRQ register should contain the clock frequency, independent of any > external clock. So, we just sat here to bisect a problem on the Samsung Chromebook where we hit exactly this problem. The read-only firmware on the device does not set CNTFRQ at boot, so this fails. Apparantly the u-boot that comes with Arndale sets it, so I haven't seen this error on that platform. > Having the bootloader set CNTFRQ is by far the preferable solution, it > is architected for this purpose. Unfortunately there is now real hardware out there that needs this due to firmware bugs / missing features, so there's little other choice. :( I'll pick this patch up in the fixes branch for 3.12, unless someone complains loudly. -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, Oct 08, 2013 at 11:15:47PM +0100, Olof Johansson wrote: > [Adding Tony, who reported a mainline booting issue, and Sean who > helped me track this down] > > On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: > >> Hi Yuvaraj, > >> > >> On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: > >> > Without the "clock-frequency" property in arch timer node, could able > >> > to see the below crash dump. > >> [snip] > >> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi > >> > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 > >> > --- a/arch/arm/boot/dts/exynos5250.dtsi > >> > +++ b/arch/arm/boot/dts/exynos5250.dtsi > >> > @@ -96,6 +96,7 @@ > >> > <1 14 0xf08>, > >> > <1 11 0xf08>, > >> > <1 10 0xf08>; > >> > + clock-frequency = <24000000>; > >> > >> Shouldn't it rather come from some clock provided by some clock controller > >> instead? > >> > >> The frequency would be then retrieved using clk_get_rate() on a clock > >> received by clk_get(), specified in device tree using generic clock > >> bindings. > > > > If the bootloader has initialised the generic timer correctly, the > > CNTFRQ register should contain the clock frequency, independent of any > > external clock. > > So, we just sat here to bisect a problem on the Samsung Chromebook > where we hit exactly this problem. The read-only firmware on the > device does not set CNTFRQ at boot, so this fails. Ouch. That's a shame. A chained bootloader (like the KVM guys are using) should be able to set CNTFRQ, so as long as any chained loader actually does that this won't cause that to blow up... > > Apparantly the u-boot that comes with Arndale sets it, so I haven't > seen this error on that platform. > > > Having the bootloader set CNTFRQ is by far the preferable solution, it > > is architected for this purpose. > > Unfortunately there is now real hardware out there that needs this due > to firmware bugs / missing features, so there's little other choice. > :( Indeed :( > > I'll pick this patch up in the fixes branch for 3.12, unless someone > complains loudly. Could you please add a note to the dts regarding why we actually need this? It would be nice to maintain the impression that this is not the preferred way of doing things... Cheers, Mark. -- 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 Wed, Oct 9, 2013 at 1:25 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Tue, Oct 08, 2013 at 11:15:47PM +0100, Olof Johansson wrote: >> [Adding Tony, who reported a mainline booting issue, and Sean who >> helped me track this down] >> >> On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: >> >> Hi Yuvaraj, >> >> >> >> On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: >> >> > Without the "clock-frequency" property in arch timer node, could able >> >> > to see the below crash dump. >> >> [snip] >> >> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi >> >> > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 >> >> > --- a/arch/arm/boot/dts/exynos5250.dtsi >> >> > +++ b/arch/arm/boot/dts/exynos5250.dtsi >> >> > @@ -96,6 +96,7 @@ >> >> > <1 14 0xf08>, >> >> > <1 11 0xf08>, >> >> > <1 10 0xf08>; >> >> > + clock-frequency = <24000000>; >> >> >> >> Shouldn't it rather come from some clock provided by some clock controller >> >> instead? >> >> >> >> The frequency would be then retrieved using clk_get_rate() on a clock >> >> received by clk_get(), specified in device tree using generic clock >> >> bindings. >> > >> > If the bootloader has initialised the generic timer correctly, the >> > CNTFRQ register should contain the clock frequency, independent of any >> > external clock. >> >> So, we just sat here to bisect a problem on the Samsung Chromebook >> where we hit exactly this problem. The read-only firmware on the >> device does not set CNTFRQ at boot, so this fails. > > Ouch. That's a shame. > > A chained bootloader (like the KVM guys are using) should be able to set > CNTFRQ, so as long as any chained loader actually does that this won't > cause that to blow up... Yes, but we have cases where we want to be able to boot without a chained u-boot as well. >> Apparantly the u-boot that comes with Arndale sets it, so I haven't >> seen this error on that platform. >> >> > Having the bootloader set CNTFRQ is by far the preferable solution, it >> > is architected for this purpose. >> >> Unfortunately there is now real hardware out there that needs this due >> to firmware bugs / missing features, so there's little other choice. >> :( > > Indeed :( > >> >> I'll pick this patch up in the fixes branch for 3.12, unless someone >> complains loudly. > > Could you please add a note to the dts regarding why we actually need > this? It would be nice to maintain the impression that this is not the > preferred way of doing things... s/dts/dtsi/, yes I can do that. Hopefully with that we won't get too much automated copy and paste to other platforms. It looks like current upstream u-boot got the timer enablement patches merged together with HYP support, which explains why I didn't see this on Arndale since it has a forked version of u-boot from Linaro somewhere. -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, Oct 8, 2013 at 5:15 PM, Olof Johansson <olof@lixom.net> wrote: > [Adding Tony, who reported a mainline booting issue, and Sean who > helped me track this down] > > On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: >>> Hi Yuvaraj, >>> >>> On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: >>> > Without the "clock-frequency" property in arch timer node, could able >>> > to see the below crash dump. >>> [snip] >>> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi >>> > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 >>> > --- a/arch/arm/boot/dts/exynos5250.dtsi >>> > +++ b/arch/arm/boot/dts/exynos5250.dtsi >>> > @@ -96,6 +96,7 @@ >>> > <1 14 0xf08>, >>> > <1 11 0xf08>, >>> > <1 10 0xf08>; >>> > + clock-frequency = <24000000>; >>> >>> Shouldn't it rather come from some clock provided by some clock controller >>> instead? >>> >>> The frequency would be then retrieved using clk_get_rate() on a clock >>> received by clk_get(), specified in device tree using generic clock >>> bindings. >> >> If the bootloader has initialised the generic timer correctly, the >> CNTFRQ register should contain the clock frequency, independent of any >> external clock. > > So, we just sat here to bisect a problem on the Samsung Chromebook > where we hit exactly this problem. The read-only firmware on the > device does not set CNTFRQ at boot, so this fails. > > Apparantly the u-boot that comes with Arndale sets it, so I haven't > seen this error on that platform. > >> Having the bootloader set CNTFRQ is by far the preferable solution, it >> is architected for this purpose. > > Unfortunately there is now real hardware out there that needs this due > to firmware bugs / missing features, so there's little other choice. > :( > > I'll pick this patch up in the fixes branch for 3.12, unless someone > complains loudly. Perhaps the subject should say something about this only applying to exynos. Rob -- 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 Wed, Oct 09, 2013 at 08:46:06PM +0100, Olof Johansson wrote: > On Wed, Oct 9, 2013 at 1:25 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Tue, Oct 08, 2013 at 11:15:47PM +0100, Olof Johansson wrote: > >> [Adding Tony, who reported a mainline booting issue, and Sean who > >> helped me track this down] > >> > >> On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> > On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: > >> >> Hi Yuvaraj, > >> >> > >> >> On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: > >> >> > Without the "clock-frequency" property in arch timer node, could able > >> >> > to see the below crash dump. > >> >> [snip] > >> >> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi > >> >> > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 > >> >> > --- a/arch/arm/boot/dts/exynos5250.dtsi > >> >> > +++ b/arch/arm/boot/dts/exynos5250.dtsi > >> >> > @@ -96,6 +96,7 @@ > >> >> > <1 14 0xf08>, > >> >> > <1 11 0xf08>, > >> >> > <1 10 0xf08>; > >> >> > + clock-frequency = <24000000>; > >> >> > >> >> Shouldn't it rather come from some clock provided by some clock controller > >> >> instead? > >> >> > >> >> The frequency would be then retrieved using clk_get_rate() on a clock > >> >> received by clk_get(), specified in device tree using generic clock > >> >> bindings. > >> > > >> > If the bootloader has initialised the generic timer correctly, the > >> > CNTFRQ register should contain the clock frequency, independent of any > >> > external clock. > >> > >> So, we just sat here to bisect a problem on the Samsung Chromebook > >> where we hit exactly this problem. The read-only firmware on the > >> device does not set CNTFRQ at boot, so this fails. > > > > Ouch. That's a shame. > > > > A chained bootloader (like the KVM guys are using) should be able to set > > CNTFRQ, so as long as any chained loader actually does that this won't > > cause that to blow up... > > Yes, but we have cases where we want to be able to boot without a > chained u-boot as well. Sorry, that was poorly worded on my behalf. I meant that in the main case I'm aware of where the having the clock-frequency property wasn't good enough (because it doesn't get propagated to guests), we have another workaround. > > >> Apparantly the u-boot that comes with Arndale sets it, so I haven't > >> seen this error on that platform. > >> > >> > Having the bootloader set CNTFRQ is by far the preferable solution, it > >> > is architected for this purpose. > >> > >> Unfortunately there is now real hardware out there that needs this due > >> to firmware bugs / missing features, so there's little other choice. > >> :( > > > > Indeed :( > > > >> > >> I'll pick this patch up in the fixes branch for 3.12, unless someone > >> complains loudly. > > > > Could you please add a note to the dts regarding why we actually need > > this? It would be nice to maintain the impression that this is not the > > preferred way of doing things... > > s/dts/dtsi/, yes I can do that. Hopefully with that we won't get too > much automated copy and paste to other platforms. Cheers! Thanks, Mark. -- 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 Wed, Oct 09, 2013 at 04:48:32PM -0500, Rob Herring wrote: > On Tue, Oct 8, 2013 at 5:15 PM, Olof Johansson <olof@lixom.net> wrote: > > [Adding Tony, who reported a mainline booting issue, and Sean who > > helped me track this down] > > > > On Mon, Sep 23, 2013 at 7:15 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> On Sat, Sep 21, 2013 at 04:24:59PM +0100, Tomasz Figa wrote: > >>> Hi Yuvaraj, > >>> > >>> On Wednesday 18 of September 2013 15:41:53 Yuvaraj Kumar C D wrote: > >>> > Without the "clock-frequency" property in arch timer node, could able > >>> > to see the below crash dump. > >>> [snip] > >>> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi > >>> > b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 > >>> > --- a/arch/arm/boot/dts/exynos5250.dtsi > >>> > +++ b/arch/arm/boot/dts/exynos5250.dtsi > >>> > @@ -96,6 +96,7 @@ > >>> > <1 14 0xf08>, > >>> > <1 11 0xf08>, > >>> > <1 10 0xf08>; > >>> > + clock-frequency = <24000000>; > >>> > >>> Shouldn't it rather come from some clock provided by some clock controller > >>> instead? > >>> > >>> The frequency would be then retrieved using clk_get_rate() on a clock > >>> received by clk_get(), specified in device tree using generic clock > >>> bindings. > >> > >> If the bootloader has initialised the generic timer correctly, the > >> CNTFRQ register should contain the clock frequency, independent of any > >> external clock. > > > > So, we just sat here to bisect a problem on the Samsung Chromebook > > where we hit exactly this problem. The read-only firmware on the > > device does not set CNTFRQ at boot, so this fails. > > > > Apparantly the u-boot that comes with Arndale sets it, so I haven't > > seen this error on that platform. > > > >> Having the bootloader set CNTFRQ is by far the preferable solution, it > >> is architected for this purpose. > > > > Unfortunately there is now real hardware out there that needs this due > > to firmware bugs / missing features, so there's little other choice. > > :( > > > > I'll pick this patch up in the fixes branch for 3.12, unless someone > > complains loudly. > > Perhaps the subject should say something about this only applying to exynos. Definitely, and I'll add a comment as Mark requested. -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 Wed, Sep 18, 2013 at 03:41:53PM +0530, Yuvaraj Kumar C D wrote: > Without the "clock-frequency" property in arch timer node, could able > to see the below crash dump. > > [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14) > [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0) > [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18) > [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) > [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) > [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) > [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) > [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58) > [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c) > [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c) > > Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> Applied with subject: ARM: exynos: dts: Update 5250 arch timer node with clock frequency -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/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 7d7cc77..668ce5d 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -96,6 +96,7 @@ <1 14 0xf08>, <1 11 0xf08>, <1 10 0xf08>; + clock-frequency = <24000000>; }; mct@101C0000 {
Without the "clock-frequency" property in arch timer node, could able to see the below crash dump. [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14) [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0) [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18) [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58) [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c) [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c) Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> --- arch/arm/boot/dts/exynos5250.dtsi | 1 + 1 file changed, 1 insertion(+)