From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ivan Djelic <ivan.djelic@parrot.com>
Cc: Mike Dunn <mikedunn@newsguy.com>,
Robert Jarzmik <robert.jarzmik@free.fr>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v2] mtd: nand: Add driver for M-sys / Sandisk diskonchip G4
Date: Tue, 08 Nov 2011 23:12:28 +0200 [thread overview]
Message-ID: <1320786750.17770.15.camel@koala> (raw)
In-Reply-To: <20111103115914.GA30600@parrot.com>
On Thu, 2011-11-03 at 12:59 +0100, Ivan Djelic wrote:
> On Thu, Nov 03, 2011 at 11:02:11AM +0000, Robert Jarzmik wrote:
> > > I can see two cleaner alternatives to solve this issue:
> > >
> > > 1. When you program a page, before writing hwecc to oob, adjust it like this:
> > > 2. Use unprotected spare oob byte 15 as a programmming marker: remove it from
> > > ...zip...
> >
> > I would see a third one:
> > 3. After reading the page, check bit DOC_ECCCONF1_PAGE_IS_WRITTEN in DOC_ECCCONF1 register.
> > I think this bit is calculated from the Hamming Code (not sure), but I'm pretty sure that
> > this bit is 0 when the page is blank, and 1 if the page was written before.
> >
>
> OK, that's even simpler.
> But as Matthieu pointed out, you would still need to clean-up bitflips in blank
> pages for UBIFS...
What happens is UBIFS writes to a blank page which already contains more
bitflips than ECC can handle? I presume UBI would get a write error? If
UBI gets an EIO on write, than it should move all the data to a
different PEB and schedule the bit-flippy eraseblock for torturing. Just
worth checking that the driver indeed returns an error in this case.
Artem.
next prev parent reply other threads:[~2011-11-08 21:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1388924089.4520961320317174391.JavaMail.root@zimbra20-e3.priv.proxad.net>
2011-11-03 11:02 ` [PATCH v2] mtd: nand: Add driver for M-sys / Sandisk diskonchip G4 Robert Jarzmik
2011-11-03 11:59 ` Ivan Djelic
2011-11-08 21:12 ` Artem Bityutskiy [this message]
2011-11-02 23:00 Mike Dunn
2011-11-03 8:58 ` Ivan Djelic
2011-11-03 9:14 ` Matthieu CASTET
2011-11-03 16:55 ` Mike Dunn
2011-11-04 14:20 ` Mike Dunn
2011-11-04 15:23 ` Ivan Djelic
2011-11-04 16:58 ` Ivan Djelic
2011-11-04 20:34 ` Mike Dunn
2011-11-03 16:54 ` Mike Dunn
2011-11-03 17:52 ` Mike Dunn
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=1320786750.17770.15.camel@koala \
--to=dedekind1@gmail.com \
--cc=ivan.djelic@parrot.com \
--cc=linux-mtd@lists.infradead.org \
--cc=mikedunn@newsguy.com \
--cc=robert.jarzmik@free.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.