[lkml]   [2008]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC] MMC multiwrite capability removal
Hi everyone,

I've been planning to remove the MMC multiwrite capability (making it
always on), but I need some help from all you driver maintainers first.

Ages ago, I had a chat with Axboe about the current situation and it
turns out that the MMC layer is a bit over-cautious. There are plenty
of other block devices that cannot report anything more than
success/failure for the whole request. So it's silly that we're
crippling the MMC layer when upper layers have to deal with that
scenario anyway.

What I need from you is and audit of your respective driver(s) and
check that they do not overestimate the number of successfully written
blocks. Please send a short reply even if your driver needs no changes.

Long version:

The data flow of a write is something like this:

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
7. The card finishes busy signalling
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

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.

I'll be having a closer look at stages 7 through 10, but that's a core
issue that shouldn't involve your drivers.


-- Pierre Ossman

Linux kernel, MMC maintainer
PulseAudio, core developer
rdesktop, core developer

 \ /
  Last update: 2008-04-19 09:55    [W:0.050 / U:25.188 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site