From: Jamie Lokier <jamie@shareable.org>
To: Liu Hui <onlyflyer@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Ricard Wanderlof <ricard.wanderlof@axis.com>
Subject: Re: Is it an atomic operation for writing a page in NAND flash
Date: Wed, 20 Jan 2010 13:33:15 +0000 [thread overview]
Message-ID: <20100120133315.GB30789@shareable.org> (raw)
In-Reply-To: <2c3b11251001200511x549f7285if75806e92300818b@mail.gmail.com>
Liu Hui wrote:
> Richard,
>
> Thank you for your confirmation and good idea.
>
> I also think about your idea before, that is, when power failure
> happens, generate an interrupt and blocks any other write requests in
> interrupt handler. But this is a little complex.
Ideally, you would design the hardware so that power failure can be
detected early near the power input, but with enough on-board power
retention (i.e. capacitor) that there is guaranteed enough continuous
power for the CPU to react and the NAND chip to have enough stable
power to complete the write reliably.
There is no need for an interrupt, if you have a fast GPIO that you
can read before each write command that tells if the input power has
not dropped.
> Now, I think I can use ECC to check the partial write, if a write was
> not finished, the ECC should be wrong, so we can detect this partial
> write and discard this write. Do you think this is a good idea?
It's good, but not perfect: In principle a power-failed write could
successfully store the correct bits including ECC so they read back
correctly, but with the cell charges not completely stable. But I
guess that's rare enough that it is just included in the normal NAND
bad block possibilities.
-- Jamie
next prev parent reply other threads:[~2010-01-20 13:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 9:58 Is it an atomic operation for writing a page in NAND flash Liu Hui
2010-01-20 10:13 ` Ricard Wanderlof
2010-01-20 13:11 ` Liu Hui
2010-01-20 13:33 ` Jamie Lokier [this message]
2010-01-20 14:25 ` Liu Hui
2010-01-20 14:54 ` Ricard Wanderlof
2010-01-20 15:11 ` Liu Hui
2010-01-20 16:09 ` Ricard Wanderlof
2010-01-21 1:37 ` Liu Hui
2010-01-20 16:17 ` David Parkinson
2010-01-20 16:35 ` Ricard Wanderlof
2010-01-20 23:08 ` Charles Manning
2010-01-20 13:41 ` Jamie Lokier
2010-01-20 13:58 ` Artem Bityutskiy
2010-01-20 14:06 ` Liu Hui
2010-01-20 14:38 ` Artem Bityutskiy
2010-01-20 14:46 ` Artem Bityutskiy
2010-01-20 14:52 ` Liu Hui
2010-01-20 14:01 ` Liu Hui
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=20100120133315.GB30789@shareable.org \
--to=jamie@shareable.org \
--cc=linux-mtd@lists.infradead.org \
--cc=onlyflyer@gmail.com \
--cc=ricard.wanderlof@axis.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