From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/4] mtd: vf610_nfc: support subpage write
Date: Tue, 7 Apr 2015 11:21:15 -0500 [thread overview]
Message-ID: <1428423675.22867.426.camel@freescale.com> (raw)
In-Reply-To: <87bnj0kq1b.fsf@nbsps.com>
On Tue, 2015-04-07 at 09:48 -0400, Bill Pringlemeir wrote:
> 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?
It's an awkward interface for drivers that expose a higher-level
programming model. Basically you have to behave as if nand_base could
send commands directly to the chip.
> 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?
At SEQIN time, you can't. You'll know based on how much data is written
into the buffer. Or, you can skip this low-level interface and replace
nand_write_page (which is what I wish we'd done in the eLBC/IFC
drivers).
> 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.
Wouldn't that mess up factory bad block markers?
-Scott
prev parent reply other threads:[~2015-04-07 16:21 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
2015-04-07 16:21 ` Scott Wood [this message]
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=1428423675.22867.426.camel@freescale.com \
--to=scottwood@freescale.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.