From: Nick Thompson <nick.thompson@gefanuc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH RFC] NAND: Improve read performance from Large Page NAND devices
Date: Tue, 01 Dec 2009 11:34:43 +0000 [thread overview]
Message-ID: <4B14FF53.5040208@gefanuc.com> (raw)
In-Reply-To: <4B14EC4D.9090208@gefanuc.com>
On 01/12/09 10:13, Nick Thompson wrote:
> On 01/12/09 00:55, Scott Wood wrote:
>> This change will break drivers that support large page and use the
>> default read_page functions, but do not implement cmd_ctrl (they replace
>> cmdfunc instead). This includes fsl_elbc_nand, mxc_nand, and
>> mpc5121_nfc. While I'd like to move them to implementing their own
>> read_page-type functions instead of cmdfunc, is there any way to make it
>> a smoother transition?
>
> Yes, as it stands they would need modifying simultaneously and I have no
> way to test such a change myself. The only required change in cmdfunc is
> not to wait after a read0 request. You maybe in a better position to decide
> if this has wider repercussions, but I will take a look at the above
> drivers as well. [This is the main reason I made this an RFC].
How about, if nand_wait_cache_load was replaceable (by a no-op in your case)
and the pre-fetch optimisation could be disabled by setting rstate to
(INIT | NO_REQ) on every page read function call #ifdef
CONFIG_NAND_NO_PREFETCH_READS?
This leaves a problem with NAND_CMD_RNDOUT which is used by oob_first
page reads but not supported by fsl_elbc_cmdfunc. I expect you don't use
oob_first though..?
I believe this would allow you to restore the original sequences and keep you
going until you can define your own page read functions.
[BTW these changes applied quite cleanly to my Linux tree and give similar
performance gains there as well. If we can reach agreement here, I will
make patches for Linux as well. Unfortunately, my tree is 2.6.18 with
backported NAND support from 2.6.32rc1, but I can deal with that.]
Nick.
next prev parent reply other threads:[~2009-12-01 11:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 13:57 [U-Boot] [PATCH RFC] NAND: Improve read performance from Large Page NAND devices Nick Thompson
2009-12-01 0:55 ` Scott Wood
2009-12-01 10:13 ` Nick Thompson
2009-12-01 11:34 ` Nick Thompson [this message]
2009-12-01 18:43 ` Scott Wood
2009-12-01 18:38 ` Scott Wood
-- strict thread matches above, loose matches on Subject: below --
2009-12-08 15:33 Nick Thompson
2009-12-08 22:06 ` Wolfgang Denk
2009-12-09 9:43 ` Nick Thompson
2009-12-09 11:02 ` Wolfgang Denk
2009-12-09 11:43 ` Nick Thompson
2010-01-16 1:51 ` Josh Gelinske
2010-01-18 12:48 ` Nick Thompson
2010-01-18 15:16 ` Josh Gelinske
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=4B14FF53.5040208@gefanuc.com \
--to=nick.thompson@gefanuc.com \
--cc=u-boot@lists.denx.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 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.