Re: [RFC][MMC] Buggy cards need to leave programming state

[Pierre Ossman]

Russell King wrote:
> On Mon, Dec 26, 2005 at 02:19:52PM +0100, Pierre Ossman wrote:
>   
>> I've gotten two reports for cards that just crap out during write
>> transfers. The solution I've given them is to make the mmc block layer
>> wait for the card to leave programming state.
>>     
>
> This is interesting.  In the specs I have, they indicate that the
> correct behaviour of a MMC card for CMD24 (write block) is that
> when its write buffer is full, it will hold the DAT signal low to
> indicate "busy" to the host controller.
>
> Now, the ARM MMCI holds the data path in the "BUSY" state while
> the MMC card asserts this indication, so we don't complete the
> data transfer until the card says it's not busy.
>
> For PXAMCI, it looks like we aren't waiting for the indication
> from the host which tells us that the "BUSY" has cleared.
>
> Does wbsd wait for the DAT busy signal to de-assert?
>   

I don't think so. We wait for the controller to leave 'block mode', but
the spec isn't clear if this includes waiting for the busy signal. There
is another bit for explicitly checking the busy bit. I can see if I can
get the bug reporters to try it out.

Doesn't the busy status map directly to the programming state anyhow?

> However, I do note that from the October dump, the card is
> reporting that it is ready for more data (bit 8):
>
>   

That's what got me thinking that waiting for it to leave programming
state is the way to go.

> MMC: req done (0d): 0: 00000f00 4b000000 00000000 00000000
>
> whereas it's impossible to tell with the November dump because
> the useful information has been edited out.  Hence the November
> dump is rather useless.
>
>   

What seems to be missing?

Rgds
Pierre

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/