On Mon, 28 Dec 2009 12:58:28 -0500, Cliff Brake <cliff.br...@gmail.com> wrote:
>
> >> STOP_TRANSMISSION
> >> bit 3 -> R1_SPI_COM_CRC (the CRC of the last command failed)
>
> mmc0: req done (CMD18): 0: 00000000 00000000 00000000 00000000
> mmc0: 4096 bytes transferred: 0
> mmc0: (CMD12): -84: 00000008 00000000 00000000 00000000
>
That's weird.
> mmc_spi spi1.0: mmc_spi: CMD12, resp R1B
> mmc_spi spi1.0: ... CMD12 response SPI_R1B: resp 0040 00000000
>
> >> bit 6, R1_SPI_PARAMETER (commands argument, block length) was out of
> >> allowed range for this card.
>
And that just seems completely bogus; the STOP_TRANSMISSION command
doesn't require any parameters.
Having read mmc_spi_response_get() I'm wondering if it's actually trying
to interpret a busy signal as a response code. Would you mind giving
this patch a go and seeing if the BUG_ON() triggers?
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index d55fe4f..3e36ff4 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -310,6 +310,7 @@ static int mmc_spi_response_get(struct mmc_spi_host *host,
checkstatus:
bitshift = 0;
+ BUG_ON(*cp == 0xff);
if (*cp & 0x80) {
/* Houston, we have an ugly card with a bit-shifted response */
rotator = *cp++ << 8;
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
