[PATCH v2 3/3] mtd: rawnand: Support for sequential cache reads

[Måns Rullgård]

Miquel Raynal <miquel.raynal at bootlin.com> writes:

> Hi Måns,
>
> mans at mansr.com wrote on Thu, 22 Jun 2023 15:59:25 +0100:
>
>> Miquel Raynal <miquel.raynal at bootlin.com> writes:
>> 
>> > From: JaimeLiao <jaimeliao.tw at gmail.com>
>> >
>> > Add support for sequential cache reads for controllers using the generic
>> > core helpers for their fast read/write helpers.
>> >
>> > Sequential reads may reduce the overhead when accessing physically
>> > continuous data by loading in cache the next page while the previous
>> > page gets sent out on the NAND bus.
>> >
>> > The ONFI specification provides the following additional commands to
>> > handle sequential cached reads:
>> >
>> > * 0x31 - READ CACHE SEQUENTIAL:
>> >   Requires the NAND chip to load the next page into cache while keeping
>> >   the current cache available for host reads.
>> > * 0x3F - READ CACHE END:
>> >   Tells the NAND chip this is the end of the sequential cache read, the
>> >   current cache shall remain accessible for the host but no more
>> >   internal cache loading operation is required.
>> >
>> > On the bus, a multi page read operation is currently handled like this:
>> >
>> > 	00 -- ADDR1 -- 30 -- WAIT_RDY (tR+tRR) -- DATA1_IN
>> > 	00 -- ADDR2 -- 30 -- WAIT_RDY (tR+tRR) -- DATA2_IN
>> > 	00 -- ADDR3 -- 30 -- WAIT_RDY (tR+tRR) -- DATA3_IN
>> >
>> > Sequential cached reads may instead be achieved with:
>> >
>> > 	00 -- ADDR1 -- 30 -- WAIT_RDY (tR) -- \
>> > 		       31 -- WAIT_RDY (tRCBSY+tRR) -- DATA1_IN \
>> > 		       31 -- WAIT_RDY (tRCBSY+tRR) -- DATA2_IN \
>> > 		       3F -- WAIT_RDY (tRCBSY+tRR) -- DATA3_IN
>> >
>> > Below are the read speed test results with regular reads and
>> > sequential cached reads, on NXP i.MX6 VAR-SOM-SOLO in mapping mode with
>> > a NAND chip characterized with the following timings:
>> > * tR: 20 µs
>> > * tRCBSY: 5 µs
>> > * tRR: 20 ns
>> > and the following geometry:
>> > * device size: 2 MiB
>> > * eraseblock size: 128 kiB
>> > * page size: 2 kiB
>> >
>> > ============= Normal read @ 33MHz =================
>> > mtd_speedtest: eraseblock read speed is 15633 KiB/s
>> > mtd_speedtest: page read speed is 15515 KiB/s
>> > mtd_speedtest: 2 page read speed is 15398 KiB/s
>> > ===================================================
>> >
>> > ========= Sequential cache read @ 33MHz ===========
>> > mtd_speedtest: eraseblock read speed is 18285 KiB/s
>> > mtd_speedtest: page read speed is 15875 KiB/s
>> > mtd_speedtest: 2 page read speed is 16253 KiB/s
>> > ===================================================
>> >
>> > We observe an overall speed improvement of about 5% when reading
>> > 2 pages, up to 15% when reading an entire block. This is due to the
>> > ~14us gain on each additional page read (tR - (tRCBSY + tRR)).
>> >
>> > Co-developed-by: Miquel Raynal <miquel.raynal at bootlin.com>
>> > Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
>> > Signed-off-by: JaimeLiao <jaimeliao.tw at gmail.com>
>> > ---
>> >  drivers/mtd/nand/raw/nand_base.c | 119 +++++++++++++++++++++++++++++--
>> >  include/linux/mtd/rawnand.h      |   9 +++
>> >  2 files changed, 124 insertions(+), 4 deletions(-)  
>> 
>> This change broke something on a TI AM3517 based system.  What I'm
>> noticing is that the u-boot fw_setenv tool is failing due to the
>> MEMGETBADBLOCK ioctl reporting some blocks as bad when they are not.
>> Everything else is, somehow, working fine.  Reverting this commit fixes
>> it, though I don't know why.  I'm seeing the same behaviour on multiple
>> devices, so I doubt there is a problem with the flash memory.
>> 
>> Is there anything I can test to get more information?
>> 
>
> May I know what NAND chip you are using?

It's a Micron MT29F4G16ABBDAH4-IT:D.  From the kernel logs:

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc
nand: Micron MT29F4G16ABBDAH4
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64

-- 
Måns Rullgård