Re: DEBUG_LL on OMAP1 (was Re: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3)
* Aaro Koskinen [12 03:42]: > Hi, > > On Thu, 10 Nov 2011, Tony Lindgren wrote: > >* Aaro Koskinen [10 13:31]: > >>--- a/arch/arm/mach-omap1/clock_data.c > >>+++ b/arch/arm/mach-omap1/clock_data.c > >>@@ -774,14 +774,6 @@ int __init omap1_clk_init(void) > >>int crystal_type = 0; /* Default 12 MHz */ > >>u32 reg, cpu_mask; > >> > >>-#ifdef CONFIG_DEBUG_LL > >>- /* > >>-* Resets some clocks that may be left on from bootloader, > >>-* but leaves serial clocks on. > >>-*/ > >>- omap_writel(0x3 << 29, MOD_CONF_CTRL_0); > >>-#endif > >>- > >>/* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ > >>reg = omap_readw(SOFT_REQ_REG) & (1 << 4); > >>omap_writew(reg, SOFT_REQ_REG); > > > >Hmm that should keep the serial clocks on. What other bit(s) need to > >be on in MOD_CONF_CTRL_0 for you in addition to the serial bits? > > On my board those serial bits are zero during the early boot (and the > serial works). By setting those bits the clock will switch from 12 -> > 48 MHz and I guess the baud rate will change and that's why the output > turns into garbage. OK, looks like on OSK5912 the uart1 serial bit is zero and must be set.. > So I think the code should reset the other bits, and leave serial bits > untouched: Sounds like we need SoC specific init_early for omap1 too. That way we can also get rid of the CONFIG_OMAP_ARM_XXXMHZ Kconfig options that are needed to make omap1_defconfig more usable. Regards, Tony > diff --git a/arch/arm/mach-omap1/clock_data.c > b/arch/arm/mach-omap1/clock_data.c > index 1297bb5..b3b69d8 100644 > --- a/arch/arm/mach-omap1/clock_data.c > +++ b/arch/arm/mach-omap1/clock_data.c > @@ -788,7 +788,11 @@ int __init omap1_clk_init(void) >* Resets some clocks that may be left on from bootloader, >* but leaves serial clocks on. >*/ > - omap_writel(0x3 << 29, MOD_CONF_CTRL_0); > + reg = omap_readl(MOD_CONF_CTRL_0) & > + ((1 << CONF_MOD_UART1_CLK_MODE_R) | > + (1 << CONF_MOD_UART2_CLK_MODE_R) | > + (1 << CONF_MOD_UART3_CLK_MODE_R)); > + omap_writel(reg, MOD_CONF_CTRL_0); > #endif > > /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ > -- 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
DEBUG_LL on OMAP1 (was Re: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3)
Hi, On Thu, 10 Nov 2011, Tony Lindgren wrote: * Aaro Koskinen [10 13:31]: --- a/arch/arm/mach-omap1/clock_data.c +++ b/arch/arm/mach-omap1/clock_data.c @@ -774,14 +774,6 @@ int __init omap1_clk_init(void) int crystal_type = 0; /* Default 12 MHz */ u32 reg, cpu_mask; -#ifdef CONFIG_DEBUG_LL - /* -* Resets some clocks that may be left on from bootloader, -* but leaves serial clocks on. -*/ - omap_writel(0x3 << 29, MOD_CONF_CTRL_0); -#endif - /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ reg = omap_readw(SOFT_REQ_REG) & (1 << 4); omap_writew(reg, SOFT_REQ_REG); Hmm that should keep the serial clocks on. What other bit(s) need to be on in MOD_CONF_CTRL_0 for you in addition to the serial bits? On my board those serial bits are zero during the early boot (and the serial works). By setting those bits the clock will switch from 12 -> 48 MHz and I guess the baud rate will change and that's why the output turns into garbage. So I think the code should reset the other bits, and leave serial bits untouched: diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c index 1297bb5..b3b69d8 100644 --- a/arch/arm/mach-omap1/clock_data.c +++ b/arch/arm/mach-omap1/clock_data.c @@ -788,7 +788,11 @@ int __init omap1_clk_init(void) * Resets some clocks that may be left on from bootloader, * but leaves serial clocks on. */ - omap_writel(0x3 << 29, MOD_CONF_CTRL_0); + reg = omap_readl(MOD_CONF_CTRL_0) & + ((1 << CONF_MOD_UART1_CLK_MODE_R) | +(1 << CONF_MOD_UART2_CLK_MODE_R) | +(1 << CONF_MOD_UART3_CLK_MODE_R)); + omap_writel(reg, MOD_CONF_CTRL_0); #endif /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ A. -- 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: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
On Thursday 10 of November 2011 at 01:28:58, Aaro Koskinen wrote: > Hi, > > On 10.11.2011, at 2.04, Tony Lindgren wrote: > > * Aaro Koskinen [09 15:25]: > >> On 10.11.2011, at 1.39, Russell King - ARM Linux wrote: > >>> On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote: > Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use > generic > map_io, init_early and init_irq) changed omap1 to use generic > map_io. > > Looks like I missed one board though. Fix this by adding a custom > map_io for Amstrad E3. > > Reported-by: Aaro Koskinen > Signed-off-by: Tony Lindgren > > --- > Untested, does this help? > --- a/arch/arm/mach-omap1/board-ams-delta.c > +++ b/arch/arm/mach-omap1/board-ams-delta.c > @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) > omap_cfg_reg(J19_1610_CAM_D6); > omap_cfg_reg(J18_1610_CAM_D7); > > -iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); > - > >>> > >>> This is definitely wrong. Using iotable_init() after map_io has > >>> returned > >>> has (and remains) a serious bug - doing so may _appear_ to work > >>> but as it > >>> doesn't obtain its memory from the standard kernel memory > >>> allocators, it > >>> will lead to duplicate usage of that memory. > >> > >> Also, the patch did not help. It still hangs like before. > > > > Hmm that patch is needed for sure but sounds like there's also > > something else wrong.. Can you try to git bisect it? > > Ok, I'll try bisecting tomorrow. Hi Aaro, Please let me know if you think I could help, or I'll wait for your findings, to avoid duplicating efforts. Thanks, Janusz -- 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: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
* Aaro Koskinen [10 13:31]: > --- a/arch/arm/mach-omap1/clock_data.c > +++ b/arch/arm/mach-omap1/clock_data.c > @@ -774,14 +774,6 @@ int __init omap1_clk_init(void) > int crystal_type = 0; /* Default 12 MHz */ > u32 reg, cpu_mask; > > -#ifdef CONFIG_DEBUG_LL > - /* > - * Resets some clocks that may be left on from bootloader, > - * but leaves serial clocks on. > - */ > - omap_writel(0x3 << 29, MOD_CONF_CTRL_0); > -#endif > - > /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ > reg = omap_readw(SOFT_REQ_REG) & (1 << 4); > omap_writew(reg, SOFT_REQ_REG); Hmm that should keep the serial clocks on. What other bit(s) need to be on in MOD_CONF_CTRL_0 for you in addition to the serial bits? > 2) By using the above hack, I could see the actual crash: > > Uncompressing Linux... done, booting the kernel. > [0.00] Initializing cgroup subsys cpu > [0.00] Linux version 3.2.0-rc1-e3 (aaro@dell) (gcc version 4.6.1 > (GCC) ) #9 PREEMPT Thu Nov 10 23:48:23 EET 2011 > [0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f > [0.00] CPU: VIVT data cache, VIVT instruction cache > [0.00] Machine: Amstrad E3 (Delta) > [0.00] bootconsole [earlycon0] enabled > [0.00] Memory policy: ECC disabled, Data cache writethrough > [0.00] OMAP1510 > [0.00] revision 2 handled as 15xx id: bc058c9b93111a16 > [0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e > [0.00] [ cut here ] > [0.00] kernel BUG at arch/arm/plat-omap/sram.c:226! > [0.00] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT > [0.00] Modules linked in: > [0.00] CPU: 0Not tainted (3.2.0-rc1-e3 #9) > [0.00] PC is at omap_sram_reprogram_clock+0x28/0x30 > [0.00] LR is at omap1_select_table_rate+0x88/0xb4 > [0.00] pc : []lr : []psr: 60d3 > [0.00] sp : c035bf10 ip : c035bf20 fp : c035bf1c > [0.00] r10: c035bfd4 r9 : 54029252 r8 : c03f8120 > [0.00] r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40 > [0.00] r3 : r2 : c0362b40 r1 : 010a r0 : 2cb0 > [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment > kernel > [0.00] Control: 317f Table: 10004000 DAC: 0017 > [0.00] Process swapper (pid: 0, stack limit = 0xc035a270) > [0.00] Stack: (0xc035bf10 to 0xc035c000) > [0.00] bf00: c035bf3c c035bf20 > c0019f54 c001b0ac > [0.00] bf20: 1000 2cb3 0004 c035ed4c c035bf74 c035bf40 > c033ea24 c0019edc > [0.00] bf40: c02f526c 0002 0015 bc058c9b 93111a16 c035335c > 0200 c035ed4c > [0.00] bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec > c035bfc4 c035bf88 > [0.00] bf80: c033bc24 c00194a0 c035bf90 c035bf98 > > [0.00] bfa0: 0001 c0354678 c035ece4 10004000 103532f4 > c035bff4 c035bfc8 > [0.00] bfc0: c0338574 c033b598 c035467c > 317d c035c03c > [0.00] bfe0: c0354678 c035ece4 c035bff8 10008040 c0338508 > > [0.00] Backtrace: > [0.00] [] (omap_sram_reprogram_clock+0x0/0x30) from > [] (omap1_select_table_rate+0x88/0xb4) > [0.00] [] (omap1_select_table_rate+0x0/0xb4) from > [] (omap1_clk_init+0x148/0x334) > [0.00] r7:c035ed4c r6:0004 r5:2cb3 r4:1000 > [0.00] [] (omap1_clk_init+0x0/0x334) from [] > (omap1_init_early+0x34/0x48) > [0.00] r8:c03f8120 r7:c035ed4c r6:c035ed4c r5:0200 r4:c035335c > [0.00] [] (omap1_init_early+0x0/0x48) from [] > (setup_arch+0x69c/0x79c) > [0.00] [] (setup_arch+0x0/0x79c) from [] > (start_kernel+0x7c/0x2f4) > [0.00] [] (start_kernel+0x0/0x2f4) from [<10008040>] > (0x10008040) > [0.00] r7:c035ece4 r6:c0354678 r5:c035c03c r4:317d > [0.00] Code: 0a02 e1a0e00f e12fff13 e89da800 (e7f001f2) > [0.00] ---[ end trace 1b75b31a2719ed1c ]--- > > The BUG_ON() in omap_sram_reprogram_clock() triggers, because > it's called before omap_sram_init(). If I comment out the code in > omap_sram_reprogram_clock(), the board boots up. Ouch. I guess I have not seen that as omap1_defconfig has by default CONFIG_OMAP_CLOCKS_SET_BY_BOOTLOADER=y. To fix the issue you're seeing we should move some of omap1_clk_init into an arch_initcall that calls omap1_select_table_rate later on, and then does propagate_rate(&ck_ref). This way sram is configured when omap_sram_reprogram_clock gets called. 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: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
Hi, On Wed, 9 Nov 2011, Tony Lindgren wrote: * Aaro Koskinen [09 15:25]: On 10.11.2011, at 1.39, Russell King - ARM Linux wrote: On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote: Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic map_io, init_early and init_irq) changed omap1 to use generic map_io. Looks like I missed one board though. Fix this by adding a custom map_io for Amstrad E3. Reported-by: Aaro Koskinen Signed-off-by: Tony Lindgren --- Untested, does this help? --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) omap_cfg_reg(J19_1610_CAM_D6); omap_cfg_reg(J18_1610_CAM_D7); - iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); - This is definitely wrong. Using iotable_init() after map_io has returned has (and remains) a serious bug - doing so may _appear_ to work but as it doesn't obtain its memory from the standard kernel memory allocators, it will lead to duplicate usage of that memory. Also, the patch did not help. It still hangs like before. Hmm that patch is needed for sure but sounds like there's also something else wrong.. Can you try to git bisect it? I found it impossible to bisect, but there are two issues I found: 1) earlyconsole turns into garbage in omap1_clk_init() unless I do the following: diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c index 92400b9..b9ce2ad 100644 --- a/arch/arm/mach-omap1/clock_data.c +++ b/arch/arm/mach-omap1/clock_data.c @@ -774,14 +774,6 @@ int __init omap1_clk_init(void) int crystal_type = 0; /* Default 12 MHz */ u32 reg, cpu_mask; -#ifdef CONFIG_DEBUG_LL - /* -* Resets some clocks that may be left on from bootloader, -* but leaves serial clocks on. -*/ - omap_writel(0x3 << 29, MOD_CONF_CTRL_0); -#endif - /* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */ reg = omap_readw(SOFT_REQ_REG) & (1 << 4); omap_writew(reg, SOFT_REQ_REG); 2) By using the above hack, I could see the actual crash: Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-rc1-e3 (aaro@dell) (gcc version 4.6.1 (GCC) ) #9 PREEMPT Thu Nov 10 23:48:23 EET 2011 [0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: Amstrad E3 (Delta) [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writethrough [0.00] OMAP1510 [0.00] revision 2 handled as 15xx id: bc058c9b93111a16 [0.00] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2cb3 ARM_CKCTL: 0x250e [0.00] [ cut here ] [0.00] kernel BUG at arch/arm/plat-omap/sram.c:226! [0.00] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.2.0-rc1-e3 #9) [0.00] PC is at omap_sram_reprogram_clock+0x28/0x30 [0.00] LR is at omap1_select_table_rate+0x88/0xb4 [0.00] pc : []lr : []psr: 60d3 [0.00] sp : c035bf10 ip : c035bf20 fp : c035bf1c [0.00] r10: c035bfd4 r9 : 54029252 r8 : c03f8120 [0.00] r7 : c0362b50 r6 : 00b71b00 r5 : c03873cc r4 : c0362b40 [0.00] r3 : r2 : c0362b40 r1 : 010a r0 : 2cb0 [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 317f Table: 10004000 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc035a270) [0.00] Stack: (0xc035bf10 to 0xc035c000) [0.00] bf00: c035bf3c c035bf20 c0019f54 c001b0ac [0.00] bf20: 1000 2cb3 0004 c035ed4c c035bf74 c035bf40 c033ea24 c0019edc [0.00] bf40: c02f526c 0002 0015 bc058c9b 93111a16 c035335c 0200 c035ed4c [0.00] bf60: c035ed4c c03f8120 c035bf84 c035bf78 c00194c4 c033e8ec c035bfc4 c035bf88 [0.00] bf80: c033bc24 c00194a0 c035bf90 c035bf98 [0.00] bfa0: 0001 c0354678 c035ece4 10004000 103532f4 c035bff4 c035bfc8 [0.00] bfc0: c0338574 c033b598 c035467c 317d c035c03c [0.00] bfe0: c0354678 c035ece4 c035bff8 10008040 c0338508 [0.00] Backtrace: [0.00] [] (omap_sram_reprogram_clock+0x0/0x30) from [] (omap1_select_table_rate+0x88/0xb4) [0.00] [] (omap1_select_table_rate+0x0/0xb4) from [] (omap1_clk_init+0x148/0x334) [0.00] r7:c035ed4c r6:0004 r5:2cb3 r4:1000 [0.00] [] (omap1_clk_init+0x0/0x334) from [] (omap1_init_early+0x34/0x48) [0.00] r8:c03f8120 r7:c035ed4c r6:c035ed
Re: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
Hi, On 10.11.2011, at 2.04, Tony Lindgren wrote: * Aaro Koskinen [09 15:25]: On 10.11.2011, at 1.39, Russell King - ARM Linux wrote: On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote: Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic map_io, init_early and init_irq) changed omap1 to use generic map_io. Looks like I missed one board though. Fix this by adding a custom map_io for Amstrad E3. Reported-by: Aaro Koskinen Signed-off-by: Tony Lindgren --- Untested, does this help? --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) omap_cfg_reg(J19_1610_CAM_D6); omap_cfg_reg(J18_1610_CAM_D7); - iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); - This is definitely wrong. Using iotable_init() after map_io has returned has (and remains) a serious bug - doing so may _appear_ to work but as it doesn't obtain its memory from the standard kernel memory allocators, it will lead to duplicate usage of that memory. Also, the patch did not help. It still hangs like before. Hmm that patch is needed for sure but sounds like there's also something else wrong.. Can you try to git bisect it? Ok, I'll try bisecting tomorrow. A. -- 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: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
* Aaro Koskinen [09 15:25]: > Hi, > > On 10.11.2011, at 1.39, Russell King - ARM Linux wrote: > >On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote: > >>Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use > >>generic > >>map_io, init_early and init_irq) changed omap1 to use generic map_io. > >> > >>Looks like I missed one board though. Fix this by adding a custom > >>map_io for Amstrad E3. > >> > >>Reported-by: Aaro Koskinen > >>Signed-off-by: Tony Lindgren > >> > >>--- > >>Untested, does this help? > >>--- a/arch/arm/mach-omap1/board-ams-delta.c > >>+++ b/arch/arm/mach-omap1/board-ams-delta.c > >>@@ -302,8 +302,6 @@ static void __init ams_delta_init(void) > >>omap_cfg_reg(J19_1610_CAM_D6); > >>omap_cfg_reg(J18_1610_CAM_D7); > >> > >>- iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); > >>- > > > >This is definitely wrong. Using iotable_init() after map_io has > >returned > >has (and remains) a serious bug - doing so may _appear_ to work > >but as it > >doesn't obtain its memory from the standard kernel memory > >allocators, it > >will lead to duplicate usage of that memory. > > Also, the patch did not help. It still hangs like before. Hmm that patch is needed for sure but sounds like there's also something else wrong.. Can you try to git bisect it? 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: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
Hi, On 10.11.2011, at 1.39, Russell King - ARM Linux wrote: On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote: Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic map_io, init_early and init_irq) changed omap1 to use generic map_io. Looks like I missed one board though. Fix this by adding a custom map_io for Amstrad E3. Reported-by: Aaro Koskinen Signed-off-by: Tony Lindgren --- Untested, does this help? --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) omap_cfg_reg(J19_1610_CAM_D6); omap_cfg_reg(J18_1610_CAM_D7); - iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); - This is definitely wrong. Using iotable_init() after map_io has returned has (and remains) a serious bug - doing so may _appear_ to work but as it doesn't obtain its memory from the standard kernel memory allocators, it will lead to duplicate usage of that memory. Also, the patch did not help. It still hangs like before. A. -- 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: [PATCH] ARM: OMAP: Fix map_io for Amstrad E3
On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote: > Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic > map_io, init_early and init_irq) changed omap1 to use generic map_io. > > Looks like I missed one board though. Fix this by adding a custom > map_io for Amstrad E3. > > Reported-by: Aaro Koskinen > Signed-off-by: Tony Lindgren > > --- > Untested, does this help? > --- a/arch/arm/mach-omap1/board-ams-delta.c > +++ b/arch/arm/mach-omap1/board-ams-delta.c > @@ -302,8 +302,6 @@ static void __init ams_delta_init(void) > omap_cfg_reg(J19_1610_CAM_D6); > omap_cfg_reg(J18_1610_CAM_D7); > > - iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); > - This is definitely wrong. Using iotable_init() after map_io has returned has (and remains) a serious bug - doing so may _appear_ to work but as it doesn't obtain its memory from the standard kernel memory allocators, it will lead to duplicate usage of that memory. -- 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
