On Tue, 2015-04-07 at 09:48 -0400, Bill Pringlemeir wrote:
On 3 Apr 2015, stefan@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