[PATCH] fix MMC response types

[PATCH] fix MMC response types

[andrzej zaborowski]

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

Previously the MMC/SD protocol layer didn't provide command and
response types to mmc_omap_start_command(). In 2.6.16 it does and the
hack that tries to find the correct command/response types based on
flags is no longer needed.
This matters particularly for response types because for command types
this hack worked fine, while it failed to give correct response type
for some SD commands such as CMD3 (in most cases this caused no big
problems because the size of the response matched).
Regards,
Andrzej
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

[-- Attachment #2: omap-mmcsd.patch --]
[-- Type: application/octet-stream, Size: 1991 bytes --]

diff -pNaur linux-omap-2.6-orig/drivers/mmc/omap.c linux-omap-2.6/drivers/mmc/omap.c
--- linux-omap-2.6-orig/drivers/mmc/omap.c	2006-03-22 17:44:41.000000000 +0000
+++ linux-omap-2.6/drivers/mmc/omap.c	2006-03-22 21:34:36.000000000 +0000
@@ -185,39 +185,38 @@ mmc_omap_start_command(struct mmc_omap_h
 		host->hw_bus_mode = host->bus_mode;
 	}
 
-	if (!(cmd->flags & MMC_RSP_PRESENT))
-		resptype = 0;			/* Resp 0 */
-
-	if (cmd->flags & MMC_RSP_136)
-		resptype = 2;			/* Resp 2 */
-	else {
-		if (host->bus_mode == MMC_BUSMODE_OPENDRAIN)
-			resptype = 3;		/* Resp 3 */
-		else
-			resptype = 1;		/* Resp 1, Resp 1b */
+	switch (mmc_resp_type(cmd)) {
+	case MMC_RSP_NONE:
+		/* Response type 0 */
+		break;
+	case MMC_RSP_R1:
+	case MMC_RSP_R1B:
+		resptype = 1;
+		break;
+	case MMC_RSP_R2:
+		resptype = 2;
+		break;
+	case MMC_RSP_R3:
+		resptype = 3;
+		break;
+	case MMC_RSP_R6:
+		resptype = 6;
+		break;
 	}
 
-	/* Protocol layer does not provide command type, but our hardware
-	 * needs it!
-	 * any data transfer means adtc type (but that information is not
-	 * in command structure, so we flagged it into host struct.)
-	 * However, telling bc, bcr and ac apart based on response is
-	 * not foolproof:
-	 * CMD0  = bc  = resp0  CMD15 = ac  = resp0
-	 * CMD2  = bcr = resp2  CMD10 = ac  = resp2
-	 *
-	 * Resolve to best guess with some exception testing:
-	 * resp0 -> bc, except CMD15 = ac
-	 * rest are ac, except if opendrain
-	 */
-	if (host->data) {
+	switch (cmd->flags & MMC_CMD_MASK) {
+	case MMC_CMD_AC:
+		cmdtype = OMAP_MMC_CMDTYPE_AC;
+		break;
+	case MMC_CMD_ADTC:
 		cmdtype = OMAP_MMC_CMDTYPE_ADTC;
-	} else if (resptype == 0 && cmd->opcode != 15) {
+		break;
+	case MMC_CMD_BC:
 		cmdtype = OMAP_MMC_CMDTYPE_BC;
-	} else if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) {
+		break;
+	case MMC_CMD_BCR:
 		cmdtype = OMAP_MMC_CMDTYPE_BCR;
-	} else {
-		cmdtype = OMAP_MMC_CMDTYPE_AC;
+		break;
 	}
 
 	cmdreg = cmd->opcode | (resptype << 8) | (cmdtype << 12);







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

Re: [PATCH] fix MMC response types

[Carlos Aguiar]

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

ext andrzej zaborowski wrote:

>Previously the MMC/SD protocol layer didn't provide command and
>response types to mmc_omap_start_command(). In 2.6.16 it does and the
>hack that tries to find the correct command/response types based on
>flags is no longer needed.
>This matters particularly for response types because for command types
>this hack worked fine, while it failed to give correct response type
>for some SD commands such as CMD3 (in most cases this caused no big
>problems because the size of the response matched).
>Regards,
>Andrzej
>--
>balrog 2oo6
>
>Dear Outlook users: Please remove me from your address books
>http://www.newsforge.com/article.pl?sid=03/08/21/143258
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linux-omap-open-source mailing list
>Linux-omap-open-source@linux.omap.com
>http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>  
>
Hi Andrzej and folks,

Attached to this mail follow my propose of fixing MMC responde types in 
mmc_omap_start_command().

This is based on the patches of the thread '[RFC] mmc: add OMAP driver' 
that I sent to LKML mailing-list in order to have integrated the MMC 
OMAP driver on the mainline kernel.

Comments and suggestions are welcome.

BR,

Carlos.

-- 
Carlos Eduardo
Software Engineer
Nokia Institute of Technology - INdT
Embedded Linux Laboratory - 10LE
Phone: +55 92 2126-1079
Mobile: +55 92 8127-1797
E-mail: carlos.aguiar@indt.org.br


[-- Attachment #2: mmc_omap_rsp.patch --]
[-- Type: text/x-patch, Size: 2103 bytes --]

Index: linux-omap-2.6.git/drivers/mmc/omap.c
===================================================================
--- linux-omap-2.6.git.orig/drivers/mmc/omap.c	2006-03-27 08:29:08.000000000 -0400
+++ linux-omap-2.6.git/drivers/mmc/omap.c	2006-03-27 08:35:03.000000000 -0400
@@ -49,6 +49,7 @@
 #include "omap.h"
 
 #define DRIVER_NAME "mmci-omap"
+#define RSP_TYPE(x)	((x) & ~(MMC_RSP_BUSY|MMC_RSP_OPCODE))
 
 #ifdef CONFIG_MMC_DEBUG
 #define DBG(x...)	pr_debug(x)
@@ -185,36 +186,27 @@ mmc_omap_start_command(struct mmc_omap_h
 		host->hw_bus_mode = host->bus_mode;
 	}
 
-	if (!(cmd->flags & MMC_RSP_PRESENT))
-		resptype = 0;			/* Resp 0 */
-
-	if (cmd->flags & MMC_RSP_136)
-		resptype = 2;			/* Resp 2 */
-	else {
-		if (host->bus_mode == MMC_BUSMODE_OPENDRAIN)
-			resptype = 3;		/* Resp 3 */
-		else
-			resptype = 1;		/* Resp 1, Resp 1b */
+	/* Our hardware needs to know exact type */
+	switch (RSP_TYPE(mmc_resp_type(cmd))) {
+	case RSP_TYPE(MMC_RSP_R1):
+		/* resp 1, resp 1b */
+		resptype = 1;
+		break;
+	case RSP_TYPE(MMC_RSP_R2):
+		resptype = 2;
+		break;
+	case RSP_TYPE(MMC_RSP_R3):
+		resptype = 3;
+		break;
+	default:
+		break;
 	}
 
-	/* Protocol layer does not provide command type, but our hardware
-	 * needs it!
-	 * any data transfer means adtc type (but that information is not
-	 * in command structure, so we flagged it into host struct.)
-	 * However, telling bc, bcr and ac apart based on response is
-	 * not foolproof:
-	 * CMD0  = bc  = resp0  CMD15 = ac  = resp0
-	 * CMD2  = bcr = resp2  CMD10 = ac  = resp2
-	 *
-	 * Resolve to best guess with some exception testing:
-	 * resp0 -> bc, except CMD15 = ac
-	 * rest are ac, except if opendrain
-	 */
-	if (host->data) {
+	if (mmc_cmd_type(cmd) == MMC_CMD_ADTC) {
 		cmdtype = OMAP_MMC_CMDTYPE_ADTC;
-	} else if (resptype == 0 && cmd->opcode != 15) {
+	} else if (mmc_cmd_type(cmd) == MMC_CMD_BC) {
 		cmdtype = OMAP_MMC_CMDTYPE_BC;
-	} else if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) {
+	} else if (mmc_cmd_type(cmd) == MMC_CMD_BCR) {
 		cmdtype = OMAP_MMC_CMDTYPE_BCR;
 	} else {
 		cmdtype = OMAP_MMC_CMDTYPE_AC;

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

Re: [PATCH] fix MMC response types

[andrzej zaborowski]

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

On 27/03/06, Carlos Aguiar <carlos.aguiar@indt.org.br> wrote:
> ext andrzej zaborowski wrote:
>
> >Previously the MMC/SD protocol layer didn't provide command and
> >response types to mmc_omap_start_command(). In 2.6.16 it does and the
> >hack that tries to find the correct command/response types based on
> >flags is no longer needed.
> >This matters particularly for response types because for command types
> >this hack worked fine, while it failed to give correct response type
> >for some SD commands such as CMD3 (in most cases this caused no big
> >problems because the size of the response matched).
> >Regards,
> >Andrzej
> >--
> >balrog 2oo6
> >
> >Dear Outlook users: Please remove me from your address books
> >http://www.newsforge.com/article.pl?sid=03/08/21/143258
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Linux-omap-open-source mailing list
> >Linux-omap-open-source@linux.omap.com
> >http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >
> >
> Hi Andrzej and folks,
>
> Attached to this mail follow my propose of fixing MMC responde types in
> mmc_omap_start_command().
>
> This is based on the patches of the thread '[RFC] mmc: add OMAP driver'
> that I sent to LKML mailing-list in order to have integrated the MMC
> OMAP driver on the mainline kernel.
>
> Comments and suggestions are welcome.
It looks fine except you forgot about the response type 6. With the
current version of mmc_omap_start_command() the hack assumes response
type 1 in place of 6 which merely causes the MMC/SD host controller to
misinterpret the status flags in the response from the card, but the
size of the response matches. However with your patch it would assume
no response at all which would most probably cause breakage.

>
> BR,
>
> Carlos.
>
> --
> Carlos Eduardo
> Software Engineer
> Nokia Institute of Technology - INdT
> Embedded Linux Laboratory - 10LE
> Phone: +55 92 2126-1079
> Mobile: +55 92 8127-1797
> E-mail: carlos.aguiar@indt.org.br
>
>
>
>

Regards,
Andrew
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

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

Re: [PATCH] fix MMC response types

[Carlos Aguiar]

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

ext andrzej zaborowski wrote:

>On 27/03/06, Carlos Aguiar <carlos.aguiar@indt.org.br> wrote:
>  
>
>>ext andrzej zaborowski wrote:
>>
>>    
>>
>>>Previously the MMC/SD protocol layer didn't provide command and
>>>response types to mmc_omap_start_command(). In 2.6.16 it does and the
>>>hack that tries to find the correct command/response types based on
>>>flags is no longer needed.
>>>This matters particularly for response types because for command types
>>>this hack worked fine, while it failed to give correct response type
>>>for some SD commands such as CMD3 (in most cases this caused no big
>>>problems because the size of the response matched).
>>>Regards,
>>>Andrzej
>>>--
>>>balrog 2oo6
>>>
>>>Dear Outlook users: Please remove me from your address books
>>>http://www.newsforge.com/article.pl?sid=03/08/21/143258
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Linux-omap-open-source mailing list
>>>Linux-omap-open-source@linux.omap.com
>>>http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>>>
>>>
>>>      
>>>
>>Hi Andrzej and folks,
>>
>>Attached to this mail follow my propose of fixing MMC responde types in
>>mmc_omap_start_command().
>>
>>This is based on the patches of the thread '[RFC] mmc: add OMAP driver'
>>that I sent to LKML mailing-list in order to have integrated the MMC
>>OMAP driver on the mainline kernel.
>>
>>Comments and suggestions are welcome.
>>    
>>
>It looks fine except you forgot about the response type 6. With the
>current version of mmc_omap_start_command() the hack assumes response
>type 1 in place of 6 which merely causes the MMC/SD host controller to
>misinterpret the status flags in the response from the card, but the
>size of the response matches. However with your patch it would assume
>no response at all which would most probably cause breakage.
>
>  
>
>>BR,
>>
>>Carlos.
>>
>>--
>>Carlos Eduardo
>>Software Engineer
>>Nokia Institute of Technology - INdT
>>Embedded Linux Laboratory - 10LE
>>Phone: +55 92 2126-1079
>>Mobile: +55 92 8127-1797
>>E-mail: carlos.aguiar@indt.org.br
>>
>>
>>
>>
>>    
>>
>
>Regards,
>Andrew
>--
>balrog 2oo6
>
>Dear Outlook users: Please remove me from your address books
>http://www.newsforge.com/article.pl?sid=03/08/21/143258
>  
>
Hi Andrew and folks,

The response type 6 was included. Thanks for your observation.

BR,

Carlos.

-- 
Carlos Eduardo
Software Engineer
Nokia Institute of Technology - INdT
Embedded Linux Laboratory - 10LE
Phone: +55 92 2126-1079
Mobile: +55 92 8127-1797
E-mail: carlos.aguiar@indt.org.br


[-- Attachment #2: mmc_omap_rsp.patch --]
[-- Type: text/x-patch, Size: 2159 bytes --]

Index: linux-omap-2.6.git/drivers/mmc/omap.c
===================================================================
--- linux-omap-2.6.git.orig/drivers/mmc/omap.c	2006-03-28 16:45:43.000000000 -0400
+++ linux-omap-2.6.git/drivers/mmc/omap.c	2006-03-28 16:52:29.000000000 -0400
@@ -49,6 +49,7 @@
 #include "omap.h"
 
 #define DRIVER_NAME "mmci-omap"
+#define RSP_TYPE(x)	((x) & ~(MMC_RSP_BUSY|MMC_RSP_OPCODE))
 
 #ifdef CONFIG_MMC_DEBUG
 #define DBG(x...)	pr_debug(x)
@@ -185,36 +186,30 @@ mmc_omap_start_command(struct mmc_omap_h
 		host->hw_bus_mode = host->bus_mode;
 	}
 
-	if (!(cmd->flags & MMC_RSP_PRESENT))
-		resptype = 0;			/* Resp 0 */
-
-	if (cmd->flags & MMC_RSP_136)
-		resptype = 2;			/* Resp 2 */
-	else {
-		if (host->bus_mode == MMC_BUSMODE_OPENDRAIN)
-			resptype = 3;		/* Resp 3 */
-		else
-			resptype = 1;		/* Resp 1, Resp 1b */
+	/* Our hardware needs to know exact type */
+	switch (RSP_TYPE(mmc_resp_type(cmd))) {
+	case RSP_TYPE(MMC_RSP_R1):
+		/* resp 1, resp 1b */
+		resptype = 1;
+		break;
+	case RSP_TYPE(MMC_RSP_R2):
+		resptype = 2;
+		break;
+	case RSP_TYPE(MMC_RSP_R3):
+		resptype = 3;
+		break;
+	case RSP_TYPE(MMC_RSP_R6):
+		resptype = 6;
+		break;
+	default:
+		break;
 	}
 
-	/* Protocol layer does not provide command type, but our hardware
-	 * needs it!
-	 * any data transfer means adtc type (but that information is not
-	 * in command structure, so we flagged it into host struct.)
-	 * However, telling bc, bcr and ac apart based on response is
-	 * not foolproof:
-	 * CMD0  = bc  = resp0  CMD15 = ac  = resp0
-	 * CMD2  = bcr = resp2  CMD10 = ac  = resp2
-	 *
-	 * Resolve to best guess with some exception testing:
-	 * resp0 -> bc, except CMD15 = ac
-	 * rest are ac, except if opendrain
-	 */
-	if (host->data) {
+	if (mmc_cmd_type(cmd) == MMC_CMD_ADTC) {
 		cmdtype = OMAP_MMC_CMDTYPE_ADTC;
-	} else if (resptype == 0 && cmd->opcode != 15) {
+	} else if (mmc_cmd_type(cmd) == MMC_CMD_BC) {
 		cmdtype = OMAP_MMC_CMDTYPE_BC;
-	} else if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) {
+	} else if (mmc_cmd_type(cmd) == MMC_CMD_BCR) {
 		cmdtype = OMAP_MMC_CMDTYPE_BCR;
 	} else {
 		cmdtype = OMAP_MMC_CMDTYPE_AC;

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

Re: [PATCH] fix MMC response types

[lamikr]

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

So there are planned to do somekind of MMC/SD code merge with the
mainline and has it already happened in the current driver version in
linux-omap.git?

Just to confuse a little bit more... I have a small patch I received
from another ipaq h6300 (omap1510 based) developer. As I do not know
anything from the mmc/sd layer, all I can say is that with this patch me
and the Deniz (patch author) were able to boot from the SD card to iPAQ
h6300. (I tested with 512 mb kingston)
Without this patch we were only able to boot from the MMC cards. Deniz
(said that he is not 100 % sure whether all of the changes are actually
needed
or would only a subset be enought.

Hopefully this patch is not needed anymore after your updates, but here
it is anyway just in case that somebody finds it usefull.

Mika

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sd_fixes.diff --]
[-- Type: text/x-patch; name="sd_fixes.diff", Size: 2422 bytes --]

diff -Naur orig/mmc.c fixed/mmc.c
--- orig/mmc.c	2006-03-18 10:22:19.000000000 +0200
+++ fixed/mmc.c	2006-03-18 10:30:32.000000000 +0200
@@ -964,7 +964,7 @@
 		mmc_decode_scr(card);
 	}
 
-	mmc_deselect_cards(host);
+	//mmc_deselect_cards(host);
 }
 
 static unsigned int mmc_calculate_clock(struct mmc_host *host)
diff -Naur orig/omap.c fixed/omap.c
--- orig/omap.c	2006-03-18 10:22:10.000000000 +0200
+++ fixed/omap.c	2006-03-18 10:42:48.000000000 +0200
@@ -2,7 +2,7 @@
  *  linux/drivers/media/mmc/omap.c
  *
  *  Copyright (C) 2004 Nokia Corporation
- *  Written by Tuukka Tikkanen and Juha Yrjölä <juha.yrjola@nokia.com>
+ *  Written by Tuukka Tikkanen and Juha Yrjölä <juha.yrjola@nokia.com>
  *  Misc hacks here and there by Tony Lindgren <tony@atomide.com>
  *  Other hacks (DMA, SD, etc) by David Brownell
  *
@@ -231,6 +231,9 @@
 	if (host->data && !(host->data->flags & MMC_DATA_WRITE))
 		cmdreg |= 1 << 15;
 
+	if (cmd->opcode==0)
+		cmdreg |= 1 << 7;
+
 	clk_enable(host->fclk);
 
 	OMAP_MMC_WRITE(host->base, CTO, 200);
@@ -890,7 +893,7 @@
 	reg &= ~(1 << 5);
 	OMAP_MMC_WRITE(host->base, SDIO, reg);
 	/* Set maximum timeout */
-	OMAP_MMC_WRITE(host->base, CTO, 0xff);
+	OMAP_MMC_WRITE(host->base, CTO, 0xfd);
 }
 
 static inline void set_data_timeout(struct mmc_omap_host *host, struct mmc_request *req)
@@ -901,7 +904,7 @@
 	/* Convert ns to clock cycles by assuming 20MHz frequency
 	 * 1 cycle at 20MHz = 500 ns
 	 */
-	timeout = req->data->timeout_clks + req->data->timeout_ns / 500;
+	timeout = (req->data->timeout_clks * 10)  + (req->data->timeout_ns*10) / 500;
 
 	/* Some cards require more time to do at least the first read operation */
 	timeout = timeout << 4;
@@ -986,7 +989,7 @@
 		mmc_omap_sg_to_buf(host);
 		host->dma_in_use = 0;
 	}
-	mod_timer(&host->xfer_timer, jiffies + msecs_to_jiffies(500));
+	mod_timer(&host->xfer_timer, jiffies + msecs_to_jiffies(1500));
 
 	pr_debug("MMC%d: %s %s %s, DTO %d cycles + %d ns, "
 			"%d blocks of %d bytes, %d segments\n",
@@ -1164,7 +1167,7 @@
 	case MMC_POWER_UP:
 	case MMC_POWER_ON:
 		mmc_omap_power(host, 1);
-		dsor |= 1<<11;
+		dsor = (120 | (1 << 11));
 		break;
 	}
 
@@ -1484,4 +1487,4 @@
 MODULE_DESCRIPTION("OMAP Multimedia Card driver");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS(DRIVER_NAME);
-MODULE_AUTHOR("Juha Yrjölä");
+MODULE_AUTHOR("Juha Yrjölä");

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

Re: [PATCH] fix MMC response types

[lamikr]

>
>Hopefully this patch is not needed anymore after your updates, but here
>it is anyway just in case that somebody finds it usefull.
>  
>
Btw, I tested this more and found out that the only thing really needed
to get h6300
to mount SD in addition of MMC card during the boot was this one.
(That's on top of the latest omap-git version)

diff -Naur orig/mmc.c fixed/mmc.c
--- orig/mmc.c	2006-03-18 10:22:19.000000000 +0200
+++ fixed/mmc.c	2006-03-18 10:30:32.000000000 +0200
@@ -964,7 +964,7 @@
 		mmc_decode_scr(card);
 	}
 
-	mmc_deselect_cards(host);
+	//mmc_deselect_cards(host);
 }

[PATCH] fix MMC response types

[Carlos Aguiar]

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

Ok, let's try again, now with the patch...

Hi Andrzej and folks,

Attached to this mail follow my propose of fixing MMC responde types in 
mmc_omap_start_command().

This is based on the patches of the thread '[RFC] mmc: add OMAP driver' 
that I sent to LKML mailing-list in order to have integrated the MMC 
OMAP driver on the mainline kernel.

Comments and suggestions are welcome.

BR,

Carlos.

-- 
Carlos Eduardo
Software Engineer
Nokia Institute of Technology - INdT
Embedded Linux Laboratory - 10LE
Phone: +55 92 2126-1079
Mobile: +55 92 8127-1797
E-mail: carlos.aguiar@indt.org.br


[-- Attachment #2: mmc_omap_rsp.patch --]
[-- Type: text/x-patch, Size: 2103 bytes --]

Index: linux-omap-2.6.git/drivers/mmc/omap.c
===================================================================
--- linux-omap-2.6.git.orig/drivers/mmc/omap.c	2006-03-27 08:29:08.000000000 -0400
+++ linux-omap-2.6.git/drivers/mmc/omap.c	2006-03-27 08:35:03.000000000 -0400
@@ -49,6 +49,7 @@
 #include "omap.h"
 
 #define DRIVER_NAME "mmci-omap"
+#define RSP_TYPE(x)	((x) & ~(MMC_RSP_BUSY|MMC_RSP_OPCODE))
 
 #ifdef CONFIG_MMC_DEBUG
 #define DBG(x...)	pr_debug(x)
@@ -185,36 +186,27 @@ mmc_omap_start_command(struct mmc_omap_h
 		host->hw_bus_mode = host->bus_mode;
 	}
 
-	if (!(cmd->flags & MMC_RSP_PRESENT))
-		resptype = 0;			/* Resp 0 */
-
-	if (cmd->flags & MMC_RSP_136)
-		resptype = 2;			/* Resp 2 */
-	else {
-		if (host->bus_mode == MMC_BUSMODE_OPENDRAIN)
-			resptype = 3;		/* Resp 3 */
-		else
-			resptype = 1;		/* Resp 1, Resp 1b */
+	/* Our hardware needs to know exact type */
+	switch (RSP_TYPE(mmc_resp_type(cmd))) {
+	case RSP_TYPE(MMC_RSP_R1):
+		/* resp 1, resp 1b */
+		resptype = 1;
+		break;
+	case RSP_TYPE(MMC_RSP_R2):
+		resptype = 2;
+		break;
+	case RSP_TYPE(MMC_RSP_R3):
+		resptype = 3;
+		break;
+	default:
+		break;
 	}
 
-	/* Protocol layer does not provide command type, but our hardware
-	 * needs it!
-	 * any data transfer means adtc type (but that information is not
-	 * in command structure, so we flagged it into host struct.)
-	 * However, telling bc, bcr and ac apart based on response is
-	 * not foolproof:
-	 * CMD0  = bc  = resp0  CMD15 = ac  = resp0
-	 * CMD2  = bcr = resp2  CMD10 = ac  = resp2
-	 *
-	 * Resolve to best guess with some exception testing:
-	 * resp0 -> bc, except CMD15 = ac
-	 * rest are ac, except if opendrain
-	 */
-	if (host->data) {
+	if (mmc_cmd_type(cmd) == MMC_CMD_ADTC) {
 		cmdtype = OMAP_MMC_CMDTYPE_ADTC;
-	} else if (resptype == 0 && cmd->opcode != 15) {
+	} else if (mmc_cmd_type(cmd) == MMC_CMD_BC) {
 		cmdtype = OMAP_MMC_CMDTYPE_BC;
-	} else if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) {
+	} else if (mmc_cmd_type(cmd) == MMC_CMD_BCR) {
 		cmdtype = OMAP_MMC_CMDTYPE_BCR;
 	} else {
 		cmdtype = OMAP_MMC_CMDTYPE_AC;

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