Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
1;3803;0c On Fri, Oct 02, 2015 at 12:15:52PM +0100, Julien Grall wrote: > On 02/10/15 11:53, Maxime Ripard wrote: > >> If no, that's very unfortunate because it means that you can't > >> re-use the same DT across multiple OS and the DT provided by the > >> firmware (if it's built-in). > > > > Is there such OS yet (and by that, I mean one that actually shares our > > DT, instead of rewriting its own) ? > > Yes, FreeBSD started to support the DT provided by vendors which are > based on Linux bindings. The ARM64 port is only using DTB provided by > the hardware. For ARM32, there is still some platform using a specific > DT for FreeBSD but they are trying to get a ride. Well, it would have been good if they contacted us in the first place then, because this has never been considered seriously afaik, and we never stated that it actually was an ABI. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
On 02/10/15 11:53, Maxime Ripard wrote: >> If no, that's very unfortunate because it means that you can't >> re-use the same DT across multiple OS and the DT provided by the >> firmware (if it's built-in). > > Is there such OS yet (and by that, I mean one that actually shares our > DT, instead of rewriting its own) ? Yes, FreeBSD started to support the DT provided by vendors which are based on Linux bindings. The ARM64 port is only using DTB provided by the hardware. For ARM32, there is still some platform using a specific DT for FreeBSD but they are trying to get a ride. Regards, -- Julien Grall -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
Hi, On Fri, Oct 02, 2015 at 11:07:35AM +0100, Julien Grall wrote: > Hi Maxime, > > On 01/10/15 21:45, Maxime Ripard wrote: > > On Thu, Oct 01, 2015 at 09:47:11AM +0100, Ian Campbell wrote: > >> Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 > >> based) breaks on Cubietruck because that DTB lacks the clock-indices nodes > >> which the new driver from the commit below adds (replacing the hardcoding > >> which used to be in clk-sunxi.c). > >> > >> It is panicing in drivers/clocksource/timer-sun5i.c with: > >> > >> [0.015413] clocksource: timer: mask: 0x max_cycles: > >> 0x, max_idle_ns: 79635851949 ns > >> [0.025049] Kernel panic - not syncing: Can't get timer clock > >> [0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > >> 4.3.0-rc2-arm-native+ #6 > >> [0.038002] Hardware name: Allwinner sun7i (A20) Family > >> [0.043253] [] (unwind_backtrace) from [] > >> (show_stack+0x10/0x14) > >> [0.050992] [] (show_stack) from [] > >> (dump_stack+0x88/0x98) > >> [0.058213] [] (dump_stack) from [] > >> (panic+0xa4/0x22c) > >> [0.065090] [] (panic) from [] > >> (sun5i_timer_init+0x80/0x384) > >> [0.072482] [] (sun5i_timer_init) from [] > >> (clocksource_of_init+0x4c/0x8c) > >> [0.081001] [] (clocksource_of_init) from [] > >> (start_kernel+0x28c/0x3c4) > >> [0.089343] [] (start_kernel) from [<4020807c>] (0x4020807c) > >> [0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock > >> > >> Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, > >> but there seems to be other problems later when earlycon hands over to > >> proper console, which I've not yet looked into). > >> > >> Is this considered acceptable linkage between the kernel and the dtbs? > >> > >> I suspect that even if anyone does care this is going to be an uphill > >> struggle for that minority so I'm going to adjust our test infrastructure > >> to pickup the dtbs from the kernel it is trying to test rather then reusing > >> the one from the OS install. > > > > It's never been something we supported (or even claim to support), so > > it's actually surprising that it's the only commit that need to be > > reverted, but yeah, you should keep your DTB in sync. > > I would have though the bindings are stable, i.e the compatibility with > old DT would have been kept in newer kernel. > > So is it something specific to cubietruck? Nope. All the platforms I've been using on a regular basis do not guarantee this. Allwinner, obviously, but also: Atmel: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n110 OMAP: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8b9a2810b02e3d9806ba2bf307c8e8dcedaf902d Berlin: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd26031ba6356d2b0f7aa214ebff4b12736b6529 Rockchip: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=26ab69cb4c1f77060bece483f2ec210163867782 etc... > If no, that's very unfortunate because it means that you can't > re-use the same DT across multiple OS and the DT provided by the > firmware (if it's built-in). Is there such OS yet (and by that, I mean one that actually shares our DT, instead of rewriting its own) ? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
Hi Maxime, On 01/10/15 21:45, Maxime Ripard wrote: > On Thu, Oct 01, 2015 at 09:47:11AM +0100, Ian Campbell wrote: >> Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 >> based) breaks on Cubietruck because that DTB lacks the clock-indices nodes >> which the new driver from the commit below adds (replacing the hardcoding >> which used to be in clk-sunxi.c). >> >> It is panicing in drivers/clocksource/timer-sun5i.c with: >> >> [0.015413] clocksource: timer: mask: 0x max_cycles: 0x, >> max_idle_ns: 79635851949 ns >> [0.025049] Kernel panic - not syncing: Can't get timer clock >> [0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 4.3.0-rc2-arm-native+ #6 >> [0.038002] Hardware name: Allwinner sun7i (A20) Family >> [0.043253] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [0.050992] [] (show_stack) from [] >> (dump_stack+0x88/0x98) >> [0.058213] [] (dump_stack) from [] (panic+0xa4/0x22c) >> [0.065090] [] (panic) from [] >> (sun5i_timer_init+0x80/0x384) >> [0.072482] [] (sun5i_timer_init) from [] >> (clocksource_of_init+0x4c/0x8c) >> [0.081001] [] (clocksource_of_init) from [] >> (start_kernel+0x28c/0x3c4) >> [0.089343] [] (start_kernel) from [<4020807c>] (0x4020807c) >> [0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock >> >> Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, >> but there seems to be other problems later when earlycon hands over to >> proper console, which I've not yet looked into). >> >> Is this considered acceptable linkage between the kernel and the dtbs? >> >> I suspect that even if anyone does care this is going to be an uphill >> struggle for that minority so I'm going to adjust our test infrastructure >> to pickup the dtbs from the kernel it is trying to test rather then reusing >> the one from the OS install. > > It's never been something we supported (or even claim to support), so > it's actually surprising that it's the only commit that need to be > reverted, but yeah, you should keep your DTB in sync. I would have though the bindings are stable, i.e the compatibility with old DT would have been kept in newer kernel. So is it something specific to cubietruck? If no, that's very unfortunate because it means that you can't re-use the same DT across multiple OS and the DT provided by the firmware (if it's built-in). Regards, -- Julien Grall -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
Hi Ian, On Thu, Oct 01, 2015 at 09:47:11AM +0100, Ian Campbell wrote: > Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 > based) breaks on Cubietruck because that DTB lacks the clock-indices nodes > which the new driver from the commit below adds (replacing the hardcoding > which used to be in clk-sunxi.c). > > It is panicing in drivers/clocksource/timer-sun5i.c with: > > [0.015413] clocksource: timer: mask: 0x max_cycles: 0x, > max_idle_ns: 79635851949 ns > [0.025049] Kernel panic - not syncing: Can't get timer clock > [0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 4.3.0-rc2-arm-native+ #6 > [0.038002] Hardware name: Allwinner sun7i (A20) Family > [0.043253] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [0.050992] [] (show_stack) from [] > (dump_stack+0x88/0x98) > [0.058213] [] (dump_stack) from [] (panic+0xa4/0x22c) > [0.065090] [] (panic) from [] > (sun5i_timer_init+0x80/0x384) > [0.072482] [] (sun5i_timer_init) from [] > (clocksource_of_init+0x4c/0x8c) > [0.081001] [] (clocksource_of_init) from [] > (start_kernel+0x28c/0x3c4) > [0.089343] [] (start_kernel) from [<4020807c>] (0x4020807c) > [0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock > > Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, > but there seems to be other problems later when earlycon hands over to > proper console, which I've not yet looked into). > > Is this considered acceptable linkage between the kernel and the dtbs? > > I suspect that even if anyone does care this is going to be an uphill > struggle for that minority so I'm going to adjust our test infrastructure > to pickup the dtbs from the kernel it is trying to test rather then reusing > the one from the OS install. It's never been something we supported (or even claim to support), so it's actually surprising that it's the only commit that need to be reverted, but yeah, you should keep your DTB in sync. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
"clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 based) breaks on Cubietruck because that DTB lacks the clock-indices nodes which the new driver from the commit below adds (replacing the hardcoding which used to be in clk-sunxi.c). It is panicing in drivers/clocksource/timer-sun5i.c with: [0.015413] clocksource: timer: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.025049] Kernel panic - not syncing: Can't get timer clock [0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.3.0-rc2-arm-native+ #6 [0.038002] Hardware name: Allwinner sun7i (A20) Family [0.043253] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [0.050992] [] (show_stack) from [] (dump_stack+0x88/0x98) [0.058213] [] (dump_stack) from [] (panic+0xa4/0x22c) [0.065090] [] (panic) from [] (sun5i_timer_init+0x80/0x384) [0.072482] [] (sun5i_timer_init) from [] (clocksource_of_init+0x4c/0x8c) [0.081001] [] (clocksource_of_init) from [] (start_kernel+0x28c/0x3c4) [0.089343] [] (start_kernel) from [<4020807c>] (0x4020807c) [0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, but there seems to be other problems later when earlycon hands over to proper console, which I've not yet looked into). Is this considered acceptable linkage between the kernel and the dtbs? I suspect that even if anyone does care this is going to be an uphill struggle for that minority so I'm going to adjust our test infrastructure to pickup the dtbs from the kernel it is trying to test rather then reusing the one from the OS install. Ian. commit ee38b2698ae234c03f65ccafa1811d4dda3c316d Author: Maxime Ripard Date: Fri Jul 31 19:46:22 2015 +0200 clk: sunxi: Add a simple gates driver The gates were handled with a common piece of framework that was registering all gates array, that was not using the CLK_OF_DECLARE logic, and was not using clock-indices but some private masks that were pretty much equivalent. Move this code in a new driver that handles all the gates array and solves both these issues. Signed-off-by: Maxime Ripard Signed-off-by: Michael Turquette [sb...@codeaurora.org: Include clk.h for consumer API usage] Signed-off-by: Stephen Boyd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
