linux-omap git tree updated to v2.6.32-rc1, important changes, please read

linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Tony Lindgren]

Hi all,

I've updated our linux-omap tree to v2.6.32-rc1. I've also
added a branch omap-2.6.31 for the old code.

This time I also nuked the remaining omap legacy code we
still had lurking around :) The commits at the end of this
mail describe what I did first as commits, then I merged
everything to be the same as the mainline v2.6.32-rc1.

So currently the linux-omap master branch is:

v2.6.32-rc1 + omap-fixes + ehci + cbus

The new model is that I'll be resetting the linux-omap master
branch to mainline at each -rc, then merge in our various
upstream queues back in again.

Please note that "Remove omap extra version in Makefile"
commit means that you now need to set the ARCH and CROSS_COMPILE
for your compiler.

The good news is that now you can pull in the linux-omap master
branch into any Linux kernel tree without messing up the other
architectures.

Also note that "Remove DEBUG_LL hack to printk" means that
in order to get DEBUG_LL working, you need to patch printk.c
yourself. You can find the patch in the omap-debug branch.

As always, if something important got thrown out, please
send patches against the mainline tree to patch back in
the missing functionality!

Regards,

Tony


f286f075db630e2266ddd011248f4533b55e8f85 REMOVE OMAP LEGACY CODE: Remove omap extra version in Makefile
3dc42bd7663d0b40eeabb5d509f9ab6f969c9ede REMOVE OMAP LEGACY CODE: Remove old documentation
e1483467f256833d406a386ef3ec97f7f5bb3642 REMOVE OMAP LEGACY CODE: Remove arch/arm hacks
9f4eec944af394feb212b48e6a7c3947424edb16 REMOVE OMAP LEGACY CODE: Remove drivers/Makefile hacks
b99dcece4468584eb08f8646477b7f0ca0c27f0f REMOVE OMAP LEGACY CODE: Remove DEBUG_LL hack to printk
9275f8614fd98139ea465455335e06b4ac4de0c4 REMOVE OMAP LEGACY CODE: Remove hacks for booting P2
dc3df234a0187c81ab9c0355ac6b659e25b11b33 REMOVE OMAP LEGACY CODE: Remove drivers/cbus

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Kalle Valo]

Tony Lindgren <tony@atomide.com> writes:

> Please note that "Remove omap extra version in Makefile"
> commit means that you now need to set the ARCH and CROSS_COMPILE
> for your compiler.

A handy tip is to create GNUmakefile containing this:

ARCH=arm
CROSS_COMPILE=arm-linux-
include Makefile

Now you can just write 'make' to compile the kernel as before.

The tip is also here:

http://elinux.org/N800#Simplify_make

-- 
Kalle Valo

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[green]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

Kalle Valo wrote at 2009-09-28 16:54 -0500:
> Tony Lindgren <tony@atomide.com> writes:
> > Please note that "Remove omap extra version in Makefile"
> > commit means that you now need to set the ARCH and CROSS_COMPILE
> > for your compiler.
> 
> A handy tip is to create GNUmakefile containing this:
> 
> ARCH=arm
> CROSS_COMPILE=arm-linux-
> include Makefile
> 
> Now you can just write 'make' to compile the kernel as before.

Great tip!

> The tip is also here:
> 
> http://elinux.org/N800#Simplify_make

I have been doing that since I noticed it at the above link.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Shilimkar, Santosh]

Tony,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Tuesday, September 29, 2009 12:34 AM
> To: linux-omap@vger.kernel.org
> Subject: linux-omap git tree updated to v2.6.32-rc1, important changes,
> please read
> 
> Hi all,
> 
> I've updated our linux-omap tree to v2.6.32-rc1. I've also
> added a branch omap-2.6.31 for the old code.
> 
> This time I also nuked the remaining omap legacy code we
> still had lurking around :) The commits at the end of this
> mail describe what I did first as commits, then I merged
> everything to be the same as the mainline v2.6.32-rc1.
> 
> So currently the linux-omap master branch is:
> 
> v2.6.32-rc1 + omap-fixes + ehci + cbus
> 
> The new model is that I'll be resetting the linux-omap master
> branch to mainline at each -rc, then merge in our various
> upstream queues back in again.
> 
> Please note that "Remove omap extra version in Makefile"
> commit means that you now need to set the ARCH and CROSS_COMPILE
> for your compiler.
> 
> The good news is that now you can pull in the linux-omap master
> branch into any Linux kernel tree without messing up the other
> architectures.
> 
> Also note that "Remove DEBUG_LL hack to printk" means that
> in order to get DEBUG_LL working, you need to patch printk.c
> yourself. You can find the patch in the omap-debug branch.
> 
> As always, if something important got thrown out, please
> send patches against the mainline tree to patch back in
> the missing functionality!

Thanks for fixing the OMAP4 compilation issues. We need below patch to make the kernel boot on OMAP4430 on the latest LO master.


>From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Tue, 29 Sep 2009 16:10:46 +0530
Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board

This patch enables omap_serial_early_init() function for OMAP4430
SDP. Without this the bootup would throw opps in omap_serial_init().

Additionally the patch removed the merge issue for the UART4.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |    4 ++--
 arch/arm/mach-omap2/io.c            |    2 ++
 arch/arm/mach-omap2/serial.c        |   10 ----------
 3 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index eb37c40..609a5a4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
 
 static void __init omap_4430sdp_init_irq(void)
 {
+	omap_board_config = sdp4430_config;
+	omap_board_config_size = ARRAY_SIZE(sdp4430_config);
 	omap2_init_common_hw(NULL, NULL);
 #ifdef CONFIG_OMAP_32K_TIMER
 	omap2_gp_clockevent_set_gptimer(1);
@@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
 static void __init omap_4430sdp_init(void)
 {
 	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
-	omap_board_config = sdp4430_config;
-	omap_board_config_size = ARRAY_SIZE(sdp4430_config);
 	omap_serial_init();
 }
 
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e3a3bad..56be87d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
 	pwrdm_init(powerdomains_omap);
 	clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
 	omap2_clk_init();
+#endif
 	omap_serial_early_init();
+#ifndef CONFIG_ARCH_OMAP4
 	omap_hwmod_late_init();
 	omap_pm_if_init();
 	omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ae21868..54dfeb5 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -109,16 +109,6 @@ static struct plat_serial8250_port serial_platform_data2[] = {
 		.regshift	= 2,
 		.uartclk	= OMAP24XX_BASE_BAUD * 16,
 	}, {
-#ifdef CONFIG_ARCH_OMAP4
-		.membase	= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
-		.mapbase	= OMAP_UART4_BASE,
-		.irq		= 70,
-		.flags		= UPF_BOOT_AUTOCONF,
-		.iotype		= UPIO_MEM,
-		.regshift	= 2,
-		.uartclk	= OMAP24XX_BASE_BAUD * 16,
-	}, {
-#endif
 		.flags		= 0
 	}
 };
-- 
1.5.4.7



Regards,
Santosh

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Tony Lindgren]

Hi,

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [090929 03:54]:

<snip>
 
> Thanks for fixing the OMAP4 compilation issues. We need below patch to make the kernel boot on OMAP4430 on the latest LO master.

No problem. In the future, let's make sure the omap4 patches are merged
into l-o master branch for testing. This time the first three patches
in the omap-fixes branch were build breakage caused by the omap4 patches
directly or indirectly..

Also, please everybody check that your patches don't break the build
for other the omaps, and also boot test on some other omaps if someting
looks risky.

Few comments below.
 
> 
> From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Tue, 29 Sep 2009 16:10:46 +0530
> Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430 board
> 
> This patch enables omap_serial_early_init() function for OMAP4430
> SDP. Without this the bootup would throw opps in omap_serial_init().

The opps probably should be oops above :)

 
> Additionally the patch removed the merge issue for the UART4.
> 
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  arch/arm/mach-omap2/board-4430sdp.c |    4 ++--
>  arch/arm/mach-omap2/io.c            |    2 ++
>  arch/arm/mach-omap2/serial.c        |   10 ----------
>  3 files changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index eb37c40..609a5a4 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
>  
>  static void __init omap_4430sdp_init_irq(void)
>  {
> +	omap_board_config = sdp4430_config;
> +	omap_board_config_size = ARRAY_SIZE(sdp4430_config);
>  	omap2_init_common_hw(NULL, NULL);
>  #ifdef CONFIG_OMAP_32K_TIMER
>  	omap2_gp_clockevent_set_gptimer(1);
> @@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
>  static void __init omap_4430sdp_init(void)
>  {
>  	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> -	omap_board_config = sdp4430_config;
> -	omap_board_config_size = ARRAY_SIZE(sdp4430_config);
>  	omap_serial_init();
>  }
>  
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index e3a3bad..56be87d 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>  	pwrdm_init(powerdomains_omap);
>  	clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
>  	omap2_clk_init();
> +#endif
>  	omap_serial_early_init();
> +#ifndef CONFIG_ARCH_OMAP4
>  	omap_hwmod_late_init();
>  	omap_pm_if_init();
>  	omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index ae21868..54dfeb5 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -109,16 +109,6 @@ static struct plat_serial8250_port serial_platform_data2[] = {
>  		.regshift	= 2,
>  		.uartclk	= OMAP24XX_BASE_BAUD * 16,
>  	}, {
> -#ifdef CONFIG_ARCH_OMAP4
> -		.membase	= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
> -		.mapbase	= OMAP_UART4_BASE,
> -		.irq		= 70,
> -		.flags		= UPF_BOOT_AUTOCONF,
> -		.iotype		= UPIO_MEM,
> -		.regshift	= 2,
> -		.uartclk	= OMAP24XX_BASE_BAUD * 16,
> -	}, {
> -#endif
>  		.flags		= 0
>  	}
>  };

Can't we fix the extra uart instead of removing it? We just added it!
It's still there in omap4, right?

Regards,

Tony

RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Shilimkar, Santosh]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Wednesday, September 30, 2009 11:25 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org
> Subject: Re: linux-omap git tree updated to v2.6.32-rc1, important changes,
> please read
> 
> Hi,
> 
> * Shilimkar, Santosh <santosh.shilimkar@ti.com> [090929 03:54]:
> 
> <snip>
> 
> > Thanks for fixing the OMAP4 compilation issues. We need below patch to
> make the kernel boot on OMAP4430 on the latest LO master.
> 
> No problem. In the future, let's make sure the omap4 patches are merged
> into l-o master branch for testing. This time the first three patches
> in the omap-fixes branch were build breakage caused by the omap4 patches
> directly or indirectly..
Agree!! 
> Also, please everybody check that your patches don't break the build
> for other the omaps, and also boot test on some other omaps if someting
> looks risky.
> 
> Few comments below.
> 
> >
> > From d9a22d9f7b68b99aa9607bdab377d998dfe82acd Mon Sep 17 00:00:00 2001
> > From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Date: Tue, 29 Sep 2009 16:10:46 +0530
> > Subject: [PATCH] ARM: OMAP4: Allow omap_serial_early_init() for OMAP4430
> board
> >
> > This patch enables omap_serial_early_init() function for OMAP4430
> > SDP. Without this the bootup would throw opps in omap_serial_init().
> 
> The opps probably should be oops above :)

YEP :)

> > Additionally the patch removed the merge issue for the UART4.
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > ---
> >  arch/arm/mach-omap2/board-4430sdp.c |    4 ++--
> >  arch/arm/mach-omap2/io.c            |    2 ++
> >  arch/arm/mach-omap2/serial.c        |   10 ----------
> >  3 files changed, 4 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
> omap2/board-4430sdp.c
> > index eb37c40..609a5a4 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c
> > @@ -58,6 +58,8 @@ static void __init gic_init_irq(void)
> >
> >  static void __init omap_4430sdp_init_irq(void)
> >  {
> > +	omap_board_config = sdp4430_config;
> > +	omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> >  	omap2_init_common_hw(NULL, NULL);
> >  #ifdef CONFIG_OMAP_32K_TIMER
> >  	omap2_gp_clockevent_set_gptimer(1);
> > @@ -70,8 +72,6 @@ static void __init omap_4430sdp_init_irq(void)
> >  static void __init omap_4430sdp_init(void)
> >  {
> >  	platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> > -	omap_board_config = sdp4430_config;
> > -	omap_board_config_size = ARRAY_SIZE(sdp4430_config);
> >  	omap_serial_init();
> >  }
> >
> > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > index e3a3bad..56be87d 100644
> > --- a/arch/arm/mach-omap2/io.c
> > +++ b/arch/arm/mach-omap2/io.c
> > @@ -302,7 +302,9 @@ void __init omap2_init_common_hw(struct
> omap_sdrc_params *sdrc_cs0,
> >  	pwrdm_init(powerdomains_omap);
> >  	clkdm_init(clockdomains_omap, clkdm_pwrdm_autodeps);
> >  	omap2_clk_init();
> > +#endif
> >  	omap_serial_early_init();
> > +#ifndef CONFIG_ARCH_OMAP4
> >  	omap_hwmod_late_init();
> >  	omap_pm_if_init();
> >  	omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
> > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> > index ae21868..54dfeb5 100644
> > --- a/arch/arm/mach-omap2/serial.c
> > +++ b/arch/arm/mach-omap2/serial.c
> > @@ -109,16 +109,6 @@ static struct plat_serial8250_port
> serial_platform_data2[] = {
> >  		.regshift	= 2,
> >  		.uartclk	= OMAP24XX_BASE_BAUD * 16,
> >  	}, {
> > -#ifdef CONFIG_ARCH_OMAP4
> > -		.membase	= OMAP2_IO_ADDRESS(OMAP_UART4_BASE),
> > -		.mapbase	= OMAP_UART4_BASE,
> > -		.irq		= 70,
> > -		.flags		= UPF_BOOT_AUTOCONF,
> > -		.iotype		= UPIO_MEM,
> > -		.regshift	= 2,
> > -		.uartclk	= OMAP24XX_BASE_BAUD * 16,
> > -	}, {
> > -#endif
> >  		.flags		= 0
> >  	}
> >  };
> 
> Can't we fix the extra uart instead of removing it? We just added it!
> It's still there in omap4, right?
This is already fixed. Above piece is not necessary since there is a separate instance for UART4 (serial_platform_data3[])
Regards,
Santosh

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Felipe Contreras]

On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> Hi all,
>
> I've updated our linux-omap tree to v2.6.32-rc1. I've also
> added a branch omap-2.6.31 for the old code.
>
> This time I also nuked the remaining omap legacy code we
> still had lurking around :) The commits at the end of this
> mail describe what I did first as commits, then I merged
> everything to be the same as the mainline v2.6.32-rc1.
>
> So currently the linux-omap master branch is:
>
> v2.6.32-rc1 + omap-fixes + ehci + cbus
>
> The new model is that I'll be resetting the linux-omap master
> branch to mainline at each -rc, then merge in our various
> upstream queues back in again.

Excellent! I was wondering why this wasn't being done. I certainly
hope linus' 2.6.32 will work on omap right away.

Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
other people report similar issues:
http://www.spinics.net/lists/linux-omap/msg17968.html

Have you got 2.6.32-rc1 (+fixes) to boot?

Cheers.

-- 
Felipe Contreras

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Tony Lindgren]

* Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> > Hi all,
> >
> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> > added a branch omap-2.6.31 for the old code.
> >
> > This time I also nuked the remaining omap legacy code we
> > still had lurking around :) The commits at the end of this
> > mail describe what I did first as commits, then I merged
> > everything to be the same as the mainline v2.6.32-rc1.
> >
> > So currently the linux-omap master branch is:
> >
> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >
> > The new model is that I'll be resetting the linux-omap master
> > branch to mainline at each -rc, then merge in our various
> > upstream queues back in again.
> 
> Excellent! I was wondering why this wasn't being done. I certainly
> hope linus' 2.6.32 will work on omap right away.

Yeah, let's hope Tomi gets in the DSS2 code too.
 
> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> other people report similar issues:
> http://www.spinics.net/lists/linux-omap/msg17968.html
> 
> Have you got 2.6.32-rc1 (+fixes) to boot?

Hmm, looks like it's musb again. This is what I get on my
overo after applying the DEBUG_LL hack from omap-debug branch:

<3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19             
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 
<1>pgd = c0004000                                                               
<1>[00000000] *pgd=00000000                                                     
Internal error: Oops: 5 [#1]                                                    
<d>Modules linked in:                                                           
CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)                   
PC is at musb_free+0x68/0xb8                                                    
LR is at musb_free+0x34/0xb8                                                    
pc : [<c028a160>]    lr : [<c028a12c>]    psr: a0000013                         
sp : c781fe50  ip : 00000064  fp : 00000000                                     
r10: 00000000  r9 : 00000000  r8 : c0557bc0                                     
r7 : c7811000  r6 : c78110e8  r5 : c78110e8  r4 : 00000000                      
r3 : 00000000  r2 : 00000001  r1 : c04c95b6  r0 : ffffffed                      
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel             
Control: 10c5387d  Table: 80004019  DAC: 00000017                               
Process swapper (pid: 1, stack limit = 0xc781e2f0)                              
Stack: (0xc781fe50 to 0xc7820000)
fe40:                                     ffffffed 00000000 c78110e8 c001e8f8   
fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000   
fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0   
fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00   
fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0   
fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4   
ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0   
ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04   
ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420   
ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4   
ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0   
ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000   
ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4   
ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
[<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)   
[<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
[<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
[<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
[<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
[<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
[<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
[<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
[<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
[<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
[<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
<4>---[ end trace 1b75b31a2719ed1c ]---                                         
<0>Kernel panic - not syncing: Attempted to kill init!

After disabling musb, it boots further but can't mount root on the MMC:

...
<4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on          
regulator_init_complete: incomplete constraints, leaving VUSB1V8 on             
<4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on          
regulator_init_complete: incomplete constraints, leaving VUSB1V5 on             
<4>regulator_init_complete: incomplete constraints, leaving VMMC1 on            
regulator_init_complete: incomplete constraints, leaving VMMC1 on               
<6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
<6>Waiting for root device /dev/mmcblk0p2...                                    
Waiting for root device /dev/mmcblk0p2...

What are you getting with DEBUG_LL enabled and the associated patch applied
from omap-debug branch?

Regards,

Tony

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Alexander Shishkin]

2009/9/29 Tony Lindgren <tony@atomide.com>:
> * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > Hi all,
>> >
>> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> > added a branch omap-2.6.31 for the old code.
>> >
>> > This time I also nuked the remaining omap legacy code we
>> > still had lurking around :) The commits at the end of this
>> > mail describe what I did first as commits, then I merged
>> > everything to be the same as the mainline v2.6.32-rc1.
>> >
>> > So currently the linux-omap master branch is:
>> >
>> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >
>> > The new model is that I'll be resetting the linux-omap master
>> > branch to mainline at each -rc, then merge in our various
>> > upstream queues back in again.
>>
>> Excellent! I was wondering why this wasn't being done. I certainly
>> hope linus' 2.6.32 will work on omap right away.
>
> Yeah, let's hope Tomi gets in the DSS2 code too.
>
>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> other people report similar issues:
>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>
>> Have you got 2.6.32-rc1 (+fixes) to boot?
>
> Hmm, looks like it's musb again. This is what I get on my
> overo after applying the DEBUG_LL hack from omap-debug branch:
>
> <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
> Internal error: Oops: 5 [#1]
> <d>Modules linked in:
> CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)
> PC is at musb_free+0x68/0xb8
> LR is at musb_free+0x34/0xb8
> pc : [<c028a160>]    lr : [<c028a12c>]    psr: a0000013
> sp : c781fe50  ip : 00000064  fp : 00000000
> r10: 00000000  r9 : 00000000  r8 : c0557bc0
> r7 : c7811000  r6 : c78110e8  r5 : c78110e8  r4 : 00000000
> r3 : 00000000  r2 : 00000001  r1 : c04c95b6  r0 : ffffffed
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 80004019  DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc781e2f0)
> Stack: (0xc781fe50 to 0xc7820000)
> fe40:                                     ffffffed 00000000 c78110e8 c001e8f8
> fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
> fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
> fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
> fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
> fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
> ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
> ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
> ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
> ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
> ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
> ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
> ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
> ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
> [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
> [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
> [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
> [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
> [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
> [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
> [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
> [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
> [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
> [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
> [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
> Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
> <4>---[ end trace 1b75b31a2719ed1c ]---
> <0>Kernel panic - not syncing: Attempted to kill init!
>
> After disabling musb, it boots further but can't mount root on the MMC:
>
> ...
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> regulator_init_complete: incomplete constraints, leaving VMMC1 on
> <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> <6>Waiting for root device /dev/mmcblk0p2...
> Waiting for root device /dev/mmcblk0p2...
>
> What are you getting with DEBUG_LL enabled and the associated patch applied
> from omap-debug branch?
MUSB enabled gives me the same backtrace. When I disable it, I get
(this is beagle B6):

<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
<1>pgd = c0004000
<1>[00000000] *pgd=00000000
Internal error: Oops: 805 [#1]
<d>Modules linked in:
CPU: 0    Tainted: G        W   (2.6.32-rc2-05968-g11ddc16 #7)
PC is at __mutex_lock_slowpath+0xe0/0x218
LR is at __mutex_lock_slowpath+0xcc/0x218
pc : [<c02967bc>]    lr : [<c02967a8>]    psr: 40000093
sp : c7819e80  ip : 11111111  fp : c6d2e824
r10: c6d2e800  r9 : c6d2e800  r8 : c7886c24
r7 : c7817a40  r6 : 60000013  r5 : c7886c20  r4 : c7886c20
r3 : 00000000  r2 : c7818000  r1 : c7819e80  r0 : c7886c20
Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc78182e8)
Stack: (0xc7819e80 to 0xc781a000)
9e80: c7886c24 00000000 11111111 c7819e80 c6d2fd00 c7886c20 c6d2e800 00000000
9ea0: c7886c20 c7886c00 c6d2e800 c6d2e800 c6d2e824 c0296900 c6d2e800 c0197afc
9ec0: c7886c00 00000000 c7886e68 00000000 c6d2e800 c0198f90 c6d369c8 00000000
9ee0: c7819f00 c6d36968 c7810518 69000001 7265746e 006c616e 00000000 00000000
9f00: c7810518 c0387d50 c0387d50 c03a0504 c03a0504 c03a4800 00000000 00000000
9f20: 00000000 c019b37c c0387d50 c01c009c c03a0504 c01bf0d4 00000000 c0387d50
9f40: c0387d84 c03a0504 c7819f60 c01bf204 00000000 c01bf1a4 c03a0504 c01be954
9f60: c7803af8 c7845970 c03a4800 c0022890 c03a0504 c03a0504 c6d30cc0 c01be1f8
9f80: c0315ab2 c00187a0 c6d30d40 c0022890 c0022948 c03a0504 00000000 00000000
9fa0: 00000000 c01bf508 c0022890 c0022948 c00187fc 00000000 00000000 c00272b4
9fc0: 00000000 00000192 c038ba20 00000000 00000000 c0022890 c0022948 00000000
9fe0: 00000000 c0008584 00000000 00000000 00000000 c0028d80 853bee50 007b4fa4
[<c02967bc>] (__mutex_lock_slowpath+0xe0/0x218) from [<c0296900>]
(mutex_lock+0xc/0x1c)
[<c0296900>] (mutex_lock+0xc/0x1c) from [<c0197afc>]
(set_fb_fix+0x30/0xbc)
[<c0197afc>] (set_fb_fix+0x30/0xbc) from [<c0198f90>]
(omapfb_do_probe+0x404/0x858)
[<c0198f90>] (omapfb_do_probe+0x404/0x858) from [<c019b37c>]
(omap3beagle_panel_probe+0x10/0x20)
[<c019b37c>] (omap3beagle_panel_probe+0x10/0x20) from [<c01c009c>]
(platform_drv_probe+0x1c/0x24)
[<c01c009c>] (platform_drv_probe+0x1c/0x24) from [<c01bf0d4>]
(driver_probe_device+0xa4/0x174)
[<c01bf0d4>] (driver_probe_device+0xa4/0x174) from [<c01bf204>]
(__driver_attach+0x60/0x84)
[<c01bf204>] (__driver_attach+0x60/0x84) from [<c01be954>]
(bus_for_each_dev+0x4c/0x8c)
[<c01be954>] (bus_for_each_dev+0x4c/0x8c) from [<c01be1f8>]
(bus_add_driver+0xa0/0x218)
[<c01be1f8>] (bus_add_driver+0xa0/0x218) from [<c01bf508>]
(driver_register+0xbc/0x148)
[<c01bf508>] (driver_register+0xbc/0x148) from [<c00272b4>]
(do_one_initcall+0x5c/0x1bc)
[<c00272b4>] (do_one_initcall+0x5c/0x1bc) from [<c0008584>]
(kernel_init+0x94/0x110)
[<c0008584>] (kernel_init+0x94/0x110) from [<c0028d80>]
(kernel_thread_exit+0x0/0x8)
Code: e2858004 e585d008 e58d8000 e58d3004 (e583d000)
<4>---[ end trace da227214a82491b8 ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Aguirre Rodriguez, Sergio Alberto]

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]

From: linux-omap-owner@vger.kernel.org [linux-omap-owner@vger.kernel.org] On Behalf Of Alexander Shishkin [virtuoso@slind.org]
Sent: Tuesday, September 29, 2009 2:20 PM
> 2009/9/29 Tony Lindgren <tony@atomide.com>:
> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi all,
> >> >
> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> >> > added a branch omap-2.6.31 for the old code.
> >> >
> >> > This time I also nuked the remaining omap legacy code we
> >> > still had lurking around :) The commits at the end of this
> >> > mail describe what I did first as commits, then I merged
> >> > everything to be the same as the mainline v2.6.32-rc1.
> >> >
> >> > So currently the linux-omap master branch is:
> >> >
> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >> >
> >> > The new model is that I'll be resetting the linux-omap master
> >> > branch to mainline at each -rc, then merge in our various
> >> > upstream queues back in again.
> >>
> >> Excellent! I was wondering why this wasn't being done. I certainly
> >> hope linus' 2.6.32 will work on omap right away.
> >
> > Yeah, let's hope Tomi gets in the DSS2 code too.
> >
> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> >> other people report similar issues:
> >> http://www.spinics.net/lists/linux-omap/msg17968.html
> >>
> >> Have you got 2.6.32-rc1 (+fixes) to boot?
> >
> > Hmm, looks like it's musb again. This is what I get on my
> > overo after applying the DEBUG_LL hack from omap-debug branch:
> >
> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > <1>pgd = c0004000
> > <1>[00000000] *pgd=00000000
> > Internal error: Oops: 5 [#1]
> > <d>Modules linked in:
> > CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)
> > PC is at musb_free+0x68/0xb8
> > LR is at musb_free+0x34/0xb8

<snip>

> >
> > After disabling musb, it boots further but can't mount root on the MMC:
> >
> > ...
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> > <6>Waiting for root device /dev/mmcblk0p2...
> > Waiting for root device /dev/mmcblk0p2...
> >
> > What are you getting with DEBUG_LL enabled and the associated patch applied
> > from omap-debug branch?
> MUSB enabled gives me the same backtrace. When I disable it, I get
> (this is beagle B6):
> 
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000

<snip>

Hi,

Can you please try attached patch?

Regards,
Sergio

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-omapfb-Condition-mutex-acquisition.patch --]
[-- Type: text/x-patch; name="0001-omapfb-Condition-mutex-acquisition.patch", Size: 2493 bytes --]

From bba2d89ea45ec0359dec6fe21c1756ad3406e347 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre <saaguirre@ti.com>
Date: Tue, 29 Sep 2009 07:44:19 -0500
Subject: [PATCH] omapfb: Condition mutex acquisition

Acquiring mutex before framebuffer registration doesn't make sense,
As there's no danger of external access to the memory related fields.

NOTE: PLEASE REVIEW! I'M NOT AN EXPERT ON THIS.

Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
---
 drivers/video/omap/omapfb_main.c |   22 ++++++++++++++--------
 1 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 125e605..0d0c8c8 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -393,7 +393,7 @@ static void omapfb_sync(struct fb_info *fbi)
  * Set fb_info.fix fields and also updates fbdev.
  * When calling this fb_info.var must be set up already.
  */
-static void set_fb_fix(struct fb_info *fbi)
+static void set_fb_fix(struct fb_info *fbi, int from_init)
 {
 	struct fb_fix_screeninfo *fix = &fbi->fix;
 	struct fb_var_screeninfo *var = &fbi->var;
@@ -403,10 +403,16 @@ static void set_fb_fix(struct fb_info *fbi)
 
 	rg = &plane->fbdev->mem_desc.region[plane->idx];
 	fbi->screen_base	= rg->vaddr;
-	mutex_lock(&fbi->mm_lock);
-	fix->smem_start		= rg->paddr;
-	fix->smem_len		= rg->size;
-	mutex_unlock(&fbi->mm_lock);
+
+	if (!from_init) {
+		mutex_lock(&fbi->mm_lock);
+		fix->smem_start		= rg->paddr;
+		fix->smem_len		= rg->size;
+		mutex_unlock(&fbi->mm_lock);
+	} else {
+		fix->smem_start		= rg->paddr;
+		fix->smem_len		= rg->size;
+	}
 
 	fix->type = FB_TYPE_PACKED_PIXELS;
 	bpp = var->bits_per_pixel;
@@ -704,7 +710,7 @@ static int omapfb_set_par(struct fb_info *fbi)
 	int r = 0;
 
 	omapfb_rqueue_lock(fbdev);
-	set_fb_fix(fbi);
+	set_fb_fix(fbi, 0);
 	r = ctrl_change_mode(fbi);
 	omapfb_rqueue_unlock(fbdev);
 
@@ -904,7 +910,7 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
 		if (old_size != size) {
 			if (size) {
 				memcpy(&fbi->var, new_var, sizeof(fbi->var));
-				set_fb_fix(fbi);
+				set_fb_fix(fbi, 0);
 			} else {
 				/*
 				 * Set these explicitly to indicate that the
@@ -1504,7 +1510,7 @@ static int fbinfo_init(struct omapfb_device *fbdev, struct fb_info *info)
 	var->bits_per_pixel = fbdev->panel->bpp;
 
 	set_fb_var(info, var);
-	set_fb_fix(info);
+	set_fb_fix(info, 1);
 
 	r = fb_alloc_cmap(&info->cmap, 16, 0);
 	if (r != 0)
-- 
1.6.0.4

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Alexander Shishkin]

2009/9/29 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> From: linux-omap-owner@vger.kernel.org [linux-omap-owner@vger.kernel.org] On Behalf Of Alexander Shishkin [virtuoso@slind.org]
> Sent: Tuesday, September 29, 2009 2:20 PM
>> 2009/9/29 Tony Lindgren <tony@atomide.com>:
>> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> >> > added a branch omap-2.6.31 for the old code.
>> >> >
>> >> > This time I also nuked the remaining omap legacy code we
>> >> > still had lurking around :) The commits at the end of this
>> >> > mail describe what I did first as commits, then I merged
>> >> > everything to be the same as the mainline v2.6.32-rc1.
>> >> >
>> >> > So currently the linux-omap master branch is:
>> >> >
>> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >> >
>> >> > The new model is that I'll be resetting the linux-omap master
>> >> > branch to mainline at each -rc, then merge in our various
>> >> > upstream queues back in again.
>> >>
>> >> Excellent! I was wondering why this wasn't being done. I certainly
>> >> hope linus' 2.6.32 will work on omap right away.
>> >
>> > Yeah, let's hope Tomi gets in the DSS2 code too.
>> >
>> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> >> other people report similar issues:
>> >> http://www.spinics.net/lists/linux-omap/msg17968.html
>> >>
>> >> Have you got 2.6.32-rc1 (+fixes) to boot?
>> >
>> > Hmm, looks like it's musb again. This is what I get on my
>> > overo after applying the DEBUG_LL hack from omap-debug branch:
>> >
>> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
>> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> > <1>pgd = c0004000
>> > <1>[00000000] *pgd=00000000
>> > Internal error: Oops: 5 [#1]
>> > <d>Modules linked in:
>> > CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)
>> > PC is at musb_free+0x68/0xb8
>> > LR is at musb_free+0x34/0xb8
>
> <snip>
>
>> >
>> > After disabling musb, it boots further but can't mount root on the MMC:
>> >
>> > ...
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
>> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
>> > <6>Waiting for root device /dev/mmcblk0p2...
>> > Waiting for root device /dev/mmcblk0p2...
>> >
>> > What are you getting with DEBUG_LL enabled and the associated patch applied
>> > from omap-debug branch?
>> MUSB enabled gives me the same backtrace. When I disable it, I get
>> (this is beagle B6):
>>
>> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> <1>pgd = c0004000
>> <1>[00000000] *pgd=00000000
>
> <snip>
>
> Hi,
>
> Can you please try attached patch?

Yep, thanks! (provided it's actually the same patch that Toni referred to).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Tony Lindgren]

* Alexander Shishkin <virtuoso@slind.org> [090929 12:20]:
> 2009/9/29 Tony Lindgren <tony@atomide.com>:
> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi all,
> >> >
> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> >> > added a branch omap-2.6.31 for the old code.
> >> >
> >> > This time I also nuked the remaining omap legacy code we
> >> > still had lurking around :) The commits at the end of this
> >> > mail describe what I did first as commits, then I merged
> >> > everything to be the same as the mainline v2.6.32-rc1.
> >> >
> >> > So currently the linux-omap master branch is:
> >> >
> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >> >
> >> > The new model is that I'll be resetting the linux-omap master
> >> > branch to mainline at each -rc, then merge in our various
> >> > upstream queues back in again.
> >>
> >> Excellent! I was wondering why this wasn't being done. I certainly
> >> hope linus' 2.6.32 will work on omap right away.
> >
> > Yeah, let's hope Tomi gets in the DSS2 code too.
> >
> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> >> other people report similar issues:
> >> http://www.spinics.net/lists/linux-omap/msg17968.html
> >>
> >> Have you got 2.6.32-rc1 (+fixes) to boot?
> >
> > Hmm, looks like it's musb again. This is what I get on my
> > overo after applying the DEBUG_LL hack from omap-debug branch:
> >
> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > <1>pgd = c0004000
> > <1>[00000000] *pgd=00000000
> > Internal error: Oops: 5 [#1]
> > <d>Modules linked in:
> > CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)
> > PC is at musb_free+0x68/0xb8
> > LR is at musb_free+0x34/0xb8
> > pc : [<c028a160>]    lr : [<c028a12c>]    psr: a0000013
> > sp : c781fe50  ip : 00000064  fp : 00000000
> > r10: 00000000  r9 : 00000000  r8 : c0557bc0
> > r7 : c7811000  r6 : c78110e8  r5 : c78110e8  r4 : 00000000
> > r3 : 00000000  r2 : 00000001  r1 : c04c95b6  r0 : ffffffed
> > Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> > Control: 10c5387d  Table: 80004019  DAC: 00000017
> > Process swapper (pid: 1, stack limit = 0xc781e2f0)
> > Stack: (0xc781fe50 to 0xc7820000)
> > fe40:                                     ffffffed 00000000 c78110e8 c001e8f8
> > fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
> > fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
> > fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
> > fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
> > fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
> > ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
> > ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
> > ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
> > ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
> > ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
> > ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
> > ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
> > ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
> > [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
> > [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
> > [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
> > [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
> > [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
> > [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
> > [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
> > [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
> > [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
> > [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
> > [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
> > Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
> > <4>---[ end trace 1b75b31a2719ed1c ]---
> > <0>Kernel panic - not syncing: Attempted to kill init!
> >
> > After disabling musb, it boots further but can't mount root on the MMC:
> >
> > ...
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> > <6>Waiting for root device /dev/mmcblk0p2...
> > Waiting for root device /dev/mmcblk0p2...
> >
> > What are you getting with DEBUG_LL enabled and the associated patch applied
> > from omap-debug branch?
> MUSB enabled gives me the same backtrace. When I disable it, I get
> (this is beagle B6):
> 
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
> Internal error: Oops: 805 [#1]
> <d>Modules linked in:
> CPU: 0    Tainted: G        W   (2.6.32-rc2-05968-g11ddc16 #7)
> PC is at __mutex_lock_slowpath+0xe0/0x218
> LR is at __mutex_lock_slowpath+0xcc/0x218
> pc : [<c02967bc>]    lr : [<c02967a8>]    psr: 40000093
> sp : c7819e80  ip : 11111111  fp : c6d2e824
> r10: c6d2e800  r9 : c6d2e800  r8 : c7886c24
> r7 : c7817a40  r6 : 60000013  r5 : c7886c20  r4 : c7886c20
> r3 : 00000000  r2 : c7818000  r1 : c7819e80  r0 : c7886c20
> Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 80004019  DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc78182e8)
> Stack: (0xc7819e80 to 0xc781a000)
> 9e80: c7886c24 00000000 11111111 c7819e80 c6d2fd00 c7886c20 c6d2e800 00000000
> 9ea0: c7886c20 c7886c00 c6d2e800 c6d2e800 c6d2e824 c0296900 c6d2e800 c0197afc
> 9ec0: c7886c00 00000000 c7886e68 00000000 c6d2e800 c0198f90 c6d369c8 00000000
> 9ee0: c7819f00 c6d36968 c7810518 69000001 7265746e 006c616e 00000000 00000000
> 9f00: c7810518 c0387d50 c0387d50 c03a0504 c03a0504 c03a4800 00000000 00000000
> 9f20: 00000000 c019b37c c0387d50 c01c009c c03a0504 c01bf0d4 00000000 c0387d50
> 9f40: c0387d84 c03a0504 c7819f60 c01bf204 00000000 c01bf1a4 c03a0504 c01be954
> 9f60: c7803af8 c7845970 c03a4800 c0022890 c03a0504 c03a0504 c6d30cc0 c01be1f8
> 9f80: c0315ab2 c00187a0 c6d30d40 c0022890 c0022948 c03a0504 00000000 00000000
> 9fa0: 00000000 c01bf508 c0022890 c0022948 c00187fc 00000000 00000000 c00272b4
> 9fc0: 00000000 00000192 c038ba20 00000000 00000000 c0022890 c0022948 00000000
> 9fe0: 00000000 c0008584 00000000 00000000 00000000 c0028d80 853bee50 007b4fa4
> [<c02967bc>] (__mutex_lock_slowpath+0xe0/0x218) from [<c0296900>]
> (mutex_lock+0xc/0x1c)
> [<c0296900>] (mutex_lock+0xc/0x1c) from [<c0197afc>]
> (set_fb_fix+0x30/0xbc)
> [<c0197afc>] (set_fb_fix+0x30/0xbc) from [<c0198f90>]
> (omapfb_do_probe+0x404/0x858)
> [<c0198f90>] (omapfb_do_probe+0x404/0x858) from [<c019b37c>]
> (omap3beagle_panel_probe+0x10/0x20)
> [<c019b37c>] (omap3beagle_panel_probe+0x10/0x20) from [<c01c009c>]
> (platform_drv_probe+0x1c/0x24)
> [<c01c009c>] (platform_drv_probe+0x1c/0x24) from [<c01bf0d4>]
> (driver_probe_device+0xa4/0x174)
> [<c01bf0d4>] (driver_probe_device+0xa4/0x174) from [<c01bf204>]
> (__driver_attach+0x60/0x84)
> [<c01bf204>] (__driver_attach+0x60/0x84) from [<c01be954>]
> (bus_for_each_dev+0x4c/0x8c)
> [<c01be954>] (bus_for_each_dev+0x4c/0x8c) from [<c01be1f8>]
> (bus_add_driver+0xa0/0x218)
> [<c01be1f8>] (bus_add_driver+0xa0/0x218) from [<c01bf508>]
> (driver_register+0xbc/0x148)
> [<c01bf508>] (driver_register+0xbc/0x148) from [<c00272b4>]
> (do_one_initcall+0x5c/0x1bc)
> [<c00272b4>] (do_one_initcall+0x5c/0x1bc) from [<c0008584>]
> (kernel_init+0x94/0x110)
> [<c0008584>] (kernel_init+0x94/0x110) from [<c0028d80>]
> (kernel_thread_exit+0x0/0x8)
> Code: e2858004 e585d008 e58d8000 e58d3004 (e583d000)
> <4>---[ end trace da227214a82491b8 ]---

Maybe try Sergio's "omapfb: Condition mutex acquisition" patch:

http://patchwork.kernel.org/patch/50551/

Does that help?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Alexander Shishkin]

2009/9/29 Tony Lindgren <tony@atomide.com>:
> * Alexander Shishkin <virtuoso@slind.org> [090929 12:20]:
>> 2009/9/29 Tony Lindgren <tony@atomide.com>:
>> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> >> > added a branch omap-2.6.31 for the old code.
>> >> >
>> >> > This time I also nuked the remaining omap legacy code we
>> >> > still had lurking around :) The commits at the end of this
>> >> > mail describe what I did first as commits, then I merged
>> >> > everything to be the same as the mainline v2.6.32-rc1.
>> >> >
>> >> > So currently the linux-omap master branch is:
>> >> >
>> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >> >
>> >> > The new model is that I'll be resetting the linux-omap master
>> >> > branch to mainline at each -rc, then merge in our various
>> >> > upstream queues back in again.
>> >>
>> >> Excellent! I was wondering why this wasn't being done. I certainly
>> >> hope linus' 2.6.32 will work on omap right away.
>> >
>> > Yeah, let's hope Tomi gets in the DSS2 code too.
>> >
>> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> >> other people report similar issues:
>> >> http://www.spinics.net/lists/linux-omap/msg17968.html
>> >>
>> >> Have you got 2.6.32-rc1 (+fixes) to boot?
>> >
>> > Hmm, looks like it's musb again. This is what I get on my
>> > overo after applying the DEBUG_LL hack from omap-debug branch:
>> >
>> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
>> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> > <1>pgd = c0004000
>> > <1>[00000000] *pgd=00000000
>> > Internal error: Oops: 5 [#1]
>> > <d>Modules linked in:
>> > CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)
>> > PC is at musb_free+0x68/0xb8
>> > LR is at musb_free+0x34/0xb8
>> > pc : [<c028a160>]    lr : [<c028a12c>]    psr: a0000013
>> > sp : c781fe50  ip : 00000064  fp : 00000000
>> > r10: 00000000  r9 : 00000000  r8 : c0557bc0
>> > r7 : c7811000  r6 : c78110e8  r5 : c78110e8  r4 : 00000000
>> > r3 : 00000000  r2 : 00000001  r1 : c04c95b6  r0 : ffffffed
>> > Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>> > Control: 10c5387d  Table: 80004019  DAC: 00000017
>> > Process swapper (pid: 1, stack limit = 0xc781e2f0)
>> > Stack: (0xc781fe50 to 0xc7820000)
>> > fe40:                                     ffffffed 00000000 c78110e8 c001e8f8
>> > fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000
>> > fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0
>> > fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00
>> > fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0
>> > fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4
>> > ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0
>> > ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04
>> > ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420
>> > ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4
>> > ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0
>> > ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000
>> > ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4
>> > ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
>> > [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)
>> > [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
>> > [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
>> > [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
>> > [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
>> > [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
>> > [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
>> > [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
>> > [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
>> > [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
>> > [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
>> > Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
>> > <4>---[ end trace 1b75b31a2719ed1c ]---
>> > <0>Kernel panic - not syncing: Attempted to kill init!
>> >
>> > After disabling musb, it boots further but can't mount root on the MMC:
>> >
>> > ...
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
>> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
>> > <6>Waiting for root device /dev/mmcblk0p2...
>> > Waiting for root device /dev/mmcblk0p2...
>> >
>> > What are you getting with DEBUG_LL enabled and the associated patch applied
>> > from omap-debug branch?
>> MUSB enabled gives me the same backtrace. When I disable it, I get
>> (this is beagle B6):
>>
>> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> <1>pgd = c0004000
>> <1>[00000000] *pgd=00000000
>> Internal error: Oops: 805 [#1]
>> <d>Modules linked in:
>> CPU: 0    Tainted: G        W   (2.6.32-rc2-05968-g11ddc16 #7)
>> PC is at __mutex_lock_slowpath+0xe0/0x218
>> LR is at __mutex_lock_slowpath+0xcc/0x218
>> pc : [<c02967bc>]    lr : [<c02967a8>]    psr: 40000093
>> sp : c7819e80  ip : 11111111  fp : c6d2e824
>> r10: c6d2e800  r9 : c6d2e800  r8 : c7886c24
>> r7 : c7817a40  r6 : 60000013  r5 : c7886c20  r4 : c7886c20
>> r3 : 00000000  r2 : c7818000  r1 : c7819e80  r0 : c7886c20
>> Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
>> Control: 10c5387d  Table: 80004019  DAC: 00000017
>> Process swapper (pid: 1, stack limit = 0xc78182e8)
>> Stack: (0xc7819e80 to 0xc781a000)
>> 9e80: c7886c24 00000000 11111111 c7819e80 c6d2fd00 c7886c20 c6d2e800 00000000
>> 9ea0: c7886c20 c7886c00 c6d2e800 c6d2e800 c6d2e824 c0296900 c6d2e800 c0197afc
>> 9ec0: c7886c00 00000000 c7886e68 00000000 c6d2e800 c0198f90 c6d369c8 00000000
>> 9ee0: c7819f00 c6d36968 c7810518 69000001 7265746e 006c616e 00000000 00000000
>> 9f00: c7810518 c0387d50 c0387d50 c03a0504 c03a0504 c03a4800 00000000 00000000
>> 9f20: 00000000 c019b37c c0387d50 c01c009c c03a0504 c01bf0d4 00000000 c0387d50
>> 9f40: c0387d84 c03a0504 c7819f60 c01bf204 00000000 c01bf1a4 c03a0504 c01be954
>> 9f60: c7803af8 c7845970 c03a4800 c0022890 c03a0504 c03a0504 c6d30cc0 c01be1f8
>> 9f80: c0315ab2 c00187a0 c6d30d40 c0022890 c0022948 c03a0504 00000000 00000000
>> 9fa0: 00000000 c01bf508 c0022890 c0022948 c00187fc 00000000 00000000 c00272b4
>> 9fc0: 00000000 00000192 c038ba20 00000000 00000000 c0022890 c0022948 00000000
>> 9fe0: 00000000 c0008584 00000000 00000000 00000000 c0028d80 853bee50 007b4fa4
>> [<c02967bc>] (__mutex_lock_slowpath+0xe0/0x218) from [<c0296900>]
>> (mutex_lock+0xc/0x1c)
>> [<c0296900>] (mutex_lock+0xc/0x1c) from [<c0197afc>]
>> (set_fb_fix+0x30/0xbc)
>> [<c0197afc>] (set_fb_fix+0x30/0xbc) from [<c0198f90>]
>> (omapfb_do_probe+0x404/0x858)
>> [<c0198f90>] (omapfb_do_probe+0x404/0x858) from [<c019b37c>]
>> (omap3beagle_panel_probe+0x10/0x20)
>> [<c019b37c>] (omap3beagle_panel_probe+0x10/0x20) from [<c01c009c>]
>> (platform_drv_probe+0x1c/0x24)
>> [<c01c009c>] (platform_drv_probe+0x1c/0x24) from [<c01bf0d4>]
>> (driver_probe_device+0xa4/0x174)
>> [<c01bf0d4>] (driver_probe_device+0xa4/0x174) from [<c01bf204>]
>> (__driver_attach+0x60/0x84)
>> [<c01bf204>] (__driver_attach+0x60/0x84) from [<c01be954>]
>> (bus_for_each_dev+0x4c/0x8c)
>> [<c01be954>] (bus_for_each_dev+0x4c/0x8c) from [<c01be1f8>]
>> (bus_add_driver+0xa0/0x218)
>> [<c01be1f8>] (bus_add_driver+0xa0/0x218) from [<c01bf508>]
>> (driver_register+0xbc/0x148)
>> [<c01bf508>] (driver_register+0xbc/0x148) from [<c00272b4>]
>> (do_one_initcall+0x5c/0x1bc)
>> [<c00272b4>] (do_one_initcall+0x5c/0x1bc) from [<c0008584>]
>> (kernel_init+0x94/0x110)
>> [<c0008584>] (kernel_init+0x94/0x110) from [<c0028d80>]
>> (kernel_thread_exit+0x0/0x8)
>> Code: e2858004 e585d008 e58d8000 e58d3004 (e583d000)
>> <4>---[ end trace da227214a82491b8 ]---
>
> Maybe try Sergio's "omapfb: Condition mutex acquisition" patch:
>
> http://patchwork.kernel.org/patch/50551/
>
> Does that help?

Indeed it does. Now I'm seeing the same regulator stuff you quoted.
Given that I'm not set up to mount rootfs from mmc, it just panics on
not able to mount rootfs (since there's nothing to mount). I think
I'll get myself some sort of an initramfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Roger Quadros]

ext Tony Lindgren wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>>> Hi all,
>>>
>>> I've updated our linux-omap tree to v2.6.32-rc1. I've also
>>> added a branch omap-2.6.31 for the old code.
>>>
>>> This time I also nuked the remaining omap legacy code we
>>> still had lurking around :) The commits at the end of this
>>> mail describe what I did first as commits, then I merged
>>> everything to be the same as the mainline v2.6.32-rc1.
>>>
>>> So currently the linux-omap master branch is:
>>>
>>> v2.6.32-rc1 + omap-fixes + ehci + cbus
>>>
>>> The new model is that I'll be resetting the linux-omap master
>>> branch to mainline at each -rc, then merge in our various
>>> upstream queues back in again.
>> Excellent! I was wondering why this wasn't being done. I certainly
>> hope linus' 2.6.32 will work on omap right away.
> 
> Yeah, let's hope Tomi gets in the DSS2 code too.
>  
>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> other people report similar issues:
>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>
>> Have you got 2.6.32-rc1 (+fixes) to boot?
> 
> Hmm, looks like it's musb again. This is what I get on my
> overo after applying the DEBUG_LL hack from omap-debug branch:

i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix boot 
with twl4030 usb transceiver enabled"

cheers,
-roger

> 
> <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19             
> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 
> <1>pgd = c0004000                                                               
> <1>[00000000] *pgd=00000000                                                     
> Internal error: Oops: 5 [#1]                                                    
> <d>Modules linked in:                                                           
> CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)                   
> PC is at musb_free+0x68/0xb8                                                    
> LR is at musb_free+0x34/0xb8                                                    
> pc : [<c028a160>]    lr : [<c028a12c>]    psr: a0000013                         
> sp : c781fe50  ip : 00000064  fp : 00000000                                     
> r10: 00000000  r9 : 00000000  r8 : c0557bc0                                     
> r7 : c7811000  r6 : c78110e8  r5 : c78110e8  r4 : 00000000                      
> r3 : 00000000  r2 : 00000001  r1 : c04c95b6  r0 : ffffffed                      
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel             
> Control: 10c5387d  Table: 80004019  DAC: 00000017                               
> Process swapper (pid: 1, stack limit = 0xc781e2f0)                              
> Stack: (0xc781fe50 to 0xc7820000)
> fe40:                                     ffffffed 00000000 c78110e8 c001e8f8   
> fe60: c781fea4 c7804180 00000000 c7804184 c0533dc8 c0533dd0 0000005c d80ab000   
> fe80: c0533dac c7811190 00000000 c781fedc c0114ad8 c7806850 c0546248 c06d74e0   
> fea0: 00000000 c03cd5c8 00000000 c781ff00 c78b8de0 c0114cbc c78b8d80 c781ff00   
> fec0: c78b8de0 c0114864 c78b8d80 c781ff00 c78b8de0 c011493c c781ff00 c78b8de0   
> fee0: c78b8d80 00000000 c781ff00 c78b8de0 c787a210 00000001 00000000 c01157b4   
> ff00: c787a210 00000000 00000000 c0533dd0 c0533dd0 c055df04 c7873600 c0557bc0   
> ff20: 00000000 00000000 00000000 c0210b7c c0533dd0 c020fbd4 c0533dd0 c0533e04   
> ff40: c055df04 c7873600 c0557bc0 c020fce0 00000000 c020fc80 c055df04 c020f420   
> ff60: c7802d08 c787b240 c0026dd4 00000080 c055df04 c020ed38 c03f14f4 c03f14f4   
> ff80: c7820000 c0026dd4 c055def0 c055df04 00000000 00000000 00000000 c020ffb0   
> ffa0: c0026dd4 c055def0 c001dca0 00000000 00000000 c0210f70 c0026dd4 00000000   
> ffc0: c001dca0 c002d2b4 00000031 00000000 00000000 00000192 00000000 c0026dd4   
> ffe0: 00000000 00000000 00000000 c0008578 00000000 c002ee10 817fdf10 00bbff00
> [<c028a160>] (musb_free+0x68/0xb8) from [<c001e8f8>] (musb_probe+0xab8/0xbb4)   
> [<c001e8f8>] (musb_probe+0xab8/0xbb4) from [<c0210b7c>] (platform_drv_probe+0x1)
> [<c0210b7c>] (platform_drv_probe+0x18/0x1c) from [<c020fbd4>] (driver_probe_dev)
> [<c020fbd4>] (driver_probe_device+0xa0/0x14c) from [<c020fce0>] (__driver_attac)
> [<c020fce0>] (__driver_attach+0x60/0x84) from [<c020f420>] (bus_for_each_dev+0x)
> [<c020f420>] (bus_for_each_dev+0x44/0x74) from [<c020ed38>] (bus_add_driver+0xf)
> [<c020ed38>] (bus_add_driver+0xf4/0x278) from [<c020ffb0>] (driver_register+0xa)
> [<c020ffb0>] (driver_register+0xa8/0x130) from [<c0210f70>] (platform_driver_pr)
> [<c0210f70>] (platform_driver_probe+0x10/0x88) from [<c002d2b4>] (do_one_initca)
> [<c002d2b4>] (do_one_initcall+0x5c/0x1b4) from [<c0008578>] (kernel_init+0x90/0)
> [<c0008578>] (kernel_init+0x90/0x10c) from [<c002ee10>] (kernel_thread_exit+0x0)
> Code: e1a01005 ebf80722 e595309c e3a04000 (e5930000)
> <4>---[ end trace 1b75b31a2719ed1c ]---                                         
> <0>Kernel panic - not syncing: Attempted to kill init!
> 
> After disabling musb, it boots further but can't mount root on the MMC:
> 
> ...
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on          
> regulator_init_complete: incomplete constraints, leaving VUSB1V8 on             
> <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on          
> regulator_init_complete: incomplete constraints, leaving VUSB1V5 on             
> <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on            
> regulator_init_complete: incomplete constraints, leaving VMMC1 on               
> <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
> twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
> <6>Waiting for root device /dev/mmcblk0p2...                                    
> Waiting for root device /dev/mmcblk0p2...
> 
> What are you getting with DEBUG_LL enabled and the associated patch applied
> from omap-debug branch?
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Alexander Shishkin]

2009/9/30 Roger Quadros <ext-roger.quadros@nokia.com>:
> ext Tony Lindgren wrote:
>>
>> * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>>>
>>> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I've updated our linux-omap tree to v2.6.32-rc1. I've also
>>>> added a branch omap-2.6.31 for the old code.
>>>>
>>>> This time I also nuked the remaining omap legacy code we
>>>> still had lurking around :) The commits at the end of this
>>>> mail describe what I did first as commits, then I merged
>>>> everything to be the same as the mainline v2.6.32-rc1.
>>>>
>>>> So currently the linux-omap master branch is:
>>>>
>>>> v2.6.32-rc1 + omap-fixes + ehci + cbus
>>>>
>>>> The new model is that I'll be resetting the linux-omap master
>>>> branch to mainline at each -rc, then merge in our various
>>>> upstream queues back in again.
>>>
>>> Excellent! I was wondering why this wasn't being done. I certainly
>>> hope linus' 2.6.32 will work on omap right away.
>>
>> Yeah, let's hope Tomi gets in the DSS2 code too.
>>
>>>
>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>> other people report similar issues:
>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>
>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>
>> Hmm, looks like it's musb again. This is what I get on my
>> overo after applying the DEBUG_LL hack from omap-debug branch:
>
> i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
> boot with twl4030 usb transceiver enabled"

I can't quite locate it in linux-usb archives (or anywhere within
google's reach). Could you sand it here or provide a link?

Regards,
--
Alex

RE: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Gadiyar, Anand]

> >>
> >>>
> >>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> >>> other people report similar issues:
> >>> http://www.spinics.net/lists/linux-omap/msg17968.html
> >>>
> >>> Have you got 2.6.32-rc1 (+fixes) to boot?
> >>
> >> Hmm, looks like it's musb again. This is what I get on my
> >> overo after applying the DEBUG_LL hack from omap-debug branch:
> >
> > i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
> > boot with twl4030 usb transceiver enabled"
> 
> I can't quite locate it in linux-usb archives (or anywhere within
> google's reach). Could you sand it here or provide a link?
> 

Here you go. Patchwork rocks!

<http://patchwork.kernel.org/patch/50721/>

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Tony Lindgren]

* Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
> > >>
> > >>>
> > >>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
> > >>> other people report similar issues:
> > >>> http://www.spinics.net/lists/linux-omap/msg17968.html
> > >>>
> > >>> Have you got 2.6.32-rc1 (+fixes) to boot?
> > >>
> > >> Hmm, looks like it's musb again. This is what I get on my
> > >> overo after applying the DEBUG_LL hack from omap-debug branch:
> > >
> > > i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
> > > boot with twl4030 usb transceiver enabled"
> > 
> > I can't quite locate it in linux-usb archives (or anywhere within
> > google's reach). Could you sand it here or provide a link?
> > 
> 
> Here you go. Patchwork rocks!
> 
> <http://patchwork.kernel.org/patch/50721/>
> 

Great, thanks. Roger, please send your fix to Samuel for merging.

Meanwhile, I'll apply it into fixes-testing while waiting for it
to get to mainline via Samuel.

Regards,

Tony

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Roger Quadros]

ext Tony Lindgren wrote:
> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>> other people report similar issues:
>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>
>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
>>>> boot with twl4030 usb transceiver enabled"
>>> I can't quite locate it in linux-usb archives (or anywhere within
>>> google's reach). Could you sand it here or provide a link?
>>>
>> Here you go. Patchwork rocks!
>>
>> <http://patchwork.kernel.org/patch/50721/>
>>
> 
> Great, thanks. Roger, please send your fix to Samuel for merging.
> 
> Meanwhile, I'll apply it into fixes-testing while waiting for it
> to get to mainline via Samuel.
> 
> Regards,
> 
> Tony

OK Tony, I'll do that.

cheers,
-roger

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Alexander Shishkin]

2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
> ext Tony Lindgren wrote:
>>
>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>
>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>> other people report similar issues:
>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>
>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>
>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>
>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>> Fix
>>>>> boot with twl4030 usb transceiver enabled"
>>>>
>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>> google's reach). Could you sand it here or provide a link?
>>>>
>>> Here you go. Patchwork rocks!
>>>
>>> <http://patchwork.kernel.org/patch/50721/>
>>>
>>
>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>
>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>> to get to mainline via Samuel.
>>
>> Regards,
>>
>> Tony
>
> OK Tony, I'll do that.

It doesn't crash any more, but I fail to get it to work either:
/sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
I do and the host never attempts to enumerate it (I have a g_ether
statically compiled in for a gadget). Hints greatly appreciated.

Regards,
--
Alex

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Roger Quadros]

ext Alexander Shishkin wrote:
> 2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
>> ext Tony Lindgren wrote:
>>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>>> other people report similar issues:
>>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>>
>>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>>> Fix
>>>>>> boot with twl4030 usb transceiver enabled"
>>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>>> google's reach). Could you sand it here or provide a link?
>>>>>
>>>> Here you go. Patchwork rocks!
>>>>
>>>> <http://patchwork.kernel.org/patch/50721/>
>>>>
>>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>>
>>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>>> to get to mainline via Samuel.
>>>
>>> Regards,
>>>
>>> Tony
>> OK Tony, I'll do that.
> 
> It doesn't crash any more, but I fail to get it to work either:
> /sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
> I do and the host never attempts to enumerate it (I have a g_ether
> statically compiled in for a gadget). Hints greatly appreciated.
> 
> Regards,
> --
> Alex

Can you retry if it works without my patch and reverting commit
66760169492445395c530c812443f58e2cfdb3dc

cheers,
-roger

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Roger Quadros]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

Roger Quadros wrote:
> ext Alexander Shishkin wrote:
>> 2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
>>> ext Tony Lindgren wrote:
>>>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>>>> other people report similar issues:
>>>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>>>
>>>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>>>> Fix
>>>>>>> boot with twl4030 usb transceiver enabled"
>>>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>>>> google's reach). Could you sand it here or provide a link?
>>>>>>
>>>>> Here you go. Patchwork rocks!
>>>>>
>>>>> <http://patchwork.kernel.org/patch/50721/>
>>>>>
>>>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>>>
>>>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>>>> to get to mainline via Samuel.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>> OK Tony, I'll do that.
>> It doesn't crash any more, but I fail to get it to work either:
>> /sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
>> I do and the host never attempts to enumerate it (I have a g_ether
>> statically compiled in for a gadget). Hints greatly appreciated.
>>
>> Regards,
>> --
>> Alex
> 
> Can you retry if it works without my patch and reverting commit
> 66760169492445395c530c812443f58e2cfdb3dc
> 
> cheers,
> -roger
> 

Also please try the attached patch on l-o HEAD.
It worked for me with file_storage driver.

dd if=/dev/zero of=/tmp/medium bs=1024 count=1024
modprobe g_file_storage file=/tmp/medium

-roger

[-- Attachment #2: 0001-twl4030-Fix-boot-with-twl4030-usb-transceiver-enabl.patch.gz --]
[-- Type: application/x-gzip, Size: 1445 bytes --]

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Roger Quadros]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

Roger Quadros wrote:
> ext Alexander Shishkin wrote:
>> 2009/10/1 Roger Quadros <ext-roger.quadros@nokia.com>:
>>> ext Tony Lindgren wrote:
>>>> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>>>>> other people report similar issues:
>>>>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>>>>
>>>>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030:
>>>>>>> Fix
>>>>>>> boot with twl4030 usb transceiver enabled"
>>>>>> I can't quite locate it in linux-usb archives (or anywhere within
>>>>>> google's reach). Could you sand it here or provide a link?
>>>>>>
>>>>> Here you go. Patchwork rocks!
>>>>>
>>>>> <http://patchwork.kernel.org/patch/50721/>
>>>>>
>>>> Great, thanks. Roger, please send your fix to Samuel for merging.
>>>>
>>>> Meanwhile, I'll apply it into fixes-testing while waiting for it
>>>> to get to mainline via Samuel.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>> OK Tony, I'll do that.
>> It doesn't crash any more, but I fail to get it to work either:
>> /sys/devices/platform/musb_hdrc/mode always says b_idle no matter what
>> I do and the host never attempts to enumerate it (I have a g_ether
>> statically compiled in for a gadget). Hints greatly appreciated.
>>
>> Regards,
>> --
>> Alex
> 
> Can you retry if it works without my patch and reverting commit
> 66760169492445395c530c812443f58e2cfdb3dc
> 
> cheers,
> -roger
> 

Also please try the attached patch on l-o HEAD.
It worked for me with file_storage driver.

dd if=/dev/zero of=/tmp/medium bs=1024 count=1024
modprobe g_file_storage file=/tmp/medium

-roger

[-- Attachment #2: 0001-twl4030-Fix-boot-with-twl4030-usb-transceiver-enabl.patch.gz --]
[-- Type: application/x-gzip, Size: 1445 bytes --]

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Roger Quadros]

ext Tony Lindgren wrote:
> * Gadiyar, Anand <gadiyar@ti.com> [090930 10:05]:
>>>>>> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>>>>>> other people report similar issues:
>>>>>> http://www.spinics.net/lists/linux-omap/msg17968.html
>>>>>>
>>>>>> Have you got 2.6.32-rc1 (+fixes) to boot?
>>>>> Hmm, looks like it's musb again. This is what I get on my
>>>>> overo after applying the DEBUG_LL hack from omap-debug branch:
>>>> i've just sent a fix for this musb problem. patch is labelled "twl4030: Fix
>>>> boot with twl4030 usb transceiver enabled"
>>> I can't quite locate it in linux-usb archives (or anywhere within
>>> google's reach). Could you sand it here or provide a link?
>>>
>> Here you go. Patchwork rocks!
>>
>> <http://patchwork.kernel.org/patch/50721/>
>>
> 
> Great, thanks. Roger, please send your fix to Samuel for merging.
> 
> Meanwhile, I'll apply it into fixes-testing while waiting for it
> to get to mainline via Samuel.
> 
> Regards,
> 
> Tony

Tony, i accidentally removed the MMC regulators in my patch. this will break 
MMC. Thanks to Felipe Balbi for pointing this out.

i will send v2 for my patch.

cheers,
-roger.

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> Hi all,
>
> I've updated our linux-omap tree to v2.6.32-rc1. I've also
> added a branch omap-2.6.31 for the old code.
>
> This time I also nuked the remaining omap legacy code we
> still had lurking around :) The commits at the end of this
> mail describe what I did first as commits, then I merged
> everything to be the same as the mainline v2.6.32-rc1.
>
> So currently the linux-omap master branch is:
>
> v2.6.32-rc1 + omap-fixes + ehci + cbus
>
> The new model is that I'll be resetting the linux-omap master
> branch to mainline at each -rc, then merge in our various
> upstream queues back in again.
>
> Please note that "Remove omap extra version in Makefile"
> commit means that you now need to set the ARCH and CROSS_COMPILE
> for your compiler.

FYI... As of 2.6.32, the kernel caches the ARCH and CROSS_COMPILE in
the build dir under include/generated/kernel.[arch,cross_compile], so
if you build using ARCH and CROSS_COMPILE once, it should remember
them until doing a clean build.

Kevin

Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Tony Lindgren]

* Kevin Hilman <khilman@deeprootsystems.com> [090930 07:07]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > Hi all,
> >
> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
> > added a branch omap-2.6.31 for the old code.
> >
> > This time I also nuked the remaining omap legacy code we
> > still had lurking around :) The commits at the end of this
> > mail describe what I did first as commits, then I merged
> > everything to be the same as the mainline v2.6.32-rc1.
> >
> > So currently the linux-omap master branch is:
> >
> > v2.6.32-rc1 + omap-fixes + ehci + cbus
> >
> > The new model is that I'll be resetting the linux-omap master
> > branch to mainline at each -rc, then merge in our various
> > upstream queues back in again.
> >
> > Please note that "Remove omap extra version in Makefile"
> > commit means that you now need to set the ARCH and CROSS_COMPILE
> > for your compiler.
> 
> FYI... As of 2.6.32, the kernel caches the ARCH and CROSS_COMPILE in
> the build dir under include/generated/kernel.[arch,cross_compile], so
> if you build using ARCH and CROSS_COMPILE once, it should remember
> them until doing a clean build.

Nice, sounds like we removed that hack just at the right moment then!

Tony