From: Matthieu CASTET <matthieu.castet@parrot.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v2] mtd: nand: support BENAND (Built-in ECC NAND)
Date: Mon, 25 Feb 2013 10:24:22 +0100 [thread overview]
Message-ID: <512B2DC6.8090104@parrot.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73E99A025@DBDE01.ent.ti.com>
Gupta, Pekon a écrit :
> Hi,
>
>> This enables support for BENAND, which is an SLC NAND flash solution
>> with embedded error correction code (ECC), currently supports only
>> 128bytes OOB type.
>>
>> In the read sequence, "status read command" is executed to check the
>> ECC status after read data. If bitflips occur, these are
>> automatically corrected by BENAND and the status indicates the result.
>>
>> The write sequence is the same as raw write and the ECC data are
>> automatically written to OOB by BENAND.
>
> Just inquisitive, can anyone please share any throughput comparison between 'BENAND' & 'normal NAND' devices having same capacity and working on same clock-freq ?
>
> (a) Usually on-chip memory controllers work on faster clock frequencies, as compared to the NAND devices connected to them externally on board.
> Thus I assume, ECC computation & correction can be done at faster rate.
>
> (b) However, on other hand BENAND(s) have luxury of accessing the Flash storage array locally, thus eliminating I/O delays | un-optimized IO signal timing from the access-path.
>
> So, if you can share the details throughput comparison between the two types of NAND devices, under various conditions it would be helpful.
>
You always have to transfer the data from/to the nand devices to/from the host.
- Either the ecc internal controller is fast and the throughput are the same
than 'normal nand' (assuming the ecc controller on the host is fast),
- either it is slow and the throughput is limited by the internal ecc controller
(throughput is slower than 'normal nand')
Matthieu
next prev parent reply other threads:[~2013-02-25 9:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 6:17 [PATCH v2] mtd: nand: support BENAND (Built-in ECC NAND) katsuki.uwatoko
2013-02-21 9:50 ` Matthieu CASTET
2013-02-22 6:23 ` katsuki.uwatoko
2013-02-25 9:06 ` Gupta, Pekon
2013-02-25 9:24 ` Matthieu CASTET [this message]
2013-02-25 9:38 ` Gupta, Pekon
2013-02-25 10:18 ` Ricard Wanderlof
2013-02-25 11:10 ` Matthieu CASTET
2013-02-25 11:35 ` Gupta, Pekon
2013-02-26 2:41 ` katsuki.uwatoko
2013-03-11 8:57 ` Artem Bityutskiy
2013-03-18 2:40 ` katsuki.uwatoko
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=512B2DC6.8090104@parrot.com \
--to=matthieu.castet@parrot.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.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 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.