Linux-next as of 20110222 broken on OMAP4

DISCUSSION Anand Gadiyar 7 participants 10 messages Feb 22, 2011 – Feb 23, 2011

Subsystems (5)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP hwmod data +1 more subsystems

lore

Share & tools

lore

Govindraj

2011-02-22 10:25 UTC #1 lore raw

Quoted 5 lines · Anand Gadiyar

Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.

SPI fix is available but yet be merged its discussed in this thread:

http://dchs.spinics.net/lists/linux-omap/msg46446.html

--
Regards,
Govindraj.R

Quoted 45 lines

If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.
- Anand
[ 0.622802] print_constraints: dummy:
[ 0.627655] NET: Registered protocol family 16
[ 0.632537] GPMC revision 6.0
[ 0.635681] Trying to install interrupt handler for IRQ402 [ 0.641418] Trying to install interrupt handler for IRQ403 [ 0.647125] Trying to install interrupt handler for IRQ404 [ 0.652862] Trying to install interrupt handler for IRQ405 [ 0.658599] Trying to install interrupt handler for IRQ406 [ 0.664306] Trying to install interrupt handler for IRQ407 [ 0.670043] Trying to install interrupt handler for IRQ408 [ 0.675781] Trying to install type control for IRQ409
[ 0.681060] Trying to set irq flags for IRQ409
[ 0.685699] gpmc: irq-20 could not claim: err -22
[ 0.695556] omap_device: omap_gpio.0: new worst case activate latency 0: 91552
[ 0.703552] OMAP GPIO hardware version 0.1
[ 0.708221] OMAP GPIO hardware version 0.1
[ 0.712890] OMAP GPIO hardware version 0.1
[ 0.717498] OMAP GPIO hardware version 0.1
[ 0.722137] OMAP GPIO hardware version 0.1
[ 0.726776] OMAP GPIO hardware version 0.1[ 0.738403] omap_mux_init:
Add partition: #1: core, flags: 2
[ 0.746276] omap_mux_init: Add partition: #2: wkup, flags: 2 [ 0.752349] error setting wl12xx data
[ 0.759674] omap_device: omap_uart.0: new worst case deactivate latency 0: 30517
[ 0.769805] Failed omap4_twl6030_hsmmc_set_late_init
[ 0.777587] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[ 0.784667] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.
[ 0.792266] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.803466] pm_dbg_init: only OMAP3 supported
[ 0.808441] OMAP DMA hardware revision 0.0
[ 0.849426] bio: create slab <bio-0> at 0
[ 0.856201] print_constraints: vwl1271: 1800 mV
[ 0.864959] SCSI subsystem initialized
[ 0.870605] usbcore: registered new interface driver usbfs

Quoted 9 lines

[ 0.876739] usbcore: registered new interface driver hub
[ 0.882751] usbcore: registered new device driver usb
[ 0.889221] omap_device: omap_i2c.1: new worst case activate latency 0:
30517
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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

Anand Gadiyar

author

2011-02-22 10:28 UTC #2 lore raw

Quoted 11 lines · Govindraj

Quoted 5 lines · Anand Gadiyar
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
SPI fix is available but yet be merged its discussed in this thread:
http://dchs.spinics.net/lists/linux-omap/msg46446.html

And the other hack I needed to fix the failure when I disable SPI is this one (thanks Tarun).

It's just a hack - I hope a better fix will be along shortly.

- Anand

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -1

Index: linux-omap-usb/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
===================================================================
@@ -5068,7 +5068,7 @@ static __initdata struct omap_hwmod *oma
 	&omap44xx_spinlock_hwmod,
 
 	/* timer class */
-	&omap44xx_timer1_hwmod,
+	/* &omap44xx_timer1_hwmod, */
 	&omap44xx_timer2_hwmod,
 	&omap44xx_timer3_hwmod,
 	&omap44xx_timer4_hwmod,

Cousson, Benoit

2011-02-22 12:51 UTC #3 lore raw

In reply to Anand Gadiyar

Hi Anand,

Quoted 8 lines · Anand

Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.

Yes, it was discussed with Tony and temporarily fixed yesterday.

The SPI fix is is already in omap-for-linus, and the timer1 temp fix is below. We need to find a better way to handle timer now that they are initialized pretty soon.

Regards,
Benoit

---

Quoted 1 line

From 9a8dc4fdab03d00d556d05ad8b64c547493ad84d Mon Sep 17 00:00:00 2001

From: Benoit Cousson <[email protected]>
Date: Tue, 22 Feb 2011 10:36:27 +0100
Subject: [PATCH] OMAP4: hwmod data: Prevent timer1 to be reset and idle during init

Since the timer1 is now started before the hwmod_init, we cannot reset it and idle it anymore.

Add the appropriate flags to prevent the hwmod framework to do that.

Signed-off-by Benoit Cousson <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc Paul Walmsley <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0

index 182aa79..79a8601 100644
@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
 static struct omap_hwmod omap44xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_timer1_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
 	.main_clk	= "timer1_fck",

Signature · 1 line

1.7.0.4

Quoted 50 lines

- Anand

[    0.622802] print_constraints: dummy:
[    0.627655] NET: Registered protocol family 16
[    0.632537] GPMC revision 6.0
[    0.635681] Trying to install interrupt handler for IRQ402
[    0.641418] Trying to install interrupt handler for IRQ403
[    0.647125] Trying to install interrupt handler for IRQ404
[    0.652862] Trying to install interrupt handler for IRQ405
[    0.658599] Trying to install interrupt handler for IRQ406
[    0.664306] Trying to install interrupt handler for IRQ407
[    0.670043] Trying to install interrupt handler for IRQ408
[    0.675781] Trying to install type control for IRQ409
[    0.681060] Trying to set irq flags for IRQ409
[    0.685699] gpmc: irq-20 could not claim: err -22
[    0.695556] omap_device: omap_gpio.0: new worst case activate latency
0: 91552
[    0.703552] OMAP GPIO hardware version 0.1
[    0.708221] OMAP GPIO hardware version 0.1
[    0.712890] OMAP GPIO hardware version 0.1
[    0.717498] OMAP GPIO hardware version 0.1
[    0.722137] OMAP GPIO hardware version 0.1
[    0.726776] OMAP GPIO hardware version 0.1[    0.738403] omap_mux_init:
Add partition: #1: core, flags: 2
[    0.746276] omap_mux_init: Add partition: #2: wkup, flags: 2
[    0.752349] error setting wl12xx data
[    0.759674] omap_device: omap_uart.0: new worst case deactivate latency
0: 30517
[    0.769805] Failed omap4_twl6030_hsmmc_set_late_init
[    0.777587] hw-breakpoint: found 6 breakpoint and 1 watchpoint
registers.
[    0.784667] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint
single-step.
[    0.792266] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.803466] pm_dbg_init: only OMAP3 supported
[    0.808441] OMAP DMA hardware revision 0.0
[    0.849426] bio: create slab<bio-0>  at 0
[    0.856201] print_constraints: vwl1271: 1800 mV
[    0.864959] SCSI subsystem initialized
[    0.870605] usbcore: registered new interface driver usbfs
[    0.876739] usbcore: registered new interface driver hub
[    0.882751] usbcore: registered new device driver usb
[    0.889221] omap_device: omap_i2c.1: new worst case activate latency 0:

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

Santosh Shilimkar

2011-02-22 13:13 UTC #4 lore raw

Quoted 21 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Cousson, Benoit
Sent: Tuesday, February 22, 2011 6:22 PM
To: Gadiyar, Anand
Cc: linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Hi Anand,
Quoted 3 lines · Anand
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi.
Disabling
Quoted 5 lines
CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.

Quoted 7 lines

Yes, it was discussed with Tony and temporarily fixed yesterday.
The SPI fix is is already in omap-for-linus, and the timer1 temp fix is below.
We need to find a better way to handle timer now that they are initialized pretty soon.

Here is an alternate patch as per discussion with Paul.

------

Quoted 1 line

From e0bb923cb6fdde0f3f39184647238d6d1c6f5bf2 Mon Sep 17 00:00:00 2001

From: Santosh Shilimkar <[email protected]>
Date: Tue, 22 Feb 2011 16:46:29 +0530
Subject: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

To adhere to recent early_init changes, commit '44dc0' made omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.

Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()

So now if we move the omap_hwmod_late_init() to mdesc->timer->init(), timer1 should work with hwmod instead of any special hwmod settings.

This was proposed by Paul Walmsley <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Tony Lindgren <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.c             |    3 +--
 arch/arm/mach-omap2/timer-gp.c               |    4 +++-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 +
 3 files changed, 5 insertions(+), 3 deletions(-)

(quoted diff) +0 -0

b/arch/arm/mach-omap2/omap_hwmod.c
index 9e89a58..b39cb40 100644

arch/arm/mach-omap2/omap_hwmod.c +0 -0

@@ -1646,7 +1646,7 @@ static int __init _populate_mpu_rt_base(struct

omap_hwmod *oh, void *data)
* to struct clk pointers for each registered omap_hwmod. Also calls
* _setup() on each hwmod. Returns 0.
*/
-static int __init omap_hwmod_late_init(void)
+int __init omap_hwmod_late_init(void)
{
int r;

@@ -1664,7 +1664,6 @@ static int __init omap_hwmod_late_init(void)

return 0;
}
-core_initcall(omap_hwmod_late_init);

/**
* omap_hwmod_enable - enable an omap_hwmod

(quoted diff) +0 -0

b/arch/arm/mach-omap2/timer-gp.c
index 7b7c268..319ca42 100644

arch/arm/mach-omap2/timer-gp.c +3 -1

@@ -37,8 +37,9 @@
 #include <linux/clockchips.h>
 
 #include <asm/mach/time.h>
-#include <plat/dmtimer.h>
 #include <asm/localtimer.h>
+#include <plat/dmtimer.h>
+#include <plat/omap_hwmod.h>
 
 #include "timer-gp.h"

@@ -231,6 +232,7 @@ static void __init omap2_gp_clocksource_init(void)
 
 static void __init omap2_gp_timer_init(void)
 {
+	omap_hwmod_late_init();
 #ifdef CONFIG_LOCAL_TIMERS
 	if (cpu_is_omap44xx()) {
 		twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);

(quoted diff) +0 -0

b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index fedd829..e2bdbb3 100644

arch/arm/plat-omap/include/plat/omap_hwmod.h +1 -0

@@ -536,6 +536,7 @@ struct omap_hwmod {
 };
 
 int omap_hwmod_init(struct omap_hwmod **ohs);
+int omap_hwmod_late_init(void);
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
 int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
 			void *data);

Signature · 1 line

1.6.0.4

From e0bb923cb6fdde0f3f39184647238d6d1c6f5bf2 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <[email protected]>
Date: Tue, 22 Feb 2011 16:46:29 +0530
Subject: [PATCH] omap: Move omap_hwmod_late_init() to mdesc->timer->init() code

To adhere to recent early_init changes, commit '44dc0' made omap_hwmod_late_init() to core_initcall to avoid ioremap() failures.

Later 'e7c7d7' removed _mpu_rt_va population omap_hwmod_late_init()

So now if we move the omap_hwmod_late_init() to mdesc->timer->init(), timer1 should work with hwmod instead of any special hwmod settings.

This was proposed by Paul Walmsley <[email protected]>

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Tony Lindgren <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.c             |    3 +--
 arch/arm/mach-omap2/timer-gp.c               |    4 +++-
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 +
 3 files changed, 5 insertions(+), 3 deletions(-)

arch/arm/mach-omap2/omap_hwmod.c +1 -2

index 9e89a58..b39cb40 100644
@@ -1646,7 +1646,7 @@ static int __init _populate_mpu_rt_base(struct omap_hwmod *oh, void *data)
  * to struct clk pointers for each registered omap_hwmod.  Also calls
  * _setup() on each hwmod.  Returns 0.
  */
-static int __init omap_hwmod_late_init(void)
+int __init omap_hwmod_late_init(void)
 {
 	int r;

@@ -1664,7 +1664,6 @@ static int __init omap_hwmod_late_init(void)
 
 	return 0;
 }
-core_initcall(omap_hwmod_late_init);
 
 /**
  * omap_hwmod_enable - enable an omap_hwmod

arch/arm/mach-omap2/timer-gp.c +3 -1

index 7b7c268..319ca42 100644
@@ -37,8 +37,9 @@
 #include <linux/clockchips.h>
 
 #include <asm/mach/time.h>
-#include <plat/dmtimer.h>
 #include <asm/localtimer.h>
+#include <plat/dmtimer.h>
+#include <plat/omap_hwmod.h>
 
 #include "timer-gp.h"

@@ -231,6 +232,7 @@ static void __init omap2_gp_clocksource_init(void)
 
 static void __init omap2_gp_timer_init(void)
 {
+	omap_hwmod_late_init();
 #ifdef CONFIG_LOCAL_TIMERS
 	if (cpu_is_omap44xx()) {
 		twd_base = ioremap(OMAP44XX_LOCAL_TWD_BASE, SZ_256);

arch/arm/plat-omap/include/plat/omap_hwmod.h +1 -0

index fedd829..e2bdbb3 100644
@@ -536,6 +536,7 @@ struct omap_hwmod {
 };
 
 int omap_hwmod_init(struct omap_hwmod **ohs);
+int omap_hwmod_late_init(void);
 struct omap_hwmod *omap_hwmod_lookup(const char *name);
 int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data),
 			void *data);

Signature · 1 line

1.6.0.4

Tony Lindgren

maintainer

2011-02-22 19:13 UTC #5 lore raw

In reply to Cousson, Benoit

Quoted 9 lines · Cousson, Benoit

Hi Anand,
Quoted 6 lines · Anand
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.

Quoted 7 lines

Quoted 2 lines
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.
Yes, it was discussed with Tony and temporarily fixed yesterday.
The SPI fix is is already in omap-for-linus, and the timer1 temp fix is below. We need to find a better way to handle timer now that they are initialized pretty soon.

I applied the fix below with Paul's ack from the other thread. So linux-next should be working again on omap4 when it gets rebuilt.

Regards,

Tony

Quoted 33 lines

---
From 9a8dc4fdab03d00d556d05ad8b64c547493ad84d Mon Sep 17 00:00:00 2001
From: Benoit Cousson <[email protected]>
Date: Tue, 22 Feb 2011 10:36:27 +0100
Subject: [PATCH] OMAP4: hwmod data: Prevent timer1 to be reset and idle during init
Since the timer1 is now started before the hwmod_init, we cannot reset it and idle it anymore.
Add the appropriate flags to prevent the hwmod framework to do that.
Signed-off-by Benoit Cousson <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Paul Walmsley <[email protected]>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0
index 182aa79..79a8601 100644
@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if *omap44xx_timer1_slaves[] = {
 static struct omap_hwmod omap44xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_timer1_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
 	.main_clk	= "timer1_fck",
Signature · 1 line
1.7.0.4

DebBarma, Tarun Kanti

2011-02-23 04:50 UTC #6 lore raw

Quoted 23 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Sent: Wednesday, February 23, 2011 12:44 AM
To: Cousson, Benoit
Cc: Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Quoted 14 lines · Cousson, Benoit
Hi Anand,
Quoted 8 lines · Anand
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.
Yes, it was discussed with Tony and temporarily fixed yesterday.

Quoted 7 lines

Quoted 1 line
The SPI fix is is already in omap-for-linus, and the timer1 temp fix is
below.
Quoted 1 line
We need to find a better way to handle timer now that they are
initialized pretty soon.
I applied the fix below with Paul's ack from the other thread. So linux-next should be working again on omap4 when it gets rebuilt.

I have tested on OMAP4 and OMAP3. BTW, it doesn't work on OMAP24xx. --
Tarun

Quoted 41 lines

Quoted 6 lines
---
From 9a8dc4fdab03d00d556d05ad8b64c547493ad84d Mon Sep 17 00:00:00 2001
From: Benoit Cousson <[email protected]>
Date: Tue, 22 Feb 2011 10:36:27 +0100
Subject: [PATCH] OMAP4: hwmod data: Prevent timer1 to be reset and idle
during init
arch/arm/mach-
Quoted 15 lines
Since the timer1 is now started before the hwmod_init, we cannot reset it and idle it anymore.
Add the appropriate flags to prevent the hwmod framework to do that.
Signed-off-by Benoit Cousson <[email protected]>
Cc Tony Lindgren <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Paul Walmsley <[email protected]>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach- renamed from arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0
omap2/omap_hwmod_44xx_data.c
arch/arm/mach-omap2/omap_hwmod_44xx_data.c static struct omap_hwmod_ocp_if
Quoted 4 lines
index 182aa79..79a8601 100644
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0
@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
*omap44xx_timer1_slaves[] = {
Quoted 9 lines
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -1
 static struct omap_hwmod omap44xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_timer1_irqs,
 	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
 	.main_clk	= "timer1_fck",
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kishore Kadiyala

Acked-by Tony Lindgren

2011-02-23 12:07 UTC #7 lore raw

Quoted 23 lines · Tarun Kanti

Quoted 23 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Sent: Wednesday, February 23, 2011 12:44 AM
To: Cousson, Benoit
Cc: Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Quoted 14 lines · Cousson, Benoit
Hi Anand,
Quoted 8 lines · Anand
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.
Yes, it was discussed with Tony and temporarily fixed yesterday.

Quoted 8 lines

Quoted 7 lines
Quoted 1 line
The SPI fix is is already in omap-for-linus, and the timer1 temp fix is
below.
Quoted 1 line
We need to find a better way to handle timer now that they are
initialized pretty soon.
I applied the fix below with Paul's ack from the other thread. So linux-next should be working again on omap4 when it gets rebuilt.
I have tested on OMAP4 and OMAP3. BTW, it doesn't work on OMAP24xx.

<snip>

The following commit breaks OMAP2420 booting

git bisect bad 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba is the first bad commit commit 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba

Author: Russell King <[email protected]>
Date:   Wed Feb 9 16:33:46 2011 +0000

ARM: Avoid building unsafe kernels on OMAP2 and MX3

OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which when they include support for SMP kernels means that the resulting kernel is unsafe on SMP and can result in corrupted filesystems as we end up using unsafe bitops.

Re-enable the use of V6K instructions on such kernels, and let such kernels running on V6 CPUs eat undefined instruction faults which will be much safer than filesystem corruption. Next merge window we can fix this properly (as it requires a much bigger set of changes.)

Acked-by Tony Lindgren <[email protected]>

Signed-off-by Russell King <[email protected]>

:040000 040000 48e40d2ece61dfc65cb701841efd31e3f7b2c0ff
df6ed06ca039457b7929bdd2fe5ca9ea6a331844 M arch

Regards,
Kishore

DebBarma, Tarun Kanti

2011-02-23 12:21 UTC #8 lore raw

Quoted 64 lines

-----Original Message-----
From: Kishore Kadiyala [mailto:[email protected]]
Sent: Wednesday, February 23, 2011 5:37 PM
To: DebBarma, Tarun Kanti
Cc: Tony Lindgren; Cousson, Benoit; Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Quoted 18 lines · Tarun Kanti
Quoted 18 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Sent: Wednesday, February 23, 2011 12:44 AM
To: Cousson, Benoit
Cc: Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Quoted 9 lines · Cousson, Benoit
Hi Anand,
Quoted 6 lines · Anand
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.
Yes, it was discussed with Tony and temporarily fixed yesterday.
The SPI fix is is already in omap-for-linus, and the timer1 temp fix
is
Quoted 7 lines
Quoted 6 lines
below.
Quoted 1 line
We need to find a better way to handle timer now that they are
initialized pretty soon.
I applied the fix below with Paul's ack from the other thread. So linux-next should be working again on omap4 when it gets rebuilt.
I have tested on OMAP4 and OMAP3. BTW, it doesn't work on OMAP24xx.
<snip>
The following commit breaks OMAP2420 booting
git bisect bad 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba is the first bad commit commit 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba
Author: Russell King <[email protected]>
Date:   Wed Feb 9 16:33:46 2011 +0000
ARM: Avoid building unsafe kernels on OMAP2 and MX3
OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which when they include support for SMP kernels means that the resulting kernel is unsafe on SMP and can result in corrupted filesystems as we end up using unsafe bitops.
Re-enable the use of V6K instructions on such kernels, and let such kernels running on V6 CPUs eat undefined instruction faults which will be much safer than filesystem corruption. Next merge window we can fix this properly (as it requires a much bigger set of changes.)

Quoted 5 lines

Acked-by Tony Lindgren <[email protected]>
Signed-off-by Russell King <[email protected]>
:040000 040000 48e40d2ece61dfc65cb701841efd31e3f7b2c0ff
df6ed06ca039457b7929bdd2fe5ca9ea6a331844 M arch

I was thinking Paul's patch already tested on N800, OMAP2420!
[PATCH 0/8] OMAP2+: hwmod/clockevent: allow late-init of individual hwmods
In other words, Paul's patch fixed the breakage on OMAP24xx. --
Tarun

Kishore Kadiyala

2011-02-23 12:52 UTC #9 lore raw

Quoted 67 lines · Tarun Kanti

Quoted 67 lines
-----Original Message-----
From: Kishore Kadiyala [mailto:[email protected]]
Sent: Wednesday, February 23, 2011 5:37 PM
To: DebBarma, Tarun Kanti
Cc: Tony Lindgren; Cousson, Benoit; Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Quoted 18 lines · Tarun Kanti
Quoted 18 lines
-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Sent: Wednesday, February 23, 2011 12:44 AM
To: Cousson, Benoit
Cc: Gadiyar, Anand; linux-omap
Subject: Re: Linux-next as of 20110222 broken on OMAP4
Quoted 9 lines · Cousson, Benoit
Hi Anand,
Quoted 6 lines · Anand
Looks like linux-next as of today is broken on at least OMAP4.
Turning on earlyprintk, I get a crash in omap_init_mcspi. Disabling CONFIG_SPI_OMAP24XX gets me as far as the following lines from my bootup log, but I haven't attempted to debug further.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
If there are any patches out there to fix this, let me know. Else I will debug this sometime tomorrow.
Yes, it was discussed with Tony and temporarily fixed yesterday.
The SPI fix is is already in omap-for-linus, and the timer1 temp fix
is
Quoted 7 lines
Quoted 6 lines
below.
Quoted 1 line
We need to find a better way to handle timer now that they are
initialized pretty soon.
I applied the fix below with Paul's ack from the other thread. So linux-next should be working again on omap4 when it gets rebuilt.
I have tested on OMAP4 and OMAP3. BTW, it doesn't work on OMAP24xx.
<snip>
The following commit breaks OMAP2420 booting
git bisect bad 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba is the first bad commit commit 15490ef8ff8fd22d677cb5d4f6a98e5a79118dba
Author: Russell King <[email protected]>
Date: Wed Feb 9 16:33:46 2011 +0000
ARM: Avoid building unsafe kernels on OMAP2 and MX3
OMAP2 (armv6) and MX3 turn off support for the V6K instructions, which when they include support for SMP kernels means that the resulting kernel is unsafe on SMP and can result in corrupted filesystems as we end up using unsafe bitops.
Re-enable the use of V6K instructions on such kernels, and let such kernels running on V6 CPUs eat undefined instruction faults which will be much safer than filesystem corruption. Next merge window we can fix this properly (as it requires a much bigger set of changes.)
Acked-by Tony Lindgren <[email protected]>
Signed-off-by Russell King <[email protected]>

Quoted 8 lines

Quoted 2 lines
:040000 040000 48e40d2ece61dfc65cb701841efd31e3f7b2c0ff df6ed06ca039457b7929bdd2fe5ca9ea6a331844 M arch
I was thinking Paul's patch already tested on N800, OMAP2420! [PATCH 0/8] OMAP2+: hwmod/clockevent: allow late-init of individual hwmods In other words, Paul's patch fixed the breakage on OMAP24xx.
--
Tarun

Sorry it was on lkml and not on linux-next

Regards,
Kishore
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html