[PATCH v2 9/9] mtd: spi-nand: macronix: Continuous read support

[Miquel Raynal]

On Mon, 2024-08-26 at 10:14:12 UTC, Miquel Raynal wrote:
> Enabling continuous read support implies several changes which must be
> done atomically in order to keep the code base consistent and
> bisectable.
> 
> 1/ Retrieving bitflips differently
> 
> Improve the helper retrieving the number of bitflips to support the case
> where many pages have been read instead of just one. In this case, if
> there is one page with bitflips, we cannot know the detail and just get
> the information of the maximum number of bitflips corrected in the most
> corrupted chunk. Compatible Macronix flashes return:
> - the ECC status for the last page read (bits 0-3),
> - the amount of bitflips for the whole read operation (bits 4-7).
> Hence, when reading two consecutive pages, if there was 2 bits corrected
> at most in one chunk, we return this amount times (arbitrary) the number
> read pages. It is probably a very pessimistic calculation in most cases,
> but still less pessimistic than if we multiplied this amount by the
> number of chunks. Anyway, this is just for statistics, the important
> data is the maximum amount of bitflips, which leads to wear leveling.
> 
> 2/ Configuring, enabling and disabling the feature
> 
> Create an init function for allocating a vendor structure. Use this
> vendor structure to cache the internal continuous read state. The state
> is being used to discriminate between the two bitflips retrieval
> methods. Finally, helpers for enabling and disabling sequential reads
> are also created.
> 
> 3/ Fill the chips table
> 
> Flag all the chips supporting the feature with the ->set_cont_read()
> helper.
> 
> In order to validate the changes, I modified the mtd-utils test suite
> with extended versions of nandbiterrs, nanddump and flash_speed in order
> to support, test and benchmark continuous reads. I also ran all the UBI
> tests successfully.
> 
> The nandbiterrs tool allows to track the ECC efficiency and
> feedback. Here is its default output (stripped):
> 
> Successfully corrected 0 bit errors per subpage
> Read reported 1 corrected bit errors
> Successfully corrected 1 bit errors per subpage
> Read reported 2 corrected bit errors
> Successfully corrected 2 bit errors per subpage
> Read reported 3 corrected bit errors
> Successfully corrected 3 bit errors per subpage
> Read reported 4 corrected bit errors
> Successfully corrected 4 bit errors per subpage
> Read reported 5 corrected bit errors
> Successfully corrected 5 bit errors per subpage
> Read reported 6 corrected bit errors
> Successfully corrected 6 bit errors per subpage
> Read reported 7 corrected bit errors
> Successfully corrected 7 bit errors per subpage
> Read reported 8 corrected bit errors
> Successfully corrected 8 bit errors per subpage
> Failed to recover 1 bitflips
> Read error after 9 bit errors per page
> 
> The output using the continuous option over two pages (the second page
> is kept intact):
> 
> Successfully corrected 0 bit errors per subpage
> Read reported 2 corrected bit errors
> Successfully corrected 1 bit errors per subpage
> Read reported 4 corrected bit errors
> Successfully corrected 2 bit errors per subpage
> Read reported 6 corrected bit errors
> Successfully corrected 3 bit errors per subpage
> Read reported 8 corrected bit errors
> Successfully corrected 4 bit errors per subpage
> Read reported 10 corrected bit errors
> Successfully corrected 5 bit errors per subpage
> Read reported 12 corrected bit errors
> Successfully corrected 6 bit errors per subpage
> Read reported 14 corrected bit errors
> Successfully corrected 7 bit errors per subpage
> Read reported 16 corrected bit errors
> Successfully corrected 8 bit errors per subpage
> Failed to recover 1 bitflips
> Read error after 9 bit errors per page
> 
> Regarding the throughput improvements, tests have been conducted in
> 1-1-1 and 1-1-4 modes, reading a full block X pages at a
> time, X ranging from 1 to 64 (size of a block with the tested device).
> The percent value on the right is the comparison of the same test
> conducted without the continuous read feature, ie. reading X pages in
> one single user request, which got naturally split by the core whit the
> continuous read optimization disabled into single-page reads.
> 
> * 1-1-1 result:
> 1 page read speed is 2634 KiB/s
> 2 page read speed is 2704 KiB/s (+3%)
> 3 page read speed is 2747 KiB/s (+5%)
> 4 page read speed is 2804 KiB/s (+7%)
> 5 page read speed is 2782 KiB/s
> 6 page read speed is 2826 KiB/s
> 7 page read speed is 2834 KiB/s
> 8 page read speed is 2821 KiB/s
> 9 page read speed is 2846 KiB/s
> 10 page read speed is 2819 KiB/s
> 11 page read speed is 2871 KiB/s (+10%)
> 12 page read speed is 2823 KiB/s
> 13 page read speed is 2880 KiB/s
> 14 page read speed is 2842 KiB/s
> 15 page read speed is 2862 KiB/s
> 16 page read speed is 2837 KiB/s
> 32 page read speed is 2879 KiB/s
> 64 page read speed is 2842 KiB/s
> 
> * 1-1-4 result:
> 1 page read speed is 7562 KiB/s
> 2 page read speed is 8904 KiB/s (+15%)
> 3 page read speed is 9655 KiB/s (+25%)
> 4 page read speed is 10118 KiB/s (+30%)
> 5 page read speed is 10084 KiB/s
> 6 page read speed is 10300 KiB/s
> 7 page read speed is 10434 KiB/s (+35%)
> 8 page read speed is 10406 KiB/s
> 9 page read speed is 10769 KiB/s (+40%)
> 10 page read speed is 10666 KiB/s
> 11 page read speed is 10757 KiB/s
> 12 page read speed is 10835 KiB/s
> 13 page read speed is 10976 KiB/s
> 14 page read speed is 11200 KiB/s
> 15 page read speed is 11009 KiB/s
> 16 page read speed is 11082 KiB/s
> 32 page read speed is 11352 KiB/s (+45%)
> 64 page read speed is 11403 KiB/s
> 
> This work has received support and could be achieved thanks to
> Alvin Zhou <alvinzhou at mxic.com.tw>.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next.

Miquel