All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Pringlemeir <bpringlemeir@nbsps.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/4] mtd: vf610_nfc: support subpage write
Date: Tue, 07 Apr 2015 09:48:32 -0400	[thread overview]
Message-ID: <87bnj0kq1b.fsf@nbsps.com> (raw)
In-Reply-To: <ee376a337fac6b33834ce1a797f89055@agner.ch> (Stefan Agner's message of "Sat, 04 Apr 2015 00:24:56 +0200")

On  3 Apr 2015, stefan at agner.ch wrote:

> I will remove the page read on NAND_CMD_SEQIN, since we memcpy the
> full page anyway. I also just realized that the page read actually
> happens always and hence slows down even full page writes...

Yes, I remove this in Linux (4.0) and it corrupted things when writing.
I think your previous conclusion about we never use 'write caching' was
wrong.

This one is for writes,

	case NAND_CMD_SEQIN: /* Pre-read for partial writes. */

This one is for reads,

	case NAND_CMD_READ0:

The interface between 'nand_base' and the MTD driver is hard to
decipher.  Does Scott (or anyone) know if there is any documentation on
this?

Stefan is completely correct that if a full page is being written, then
the 'SEQIN' should not read a page.  However, I only see 'column' being
passed.  How is 'SEQIN' and 'PAGEPROG' to detect if a full page is being
written or not?

The other way to handle things would to be to investigate the
NFC_CFG[PAGE_CNT] and NFC_SECSZ to have the virtual pages support
sub-pages.  I think the OOB mapping would be non-standard in such cases.
The buffer management in the driver is most simple in it's current form.
The other versions that I found seemed to be buggy to me.  However, the
current driver doesn't use all of the NFC SRAM buffer space.

Btw, the READ_OOB is very nice for Linux as well.  It is a much faster
mount of UBI/UbiFs as well.

Fwiw,
Bill Pringlemeir.

  reply	other threads:[~2015-04-07 13:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-03 18:40 [U-Boot] [PATCH 1/4] mtd: vf610_nfc: use in-band bad block table Stefan Agner
2015-04-03 18:40 ` [U-Boot] [PATCH 2/4] mtd: vf610_nfc: add Freescale NFC controller configs to Kconfig Stefan Agner
2015-04-03 20:30   ` Scott Wood
2015-04-03 20:42     ` Stefan Agner
2015-04-03 20:46       ` Scott Wood
2015-04-03 22:30         ` Stefan Agner
2015-04-03 22:47           ` Scott Wood
2015-04-03 18:40 ` [U-Boot] [PATCH 3/4] mtd: vf610_nfc: add 32-error correction option for HW ECC Stefan Agner
2015-04-03 18:40 ` [U-Boot] [PATCH 4/4] mtd: vf610_nfc: support subpage write Stefan Agner
2015-04-03 20:36   ` Scott Wood
2015-04-03 22:24     ` Stefan Agner
2015-04-07 13:48       ` Bill Pringlemeir [this message]
2015-04-07 16:21         ` Scott Wood

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=87bnj0kq1b.fsf@nbsps.com \
    --to=bpringlemeir@nbsps.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.