public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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