From: David Brownell <david-b@pacbell.net>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: Andrew Victor <linux@maxim.org.za>, Pavel Pisa <ppisa@pikron.com>,
Carlos Aguiar <carlos.aguiar@indt.org.br>,
Anderson Briglia <briglia.anderson@gmail.com>,
"Syed Mohammed, Khasim" <x0khasim@ti.com>,
Russell King <rmk@arm.linux.org.uk>, Alex Dubov <oakad@yahoo.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] MMC multiwrite capability removal
Date: Mon, 21 Apr 2008 12:05:09 -0700 [thread overview]
Message-ID: <200804211205.10060.david-b@pacbell.net> (raw)
In-Reply-To: <20080419095136.15a50cc9@mjolnir.drzeus.cx>
On Saturday 19 April 2008, Pierre Ossman wrote:
> 1. Data starts moving from main memory to host memory (DMA or PIO)
> 2. Data finishes moving from main memory to host memory
> 3. A sector moves to the front of the device write queue
> 4. The sector starts being sent over the wire
> 5. The sector finishes being sent over the wire
> 6. The card acknowledges a successful transfer
The mmc_spi driver will report failure at this point, when
the card reports an error.
> 7. The card finishes busy signalling
The mmc_spi driver won't report that a sector has been
successfully written until the card stops BUSY signaling.
It's also possible to report an error at this point, such
as ETIMEDOUT if the card doesn't finish that signaling.
> 8. The sector moves to the front of the card write queue
> 9. The sector gets picked up by the FTL
> 10. The sector is written to media
>
> In a perfect world we would report the number of sectors that made it
> to 10. Unfortunately we have limited insight into what the card is up
> to.
>
> What your host drivers should report is sectors that have passed stage
> 6. If your controller doesn't give you enough information to determine
> that, then you must report 0 for all failed transfers.
Seems like mmc_spi does that. Though having looked at this,
I wonder whether per-driver variations in fault reports on
these paths wouldn't make some trouble...
- Dave
prev parent reply other threads:[~2008-04-21 19:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-19 7:51 [RFC] MMC multiwrite capability removal Pierre Ossman
2008-04-20 2:34 ` Alex Dubov
2008-04-20 8:30 ` Pierre Ossman
2008-04-20 14:54 ` Alex Dubov
2008-04-21 19:05 ` David Brownell [this message]
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=200804211205.10060.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=briglia.anderson@gmail.com \
--cc=carlos.aguiar@indt.org.br \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@maxim.org.za \
--cc=oakad@yahoo.com \
--cc=ppisa@pikron.com \
--cc=rmk@arm.linux.org.uk \
--cc=x0khasim@ti.com \
/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