Re: [PATCH] fix MMC response types

[Carlos Aguiar <carlos.aguiar@indt.org.br>]

[-- 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 --]