mmci-omap regressions

mmci-omap regressions

[Ladislav Michl]

Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
2.6.22-omap1 showed that
--- a/drivers/mmc/host/omap.c	2009-01-12 09:32:23.000000000 +0100
+++ b/drivers/mmc/host/omap.c	2009-01-12 09:46:26.000000000 +0100
@@ -974,7 +974,7 @@
 	 * 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_ON) {
+	if (ios->power_mode == MMC_POWER_UP) {
 		/* Send clock cycles, poll completion */
 		OMAP_MMC_WRITE(host, IE, 0);
 		OMAP_MMC_WRITE(host, STAT, 0xffff);
did the trick.

With above patch applied to 2.6.22-omap1 I got
# modprobe omap
mmci-omap mmci-omap.1: command timeout, CMD 8
 mmcblk0: mmc0:0001        127104KiB
 mmcblk0: p1
while there is no command timeout with 2.6.15-omap2, but at least it works.

Doing the same modification in current git doesn't help. Moreover removing
omap.ko and inserting again behaves differently than inserting for first
time:
# modprobe omap
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmc0: error -22 whilst initialising MMC card
# rmmod omap
# modprobe omap
mmci-omap: probe of mmci-omap.0 failed with error -16

I'll happily send any requested debug informations and test any patches

Thank you,
	ladis

Re: mmci-omap regressions

[Tony Lindgren]

Hi,

* Ladislav Michl <ladis@linux-mips.org> [090112 11:19]:
> Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
> my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
> for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
> 2.6.22-omap1 showed that
> --- a/drivers/mmc/host/omap.c	2009-01-12 09:32:23.000000000 +0100
> +++ b/drivers/mmc/host/omap.c	2009-01-12 09:46:26.000000000 +0100
> @@ -974,7 +974,7 @@
>  	 * 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_ON) {
> +	if (ios->power_mode == MMC_POWER_UP) {
>  		/* Send clock cycles, poll completion */
>  		OMAP_MMC_WRITE(host, IE, 0);
>  		OMAP_MMC_WRITE(host, STAT, 0xffff);
> did the trick.
> 
> With above patch applied to 2.6.22-omap1 I got
> # modprobe omap
> mmci-omap mmci-omap.1: command timeout, CMD 8
>  mmcblk0: mmc0:0001        127104KiB
>  mmcblk0: p1
> while there is no command timeout with 2.6.15-omap2, but at least it works.

OK, well at least that's a good start on figuring out what has broken
it. It does not seem like the right fix though as the MMC_POWER_UP
should just power up the slot, and clocks should not get turned on
until in MMC_POWER_ON.

> Doing the same modification in current git doesn't help. Moreover removing
> omap.ko and inserting again behaves differently than inserting for first
> time:
> # modprobe omap
> mmci-omap mmci-omap.0: command timeout (CMD8)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmc0: error -22 whilst initialising MMC card
> # rmmod omap
> # modprobe omap
> mmci-omap: probe of mmci-omap.0 failed with error -16

Looks like the current git head does goto exit after MMC_POWER_UP before
you even get to that code.

> I'll happily send any requested debug informations and test any patches

Can you maybe try to debug by applying your patch and commenting out
the goto exit?

Regards,

Tony

Re: mmci-omap regressions

[Ladislav Michl]

On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Looks like the current git head does goto exit after MMC_POWER_UP before
> you even get to that code.

...and 2.6.22-omap1 version does return at the same place. So patch can be
also shown as
--- a/drivers/mmc/host/omap.c	2009-01-12 09:32:23.000000000 +0100
+++ b/drivers/mmc/host/omap.c	2009-01-12 12:31:52.000000000 +0100
@@ -974,14 +974,6 @@
 	 * 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_ON) {
-		/* Send clock cycles, poll completion */
-		OMAP_MMC_WRITE(host, IE, 0);
-		OMAP_MMC_WRITE(host, STAT, 0xffff);
-		OMAP_MMC_WRITE(host, CMD, 1 << 7);
-		while ((OMAP_MMC_READ(host, STAT) & 1) == 0);
-		OMAP_MMC_WRITE(host, STAT, 1);
-	}
 	clk_disable(host->fclk);
 }

Sorry for not thinking a bit harder first time. I'll try to figure out how
to make git version working.

	ladis

Re: mmci-omap regressions

[Ladislav.Michl]

Hmm, it seems noone is going to fix it for me, so let's move on...

On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Hi,
> 
> * Ladislav Michl <ladis@linux-mips.org> [090112 11:19]:
> > Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
> > my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
> > for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
> > 2.6.22-omap1 showed that
> > --- a/drivers/mmc/host/omap.c	2009-01-12 09:32:23.000000000 +0100
> > +++ b/drivers/mmc/host/omap.c	2009-01-12 09:46:26.000000000 +0100
> > @@ -974,7 +974,7 @@
> >  	 * 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_ON) {
> > +	if (ios->power_mode == MMC_POWER_UP) {
> >  		/* Send clock cycles, poll completion */
> >  		OMAP_MMC_WRITE(host, IE, 0);
> >  		OMAP_MMC_WRITE(host, STAT, 0xffff);
> > did the trick.
> > 
> > With above patch applied to 2.6.22-omap1 I got
> > # modprobe omap
> > mmci-omap mmci-omap.1: command timeout, CMD 8
> >  mmcblk0: mmc0:0001        127104KiB
> >  mmcblk0: p1
> > while there is no command timeout with 2.6.15-omap2, but at least it works.
> 
> OK, well at least that's a good start on figuring out what has broken
> it. It does not seem like the right fix though as the MMC_POWER_UP
> should just power up the slot, and clocks should not get turned on
> until in MMC_POWER_ON.
> 
> > Doing the same modification in current git doesn't help. Moreover removing
> > omap.ko and inserting again behaves differently than inserting for first
> > time:
> > # modprobe omap
> > mmci-omap mmci-omap.0: command timeout (CMD8)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD5)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmci-omap mmci-omap.0: command timeout (CMD55)
> > mmc0: error -22 whilst initialising MMC card
> > # rmmod omap
> > # modprobe omap
> > mmci-omap: probe of mmci-omap.0 failed with error -16
> 
> Looks like the current git head does goto exit after MMC_POWER_UP before
> you even get to that code.
> 
> > I'll happily send any requested debug informations and test any patches
> 
> Can you maybe try to debug by applying your patch and commenting out
> the goto exit?

Here is somehow working version. It seems sending init stream multiple times
is not good idea. Please note I have no clue how is MMC supposed to work
(except very basic knowledge).

So with the patch (complete patch, see mmc driver fixes I posted earlier today)
below, output looks like:

# modprobe omap
MMC_POWER_OFF
MMC dsor: 0
MMC_POWER_UP
MMC_POWER_ON
MMC dsor: 878
time elapsed: 254us
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 803
mmc0: new MMC card at address 0001
mmcblk0: mmc0:0001 D0601 122 MiB
 mmcblk0:
 p1

Note, that "command timeout" is still there, but at least it detect card and
also note that "worst case at 400kHz, 80 cycles makes 200 microsecs" took
actually more than 200us.


diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5d773b8..0bcd6b0 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -123,15 +123,16 @@ struct mmc_omap_host {
 	struct mmc_data *	data;
 	struct mmc_host *	mmc;
 	struct device *		dev;
-	unsigned char		id; /* 16xx chips have 2 MMC blocks */
 	struct clk *		iclk;
 	struct clk *		fclk;
 	struct resource		*mem_res;
 	void __iomem		*virt_base;
 	unsigned int		phys_base;
 	int			irq;
+	unsigned char		id; /* 16xx chips have 2 MMC blocks */
 	unsigned char		bus_mode;
 	unsigned char		hw_bus_mode;
+	unsigned char		power_mode;
 
 	struct work_struct	cmd_abort_work;
 	unsigned		abort:1;
@@ -1233,7 +1234,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	struct mmc_omap_slot *slot = mmc_priv(mmc);
 	struct mmc_omap_host *host = slot->host;
 	int i, dsor;
-	int clk_enabled;
+	int clk_enabled, init_stream;
 
 	mmc_omap_select_slot(slot, 0);
 
@@ -1243,20 +1244,27 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		slot->vdd = ios->vdd;
 
 	clk_enabled = 0;
+	init_stream = 0;
 	switch (ios->power_mode) {
 	case MMC_POWER_OFF:
+		printk("MMC_POWER_OFF\n");
 		mmc_omap_set_power(slot, 0, ios->vdd);
 		break;
 	case MMC_POWER_UP:
+		printk("MMC_POWER_UP\n");
 		/* Cannot touch dsor yet, just power up MMC */
 		mmc_omap_set_power(slot, 1, ios->vdd);
+		host->power_mode = ios->power_mode;
 		goto exit;
 	case MMC_POWER_ON:
+		printk("MMC_POWER_ON\n");
 		mmc_omap_fclk_enable(host, 1);
 		clk_enabled = 1;
-		dsor |= 1 << 11;
+		if (host->power_mode != MMC_POWER_ON)
+			init_stream = 1;
 		break;
 	}
+	host->power_mode = ios->power_mode;
 
 	if (slot->bus_mode != ios->bus_mode) {
 		if (slot->pdata->set_bus_mode != NULL)
@@ -1269,12 +1277,15 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	 * goes somehow out of sync, and the POW bit is not being set,
 	 * which results in the while loop below getting stuck.
 	 * Writing to the CON register twice seems to do the trick. */
+	if (ios->power_mode == MMC_POWER_ON)
+		dsor |= 1 << 11;
+	printk("MMC dsor: %x\n", dsor);
 	for (i = 0; i < 2; i++)
 		OMAP_MMC_WRITE(host, CON, dsor);
 	slot->saved_con = dsor;
-	if (ios->power_mode == MMC_POWER_ON) {
+	if (init_stream) {
 		/* worst case at 400kHz, 80 cycles makes 200 microsecs */
-		int usecs = 250;
+		int usecs = 512;
 
 		/* Send clock cycles, poll completion */
 		OMAP_MMC_WRITE(host, IE, 0);
@@ -1285,8 +1296,8 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 			usecs--;
 		}
 		OMAP_MMC_WRITE(host, STAT, 1);
+		printk("time elapsed: %dus\n", 512 - usecs);
 	}
-
 exit:
 	mmc_omap_release_slot(slot, clk_enabled);
 }
@@ -1445,6 +1456,7 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, host);
 
 	host->id = pdev->id;
+	host->power_mode = -1;
 	host->mem_res = res;
 	host->irq = irq;
 
@@ -1459,8 +1471,10 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
 		goto err_ioremap;
 
 	host->iclk = clk_get(&pdev->dev, "ick");
-	if (IS_ERR(host->iclk))
+	if (IS_ERR(host->iclk)) {
+		ret = PTR_ERR(host->iclk);
 		goto err_free_mmc_host;
+	}
 	clk_enable(host->iclk);
 
 	host->fclk = clk_get(&pdev->dev, "fck");
@@ -1500,10 +1514,8 @@ err_free_irq:
 err_free_fclk:
 	clk_put(host->fclk);
 err_free_iclk:
-	if (host->iclk != NULL) {
-		clk_disable(host->iclk);
-		clk_put(host->iclk);
-	}
+	clk_disable(host->iclk);
+	clk_put(host->iclk);
 err_free_mmc_host:
 	iounmap(host->virt_base);
 err_ioremap:
@@ -1529,6 +1541,7 @@ static int mmc_omap_remove(struct platform_device *pdev)
 		host->pdata->cleanup(&pdev->dev);
 
 	mmc_omap_fclk_enable(host, 0);
+	free_irq(host->irq, host);
 	clk_put(host->fclk);
 	clk_disable(host->iclk);
 	clk_put(host->iclk);

Hints and ideas welcome and appreciated :-)

Thanks,
	ladis

Re: mmci-omap regressions

[Tony Lindgren]

* Ladislav.Michl@seznam.cz <Ladislav.Michl@seznam.cz> [091021 12:15]:
> Hmm, it seems noone is going to fix it for me, so let's move on...
> 
> On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> > Hi,
> > 
> > * Ladislav Michl <ladis@linux-mips.org> [090112 11:19]:
> > > Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
> > > my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
> > > for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
> > > 2.6.22-omap1 showed that
> > > --- a/drivers/mmc/host/omap.c	2009-01-12 09:32:23.000000000 +0100
> > > +++ b/drivers/mmc/host/omap.c	2009-01-12 09:46:26.000000000 +0100
> > > @@ -974,7 +974,7 @@
> > >  	 * 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_ON) {
> > > +	if (ios->power_mode == MMC_POWER_UP) {
> > >  		/* Send clock cycles, poll completion */
> > >  		OMAP_MMC_WRITE(host, IE, 0);
> > >  		OMAP_MMC_WRITE(host, STAT, 0xffff);
> > > did the trick.
> > > 
> > > With above patch applied to 2.6.22-omap1 I got
> > > # modprobe omap
> > > mmci-omap mmci-omap.1: command timeout, CMD 8
> > >  mmcblk0: mmc0:0001        127104KiB
> > >  mmcblk0: p1
> > > while there is no command timeout with 2.6.15-omap2, but at least it works.
> > 
> > OK, well at least that's a good start on figuring out what has broken
> > it. It does not seem like the right fix though as the MMC_POWER_UP
> > should just power up the slot, and clocks should not get turned on
> > until in MMC_POWER_ON.
> > 
> > > Doing the same modification in current git doesn't help. Moreover removing
> > > omap.ko and inserting again behaves differently than inserting for first
> > > time:
> > > # modprobe omap
> > > mmci-omap mmci-omap.0: command timeout (CMD8)
> > > mmci-omap mmci-omap.0: command timeout (CMD5)
> > > mmci-omap mmci-omap.0: command timeout (CMD5)
> > > mmci-omap mmci-omap.0: command timeout (CMD5)
> > > mmci-omap mmci-omap.0: command timeout (CMD5)
> > > mmci-omap mmci-omap.0: command timeout (CMD55)
> > > mmci-omap mmci-omap.0: command timeout (CMD55)
> > > mmci-omap mmci-omap.0: command timeout (CMD55)
> > > mmci-omap mmci-omap.0: command timeout (CMD55)
> > > mmc0: error -22 whilst initialising MMC card
> > > # rmmod omap
> > > # modprobe omap
> > > mmci-omap: probe of mmci-omap.0 failed with error -16
> > 
> > Looks like the current git head does goto exit after MMC_POWER_UP before
> > you even get to that code.
> > 
> > > I'll happily send any requested debug informations and test any patches
> > 
> > Can you maybe try to debug by applying your patch and commenting out
> > the goto exit?
> 
> Here is somehow working version. It seems sending init stream multiple times
> is not good idea. Please note I have no clue how is MMC supposed to work
> (except very basic knowledge).
> 
> So with the patch (complete patch, see mmc driver fixes I posted earlier today)
> below, output looks like:
> 
> # modprobe omap
> MMC_POWER_OFF
> MMC dsor: 0
> MMC_POWER_UP
> MMC_POWER_ON
> MMC dsor: 878
> time elapsed: 254us
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> mmci-omap mmci-omap.0: command timeout (CMD8)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 803
> mmc0: new MMC card at address 0001
> mmcblk0: mmc0:0001 D0601 122 MiB
>  mmcblk0:
>  p1
> 
> Note, that "command timeout" is still there, but at least it detect card and
> also note that "worst case at 400kHz, 80 cycles makes 200 microsecs" took
> actually more than 200us.

Good to hear. Can you please resend this too to the mmc list?

Regards,

Tony 
 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index 5d773b8..0bcd6b0 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -123,15 +123,16 @@ struct mmc_omap_host {
>  	struct mmc_data *	data;
>  	struct mmc_host *	mmc;
>  	struct device *		dev;
> -	unsigned char		id; /* 16xx chips have 2 MMC blocks */
>  	struct clk *		iclk;
>  	struct clk *		fclk;
>  	struct resource		*mem_res;
>  	void __iomem		*virt_base;
>  	unsigned int		phys_base;
>  	int			irq;
> +	unsigned char		id; /* 16xx chips have 2 MMC blocks */
>  	unsigned char		bus_mode;
>  	unsigned char		hw_bus_mode;
> +	unsigned char		power_mode;
>  
>  	struct work_struct	cmd_abort_work;
>  	unsigned		abort:1;
> @@ -1233,7 +1234,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  	struct mmc_omap_slot *slot = mmc_priv(mmc);
>  	struct mmc_omap_host *host = slot->host;
>  	int i, dsor;
> -	int clk_enabled;
> +	int clk_enabled, init_stream;
>  
>  	mmc_omap_select_slot(slot, 0);
>  
> @@ -1243,20 +1244,27 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  		slot->vdd = ios->vdd;
>  
>  	clk_enabled = 0;
> +	init_stream = 0;
>  	switch (ios->power_mode) {
>  	case MMC_POWER_OFF:
> +		printk("MMC_POWER_OFF\n");
>  		mmc_omap_set_power(slot, 0, ios->vdd);
>  		break;
>  	case MMC_POWER_UP:
> +		printk("MMC_POWER_UP\n");
>  		/* Cannot touch dsor yet, just power up MMC */
>  		mmc_omap_set_power(slot, 1, ios->vdd);
> +		host->power_mode = ios->power_mode;
>  		goto exit;
>  	case MMC_POWER_ON:
> +		printk("MMC_POWER_ON\n");
>  		mmc_omap_fclk_enable(host, 1);
>  		clk_enabled = 1;
> -		dsor |= 1 << 11;
> +		if (host->power_mode != MMC_POWER_ON)
> +			init_stream = 1;
>  		break;
>  	}
> +	host->power_mode = ios->power_mode;
>  
>  	if (slot->bus_mode != ios->bus_mode) {
>  		if (slot->pdata->set_bus_mode != NULL)
> @@ -1269,12 +1277,15 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  	 * goes somehow out of sync, and the POW bit is not being set,
>  	 * which results in the while loop below getting stuck.
>  	 * Writing to the CON register twice seems to do the trick. */
> +	if (ios->power_mode == MMC_POWER_ON)
> +		dsor |= 1 << 11;
> +	printk("MMC dsor: %x\n", dsor);
>  	for (i = 0; i < 2; i++)
>  		OMAP_MMC_WRITE(host, CON, dsor);
>  	slot->saved_con = dsor;
> -	if (ios->power_mode == MMC_POWER_ON) {
> +	if (init_stream) {
>  		/* worst case at 400kHz, 80 cycles makes 200 microsecs */
> -		int usecs = 250;
> +		int usecs = 512;
>  
>  		/* Send clock cycles, poll completion */
>  		OMAP_MMC_WRITE(host, IE, 0);
> @@ -1285,8 +1296,8 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  			usecs--;
>  		}
>  		OMAP_MMC_WRITE(host, STAT, 1);
> +		printk("time elapsed: %dus\n", 512 - usecs);
>  	}
> -
>  exit:
>  	mmc_omap_release_slot(slot, clk_enabled);
>  }
> @@ -1445,6 +1456,7 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, host);
>  
>  	host->id = pdev->id;
> +	host->power_mode = -1;
>  	host->mem_res = res;
>  	host->irq = irq;
>  
> @@ -1459,8 +1471,10 @@ static int __init mmc_omap_probe(struct platform_device *pdev)
>  		goto err_ioremap;
>  
>  	host->iclk = clk_get(&pdev->dev, "ick");
> -	if (IS_ERR(host->iclk))
> +	if (IS_ERR(host->iclk)) {
> +		ret = PTR_ERR(host->iclk);
>  		goto err_free_mmc_host;
> +	}
>  	clk_enable(host->iclk);
>  
>  	host->fclk = clk_get(&pdev->dev, "fck");
> @@ -1500,10 +1514,8 @@ err_free_irq:
>  err_free_fclk:
>  	clk_put(host->fclk);
>  err_free_iclk:
> -	if (host->iclk != NULL) {
> -		clk_disable(host->iclk);
> -		clk_put(host->iclk);
> -	}
> +	clk_disable(host->iclk);
> +	clk_put(host->iclk);
>  err_free_mmc_host:
>  	iounmap(host->virt_base);
>  err_ioremap:
> @@ -1529,6 +1541,7 @@ static int mmc_omap_remove(struct platform_device *pdev)
>  		host->pdata->cleanup(&pdev->dev);
>  
>  	mmc_omap_fclk_enable(host, 0);
> +	free_irq(host->irq, host);
>  	clk_put(host->fclk);
>  	clk_disable(host->iclk);
>  	clk_put(host->iclk);
> 
> Hints and ideas welcome and appreciated :-)
> 
> Thanks,
> 	ladis

Re: mmci-omap regressions

[Måns Rullgård]

Ladislav Michl <ladis@linux-mips.org> writes:

> Last time I used MMC card with linux-2.6.15-omap2 and it worked
> pretty well on my custom 5910 based board. Current git nor
> linux-2.6.22-omap1 (currently used for production) doesn't work at
> all. Inspecting diff between 2.6.15-omap2 and 2.6.22-omap1 showed
> that

[...]

> Doing the same modification in current git doesn't help. Moreover removing
> omap.ko and inserting again behaves differently than inserting for first
> time:
> # modprobe omap
> mmci-omap mmci-omap.0: command timeout (CMD8)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmc0: error -22 whilst initialising MMC card
> # rmmod omap
> # modprobe omap
> mmci-omap: probe of mmci-omap.0 failed with error -16
>
> I'll happily send any requested debug informations and test any patches

I'm getting the same error on Nokia 770.  Anything I can do to help?

-- 
Måns Rullgård
mans@mansr.com

--
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: mmci-omap regressions

[andrzej zaborowski]

2009/1/12 Ladislav Michl <ladis@linux-mips.org>:
> Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
> my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
> for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
> 2.6.22-omap1 showed that
> --- a/drivers/mmc/host/omap.c   2009-01-12 09:32:23.000000000 +0100
> +++ b/drivers/mmc/host/omap.c   2009-01-12 09:46:26.000000000 +0100
> @@ -974,7 +974,7 @@
>         * 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_ON) {
> +       if (ios->power_mode == MMC_POWER_UP) {
>                /* Send clock cycles, poll completion */
>                OMAP_MMC_WRITE(host, IE, 0);
>                OMAP_MMC_WRITE(host, STAT, 0xffff);
> did the trick.

Just confirming that I had the same issue on Palm T|E (omap15xx) and
used a similar modification to make it work.  This was with 2.6.22 so
very long ago.

Cheers