On Sat, Jan 2, 2010 at 9:17 AM, Matt Fleming <matt@xxxxxxxxxxxxxxxxx> wrote:
> On Mon, 28 Dec 2009 12:58:28 -0500, Cliff Brake <cliff.brake@xxxxxxxxx> 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;
>
Matt,
I applied the above patch, and the BUG_ON did not trigger. Appreciate
the ideas, and welcome any other thoughts.
I wonder if there is something wrong with the previous
READ_MULTIPLE_BLOCK command, and that is what the cards are
complaining about, not the STOP_TRANSMISSION command?
I'm decoding the READ_MULTIPLE_BLOCK arguments next ....
Thanks,
Cliff
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
