Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Jan 14, 2015 at 11:10:08PM +, Russell King - ARM Linux wrote: > On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote: > > This seems like it could be a similar issue to what we were seeing on > > omap3 where the legacy IRQ mappings went wrong without using the > > irq_domain_add_legacy(). Maybe vexpress affects NR_IRQS or something? > > > > Also, I think we could now disable the legacy DMA init completely > > except for omap2 and 3. > > I've added a "cat /proc/interrupts" which should reveal whether the IRQs > have changed between the two different builds. Okay, both omap4 and combined kernels indicate that the legacy DMA gets the same interrupt: 44: 0 0 4a31.gpio 18 DMA so that can't be the issue as the combined kernel spits out the warning, but the omap4 kernel doesn't. Something else is going on which causes this; the hint that it's got something to do with this is just a symptom of some other problem. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [150114 09:54]: > > On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: > > > The "combined" kernel boot follows a similar pattern, but yets a bit > > > further before oopsing, with ASoC DAPM code printing random bits of > > > kernel memory. > > > > Note that the "combined" kernel (which is OMAP4 + Versatile Express) > > has for a while now also spat out this: > > > > WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 > > l3_interrupt_handler+0x218/0x2f0() > > 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access > > in Supervisor mode during Functional access > > Modules linked in: > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 > > Hardware name: Generic OMAP4 (Flattened Device Tree) > > Backtrace: > > [] (dump_backtrace) from [] (show_stack+0x18/0x1c) > > r6:c04c073e r5:0009 r4: r3:00200040 > > [] (show_stack) from [] (dump_stack+0x78/0x94) > > [] (dump_stack) from [] (warn_slowpath_common+0x8c/0xb8) > > r4:ce461b38 r3:ce458000 > > [] (warn_slowpath_common) from [] > > (warn_slowpath_fmt+0x38/0x40) > > r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 > > [] (warn_slowpath_fmt) from [] > > (l3_interrupt_handler+0x218/0x2f0) > > r3:ce54ad40 r2:c04c0772 > > [] (l3_interrupt_handler) from [] > > (handle_irq_event_percpu+0x38/0x13c) > > r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 > > r4:ce54f480 > > [] (handle_irq_event_percpu) from [] > > (handle_irq_event+0x44/0x64) > > r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 > > r4:ce440700 > > [] (handle_irq_event) from [] > > (handle_fasteoi_irq+0xb0/0x128) > > r6:ce440760 r5:c06c5fec r4:ce440700 r3: > > [] (handle_fasteoi_irq) from [] > > (generic_handle_irq+0x28/0x38) > > r6:ce408000 r5: r4:0013 r3:c0079544 > > [] (generic_handle_irq) from [] > > (__handle_domain_irq+0x90/0xb8) > > r4: r3:0110 > > [] (__handle_domain_irq) from [] > > (gic_handle_irq+0x44/0x68) > > r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 > > [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c) > > Exception stack(0xce461cd8 to 0xce461d20) > > 1cc0: 0001 > > ce458508 > > 1ce0: 6113 ce5b1960 002c ce5b1960 > > ce5b1938 > > 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 > > > > r6: r5:2113 r4:c046df64 r3:ce458000 > > [] (_raw_spin_unlock_irqrestore) from [] > > (__setup_irq+0x3bc/0x4e4) > > r5:c06b7c00 r4:ce5b1900 > > [] (__setup_irq) from [] (setup_irq+0x50/0x90) > > r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c > > r4:ce5b1900 > > [] (setup_irq) from [] > > (omap_system_dma_probe+0x20c/0x2a4) > > r6:ce67ec10 r5:002c r4:0020 r3:0002 > > [] (omap_system_dma_probe) from [] > > (platform_drv_probe+0x50/0x98) > > r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed > > r4:ce67ec10 > > [] (platform_drv_probe) from [] > > (driver_probe_device+0x13c/0x34c) > > r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 > > [] (driver_probe_device) from [] > > (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 > > r4:ce67ec10 > > [] (__driver_attach) from [] > > (bus_for_each_dev+0x5c/0x98) > > r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 > > [] (bus_for_each_dev) from [] (driver_attach+0x20/0x28) > > r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 > > [] (driver_attach) from [] (bus_add_driver+0xf8/0x1fc) > > [] (bus_add_driver) from [] (driver_register+0xa4/0xe8) > > r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 > > [] (driver_register) from [] > > (__platform_driver_register+0x50/0x64) > > r5:c068d0e8 r4:ce621f80 > > [] (__platform_driver_register) from [] > > (omap_system_dma_init+0x18/0x20) > > [] (omap_system_dma_init) from [] > > (do_one_initcall+0x114/0x1e0) > > [] (do_one_initcall) from [] > > (kernel_init_freeable+0x110/0x1dc) > > r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 > > r4:0003 > > [] (kernel_init_freeable) from [] > > (kernel_init+0x10/0xec) > > r10: r8: r7: r6: r5:c0460830 r4: > > [] (kernel_init) from [] (ret_from_fork+0x14/0x24) > > r4: r3: > > ---[ end trace bcb85e0273c31888 ]--- > > OMAP DMA hardware revision 0.0 > > > > This does not occur when booting the plain "omap4" kernel. > > > > I thought it may be related to another error which people have been > > reporting, but as it's still there, I thought I should report it. > > > > To me, this suggests that Versatile Express code may be initialising > > on non-Versatile Express hardware, possibly touching hardware, but > > it looks like it's happening within the setup_irq() called from the > > legacy OM
Re: OMAP 4430 SDP: rather sick with recent kernels
* Tony Lindgren [150114 11:16]: > * Russell King - ARM Linux [150114 09:54]: > > On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: > > > The "combined" kernel boot follows a similar pattern, but yets a bit > > > further before oopsing, with ASoC DAPM code printing random bits of > > > kernel memory. > > > > Note that the "combined" kernel (which is OMAP4 + Versatile Express) > > has for a while now also spat out this: > > > > WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 > > l3_interrupt_handler+0x218/0x2f0() > > 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access > > in Supervisor mode during Functional access > > Modules linked in: > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 > > Hardware name: Generic OMAP4 (Flattened Device Tree) > > Backtrace: > > [] (dump_backtrace) from [] (show_stack+0x18/0x1c) > > r6:c04c073e r5:0009 r4: r3:00200040 > > [] (show_stack) from [] (dump_stack+0x78/0x94) > > [] (dump_stack) from [] (warn_slowpath_common+0x8c/0xb8) > > r4:ce461b38 r3:ce458000 > > [] (warn_slowpath_common) from [] > > (warn_slowpath_fmt+0x38/0x40) > > r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 > > [] (warn_slowpath_fmt) from [] > > (l3_interrupt_handler+0x218/0x2f0) > > r3:ce54ad40 r2:c04c0772 > > [] (l3_interrupt_handler) from [] > > (handle_irq_event_percpu+0x38/0x13c) > > r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 > > r4:ce54f480 > > [] (handle_irq_event_percpu) from [] > > (handle_irq_event+0x44/0x64) > > r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 > > r4:ce440700 > > [] (handle_irq_event) from [] > > (handle_fasteoi_irq+0xb0/0x128) > > r6:ce440760 r5:c06c5fec r4:ce440700 r3: > > [] (handle_fasteoi_irq) from [] > > (generic_handle_irq+0x28/0x38) > > r6:ce408000 r5: r4:0013 r3:c0079544 > > [] (generic_handle_irq) from [] > > (__handle_domain_irq+0x90/0xb8) > > r4: r3:0110 > > [] (__handle_domain_irq) from [] > > (gic_handle_irq+0x44/0x68) > > r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 > > [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c) > > Exception stack(0xce461cd8 to 0xce461d20) > > 1cc0: 0001 > > ce458508 > > 1ce0: 6113 ce5b1960 002c ce5b1960 > > ce5b1938 > > 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 > > > > r6: r5:2113 r4:c046df64 r3:ce458000 > > [] (_raw_spin_unlock_irqrestore) from [] > > (__setup_irq+0x3bc/0x4e4) > > r5:c06b7c00 r4:ce5b1900 > > [] (__setup_irq) from [] (setup_irq+0x50/0x90) > > r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c > > r4:ce5b1900 > > [] (setup_irq) from [] > > (omap_system_dma_probe+0x20c/0x2a4) > > r6:ce67ec10 r5:002c r4:0020 r3:0002 > > [] (omap_system_dma_probe) from [] > > (platform_drv_probe+0x50/0x98) > > r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed > > r4:ce67ec10 > > [] (platform_drv_probe) from [] > > (driver_probe_device+0x13c/0x34c) > > r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 > > [] (driver_probe_device) from [] > > (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 > > r4:ce67ec10 > > [] (__driver_attach) from [] > > (bus_for_each_dev+0x5c/0x98) > > r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 > > [] (bus_for_each_dev) from [] (driver_attach+0x20/0x28) > > r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 > > [] (driver_attach) from [] (bus_add_driver+0xf8/0x1fc) > > [] (bus_add_driver) from [] (driver_register+0xa4/0xe8) > > r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 > > [] (driver_register) from [] > > (__platform_driver_register+0x50/0x64) > > r5:c068d0e8 r4:ce621f80 > > [] (__platform_driver_register) from [] > > (omap_system_dma_init+0x18/0x20) > > [] (omap_system_dma_init) from [] > > (do_one_initcall+0x114/0x1e0) > > [] (do_one_initcall) from [] > > (kernel_init_freeable+0x110/0x1dc) > > r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 > > r4:0003 > > [] (kernel_init_freeable) from [] > > (kernel_init+0x10/0xec) > > r10: r8: r7: r6: r5:c0460830 r4: > > [] (kernel_init) from [] (ret_from_fork+0x14/0x24) > > r4: r3: > > ---[ end trace bcb85e0273c31888 ]--- > > OMAP DMA hardware revision 0.0 > > > > This does not occur when booting the plain "omap4" kernel. > > > > I thought it may be related to another error which people have been > > reporting, but as it's still there, I thought I should report it. > > > > To me, this suggests that Versatile Express code may be initialising > > on non-Versatile Express hardware, possibly touching hardware, but > > it looks like it's happening within the setup_irq() called from the > > legacy OMAP DMA code, though it's possi
Re: OMAP 4430 SDP: rather sick with recent kernels
* Russell King - ARM Linux [150114 09:54]: > On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: > > The "combined" kernel boot follows a similar pattern, but yets a bit > > further before oopsing, with ASoC DAPM code printing random bits of > > kernel memory. > > Note that the "combined" kernel (which is OMAP4 + Versatile Express) > has for a while now also spat out this: > > WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 > l3_interrupt_handler+0x218/0x2f0() > 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in > Supervisor mode during Functional access > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 > Hardware name: Generic OMAP4 (Flattened Device Tree) > Backtrace: > [] (dump_backtrace) from [] (show_stack+0x18/0x1c) > r6:c04c073e r5:0009 r4: r3:00200040 > [] (show_stack) from [] (dump_stack+0x78/0x94) > [] (dump_stack) from [] (warn_slowpath_common+0x8c/0xb8) > r4:ce461b38 r3:ce458000 > [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x38/0x40) > r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 > [] (warn_slowpath_fmt) from [] > (l3_interrupt_handler+0x218/0x2f0) > r3:ce54ad40 r2:c04c0772 > [] (l3_interrupt_handler) from [] > (handle_irq_event_percpu+0x38/0x13c) > r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 > r4:ce54f480 > [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x44/0x64) > r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 > r4:ce440700 > [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xb0/0x128) > r6:ce440760 r5:c06c5fec r4:ce440700 r3: > [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x28/0x38) > r6:ce408000 r5: r4:0013 r3:c0079544 > [] (generic_handle_irq) from [] > (__handle_domain_irq+0x90/0xb8) > r4: r3:0110 > [] (__handle_domain_irq) from [] > (gic_handle_irq+0x44/0x68) > r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 > [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c) > Exception stack(0xce461cd8 to 0xce461d20) > 1cc0: 0001 ce458508 > 1ce0: 6113 ce5b1960 002c ce5b1960 ce5b1938 > 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 > r6: r5:2113 r4:c046df64 r3:ce458000 > [] (_raw_spin_unlock_irqrestore) from [] > (__setup_irq+0x3bc/0x4e4) > r5:c06b7c00 r4:ce5b1900 > [] (__setup_irq) from [] (setup_irq+0x50/0x90) > r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c > r4:ce5b1900 > [] (setup_irq) from [] (omap_system_dma_probe+0x20c/0x2a4) > r6:ce67ec10 r5:002c r4:0020 r3:0002 > [] (omap_system_dma_probe) from [] > (platform_drv_probe+0x50/0x98) > r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed > r4:ce67ec10 > [] (platform_drv_probe) from [] > (driver_probe_device+0x13c/0x34c) > r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 > [] (driver_probe_device) from [] > (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 > r4:ce67ec10 > [] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x98) > r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 > [] (bus_for_each_dev) from [] (driver_attach+0x20/0x28) > r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 > [] (driver_attach) from [] (bus_add_driver+0xf8/0x1fc) > [] (bus_add_driver) from [] (driver_register+0xa4/0xe8) > r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 > [] (driver_register) from [] > (__platform_driver_register+0x50/0x64) > r5:c068d0e8 r4:ce621f80 > [] (__platform_driver_register) from [] > (omap_system_dma_init+0x18/0x20) > [] (omap_system_dma_init) from [] > (do_one_initcall+0x114/0x1e0) > [] (do_one_initcall) from [] > (kernel_init_freeable+0x110/0x1dc) > r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 > r4:0003 > [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) > r10: r8: r7: r6: r5:c0460830 r4: > [] (kernel_init) from [] (ret_from_fork+0x14/0x24) > r4: r3: > ---[ end trace bcb85e0273c31888 ]--- > OMAP DMA hardware revision 0.0 > > This does not occur when booting the plain "omap4" kernel. > > I thought it may be related to another error which people have been > reporting, but as it's still there, I thought I should report it. > > To me, this suggests that Versatile Express code may be initialising > on non-Versatile Express hardware, possibly touching hardware, but > it looks like it's happening within the setup_irq() called from the > legacy OMAP DMA code, though it's possible that could be because > Versatile Express code could be hitting some register which causes > OMAP4 to later to wrong. > > I think it's going to be particularly horrid to debug... This seems like it could be a similar issue to what we were seeing on omap3 where the lega
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote: > The "combined" kernel boot follows a similar pattern, but yets a bit > further before oopsing, with ASoC DAPM code printing random bits of > kernel memory. Note that the "combined" kernel (which is OMAP4 + Versatile Express) has for a while now also spat out this: WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1 Hardware name: Generic OMAP4 (Flattened Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:c04c073e r5:0009 r4: r3:00200040 [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (warn_slowpath_common+0x8c/0xb8) r4:ce461b38 r3:ce458000 [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40) r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400 [] (warn_slowpath_fmt) from [] (l3_interrupt_handler+0x218/0x2f0) r3:ce54ad40 r2:c04c0772 [] (l3_interrupt_handler) from [] (handle_irq_event_percpu+0x38/0x13c) r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7: r6: r5:0013 r4:ce54f480 [] (handle_irq_event_percpu) from [] (handle_irq_event+0x44/0x64) r10: r9:ce5b1938 r8:ce5b1960 r7:0001 r6:ce54f480 r5:ce440760 r4:ce440700 [] (handle_irq_event) from [] (handle_fasteoi_irq+0xb0/0x128) r6:ce440760 r5:c06c5fec r4:ce440700 r3: [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x38) r6:ce408000 r5: r4:0013 r3:c0079544 [] (generic_handle_irq) from [] (__handle_domain_irq+0x90/0xb8) r4: r3:0110 [] (__handle_domain_irq) from [] (gic_handle_irq+0x44/0x68) r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100 [] (gic_handle_irq) from [] (__irq_svc+0x44/0x5c) Exception stack(0xce461cd8 to 0xce461d20) 1cc0: 0001 ce458508 1ce0: 6113 ce5b1960 002c ce5b1960 ce5b1938 1d00: ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 2113 r6: r5:2113 r4:c046df64 r3:ce458000 [] (_raw_spin_unlock_irqrestore) from [] (__setup_irq+0x3bc/0x4e4) r5:c06b7c00 r4:ce5b1900 [] (__setup_irq) from [] (setup_irq+0x50/0x90) r10:c06ea338 r9:2113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:002c r4:ce5b1900 [] (setup_irq) from [] (omap_system_dma_probe+0x20c/0x2a4) r6:ce67ec10 r5:002c r4:0020 r3:0002 [] (omap_system_dma_probe) from [] (platform_drv_probe+0x50/0x98) r10:c066d8b0 r9: r8: r7:c02971b8 r6:c06b7b94 r5:ffed r4:ce67ec10 [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x34c) r6: r5:c06b7b94 r4:ce67ec10 r3:c0298738 [] (driver_probe_device) from [] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10 [] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x98) r6:c06b7b94 r5:ce461e48 r4: r3:c02971b8 [] (bus_for_each_dev) from [] (driver_attach+0x20/0x28) r7: r6:c06ce978 r5:ce61c100 r4:c06b7b94 [] (driver_attach) from [] (bus_add_driver+0xf8/0x1fc) [] (bus_add_driver) from [] (driver_register+0xa4/0xe8) r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94 [] (driver_register) from [] (__platform_driver_register+0x50/0x64) r5:c068d0e8 r4:ce621f80 [] (__platform_driver_register) from [] (omap_system_dma_init+0x18/0x20) [] (omap_system_dma_init) from [] (do_one_initcall+0x114/0x1e0) [] (do_one_initcall) from [] (kernel_init_freeable+0x110/0x1dc) r10:c066d8b0 r9: r8:007d r7:c06e9040 r6:c067ddf0 r5:c066d898 r4:0003 [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) r10: r8: r7: r6: r5:c0460830 r4: [] (kernel_init) from [] (ret_from_fork+0x14/0x24) r4: r3: ---[ end trace bcb85e0273c31888 ]--- OMAP DMA hardware revision 0.0 This does not occur when booting the plain "omap4" kernel. I thought it may be related to another error which people have been reporting, but as it's still there, I thought I should report it. To me, this suggests that Versatile Express code may be initialising on non-Versatile Express hardware, possibly touching hardware, but it looks like it's happening within the setup_irq() called from the legacy OMAP DMA code, though it's possible that could be because Versatile Express code could be hitting some register which causes OMAP4 to later to wrong. I think it's going to be particularly horrid to debug... -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 31, 2014 at 04:00:14PM +0200, Peter Ujfalusi wrote: > On 12/18/2014 01:49 PM, Mark Brown wrote: > > Right, spot on - I'll send a revert for that upstream. Thanks for > > tracking this down. > Mark, can you send the e3b1e6a19e09877b91517dfe304a2b3f6b2138fc (found it in > linux-next) for 3.19 if it not yet done? With that applied mainline boots up > on my Blaze. Already done. signature.asc Description: Digital signature
Re: OMAP 4430 SDP: rather sick with recent kernels
On 12/18/2014 01:49 PM, Mark Brown wrote: > On Thu, Dec 18, 2014 at 10:16:18AM +, Russell King - ARM Linux wrote: > >> So that doesn't work - but importantly, it does point towards a >> possible culpret - snd_soc_of_parse_audio_routing(). > >> This is obvious when you stop and think about what it's doing, this is >> truely where this bug lies, and it /is/ in generic ASoC code. > >> The problem is that this function doesn't consider the implications of >> deferred probing. Let's see what happens if we defer, and re-do the >> ABE initialisation, including calling this function: > > Right, spot on - I'll send a revert for that upstream. Thanks for > tracking this down. Mark, can you send the e3b1e6a19e09877b91517dfe304a2b3f6b2138fc (found it in linux-next) for 3.19 if it not yet done? With that applied mainline boots up on my Blaze. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On 12/18/2014 06:41 PM, Tony Lindgren wrote: > * Tony Lindgren [141217 09:28]: >> >> And then there are these too in the current mainline that are >> clock related: >> >> omap4xxx_dt_clk_init: failed to configure ABE DPLL! >> ... >> clock: dpll_abe_ck failed transition to 'locked' >> clock: dpll_abe_ck failed transition to 'locked' >> clock: dpll_abe_ck failed transition to 'locked' >> [ cut here ] >> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30() >> Modules linked in: >> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699 >> Hardware name: Generic OMAP4 (Flattened Device Tree) >> [] (unwind_backtrace) from [] (show_stack+0x10/0x14) >> [] (show_stack) from [] (dump_stack+0x80/0x9c) >> [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) >> [] (warn_slowpath_common) from [] (warn_slowpath_null+ >> 0x1c/0x24) >> [] (warn_slowpath_null) from [] (clk_disable+0x24/0x30) >> [] (clk_disable) from [] (_disable_clocks+0x18/0x68) >> [] (_disable_clocks) from [] (_idle+0x15c/0x240) >> [] (_idle) from [] (_setup+0x174/0x22c) >> [] (_setup) from [] (omap_hwmod_for_each+0x30/0x5c) >> [] (omap_hwmod_for_each) from [] >> (__omap_hwmod_setup_all+0x30/0x40) >> [] (__omap_hwmod_setup_all) from [] >> (do_one_initcall+0x80/0x1d8) >> [] (do_one_initcall) from [] >> (kernel_init_freeable+0x1f4/0x2cc) >> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) >> [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) >> ---[ end trace f0d1b75165d8ef11 ]--- >> clock: dpll_abe_ck failed transition to 'locked' >> clock: dpll_abe_ck failed transition to 'locked' >> ... >> >> Tero & Tomi, can you please look into these clock issues above? > > FYI, looks like merging Mike's pending clk-next to current mainline > somehow fixes the clock issues above. It seems the audio changes > depended on changes in clk-next? I'm not aware of any audio changes around here. BTW: today's linux-next boots fine on Blaze with audio working. > > Regards, > > Tony > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
* Tony Lindgren [141217 09:28]: > > And then there are these too in the current mainline that are > clock related: > > omap4xxx_dt_clk_init: failed to configure ABE DPLL! > ... > clock: dpll_abe_ck failed transition to 'locked' > clock: dpll_abe_ck failed transition to 'locked' > clock: dpll_abe_ck failed transition to 'locked' > [ cut here ] > WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30() > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699 > Hardware name: Generic OMAP4 (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x80/0x9c) > [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) > [] (warn_slowpath_common) from [] (warn_slowpath_null+ > 0x1c/0x24) > [] (warn_slowpath_null) from [] (clk_disable+0x24/0x30) > [] (clk_disable) from [] (_disable_clocks+0x18/0x68) > [] (_disable_clocks) from [] (_idle+0x15c/0x240) > [] (_idle) from [] (_setup+0x174/0x22c) > [] (_setup) from [] (omap_hwmod_for_each+0x30/0x5c) > [] (omap_hwmod_for_each) from [] > (__omap_hwmod_setup_all+0x30/0x40) > [] (__omap_hwmod_setup_all) from [] > (do_one_initcall+0x80/0x1d8) > [] (do_one_initcall) from [] > (kernel_init_freeable+0x1f4/0x2cc) > [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) > [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) > ---[ end trace f0d1b75165d8ef11 ]--- > clock: dpll_abe_ck failed transition to 'locked' > clock: dpll_abe_ck failed transition to 'locked' > ... > > Tero & Tomi, can you please look into these clock issues above? FYI, looks like merging Mike's pending clk-next to current mainline somehow fixes the clock issues above. It seems the audio changes depended on changes in clk-next? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On 12/18/2014 01:48 PM, Peter Rosin wrote: Russel King wrote: *snip* Now, we have this call to snd_soc_of_parse_audio_routing(), which allocates some memory, copies the old routes into it, and then adds to them from DT. That explains why the pointer and number of routes are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36. So that doesn't work - but importantly, it does point towards a possible culpret - snd_soc_of_parse_audio_routing(). This is obvious when you stop and think about what it's doing, this is truely where this bug lies, and it /is/ in generic ASoC code. The problem is that this function doesn't consider the implications of deferred probing. Let's see what happens if we defer, and re-do the ABE initialisation, including calling this function: 17 + 19 = 36. - first probe 17 + 19 + 19 = 55. - second probe Oh - that works in terms of the number, and it would also explain why the table has been screwed - because the second time we memcpy(), we're memcpy()ing from data which was allocated via devm_kzalloc(), and thus would have been freed after the first failed probe. Mark - this is a core ASoC problem. Sorry about this, I wasn't even aware of deferred probing when I wrote f8781db8aeb1. From my point of view, it is certainly possible to solve this in the card driver which needs to add card dapm routes instead. So, a revert is fine by me, if no better solution comes up. Looks to me that for this feature we would need a separate function, something like: int snd_soc_of_parse_audio_routing_append(struct snd_soc_card *card, const char *propname); even if the implementation behind would be the same. But I guess it is little late for new designs at this phase. Best regards, Jyri -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP 4430 SDP: rather sick with recent kernels
Russel King wrote: *snip* > Now, we have this call to snd_soc_of_parse_audio_routing(), which > allocates some memory, copies the old routes into it, and then adds > to them from DT. That explains why the pointer and number of routes > are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36. > So that doesn't work - but importantly, it does point towards a > possible culpret - snd_soc_of_parse_audio_routing(). > > This is obvious when you stop and think about what it's doing, this is > truely where this bug lies, and it /is/ in generic ASoC code. > > The problem is that this function doesn't consider the implications of > deferred probing. Let's see what happens if we defer, and re-do the > ABE initialisation, including calling this function: > > 17 + 19 = 36. - first probe > 17 + 19 + 19 = 55. - second probe > > Oh - that works in terms of the number, and it would also explain why > the table has been screwed - because the second time we memcpy(), we're > memcpy()ing from data which was allocated via devm_kzalloc(), and thus > would have been freed after the first failed probe. > > Mark - this is a core ASoC problem. Sorry about this, I wasn't even aware of deferred probing when I wrote f8781db8aeb1. From my point of view, it is certainly possible to solve this in the card driver which needs to add card dapm routes instead. So, a revert is fine by me, if no better solution comes up. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On Thu, Dec 18, 2014 at 10:16:18AM +, Russell King - ARM Linux wrote: > So that doesn't work - but importantly, it does point towards a > possible culpret - snd_soc_of_parse_audio_routing(). > This is obvious when you stop and think about what it's doing, this is > truely where this bug lies, and it /is/ in generic ASoC code. > The problem is that this function doesn't consider the implications of > deferred probing. Let's see what happens if we defer, and re-do the > ABE initialisation, including calling this function: Right, spot on - I'll send a revert for that upstream. Thanks for tracking this down. signature.asc Description: Digital signature
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 17, 2014 at 11:08:06PM +0200, Jyri Sarha wrote: > I tried booting my 4460 Panda - which is the closest thing to 4430SDP that > I've got - on next-20141217, but I could not get it to the point where the > omap-abe-twl6040 probed. It probably is the problem you are talking about as > the hang does not happen if I disable ASoC ABE all together, right? > > I'll take a deeper look at it tomorrow, as Peter is not working ATM. Digging into this at my end: [] (snd_soc_instantiate_card) from [] (snd_soc_register_card+0x344/0x424) r10:005c r9: r8:0620 r7:ce437630 r6:ce437630 r5:0002 r4:c05cae58 c02c95e8: e1a4mov r0, r4 c02c95ec: ebfffc29bl c02c8698 So 'card' is 0xc05cae58, which is correct: c05cae58 d omap_abe_card [] (snd_soc_dapm_add_routes) from [] (snd_soc_instantiate_card+0x8a8/0xc14) r10: r9: r8:ce437010 r7:ce437630 r6:0002 r5:c05cb0bc r4:c05cae58 c02c8f28: e594110cldr r1, [r4, #268] ; 0x10c c02c8f2c: e351cmp r1, #0 c02c8f30: 0a02beq c02c8f40 c02c8f34: e51b0044ldr r0, [fp, #-68] ; 0x44 c02c8f38: e5942110ldr r2, [r4, #272] ; 0x110 c02c8f3c: eb000c6abl c02cc0ec This corresponds with: if (card->dapm_routes) snd_soc_dapm_add_routes(&card->dapm, card->dapm_routes, card->num_dapm_routes); Again, we see r4 is the omap_abe_card, and the code is loading dapm_routes and num_dapm_routes. The dump of this in the vmlinux file gives: c05cae58 : ... c05caf5c: c045d098umaalgt sp, r5, r8, r0 c05caf60: 000aandeq r0, r0, sl c05caf64: c045d6a4subgt sp, r5, r4, lsr #13 c05caf68: 0011andeq r0, r0, r1, lsl r0 and 0x10c/0x110 gives 0xc045d6a4 / 17. c045d6a4 r audio_map So that looks fine. [] (snd_soc_dapm_add_route) from [] (snd_soc_dapm_add_routes+0x48/0xac) r10:c0458801 r9: r8:0037 r7: r6: r5:c05cafb8 r4:ce57b420 c02cc0ec : c02cc0fc: e1a05000mov r5, r0 c02cc104: e1a04001mov r4, r1 c02cc108: e3a07000mov r7, #0 c02cc114: e1a08002mov r8, r2 c02cc118: e2844010add r4, r4, #16 c02cc120: e1a06007mov r6, r7 c02cc128: ea0fb c02cc16c c02cc12c: e1a5mov r0, r5 c02cc130: eb74bl c02cbf08 c02cc134: e2509000subsr9, r0, #0 c02cc138: aa09bge c02cc164 ... c02cc168: e2844010add r4, r4, #16 c02cc16c: e1560008cmp r6, r8 c02cc170: e2441010sub r1, r4, #16 c02cc174: baecblt c02cc12c Here, r5 is &card->dapm. r4 should be card->dapm_routes, possibly incremented by 16 up to 17 times, which should be in the range of 0xc045d6a4 - 0xc045d7b4, but it isn't, it's 0xce57b420. Also, r8 is card->num_dapm_routes, which should be 17, but it's 0x37 (55). The index is r6, and at least that's sensibly at zero. Now, we have this call to snd_soc_of_parse_audio_routing(), which allocates some memory, copies the old routes into it, and then adds to them from DT. That explains why the pointer and number of routes are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36. So that doesn't work - but importantly, it does point towards a possible culpret - snd_soc_of_parse_audio_routing(). This is obvious when you stop and think about what it's doing, this is truely where this bug lies, and it /is/ in generic ASoC code. The problem is that this function doesn't consider the implications of deferred probing. Let's see what happens if we defer, and re-do the ABE initialisation, including calling this function: 17 + 19 = 36. - first probe 17 + 19 + 19 = 55. - second probe Oh - that works in terms of the number, and it would also explain why the table has been screwed - because the second time we memcpy(), we're memcpy()ing from data which was allocated via devm_kzalloc(), and thus would have been freed after the first failed probe. Mark - this is a core ASoC problem. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On 12/17/2014 08:51 PM, Russell King - ARM Linux wrote: On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote: Hi, * Russell King - ARM Linux [141217 01:55]: Tony, As the IOMMU stuff was merged last night, which removed a really quite horrid conflict resolution, I updated my nightly build tree from its previous state last Thursday. Now, SDP4430 seems to be really quite broken. Sigh, things are just break left and right every merge window :( Some of these things were present before the merge window, so they're less of a concern. The biggest problem though is the ABE ASoC stuff exploding, which prevents my test system getting anywhere near mounting its rootfs. It's fine in the "combined" case, because we end up totally dead as far as serial console goes, but the "omap4430" kernel boot test never ends because the kernel doesn't stop spewing "rcu_sched stall" messages. I tried booting my 4460 Panda - which is the closest thing to 4430SDP that I've got - on next-20141217, but I could not get it to the point where the omap-abe-twl6040 probed. It probably is the problem you are talking about as the hang does not happen if I disable ASoC ABE all together, right? I'll take a deeper look at it tomorrow, as Peter is not working ATM. Best regards, Jyri -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
* Tony Lindgren [141217 11:14]: > > Also, in your 3430-LDP logs, the DMA setup_irq related "In-band Error" > is a mystery. I'm not seeing that with omap2plus_defconfig, but can > reproduce it here with your LDP .config file. Got any ideas on that one? Hmm it looks like that's some CONFIG_PREEMPT related regression.. Disablig CONFIG_PREEMPT makes it go away. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
* Russell King - ARM Linux [141217 10:54]: > On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote: > > Hi, > > > > * Russell King - ARM Linux [141217 01:55]: > > > Tony, > > > > > > As the IOMMU stuff was merged last night, which removed a really quite > > > horrid conflict resolution, I updated my nightly build tree from its > > > previous state last Thursday. > > > > > > Now, SDP4430 seems to be really quite broken. > > > > Sigh, things are just break left and right every merge window :( > > Some of these things were present before the merge window, so they're > less of a concern. The biggest problem though is the ABE ASoC stuff > exploding, which prevents my test system getting anywhere near mounting > its rootfs. Right. > It's fine in the "combined" case, because we end up totally dead as > far as serial console goes, but the "omap4430" kernel boot test never > ends because the kernel doesn't stop spewing "rcu_sched stall" messages. Yeah and there are some new clock issues for sure like I posted. Also, in your 3430-LDP logs, the DMA setup_irq related "In-band Error" is a mystery. I'm not seeing that with omap2plus_defconfig, but can reproduce it here with your LDP .config file. Got any ideas on that one? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote: > Hi, > > * Russell King - ARM Linux [141217 01:55]: > > Tony, > > > > As the IOMMU stuff was merged last night, which removed a really quite > > horrid conflict resolution, I updated my nightly build tree from its > > previous state last Thursday. > > > > Now, SDP4430 seems to be really quite broken. > > Sigh, things are just break left and right every merge window :( Some of these things were present before the merge window, so they're less of a concern. The biggest problem though is the ABE ASoC stuff exploding, which prevents my test system getting anywhere near mounting its rootfs. It's fine in the "combined" case, because we end up totally dead as far as serial console goes, but the "omap4430" kernel boot test never ends because the kernel doesn't stop spewing "rcu_sched stall" messages. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
* Nishanth Menon [141217 09:35]: > On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren wrote: > > > >> twl: not initialized > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 141 Vs max 1316660 > > > > This seems to be some twl related init order issue, I'll take a > > look at this one. > > > >> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu > >> omap2_set_init_voltage: unable to set vdd_mpu > >> omap2_set_init_voltage: unable to find boot up OPP for vdd_core > >> omap2_set_init_voltage: unable to set vdd_core > >> omap2_set_init_voltage: unable to find boot up OPP for vdd_iva > >> omap2_set_init_voltage: unable to set vdd_iva > > > > I believe Nishanth has some plans for these? > > > Not in the near future. looks like converting VC/VP into regulator and > fit inside DT world has gone no where.. Looks like also the "twl: not initialized" error is caused by this: omap2_common_pm_late_init omap_voltage_late_init omap_vc_init_channel omap_vc_calc_vsel twl6030_uv_to_vsel twl_i2c_read twl_get_regmap Can't we fix it with pdata-quirks.c as this error is now showing up on at least omap3 and 4? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren wrote: > >> twl: not initialized >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 141 Vs max 1316660 > > This seems to be some twl related init order issue, I'll take a > look at this one. > >> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu >> omap2_set_init_voltage: unable to set vdd_mpu >> omap2_set_init_voltage: unable to find boot up OPP for vdd_core >> omap2_set_init_voltage: unable to set vdd_core >> omap2_set_init_voltage: unable to find boot up OPP for vdd_iva >> omap2_set_init_voltage: unable to set vdd_iva > > I believe Nishanth has some plans for these? Not in the near future. looks like converting VC/VP into regulator and fit inside DT world has gone no where.. Regards, Nishanth Menon -- --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP 4430 SDP: rather sick with recent kernels
Hi, * Russell King - ARM Linux [141217 01:55]: > Tony, > > As the IOMMU stuff was merged last night, which removed a really quite > horrid conflict resolution, I updated my nightly build tree from its > previous state last Thursday. > > Now, SDP4430 seems to be really quite broken. Sigh, things are just break left and right every merge window :( Anyways, I've added a bunch of ti.com people to Cc, let's fix up the noisy dmesg --level=err and dmesg --level=warn output too so we can notice the real issues easier, see below. > ti_dt_clocks_register: failed to lookup clock node dss_fck > ti_dt_clocks_register: failed to lookup clock node dss_fck > ti_dt_clocks_register: failed to lookup clock node div_ts_ck > ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk And then there are these too in the current mainline that are clock related: omap4xxx_dt_clk_init: failed to configure ABE DPLL! ... clock: dpll_abe_ck failed transition to 'locked' clock: dpll_abe_ck failed transition to 'locked' clock: dpll_abe_ck failed transition to 'locked' [ cut here ] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30() Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699 Hardware name: Generic OMAP4 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x80/0x9c) [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) [] (warn_slowpath_common) from [] (warn_slowpath_null+ 0x1c/0x24) [] (warn_slowpath_null) from [] (clk_disable+0x24/0x30) [] (clk_disable) from [] (_disable_clocks+0x18/0x68) [] (_disable_clocks) from [] (_idle+0x15c/0x240) [] (_idle) from [] (_setup+0x174/0x22c) [] (_setup) from [] (omap_hwmod_for_each+0x30/0x5c) [] (omap_hwmod_for_each) from [] (__omap_hwmod_setup_all+0x30/0x40) [] (__omap_hwmod_setup_all) from [] (do_one_initcall+0x80/0x1d8) [] (do_one_initcall) from [] (kernel_init_freeable+0x1f4/0x2cc) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) ---[ end trace f0d1b75165d8ef11 ]--- clock: dpll_abe_ck failed transition to 'locked' clock: dpll_abe_ck failed transition to 'locked' ... Tero & Tomi, can you please look into these clock issues above? > omap_hwmod: l3_main_3 using broken dt data from ocp > omap_hwmod: l3_main_2 using broken dt data from ocp This is a known issue that will take a while to get fixed to get things match with compatible and ti,hwmods and the hwmod data we have. > irq: no irq domain found for /ocp/pinmux@4a100040 ! > irq: no irq domain found for /ocp/pinmux@4a100040 ! > irq: no irq domain found for /ocp/pinmux@4a100040 ! All these deferred probe issues should go away when we can remove the custom initcall levels for drivers once omap3 is DT only. Some of that we may be able to do already by making all the GPIO usage in the remaining board-*.c files happen later. > platform 4b501000.aes: Cannot lookup hwmod 'aes' > platform 480a5000.des: Cannot lookup hwmod 'des' Looks like Joel added the .dts entries for aes and des, but somehow the related omap_hwmod_data_44xx.c entries never made it. Probably because Paul was not in Cc for the thread "[PATCH 00/10] ARM: OMAP: dts and HWMOD entries for crypto modules" Joel, can you please update that series, and repost with Paul also in Cc? Looks like there there's a dependency to omap_hwmod_sysc_type4 for aes and des for the des and aes hwmod data. > twl: not initialized > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 > twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 141 Vs max 1316660 This seems to be some twl related init order issue, I'll take a look at this one. > omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu > omap2_set_init_voltage: unable to set vdd_mpu > omap2_set_init_voltage: unable to find boot up OPP for vdd_core > omap2_set_init_voltage: unable to set vdd_core > omap2_set_init_voltage: unable to find boot up OPP for vdd_iva > omap2_set_init_voltage: unable to set vdd_iva I believe Nishanth has some plans for these? > From there, the system crash'n'burns badly due to an ASoC DAPM oops. > > The "combined" kernel boot follows a similar pattern, but yets a bit > further before oopsing, with ASoC DAPM code printing random bits of > kernel memory. Jyri, Tomi & Peter, can you please take a look at ASoC DAPM issue? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo
