H4 boot with latest git kernel

H4 boot with latest git kernel

[Trilok Soni]

Hi,

H4 booting sequence stops just after the following NET messages. I am
using latest pull from git. I have tried disabling IrDA, thinking that
it might had created some problems. Is it working for anyone out
there?

------
Linux version 2.6.20-rc7-omap1-g4a71abfb-dirty (trilok@cauveri) (gcc
version 4.1.
1 (CodeSourcery ARM Sourcery G++ 2006q3-26)) #33 Fri Feb 9 22:20:38 IST 2007
CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387f
Machine: OMAP2420 H4 board
Memory policy: ECC disabled, Data cache writeback
OMAP2420
SRAM: Mapped pa 0x40200000 to va 0xd0000000 size: 0x100000
CPU0: D VIPT write-back cache
CPU0: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
Built 1 zonelists.  Total pages: 32512
Kernel command line: console=ttyS0,115200n8 noinitrd root=/dev/nfs rw nfsroot=10
.203.97.28:/pub/fs/eabi,rsize=1024,wsize=1024 ip=10.203.97.29:10.203.97.28:255.2
55.255.192:omap2:eth0
Clocking rate (Crystal/DPLL/MPU): 12.0/600/300 MHz
clock.c: Enable for dpll_ck without enable code
GPMC revision 1.0
IRQ: Found an INTC at 0xd80fe000 (revision 1.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP242x GPIO hardware version 1.5
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB 0MB = 128MB total
Memory: 126848KB available (2568K code, 240K data, 112K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
MUX: setup M15_24XX_GPIO92 (0x4800010a): 0x03 -> 0x03
MUX: setup T19_24XX_KBR0 (0x48000106): 0x0f -> 0x1b
MUX: setup R19_24XX_KBR1 (0x48000107): 0x0f -> 0x1b
MUX: setup V18_24XX_KBR2 (0x48000139): 0x07 -> 0x1b
MUX: setup M21_24XX_KBR3 (0x480000c9): 0x0f -> 0x1b
MUX: setup E5__24XX_KBR4 (0x48000138): 0x0f -> 0x1b
MUX: setup B3__24XX_KBR5 (0x48000030): 0x03 -> 0x1b
MUX: setup AA4_24XX_KBC2 (0x480000e7): 0x03 -> 0x03
MUX: setup B13_24XX_KBC6 (0x48000110): 0x03 -> 0x03
MUX: setup R20_24XX_KBC0 (0x48000108): 0x0f -> 0x03
MUX: setup M14_24XX_KBC1 (0x48000109): 0x1f -> 0x03
MUX: setup V17_24XX_KBC3 (0x48000135): 0x07 -> 0x03
MUX: setup P21_24XX_KBC4 (0x480000ca): 0x0f -> 0x03
MUX: setup L14_24XX_KBC5 (0x4800010f): 0x0f -> 0x03
MUX: setup H18_24XX_MMC_CMD (0x480000f4): 0x00 -> 0x00
MUX: setup H15_24XX_MMC_CLKI (0x480000fe): 0x00 -> 0x00
MUX: setup G19_24XX_MMC_CLKO (0x480000f3): 0x00 -> 0x00
MUX: setup F20_24XX_MMC_DAT0 (0x480000f5): 0x00 -> 0x00
MUX: setup F19_24XX_MMC_DAT_DIR0 (0x480000f9): 0x00 -> 0x00
MUX: setup G18_24XX_MMC_CMD_DIR (0x480000fd): 0x00 -> 0x00
MUX: setup H14_24XX_MMC_DAT1 (0x480000f6): 0x00 -> 0x00
MUX: setup E19_24XX_MMC_DAT2 (0x480000f7): 0x00 -> 0x00
MUX: setup D19_24XX_MMC_DAT3 (0x480000f8): 0x00 -> 0x00
MUX: setup E20_24XX_MMC_DAT_DIR1 (0x480000fa): 0x00 -> 0x00
MUX: setup F18_24XX_MMC_DAT_DIR2 (0x480000fb): 0x00 -> 0x00
MUX: setup E18_24XX_MMC_DAT_DIR3 (0x480000fc): 0x00 -> 0x00
MUX: setup M19_24XX_I2C1_SCL (0x48000111): 0x00 -> 0x00
MUX: setup L15_24XX_I2C1_SDA (0x48000112): 0x00 -> 0x00
OMAP DMA hardware revision 1.0
Initializing OMAP McBSP system
MUX: setup Y15_24XX_MCBSP2_CLKX (0x48000124): 0x0f -> 0x09
MUX: setup R14_24XX_MCBSP2_FSX (0x48000125): 0x0f -> 0x09
MUX: setup W15_24XX_MCBSP2_DR (0x48000126): 0x0f -> 0x09
MUX: setup V15_24XX_MCBSP2_DX (0x48000127): 0x0f -> 0x09
MUX: setup V14_24XX_GPIO117 (0x48000128): 0x0f -> 0x0b
omap_dsp_init() done
MUX: setup K18_24XX_USB0_DAT (0x48000123): 0x00 -> 0x00
MUX: setup K19_24XX_USB0_TXEN (0x48000121): 0x00 -> 0x00
MUX: setup J14_24XX_USB0_SE0 (0x48000122): 0x00 -> 0x00
USB: hmc 0, usb0 3 wires
i2c_omap i2c_omap.1: bus 1 rev3.1 at 100 kHz
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
NetWinder Floating Point Emulator V0.97 (double precision)
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
omapfb: configured for panel h4
omapfb: DISPC version 1.0 initialized
Console: switching to colour frame buffer device 30x40
omapfb: Framebuffer initialized. Total vram 153600 planes 1
omapfb: Pixclock 6250 kHz hfreq 18.3 kHz vfreq 58.6 Hz
OMAP Watchdog Timer: initial timeout 60 sec
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x4806e000 (irq = 74) is a ST16654
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@cam.org>
eth0: SMC91C94 (rev 9) at c8850300 IRQ 252 [nowait]
eth0: Ethernet addr: 00:50:c2:27:1e:ab
MUX: setup W19_24XX_SYS_NIRQ (0x4800012c): 0x00 -> 0x18
Menelaus rev 1.1
omapflash.0: Found 1 x16 devices at 0x0 in 16-bit bank
omapflash.0: Found 1 x16 devices at 0x2000000 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
 Intel/Sharp Extended Query Table at 0x010A
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Creating 4 MTD partitions on "omapflash.0":
0x00000000-0x00020000 : "bootloader"
0x00020000-0x00040000 : "params"
0x00040000-0x00240000 : "kernel"
0x00240000-0x04000000 : "filesystem"
OMAP Keypad Driver
input: omap-keypad as /class/input/input0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
----

-- 
--Trilok Soni

Re: H4 boot with latest git kernel

[Tony Lindgren]

* Trilok Soni <soni.trilok@gmail.com> [070209 03:30]:
> Hi,
> 
> H4 booting sequence stops just after the following NET messages. I am
> using latest pull from git. I have tried disabling IrDA, thinking that
> it might had created some problems. Is it working for anyone out
> there?

Maybe try booting with initcall_debug kernel parameter to see where
it hangs?

Regards,

Tony

[PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Woodruff, Richard]

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

Hi,

So took a quick look with the emulator and see its hanging in MMC.  I'm
not an MMC expert but I don't see how you can send an init-stream
command with no clocks running and if you did it looks like it should be
80clocks over 1ms.

The note in the upper layer in mmc.c says you power it first, then send
clocks out.  mmc.c calls MMC_POWER_UP twice.  The first time with
ios->clock = 0 and a second time with iso->clock=f_min.  To me that just
says set the power bit in the first pass and set the initstream command
in the second pass.

The below patch seems to work fine and would appear to be a long
standing bug.

Signed-off-by: Richard Woodruff <r-woodruff2.com>

diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 796172a..55075cc 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -990,7 +990,7 @@ static void mmc_omap_set_ios(struct mmc_
 	 * Writing to the CON register twice seems to do the trick. */
 	for (i = 0; i < 2; i++)
 		OMAP_MMC_WRITE(host, CON, dsor);
-	if (ios->power_mode == MMC_POWER_UP) {
+	if ((ios->power_mode == MMC_POWER_UP) && ios->clock) {
 		/* Send clock cycles, poll completion */
 		OMAP_MMC_WRITE(host, IE, 0);
 		OMAP_MMC_WRITE(host, STAT, 0xffff);

Regards,
Richard W.



> -----Original Message-----
> From: linux-omap-open-source-bounces+r-woodruff2=ti.com@linux.omap.com
>
[mailto:linux-omap-open-source-bounces+r-woodruff2=ti.com@linux.omap.com
]
> On Behalf Of Tony Lindgren
> Sent: Friday, February 09, 2007 10:52 AM
> To: Trilok Soni
> Cc: linux-omap-open-source@linux.omap.com
> Subject: Re: H4 boot with latest git kernel
> 
> * Trilok Soni <soni.trilok@gmail.com> [070209 03:30]:
> > Hi,
> >
> > H4 booting sequence stops just after the following NET messages. I
am
> > using latest pull from git. I have tried disabling IrDA, thinking
that
> > it might had created some problems. Is it working for anyone out
> > there?
> 
> Maybe try booting with initcall_debug kernel parameter to see where
> it hangs?
> 
> Regards,
> 
> Tony
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source

[-- Attachment #2: mmcfix.diff --]
[-- Type: application/octet-stream, Size: 534 bytes --]

diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 796172a..55075cc 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -990,7 +990,7 @@ static void mmc_omap_set_ios(struct mmc_
 	 * Writing to the CON register twice seems to do the trick. */
 	for (i = 0; i < 2; i++)
 		OMAP_MMC_WRITE(host, CON, dsor);
-	if (ios->power_mode == MMC_POWER_UP) {
+	if ((ios->power_mode == MMC_POWER_UP) && ios->clock) {
 		/* Send clock cycles, poll completion */
 		OMAP_MMC_WRITE(host, IE, 0);
 		OMAP_MMC_WRITE(host, STAT, 0xffff);

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [070209 13:48]:
> Hi,
> 
> So took a quick look with the emulator and see its hanging in MMC.  I'm
> not an MMC expert but I don't see how you can send an init-stream
> command with no clocks running and if you did it looks like it should be
> 80clocks over 1ms.
> 
> The note in the upper layer in mmc.c says you power it first, then send
> clocks out.  mmc.c calls MMC_POWER_UP twice.  The first time with
> ios->clock = 0 and a second time with iso->clock=f_min.  To me that just
> says set the power bit in the first pass and set the initstream command
> in the second pass.
> 
> The below patch seems to work fine and would appear to be a long
> standing bug.
> 
> Signed-off-by: Richard Woodruff <r-woodruff2.com>
> 
> diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
> index 796172a..55075cc 100644
> --- a/drivers/mmc/omap.c
> +++ b/drivers/mmc/omap.c
> @@ -990,7 +990,7 @@ static void mmc_omap_set_ios(struct mmc_
>  	 * Writing to the CON register twice seems to do the trick. */
>  	for (i = 0; i < 2; i++)
>  		OMAP_MMC_WRITE(host, CON, dsor);
> -	if (ios->power_mode == MMC_POWER_UP) {
> +	if ((ios->power_mode == MMC_POWER_UP) && ios->clock) {
>  		/* Send clock cycles, poll completion */
>  		OMAP_MMC_WRITE(host, IE, 0);
>  		OMAP_MMC_WRITE(host, STAT, 0xffff);
> 

Thanks. Looks like we're still doing the MMC powerup wrong for omap
though. I made a patch for that a while back but it got forgotten
for some reason:

http://lkml.org/lkml/2006/5/4/44

I'll refresh that patch so we can make sure it works on all platforms.

Regards,

Tony

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[tony]

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

* Tony Lindgren <tony@atomide.com> [070210 09:42]:
> * Woodruff, Richard <r-woodruff2@ti.com> [070209 13:48]:
> > Hi,
> > 
> > So took a quick look with the emulator and see its hanging in MMC.  I'm
> > not an MMC expert but I don't see how you can send an init-stream
> > command with no clocks running and if you did it looks like it should be
> > 80clocks over 1ms.
> > 
> > The note in the upper layer in mmc.c says you power it first, then send
> > clocks out.  mmc.c calls MMC_POWER_UP twice.  The first time with
> > ios->clock = 0 and a second time with iso->clock=f_min.  To me that just
> > says set the power bit in the first pass and set the initstream command
> > in the second pass.
> > 
> > The below patch seems to work fine and would appear to be a long
> > standing bug.
> > 
> > Signed-off-by: Richard Woodruff <r-woodruff2.com>
> > 
> > diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
> > index 796172a..55075cc 100644
> > --- a/drivers/mmc/omap.c
> > +++ b/drivers/mmc/omap.c
> > @@ -990,7 +990,7 @@ static void mmc_omap_set_ios(struct mmc_
> >  	 * Writing to the CON register twice seems to do the trick. */
> >  	for (i = 0; i < 2; i++)
> >  		OMAP_MMC_WRITE(host, CON, dsor);
> > -	if (ios->power_mode == MMC_POWER_UP) {
> > +	if ((ios->power_mode == MMC_POWER_UP) && ios->clock) {
> >  		/* Send clock cycles, poll completion */
> >  		OMAP_MMC_WRITE(host, IE, 0);
> >  		OMAP_MMC_WRITE(host, STAT, 0xffff);
> > 
> 
> Thanks. Looks like we're still doing the MMC powerup wrong for omap
> though. I made a patch for that a while back but it got forgotten
> for some reason:
> 
> http://lkml.org/lkml/2006/5/4/44
> 
> I'll refresh that patch so we can make sure it works on all platforms.

Here are the refreshed patches to try.

Regards,

Tony

[-- Attachment #2: 0001-MMC-Fix-omap-to-use-MMC_POWER_ON.txt --]
[-- Type: text/plain, Size: 1280 bytes --]

>From fa6a7886da554980d7a250fc7232b8ed40168baf Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Sat, 10 Feb 2007 10:35:03 -0800
Subject: MMC: OMAP: Fix omap to use MMC_POWER_ON

As discussed earlier on LKML:

http://lkml.org/lkml/2006/5/4/44

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/mmc/omap.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 796172a..7cc8972 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -973,8 +973,10 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		mmc_omap_power(host, 0);
 		break;
 	case MMC_POWER_UP:
-	case MMC_POWER_ON:
+		/* Cannot touch dsor yet, just power up MMC */
 		mmc_omap_power(host, 1);
+		return;
+	case MMC_POWER_ON:
 		dsor |= 1 << 11;
 		break;
 	}
@@ -990,7 +992,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	 * Writing to the CON register twice seems to do the trick. */
 	for (i = 0; i < 2; i++)
 		OMAP_MMC_WRITE(host, CON, dsor);
-	if (ios->power_mode == MMC_POWER_UP) {
+	if (ios->power_mode == MMC_POWER_ON) {
 		/* Send clock cycles, poll completion */
 		OMAP_MMC_WRITE(host, IE, 0);
 		OMAP_MMC_WRITE(host, STAT, 0xffff);
-- 
1.4.4.2


[-- Attachment #3: 0002-MMC-Clean-up-omap-set_ios.txt --]
[-- Type: text/plain, Size: 2224 bytes --]

>From 6e580793454d53e012e53581991dc54375c54143 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Sat, 10 Feb 2007 10:40:31 -0800
Subject: MMC: OMAP: Clean up omap set_ios and make MMC_POWER_ON work

Move divisor calculation into a separate function and
re-arrange the init order to make MMC_POWER_ON work.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/mmc/omap.c |   47 ++++++++++++++++++++++++++---------------------
 1 files changed, 26 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 7cc8972..2ae4c1b 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -940,33 +940,41 @@ static void mmc_omap_power(struct mmc_omap_host *host, int on)
 	}
 }
 
-static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+static int mmc_omap_calc_divisor(struct mmc_host *mmc, struct mmc_ios *ios)
 {
 	struct mmc_omap_host *host = mmc_priv(mmc);
+	int func_clk_rate = clk_get_rate(host->fclk);
 	int dsor;
-	int realclock, i;
-
-	realclock = ios->clock;
 
 	if (ios->clock == 0)
-		dsor = 0;
-	else {
-		int func_clk_rate = clk_get_rate(host->fclk);
-
-		dsor = func_clk_rate / realclock;
-		if (dsor < 1)
-			dsor = 1;
+		return 0;
 
-		if (func_clk_rate / dsor > realclock)
-			dsor++;
+	dsor = func_clk_rate / ios->clock;
+	if (dsor < 1)
+		dsor = 1;
 
-		if (dsor > 250)
-			dsor = 250;
+	if (func_clk_rate / dsor > ios->clock)
 		dsor++;
 
-		if (ios->bus_width == MMC_BUS_WIDTH_4)
-			dsor |= 1 << 15;
-	}
+	if (dsor > 250)
+		dsor = 250;
+	dsor++;
+
+	if (ios->bus_width == MMC_BUS_WIDTH_4)
+		dsor |= 1 << 15;
+
+	return dsor;
+}
+
+static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+	struct mmc_omap_host *host = mmc_priv(mmc);
+	int dsor;
+	int i;
+
+	dsor = mmc_omap_calc_divisor(mmc, ios);
+	host->bus_mode = ios->bus_mode;
+	host->hw_bus_mode = host->bus_mode;
 
 	switch (ios->power_mode) {
 	case MMC_POWER_OFF:
@@ -981,9 +989,6 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		break;
 	}
 
-	host->bus_mode = ios->bus_mode;
-	host->hw_bus_mode = host->bus_mode;
-
 	clk_enable(host->fclk);
 
 	/* On insanely high arm_per frequencies something sometimes
-- 
1.4.4.2


[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

RE: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Woodruff, Richard]

> > Thanks. Looks like we're still doing the MMC powerup wrong for omap
> > though. I made a patch for that a while back but it got forgotten
> > for some reason:
> >
> > http://lkml.org/lkml/2006/5/4/44
> >
> > I'll refresh that patch so we can make sure it works on all
platforms.
> 
> Here are the refreshed patches to try.

The board does work with these patches also.  It's a cleaner way to fix
it up even if it is more than a line ;)

Regards,
Richard W.

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [070219 08:05]:
> > > Thanks. Looks like we're still doing the MMC powerup wrong for omap
> > > though. I made a patch for that a while back but it got forgotten
> > > for some reason:
> > >
> > > http://lkml.org/lkml/2006/5/4/44
> > >
> > > I'll refresh that patch so we can make sure it works on all
> platforms.
> > 
> > Here are the refreshed patches to try.
> 
> The board does work with these patches also.  It's a cleaner way to fix
> it up even if it is more than a line ;)

Great, let's plan on pushing them then. Anderson & Carlos, have you guys
had a chance to test these two patches on other boards?

Regards,

Tony

RE: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Kyungmin Park]

> 
> Great, let's plan on pushing them then. Anderson & Carlos, 
> have you guys had a chance to test these two patches on other boards?

It's working on apollon board.

Thank you,
Kyungmin Park

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Anderson Briglia]

ext Tony Lindgren wrote:
> * Woodruff, Richard <r-woodruff2@ti.com> [070219 08:05]:
>>>> Thanks. Looks like we're still doing the MMC powerup wrong for omap
>>>> though. I made a patch for that a while back but it got forgotten
>>>> for some reason:
>>>>
>>>> http://lkml.org/lkml/2006/5/4/44
>>>>
>>>> I'll refresh that patch so we can make sure it works on all
>> platforms.
>>> Here are the refreshed patches to try.
>> The board does work with these patches also.  It's a cleaner way to fix
>> it up even if it is more than a line ;)
> 
> Great, let's plan on pushing them then. Anderson & Carlos, have you guys
> had a chance to test these two patches on other boards?
> 

Hi Tony,

Sorry about the delay.
Carlos tested on H2 and H3 and it is working, but seems that the patches are not working on H4. He is investigating what
is wrong and will send a response asap. We are using the latest git tree.

Regards,

Anderson Briglia

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Carlos Aguiar]

ext Woodruff, Richard wrote:
>>> Thanks. Looks like we're still doing the MMC powerup wrong for omap
>>> though. I made a patch for that a while back but it got forgotten
>>> for some reason:
>>>
>>> http://lkml.org/lkml/2006/5/4/44
>>>
>>> I'll refresh that patch so we can make sure it works on all
>>>       
> platforms.
>   
>> Here are the refreshed patches to try.
>>     
>
> The board does work with these patches also.  It's a cleaner way to fix
> it up even if it is more than a line ;)
>
> Regards,
> Richard W.
>
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
>   
Hi Richard,

Which board you used to test theses patches?

As we've (me and Briglia) mentioned, the mmc it's not working on my H4
board. I'm still investigating to find out the problem.

BR,

Carlos.

-- 
Carlos Eduardo
Nokia Institute of Technology - INdT
Open Source Mobile Research Center - OSMRC
Phone: +55 92 2126-1079
Mobile: +55 92 8127-1797
E-mail: carlos.aguiar@indt.org.br

RE: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Woodruff, Richard]

> Hi Richard,
> 
> Which board you used to test theses patches?

I didn't fully test MMC.  I did make sure it fixed the boot lock up.

My board is a 'HRP' version using the latest ES rev of the 2420.

> As we've (me and Briglia) mentioned, the mmc it's not working on my H4
> board. I'm still investigating to find out the problem.

What does not working mean?  No boot, crash on card insertion, card not
taking some command?

Did you try with the simple 1 line patch I submitted also?

Regards,
Richard W.

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Anderson Briglia]

ext Woodruff, Richard wrote:
>> Hi Richard,
>>
>> Which board you used to test theses patches?
> 
> I didn't fully test MMC.  I did make sure it fixed the boot lock up.
> 
> My board is a 'HRP' version using the latest ES rev of the 2420.
> 
>> As we've (me and Briglia) mentioned, the mmc it's not working on my H4
>> board. I'm still investigating to find out the problem.
> 
> What does not working mean?  No boot, crash on card insertion, card not
> taking some command?

Card is not being recognized. The clocks are initialized, after that, nothing happens when a mmc card is
inserted/removed. I guess it is ok for H4 once the driver does not support two MMC slots, yet.

> 
> Did you try with the simple 1 line patch I submitted also?

We tested using the latest patches sent by Tony.

Anderson Briglia

RE: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Woodruff, Richard]

> > What does not working mean?  No boot, crash on card insertion, card
not
> > taking some command?
> 
> Card is not being recognized. The clocks are initialized, after that,
> nothing happens when a mmc card is
> inserted/removed. I guess it is ok for H4 once the driver does not
support
> two MMC slots, yet.

As I recall Menelaus IO companion chip really only supports 1 slot.  If
the drivers (menelaus + mmc) are smart then menelaus can multiplexed
between the two slots.

It might be only 1 slot in the H4 port is supported (I know the state
for the open source driver sets, even for internal version I think we
only coded up for 1 of the 2).   Seems like at least a couple bugs exist
in this version (mmc power up for sure, and likely menelaus-h4-port
related)...  Does either of the slots work?

Regards,
Richard W.

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Carlos Aguiar]

ext Woodruff, Richard wrote:
>>> What does not working mean?  No boot, crash on card insertion, card
>>>       
> not
>   
>>> taking some command?
>>>       
>> Card is not being recognized. The clocks are initialized, after that,
>> nothing happens when a mmc card is
>> inserted/removed. I guess it is ok for H4 once the driver does not
>>     
> support
>   
>> two MMC slots, yet.
>>     
>
> As I recall Menelaus IO companion chip really only supports 1 slot.  If
> the drivers (menelaus + mmc) are smart then menelaus can multiplexed
> between the two slots.
>
> It might be only 1 slot in the H4 port is supported (I know the state
> for the open source driver sets, even for internal version I think we
> only coded up for 1 of the 2).   Seems like at least a couple bugs exist
> in this version (mmc power up for sure, and likely menelaus-h4-port
> related)...  Does either of the slots work?
>   
Both slots aren't working.

BR,

Carlos.
> Regards,
> Richard W.
>
>   


-- 
Carlos Eduardo
Software Engineer
Nokia Institute of Technology - INdT
Open Source Mobile Research Center - OSMRC
Phone: +55 92 2126-1079
Mobile: +55 92 8127-1797
E-mail: carlos.aguiar@indt.org.br

Re: [PATCH] - Fix MMC -- was H4 boot with latest git kernel

[Tony Lindgren]

* Carlos Aguiar <carlos.aguiar@indt.org.br> [070228 07:05]:
> ext Woodruff, Richard wrote:
> >>> What does not working mean?  No boot, crash on card insertion, card
> >>>       
> > not
> >   
> >>> taking some command?
> >>>       
> >> Card is not being recognized. The clocks are initialized, after that,
> >> nothing happens when a mmc card is
> >> inserted/removed. I guess it is ok for H4 once the driver does not
> >>     
> > support
> >   
> >> two MMC slots, yet.
> >>     
> >
> > As I recall Menelaus IO companion chip really only supports 1 slot.  If
> > the drivers (menelaus + mmc) are smart then menelaus can multiplexed
> > between the two slots.
> >
> > It might be only 1 slot in the H4 port is supported (I know the state
> > for the open source driver sets, even for internal version I think we
> > only coded up for 1 of the 2).   Seems like at least a couple bugs exist
> > in this version (mmc power up for sure, and likely menelaus-h4-port
> > related)...  Does either of the slots work?
> >   
> Both slots aren't working.

Have you looked at the MMC/Menelaus changes in the n800 tree? That
should offer some clues.

BTW, I'll push the two patches for MMC power up code changes today.

Tony