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.
>From the specs I have, this behaviour is required for SD cards, but not
MMC. The two bug reports I have are both for MMC though. So either these
cards are broken, or they patch works simply because it adds an extra delay.
(Oddly enough, I have yet to receive a report of a SD card that
misbehaves because of this.)
Russell, what's your take on this? Play it safe and put this patch in
mainline or do you have some ideas to test first?
Threads for bug reports:
http://list.drzeus.cx/pipermail/wbsd-devel/2005-October/000351.html
http://list.drzeus.cx/pipermail/wbsd-devel/2005-November/000388.html
Entries with relevant dumps:
http://list.drzeus.cx/pipermail/wbsd-devel/2005-November/000396.html
http://list.drzeus.cx/pipermail/wbsd-devel/2005-October/000361.html
Rgds
Pierre
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?
However, I do note that from the October dump, the card is
reporting that it is ready for more data (bit 8):
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.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
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
On Mon, Dec 26, 2005 at 08:57:55PM +0100, Pierre Ossman wrote:
> Russell King wrote:
> > 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?
The lines containing the respose to the CMD0x18 and CMD0x0d - iow
the card status. I'd like to see the result from the previous
two commands to the errors occurring.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Russell King wrote:
> On Mon, Dec 26, 2005 at 08:57:55PM +0100, Pierre Ossman wrote:
>
>> Russell King wrote:
>>
>>> 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?
>>
>
> The lines containing the respose to the CMD0x18 and CMD0x0d - iow
> the card status. I'd like to see the result from the previous
> two commands to the errors occurring.
>
>
I'll see if I can get hold of him to give a dump all the way from
loading the module.
Rgds
Pierre