- 18 Jun, 2021 12 commits
-
-
Miquel Raynal authored
Add Naga from Xilinx and myself responsible of this driver. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Link: https://lore.kernel.org/linux-mtd/20210610082040.2075611-17-miquel.raynal@bootlin.com
-
Md Sadre Alam authored
QPIC_EBI2_ECC_BUF_CFG register got obsolete from QPIC V2.0 onwards. Avoid writing this register if QPIC version is V2.0 or newer. Signed-off-by:
Md Sadre Alam <mdalam@codeaurora.org> Signed-off-by:
-
Souptick Joarder authored
Kernel test robot throws below warning -> drivers/mtd/nand/raw/marvell_nand.c:454: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Minor documentation correction. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Zhen Lei authored
Use DEVICE_ATTR_RO() helper macro instead of plain DEVICE_ATTR(), which makes the code a bit shorter and easier to read. Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
Patrice Chotard authored
After power up, all SPI NAND's blocks are locked. Only read operations are allowed, write and erase operations are forbidden. The SPI NAND framework unlocks all the blocks during its initialization. During a standby low power, the memory is powered down, losing its configuration. During the resume, the QSPI driver state is restored but the SPI NAND framework does not reconfigured the memory. This patch adds SPI-NAND MTD PM handlers for resume ops. SPI NAND resume op re-initializes SPI NAND flash to its probed state. Signed-off-by:
Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by:
Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by:
-
Patrice Chotard authored
Add spinand_init_flash() helper which implement all needed init for future SPI-NAND resume ops. Signed-off-by:
-
Patrice Chotard authored
Put REG_CFG reading code in spinand_read_cfg(). This function will be needed by the future SPI-NAND resume ops. Signed-off-by:
-
Yang Yingliang authored
Add clk_disable_unprepare() on error path in marvell_nfc_resume(). Fixes: bd9c3f9b ("mtd: rawnand: marvell: add suspend and resume hooks") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Miquel Raynal authored
Add support for the timings register which may improve a bit the overall throughput. Signed-off-by:
-
Miquel Raynal authored
There are 2 timing registers: - "data interface" - "timings" So far, the "data interface" register was named "timings" which begins misleading when bringing support for the "timings" register. Rename it to "data_iface". Signed-off-by:
-
Miquel Raynal authored
Without the use of le16_to_cpu(), these accesses would have been wrong on a big-endian machine. Reported-by:
-
Miquel Raynal authored
Xilinx ZynqMP SoC and the Arasan controller support 64-bit DMA addressing. Define the right mask otherwise the default is 32 and some accesses may overflow the default mask. Reported-by:
Jorge Courett <jorge.courett@gmail.com> Signed-off-by:
-
- 11 Jun, 2021 2 commits
-
-
Miquel Raynal authored
In the raw NAND world, ECC engines increment ecc_stats and the final caller is responsible for returning -EBADMSG if the verification failed. In the SPI-NAND world it was a bit different until now because there was only one possible ECC engine: the on-die one. Indeed, the spinand_mtd_read() call was incrementing the ecc_stats counters depending on the outcome of spinand_check_ecc_status() directly. So now let's split the logic like this: - spinand_check_ecc_status() is specific to the SPI-NAND on-die engine and is kept very simple: it just returns the ECC status (bonus point: the content of this helper can be overloaded). - spinand_ondie_ecc_finish_io_req() is the caller of spinand_check_ecc_status() and will increment the counters and eventually return -EBADMSG. - spinand_mtd_read() is not tied to the on-die ECC implementation and should be able to handle results coming from other ECC engines: it has the responsibility of returning the maximum number of bitflips which happened during the entire operation as this is the only helper that is aware that several pages may be read in a row. Fixes: 945845b5 ("mtd: spinand: Instantiate a SPI-NAND on-die ECC engine") Reported-by:
YouChing Lin <ycllin@mxic.com.tw> Signed-off-by:
-
Miquel Raynal authored
Memory controller drivers for v5.14 - PL353 Bigger work around ARM Primecell PL35x SMC memory controller driver by Miquel Raynal built on previous series from Naga Sureshkumar Relli. This includes bindings cleanup and correction, converting these to dtschema and several cleanyps in pl353-smc driver.
-
- 10 Jun, 2021 14 commits
-
-
Miquel Raynal authored
Convert this binding file to yaml schema. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210610082040.2075611-10-miquel.raynal@bootlin.comSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
-
Miquel Raynal authored
Add Naga from Xilinx and myself responsible of this driver. Signed-off-by:
-
Miquel Raynal authored
This is a purely cosmetic change. Signed-off-by:
-
Miquel Raynal authored
APER does not mean anything, while it seems legitimate to call this clock the AXI peripheral clock. Signed-off-by:
-
Miquel Raynal authored
There is no point in having all these definitions at the SMC bus level, these are extremely tight to the NAND controller driver implementation, are not particularly generic, imply more boilerplate than needed, do not really follow the device model by receiving no argument and some of them are actually buggy. Let's get rid of these right now as there is no current user and keep this driver at a simple level: only the SMC bare initializations. The NAND controller driver which I am going to introduce will take care of redefining properly all these helpers and using them directly. Signed-off-by:
-
Miquel Raynal authored
A goto label is better named do_something: than out_something_to_do: Use the former wording and really describe what the jump involves. Signed-off-by: -
Miquel Raynal authored
Use proper spacing. Signed-off-by:
-
Miquel Raynal authored
To be fully valid, the NAND controller node in the example should be named nand-controller instead of flash, should be at the address @0,0 instead of @e1000000 and should have a couple of: - #address-cells - #size-cells properties. The label is being renamed nfc0 as well which is more usual than nand_0. Signed-off-by:
-
Miquel Raynal authored
These nodes are given as examples and are not described nor used anywhere else. There is also no hardware of my knowledge compatible with these yet. If we want to be backward compatible, then we should avoid partially describing nodes and their content while there are no users. Plus, the examples are wrong (the addresses should be updated) so let's drop them before converting this file to yaml (only the NAND node, which will be fixed in the example and described somewhere else is kept). Signed-off-by:
-
Miquel Raynal authored
Enhance the spacing, the comment style, add { }, remove (...). Signed-off-by: -
Miquel Raynal authored
Each chil node should have a reg property, no matter the type of controller (NAND, NOR, SRAM). This should be part of the bindings. Signed-off-by:
-
Miquel Raynal authored
This sentence does not belong to this file as this file describes the bus on which various controllers are wired to. Signed-off-by:
-
Miquel Raynal authored
The ranges property is missing in the description while actually used in the example. This property is actually needed, so mention it. Signed-off-by:
-
Miquel Raynal authored
Reword this document before converting it to yaml. Signed-off-by:
-
- 26 May, 2021 12 commits
-
-
Jaime Liao authored
Macronix NAND Flash devices are available in different configurations and densities. MX"35" means SPI NAND MX35"LF"/"UF" , LF means 3V and UF meands 1.8V MX35LF"2G" , 2G means 2Gbits MX35LF2G"E4"/"24"/"14", E4 means internal ECC and Quad I/O(x4) 24 means 8-bit ecc requirement and Quad I/O(x4) 14 means 4-bit ecc requirement and Quad I/O(x4) MX35LF2G14AC is 3V 2Gbit serial NAND flash device (without on-die ECC) https://www.mxic.com.tw/Lists/Datasheet/Attachments/7926/MX35LF2G14AC,%203V,%202Gb,%20v1.1.pdf MX35UF4G24AD is 1.8V 4Gbit serial NAND flash device (without on-die ECC) https://www.mxic.com.tw/Lists/Datasheet/Attachments/7980/MX35UF4G24AD,%201.8V,%204Gb,%20v0.00.pdf MX35UF4GE4AD/MX35UF2GE4AD are 1.8V 4G/2Gbit serial NAND flash device with 8-bit on-die ECC https://www.mxic.com.tw/Lists/Datasheet/Attachments/7983/MX35UF4GE4AD,%201.8V,%204Gb,%20v0.00.pdf MX35UF2GE4AC/MX35UF1GE4AC are 1.8V 2G/1Gbit serial NAND flash device with 8-bit on-die ECC https://www.mxic.com.tw/Lists/Datasheet/Attachments/7974/MX35UF2GE4AC,%201.8V,%202Gb,%20v1.0.pdf MX35UF2G14AC/MX35UF1G14AC are 1.8V 2G/1Gbit serial NAND flash device (without on-die ECC) https://www.mxic.com.tw/Lists/Datasheet/Attachments/7931/MX35UF2G14AC,%201.8V,%202Gb,%20v1.1.pdf Validated via normal(default) and QUAD mode by read, erase, read back, on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host(drivers/spi/spi-mxic.c). Signed-off-by:
Jaime Liao <jaimeliao@mxic.com.tw> Signed-off-by:
-
Zhen Lei authored
The result of an expression consisting of a single relational operator is already of the bool type and does not need to be evaluated explicitly. No functional change. Signed-off-by:
-
Miquel Raynal authored
Make use of the cs-gpios DT property as well as the core helper to parse it so that the Arasan controller driver can now assert many more chips than natively. The Arasan controller has an internal limitation: RB0 is tied to CS0 and RB1 is tied to CS1. Hence, it is possible to use external GPIOs as long as one or the other native CS is not used (or configured to be driven as a GPIO) and that all additional CS are physically wired on its corresponding RB line. Eg. CS0 is used as a native CS, CS1 is not used as native CS and may be used as a GPIO CS, CS2 is an additional GPIO CS. Then the target asserted by CS0 should also be wired to RB0, while the targets asserted by CS1 and CS2 should be wired to RB1. Signed-off-by:
-
Miquel Raynal authored
The controller being always asserting one CS or the other, there is no need to actually select the right target before doing a page read/write. However, the anfc_select_target() helper actually also changes the timing configuration and clock in the case were two different NAND chips with different timing requirements would be used. In this situation, we must ensure proper configuration of the controller by calling it. As a consequence of this change, the anfc_select_target() helper is being moved earlier in the driver. Fixes: 88ffef1b ("mtd: rawnand: arasan: Support the hardware BCH ECC engine") Signed-off-by:
-
Miquel Raynal authored
New chips may feature a lot of CS because of their extended length. As many controllers have been designed a decade ago, they usually only feature just a couple. This does not mean that the entire range of these chips cannot be accessed: it is just a matter of adding more GPIO CS in the hardware design. A DT property has been added to describe the CS array: cs-gpios. Here is the code parsing it this new property, allocating what needs to be, requesting the GPIOs and returning an array with the additional available CS. The first entries of this array are left empty and are reserved for native CS. Signed-off-by:
-
Miquel Raynal authored
The struct gpio_desc is declared in the middle of the rawnand.h header, right before the first function using it (nand_gpio_waitrdy). Before adding a new function and to make it clear: move the declaration to the top of the file. Signed-off-by:
-
Miquel Raynal authored
To reach higher capacities, arrays of chips are now pretty common. Unfortunately, most of the controllers have been designed a decade ago and did not all anticipate the need for several chip-selects. The new cs-gpios property allows to workaround this limitation by adding as many GPIO chip-select as needed. Signed-off-by:
-
Miquel Raynal authored
Add support for the NV-DDR interface. Signed-off-by:
-
Miquel Raynal authored
As explained in the comment introduced above the fix, the Arasan controller driver starts an operation when the prog register is being written with a "type" specific to the action to perform. The prog type used until now to perform a CHANGE READ COLUMN with an SDR interface was the PAGE READ type (CMD + ADDR + CMD + DATA). Unfortunately, for an unknown reason (let's call this a silicon bug) any CHANGE READ COLUMN performed this way in NV-DDR mode will fail: the data ready flag will never be triggered, nor will be the transfer complete flag. Forcefully, this leads to a timeout situation which is not easy to handle. Fortunately, it was spotted that sending the same commands through a different prog register "type", CHANGE READ COLUMN ENHANCED, would work all the time (even though this particular command is not supported by the core and is only available in a limited set of devices - we only care about the controller configuration and not the actual command which is sent to the device). So let's use this type instead when a CHANGE READ COLUMN is requested. Signed-off-by:
-
Miquel Raynal authored
This macro is not yet being used so the compilers never complained about it. Fix the macro before using it. Signed-off-by:
-
Miquel Raynal authored
When I submitted the driver I added Naga as Maintainer and forgot to add myself. Signed-off-by:
-
Miquel Raynal authored
Now that the necessary peaces to support the NV-DDR interface type have been contributed, let's add the relevant logic to make use of it. In particular, the core does not choose the best SDR timings anymore but calls a more generic helper instead. This helper checks if NV-DDR is supported by trying to find the best NV-DDR supported mode through a logic very close to what is being done for SDR timings. If no NV-DDR mode in common between the NAND controller and the NAND chip is found, the core will fallback to SDR. Side note: theoretically, the data clock speed in NV-DDR mode 0 is slower than in SDR mode 5. In the situation where we would get a working NV-DDR mode 0, we could also try if SDR mode 5 is supported and eventually fallback to it in order to get the fastest possible throughput. However, in the field, it looks like most of the devices supporting NV-DDR avoid implementing the fastest SDR modes (like 4 and 5 EDO modes, which are a bit more complicated to handle than the other SDR modes). So, we will stick to the simplest logic: try NV-DDR otherwise fallback to SDR. If someone else experiences strong differences because of that we may still implement the logic defined above. Signed-off-by:
-
