public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][MMC] Buggy cards need to leave programming state
Date: Mon, 26 Dec 2005 19:13:07 +0000	[thread overview]
Message-ID: <20051226191307.GA17191@flint.arm.linux.org.uk> (raw)
In-Reply-To: <43AFEDF8.2060404@drzeus.cx>

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

  reply	other threads:[~2005-12-26 19:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-26 13:19 [RFC][MMC] Buggy cards need to leave programming state Pierre Ossman
2005-12-26 19:13 ` Russell King [this message]
2005-12-26 19:57   ` Pierre Ossman
2005-12-26 20:17     ` Russell King
2005-12-26 20:33       ` Pierre Ossman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051226191307.GA17191@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox