[RFC] MMC multiwrite capability removal

[RFC] MMC multiwrite capability removal

[Pierre Ossman]

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
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.

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

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: [RFC] MMC multiwrite capability removal

[Alex Dubov]

--- Pierre Ossman <drzeus-list@drzeus.cx> wrote:

> 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.
> 

tifm_sd relies on controller to report the number of successfully transferred
blocks. Of course, I cannot be sure to what extent the controller is
trustworthy. It worked fine until now, though.




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [RFC] MMC multiwrite capability removal

[Pierre Ossman]

On Sat, 19 Apr 2008 19:34:12 -0700 (PDT)
Alex Dubov <oakad@yahoo.com> wrote:

> 
> tifm_sd relies on controller to report the number of successfully transferred
> blocks. Of course, I cannot be sure to what extent the controller is
> trustworthy. It worked fine until now, though.
> 

Sounds like a perfect example of when we have to report 0 upon
failures. I suspect most controllers will be like this as all the specs
I've glanced at lack the detail needed to implement a proper sector
count.

The problems caused by reporting incorrect values here are extremely
rare and difficult to provoke, so normal testing is not likely to
uncover it.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: [RFC] MMC multiwrite capability removal

[Alex Dubov]

--- Pierre Ossman <drzeus-list@drzeus.cx> wrote:

> On Sat, 19 Apr 2008 19:34:12 -0700 (PDT)
> Alex Dubov <oakad@yahoo.com> wrote:
> 
> > 
> > tifm_sd relies on controller to report the number of successfully
> transferred
> > blocks. Of course, I cannot be sure to what extent the controller is
> > trustworthy. It worked fine until now, though.
> > 
> 
> Sounds like a perfect example of when we have to report 0 upon
> failures. I suspect most controllers will be like this as all the specs
> I've glanced at lack the detail needed to implement a proper sector
> count.
> 
> The problems caused by reporting incorrect values here are extremely
> rare and difficult to provoke, so normal testing is not likely to
> uncover it.
> 

On the other hand, you may remember that in one of the earlier versions of the
driver I actually counted busy/ready cycles during transfer and from what I
remember, it appeared like controller does the right thing - decrements the
page counter at the "not busy" strobe.



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [RFC] MMC multiwrite capability removal

[David Brownell]

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