public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: "Wolfgang Mües" <wolfgang.mues@auerswald.de>
Cc: "Pierre Ossman" <pierre@ossman.eu>,
	"Matt Fleming" <matt@console-pimps.org>,
	"Pierre Ossman" <drzeus@drzeus.cx>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mike Frysinger" <vapier.adi@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc_spi: use EILSEQ for possible transmission errors
Date: Mon, 25 May 2009 02:43:46 -0700	[thread overview]
Message-ID: <200905250243.46984.david-b@pacbell.net> (raw)
In-Reply-To: <200905251104.47550.wolfgang.mues@auerswald.de>

On Monday 25 May 2009, Wolfgang Mües wrote:
> Can someone please explain for me the purpose and the implementation of this 
> wear level logic in block.c?

I think you're misinterpreting what I said.  The wear leveling
logic is in the microcontroller *INSIDE THE MMC/SD DEVICE* not
on the Linux side driver.


> I can not see why a sector erase and the sector erase result codes of a MMC/SD 
> card can be used to get any usefull information about wear leveling in the 
> card. The mapping of physical to logical blocks is not reported by the card, 
> and the number of erase cycles for each block is also not reported. SO how 
> can the host be able to optimize the wear leveling?

It can't.  But when the card controller knows that for example
certain logical blocks are not holding data, it can use that
for wear leveling ... it's got more physical blocks to use to
even out the writes, as well as having any records it kept on
writes, reads, and erasures.




  reply	other threads:[~2009-05-25  9:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14 11:24 [PATCH] mmc_spi: use EILSEQ for possible transmission errors Wolfgang Mües
2009-05-19 11:29 ` Matt Fleming
2009-05-19 11:47   ` Wolfgang Mües
2009-05-20  7:53     ` Matt Fleming
2009-05-20  4:49   ` David Brownell
2009-05-20  8:35     ` Wolfgang Mües
2009-05-20  9:20       ` David Brownell
2009-05-20 10:08         ` Pierre Ossman
2009-05-21  2:02           ` David Brownell
2009-05-25  9:04             ` Wolfgang Mües
2009-05-25  9:43               ` David Brownell [this message]
2009-05-25 10:18                 ` Wolfgang Mües
2009-05-25 11:50                   ` Pierre Ossman
2009-05-25 14:59                     ` Wolfgang Mües
2009-06-09 18:07                       ` Pierre Ossman
2009-06-10  7:29                         ` Wolfgang Mües
2009-06-10  7:37                           ` Matt Fleming
2009-06-13 10:57                           ` Pierre Ossman
2009-05-25 11:48             ` Pierre Ossman
2009-05-20 10:31         ` Wolfgang Mües

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=200905250243.46984.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=drzeus@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@console-pimps.org \
    --cc=pierre@ossman.eu \
    --cc=vapier.adi@gmail.com \
    --cc=wolfgang.mues@auerswald.de \
    /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