- 15 Sep, 2024 2 commits
-
-
Miquel Raynal authored
* Raw NAND changes The use of for_each_child_of_node_scoped() has been spread into the subsystem drivers. Aside from that, a couple of exit path have been fixed (mtk, denali), the TI GPMC bindings have been enhanced to comply with up-to-date partition descriptions and as always there is a load of small and misc fixes. * SPI-NAND changes The most impacting series this cycle is bringing support for continuous reads in the SPI-NAND subsystem. This is a feature already merged in the raw NAND subsystem which allows optimizing the internal fetch times in the chip while reading sequential pages within an eraseblock. For now only Macronix NANDs benefit from this feature. While we are talking about Macronix, some of their chip need an explicit action for selecting a different plane, and support for it has also been brought. The bitflip threshold has also been set to the same arbitrary level as in the raw NAND subsystem to optimize wear leveling decisions, and finally support for a new Winbond chip has been added.
-
Miquel Raynal authored
SPI NOR changes for 6.12 Notable changes: - Add Write Protect support for N25Q064A. - New flash support for Zetta ZD25Q128C and Spansion S28HS256T. - Fix a NULL dereference in probe path for flashes without a name. The probe path tries to access the name without checking its existence first. S28HS256T is the first flash to define its entry without a name, uncovering this issue.
-
- 14 Sep, 2024 5 commits
-
-
Michael Walle authored
Fix flash probing by name. Flash entries without a name are allowed since commit 15eb8303 ("mtd: spi-nor: mark the flash name as obsolete"). But it was just until recently that a flash entry without a name was actually introduced. This triggers a bug in the legacy probe by name path. Skip entries without a name to fix it. Fixes: 2095e7da8049 ("mtd: spi-nor: spansion: Add support for S28HS256T") Reported-by:
Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/r/66c8ebb0-1324-4ad9-9926-8d4eb7e1e63a@nvidia.com/Tested-by:
Michael Walle <mwalle@kernel.org> Reviewed-by:
Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by:
Pratyush Yadav <pratyush@kernel.org> Signed-off-by:
-
Takahiro Kuwano authored
Infineon S28HS256T is 256Mb Octal SPI device which has same functionalities with 512Mb and 1Gb parts. Link: https://www.infineon.com/dgdl/Infineon-S28HS256T_S28HL256T_256Mb_SEMPER_Flash_Octal_interface_1_8V_3-DataSheet-v02_00-EN.pdf?fileId=8ac78c8c8fc2dd9c018fc66787aa0657Signed-off-by:
Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Reviewed-by:
-
Michael Walle authored
Zetta normally uses BAh as its vendor ID. But for the ZD25Q128C they took the one from Winbond and messed up the size parameters in SFDP. Most functions seem compatible with the W25Q128, we just have to fix up the size. Link: http://www.zettadevice.com/upload/file/20150821/DS_Zetta_25Q128_RevA.pdf Link: https://www.lcsc.com/datasheet/lcsc_datasheet_2312081757_Zetta-ZD25Q128CSIGT_C19626875.pdfSigned-off-by:
-
Brian Norris authored
These flash chips are used on Google / TP-Link / ASUS OnHub devices, and OnHub devices are write-protected by default (same as any other ChromeOS/Chromebook system). I've referred to datasheets, and tested on OnHub devices. Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Reviewed-by:
-
Csókás, Bence authored
Writing to the Flash in `sst_nor_write()` is a 3-step process: first an optional one-byte write to get 2-byte-aligned, then the bulk of the data is written out in vendor-specific 2-byte writes. Finally, if there's a byte left over, another one-byte write. This was implemented 3 times in the body of `sst_nor_write()`. To reduce code duplication, factor out these sub-steps to their own function. Signed-off-by:
Csókás, Bence <csokas.bence@prolan.hu> Reviewed-by:
-
- 09 Sep, 2024 4 commits
-
-
Cheng Ming Lin authored
Macronix serial NAND flash with a two-plane structure requires insertion of the Plane Select bit into the column address during the write_to_cache operation. Additionally, for MX35{U,F}2G14AC and MX35LF2GE4AB, insertion of the Plane Select bit into the column address is required during the read_from_cache operation. Signed-off-by:Cheng Ming Lin <chengminglin@mxic.com.tw> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20240909092643.2434479-3-linchengming884@gmail.com
-
Cheng Ming Lin authored
Add two flags for inserting the Plane Select bit into the column address during the write_to_cache and the read_from_cache operation. Add the SPINAND_HAS_PROG_PLANE_SELECT_BIT flag for serial NAND flash that require inserting the Plane Select bit into the column address during the write_to_cache operation. Add the SPINAND_HAS_READ_PLANE_SELECT_BIT flag for serial NAND flash that require inserting the Plane Select bit into the column address during the read_from_cache operation. Signed-off-by:
-
Roger Quadros authored
Allow fixed-partitions to be specified through a partitions node. Fixes the below dtbs_check warning: arch/arm64/boot/dts/ti/k3-am642-evm-nand.dtb: nand@0,0: Unevaluated properties are not allowed ('partitions' was unexpected) Signed-off-by:Roger Quadros <rogerq@kernel.org> Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
Miquel Raynal authored
Reviewing a series converting the for_each_chil_of_node() loops into their _scoped variants made me realize there was no cleanup of the already registered NAND devices upon error which may leak memory on systems with more than a chip when this error occurs. We should call the _nand_chips_cleanup() function when this happens. Fixes: 1d6b1e46 ("mtd: mediatek: driver for MTK Smart Device") Signed-off-by:
Matthias Brugger <matthias.bgg@kernel.org> Link: https://lore.kernel.org/linux-mtd/20240826153019.67106-2-miquel.raynal@bootlin.com
-
- 06 Sep, 2024 25 commits
-
-
Charles Han authored
devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fixes: acfe63ec ("mtd: Convert to using %pOFn instead of device_node.name") Signed-off-by:
Charles Han <hanchunchao@inspur.com> Signed-off-by:
-
Miquel Raynal authored
There are some un-freed resources in one of the error path which would benefit from a helper going through all the registered mtk chips one by one and perform all the necessary cleanup. This is precisely what the remove path does, so let's extract the logic in a helper. There is no functional change. Signed-off-by:
-
Alexander Dahl authored
Like for other atmel drivers (serial, crypto, mmc, …), too. Signed-off-by:
Alexander Dahl <ada@thorsis.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Miquel Raynal authored
There is a reason why sometime we write "NAND chip" with an 's'. It usually means several chips can be managed by the same controller. So when initializing a single chip at a time, the wording "chip" must be used, otherwise when talking about all the chips managed by the controller, we want to use "chips". Fix the function name to clarify the meson_nfc_nand_chip*s*_cleanup() helper intend. Signed-off-by:
-
Miquel Raynal authored
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@mxic.com.tw>. Signed-off-by:
-
Miquel Raynal authored
Macronix SPI-NANDs encode the ECC status into two bits. There are three standard situations (no bitflip, bitflips, error), and an additional possible situation which is only triggered when configuring the 0x10 configuration register, allowing to know, if there have been bitflips, whether the maximum amount of bitflips was above a configurable threshold or not. In all cases, for now, s this configuration register is unset, it means the same as "there are bitflips". This value is maybe standard, maybe not. For now, let's define it in the Macronix driver, we can safely move it to a shared place later if that is relevant. Signed-off-by:
-
Miquel Raynal authored
With GET_STATUS commands, SPI-NAND devices can tell the status of the last read operation, in particular if there was: - no bitflips - corrected bitflips - uncorrectable bitflips The next step then to read an ECC status register and retrieve the amount of bitflips, when relevant, if possible. The logic used here works well for now, but will no longer apply to continuous reads. In order to prepare the introduction of continuous reads, let's factorize out the code that is specific to single-page reads. Signed-off-by:
-
Miquel Raynal authored
Use "macronix_" instead of "mx35lf1ge4ab_" as common prefix for the ->get_status() callback name. This callback is used by many different families, there is no variation in the implementation so far. Signed-off-by:
-
Miquel Raynal authored
This helper function will soon be used from a vendor driver, let's export it through the spinand.h header. No need for any export, as there is currently no reason for any module to need it. Signed-off-by:
-
Miquel Raynal authored
A regular page read consist in: - Asking one page of content from the NAND array to be loaded in the chip's SRAM, - Waiting for the operation to be done, - Retrieving the data (I/O phase) from the chip's SRAM. When reading several sequential pages, the above operation is repeated over and over. There is however a way to optimize these accesses, by enabling continuous reads. The feature requires the NAND chip to have a second internal SRAM area plus a bit of additional internal logic to trigger another internal transfer between the NAND array and the second SRAM area while the I/O phase is ongoing. Once the first I/O phase is done, the host can continue reading more data, continuously, as the chip will automatically switch to the second SRAM content (which has already been loaded) and in turns trigger the next load into the first SRAM area again. From an instruction perspective, the command op-codes are different, but the same cycles are required. The only difference is that after a continuous read (which is stopped by a CS deassert), the host must observe a delay of tRST. However, because there is no guarantee in Linux regarding the actual state of the CS pin after a transfer (in order to speed-up the next transfer if targeting the same device), it was necessary to manually end the continuous read with a configuration register write operation. Continuous reads have two main drawbacks: * They only work on full pages (column address ignored) * Only the main data area is pulled, out-of-band bytes are not accessible. Said otherwise, the feature can only be useful with on-die ECC engines. Performance wise, measures have been performed on a Zynq platform using Macronix SPI-NAND controller with a Macronix chip (based on the flash_speed tool modified for testing sequential reads): - 1-1-1 mode: performances improved from +3% (2-pages) up to +10% after a dozen pages. - 1-1-4 mode: performances improved from +15% (2-pages) up to +40% after a dozen pages. This series is based on a previous work from Macronix engineer Jaime Liao. Signed-off-by: -
Miquel Raynal authored
There is currently only a single path for performing page reads as requested by the MTD layer. Soon there will be two: - a "regular" page read - a continuous page read Let's extract the page read logic in a dedicated helper, so the introduction of continuous page reads will be as easy as checking whether continuous reads shall/can be used and calling one helper or the other. There is not behavioral change intended. Signed-off-by:
-
Miquel Raynal authored
In order to be able to iterate easily across eraseblocks rather than pages, let's introduce a block iterator inspired from the page iterator. The main usage of this iterator will be for continuous/sequential reads, where it is interesting to use a single request rather than split the requests in smaller chunks (ie. pages) that can be hardly optimized. So a "continuous" boolean get's added for this purpose. Signed-off-by:
-
Miquel Raynal authored
Soon a helper for iterating over blocks will be needed (for continuous read purposes). In order to clarify the intend of this helper, let's rename it with the "page" wording inside. While at it, improve the doc and fix a typo. Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop by using for_each_child_of_node_scoped(). Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop by using for_each_child_of_node_scoped(). Signed-off-by:
-
Jinjie Ruan authored
Avoids the need for manual cleanup of_node_put() in early exits from the loop. Signed-off-by:
-
Jinjie Ruan authored
The devm_clk_get_enabled() helper: - calls devm_clk_get() - calls clk_prepare_enable() and registers what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code. Signed-off-by: -
Chen Ridong authored
The pci_release_regions was miss at error case, just add it. Signed-off-by:
Chen Ridong <chenridong@huawei.com> Signed-off-by:
-
- 23 Aug, 2024 4 commits
-
-
Bartosz Golaszewski authored
There are no longer any users of the platform data for davinci rawnand in board files. We can remove the public pdata headers and move the structures that are still used into the driver compilation unit while removing the rest. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by:
-
Daniel Golle authored
Reporting an unclean read from SPI-NAND only when the maximum number of correctable bitflip errors has been hit seems a bit late. UBI LEB scrubbing, which depends on the lower MTD device reporting correctable bitflips, then only kicks in when it's almost too late. Set bitflip_threshold to 75% of the ECC strength, which is also the default for raw NAND. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Reviewed-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by:
-
Robert Marko authored
Add support for Winbond W25N01KV 1Gbit SPI-NAND. It has 4-bit on-die ECC. Signed-off-by:
Robert Marko <robimarko@gmail.com> Signed-off-by:
-
Yan Zhen authored
When we are allocating an array, using kmemdup_array() to take care about multiplication and possible overflows. Also it makes auditing the code easier. Signed-off-by:
Yan Zhen <yanzhen@vivo.com> Signed-off-by:
-
