Re: SD response type 6 vs. 1

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

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

ext Pierre Ossman wrote:
> andrzej zaborowski wrote:
>   
>> Hi,
>>  Linux has the same values for MMC_RSP_R1 and MMC_RSP_R6 thus making
>> the two response formats indistinguishable for mmc/sd hosts. Hardware
>> like my OMAP310 needs to know exactly whether to expect an R1 or R6
>> format, otherwise CMD3 fails.
>>
>> Sure it would be nice if it didn't care, but nevertheless, it's not a
>> hardware bug - the two formats are specified separately in SD specs
>> because they *are* different. So the hardware has full right to know
>> the right response type. Rather it's a hack to rely on R1 and R6
>> having the same size, like Linux does now. It would also be a hack to
>> allow the CMD3 to fail with CRC error and ignore the error, like
>> omap.c did before, because it makes an assumption that's not in the
>> OMAP specs.
>>     
>
> If you're referring to CERR, then I suggest you reread the specs. They
> even explicitly say its okay to ignore it.
>
> Anyway, I'm not going into this discussion again without a valid
> argument as to why the suggest path won't work.
>
>   
>> The following is an ugly fix. It's ugly because host code should be
>> agnostic to opcodes, as mentioned by Pierre Ossman.
>> I believe this was already submitted by Carlos Aguiar and rejected by
>> Pierre, which resulted in leaving the driver broken on some boards.
>>     
>
> This just hides the fact that the host parses the data more than we want
> and expect it to do.
>
>   
>> A more correct and more intrusive fix would look like this:
>>     
>
> Afraid not. The response type specifies format, not semantical contents.
>
> The correct fix has already been discussed, but I have seen zero
> attempts at implementing it:
>
> http://linux.omap.com/pipermail/linux-omap-open-source/2007-April/009500.html
>
>   
Hi Pierre and andrzej,

Regarding the correct fix mentioned (and discussed) by Pierre, I'd
implemented a piece of this fix by removing CERR, but it's not enough to
make SD works. The patch find attached to this mail.

The part of be able to leave it out to do the card error parsing with
software, like Pierre said, must be implemented.

I'm now busy working in a patches series to MMC multislot support for
OMAP (1510, H2, H3 and H4) platforms.

Regards,

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


[-- Attachment #2: 0001-MMC-OMAP-Totally-remove-CERR-interrupt.diff --]
[-- Type: text/plain, Size: 1811 bytes --]

Totally disable of CERR interrupt, by not writing OMAP_MMC_STAT_CARD_ERR
bit to IE register and removing OMAP_MMC_STAT_CARD_ERR quiks on omap.c

Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar@indt.org.br>

Index: linux-omap/drivers/mmc/host/omap.c
===================================================================
--- linux-omap.orig/drivers/mmc/host/omap.c	2007-06-04 14:37:56.000000000 -0400
+++ linux-omap/drivers/mmc/host/omap.c	2007-06-04 14:45:49.000000000 -0400
@@ -253,8 +253,7 @@ mmc_omap_start_command(struct mmc_omap_h
 		       OMAP_MMC_STAT_A_EMPTY    | OMAP_MMC_STAT_A_FULL    |
 		       OMAP_MMC_STAT_CMD_CRC    | OMAP_MMC_STAT_CMD_TOUT  |
 		       OMAP_MMC_STAT_DATA_CRC   | OMAP_MMC_STAT_DATA_TOUT |
-		       OMAP_MMC_STAT_END_OF_CMD | OMAP_MMC_STAT_CARD_ERR  |
-		       OMAP_MMC_STAT_END_OF_DATA);
+		       OMAP_MMC_STAT_END_OF_CMD | OMAP_MMC_STAT_END_OF_DATA);
 	OMAP_MMC_WRITE(host, CMD, cmdreg);
 }
 
@@ -523,31 +522,6 @@ static irqreturn_t mmc_omap_irq(int irq,
 					"command CRC error without cmd?\n");
 		}
 
-		if (status & OMAP_MMC_STAT_CARD_ERR) {
-			if (host->cmd && host->cmd->opcode == MMC_STOP_TRANSMISSION) {
-				u32 response = OMAP_MMC_READ(host, RSP6)
-					| (OMAP_MMC_READ(host, RSP7) << 16);
-				/* STOP sometimes sets must-ignore bits */
-				if (!(response & (R1_CC_ERROR
-								| R1_ILLEGAL_COMMAND
-								| R1_COM_CRC_ERROR))) {
-					end_command = 1;
-					continue;
-				}
-			}
-
-			dev_dbg(mmc_dev(host->mmc), "card status error (CMD%d)\n",
-				host->cmd->opcode);
-			if (host->cmd) {
-				host->cmd->error = MMC_ERR_FAILED;
-				end_command = 1;
-			}
-			if (host->data) {
-				host->data->error = MMC_ERR_FAILED;
-				transfer_error = 1;
-			}
-		}
-
 		/*
 		 * NOTE: On 1610 the END_OF_CMD may come too early when
 		 * starting a write 

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