- Mar 15, 2022
-
-
Amit Kumar Mahapatra authored
While calculating speed during mtd_speedtest, the time interval (i.e., start - finish) is rounded off to the nearest milliseconds by ignoring the fractional part. This leads to miscalculation of speed. The miscalculation is more visible while running speed test on small partition sizes(i.e., when partition size is equal to eraseblock size or twice the eraseblock size) at higher spi frequencies. For e.g., while calculating eraseblock read speed for a mtd partition with size equal to the eraseblock size(i.e., 64KiB) the eraseblock read time interval comes out to be 966490 nanosecond. This is then converted to millisecond(i.e., 0.966 msec.). The integer part (i.e., 0 msec) of the value is considered and the fractional part (i.e., 0.966) is ignored,for calculating the eraseblock read speed. So the reported eraseblock read speed is 0 KiB/s, which is incorrect. There are two approaches to fix this issue. First approach will be to keep the time interval in millisecond. and round up the integer value, with this approach the 0.966msec time interval in the above example will be rounded up to 1msec and this value is used for calculating the speed. Downside of this approach is that the reported speed is still not accurate. Second approach will be to convert the time interval to microseconds instead of milliseconds, with this approach the 966490 nanosecond time interval in the above example will be converted t0 966.490usec and this value is used for calculating the speed. As compared to the current implementation and the suggested First approach, this approach will report a more accurate speed. Downside of this approach is that, in future if the mtd size is too large then the u64 variable, that holds the number of bytes, might overflow. In this patch we have gone with the second approach as this reports a more accurate speed. With this approach the eraseblock read speed in the above example comes out to be 132505 KiB/s when the spi clock is configured at 150Mhz. Signed-off-by:
Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220208103905.13354-1-amit.kumar-mahapatra@xilinx.com
-
- Feb 18, 2022
-
-
INAGAKI Hiroshi authored
Buffalo sells some router devices which have trx-formatted firmware, based on MediaTek MIPS SoCs. To use parser_trx on those devices, add "RALINK" to dependency and allow to compile for MediaTek MIPS SoCs. examples: - WCR-1166DS (MT7628) - WSR-1166DHP (MT7621) - WSR-2533DHP (MT7621) Signed-off-by:
INAGAKI Hiroshi <musashino.open@gmail.com> Signed-off-by:
-
Corentin Labbe authored
Drop mtd/cortina,gemini-flash.txt since it is nearly already handled by Documentation/devicetree/bindings/mtd/mtd-physmap.yaml. We add jedec-flash to list of compatible because one board (gemini-dlink-dns-313.dts) needs it. See commit a10d862e ("ARM: dts: Fix the DNS-313 flash compatible") The flash on the DNS-313 needs to be probed as JEDEC, it does not conform to the common CFI standard. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Julia Lawall authored
Platform_driver probe functions aren't called with locks held and thus don't need GFP_ATOMIC. Use GFP_KERNEL instead. Problem found with Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
-
Miquel Raynal authored
Topic branch bringing-in changes related to the support of ECC engines that can be used by SPI controllers to manage SPI NANDs as well as possibly by parallel NAND controllers. In particular, it brings support for Macronix ECC engine that can be used with Macronix SPI controller. The changes touch the NAND core, the NAND ECC core, the spi-mem layer, a SPI controller driver and add a new NAND ECC driver, as well as a number of binding updates. Binding changes: * Vendor prefixes: Clarify Macronix prefix * SPI NAND: Convert spi-nand description file to yaml * Raw NAND chip: Create a NAND chip description * Raw NAND controller: - Harmonize the property types - Fix a comment in the examples - Fix the reg property description * Describe Macronix NAND ECC engine * Macronix SPI controller: - Document the nand-ecc-engine property - Convert to yaml - The interrupt property is not mandatory NAND core changes: * ECC: - Add infrastructure to support hardware engines - Add a new helper to retrieve the ECC context - Provide a helper to retrieve a pilelined engine device NAND-ECC changes: * Macronix ECC engine: - Add Macronix external ECC engine support - Support SPI pipelined mode SPI-NAND core changes: * Delay a little bit the dirmap creation * Create direct mapping descriptors for ECC operations SPI-NAND driver changes: * macronix: Use random program load SPI changes: * Macronix SPI controller: - Fix the transmit path - Create a helper to configure the controller before an operation - Create a helper to ease the start of an operation - Add support for direct mapping - Add support for pipelined ECC operations * spi-mem: - Introduce a capability structure - Check the controller extra capabilities - cadence-quadspi/mxic: Provide capability structures - Kill the spi_mem_dtr_supports_op() helper - Add an ecc parameter to the spi_mem_op structure
-
- Feb 10, 2022
-
-
Miquel Raynal authored
Some SPI-NAND chips do not have a proper on-die ECC engine providing error correction/detection. This is particularly an issue on embedded devices with limited resources because all the computations must happen in software, unless an external hardware engine is provided. These external engines are new and can be of two categories: external or pipelined. Macronix is providing both, the former being already supported. The second, however, is very SoC implementation dependent and must be instantiated by the SPI host controller directly. An entire subsystem has been contributed to support these engines which makes the insertion into another subsystem such as SPI quite straightforward without the need for a lot of specific functions. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/linux-mtd/20220202144536.393792-1-miquel.raynal@bootlin.com
-
Miquel Raynal authored
Implement the ->dirmap_create() and ->dirmap_read/write() hooks to provide a fast path for read and write accesses. Signed-off-by:
Zhengxun Li <zhengxunli@mxic.com.tw> Reviewed-by:
-
Miquel Raynal authored
Create the mxic_spi_mem_prep_op_cfg() helper to provide the content to write to the register controlling the next IO command. This helper will soon be used by the dirmap implementation and having this code factorized out earlier will clarify this addition. Signed-off-by:
-
Miquel Raynal authored
Create the mxic_spi_set_hc_cfg() helper to configure the HC_CFG register. This helper will soon be used by the dirmap implementation and having this code factorized out earlier will clarify this addition. Signed-off-by:
-
Miquel Raynal authored
By working with external hardware ECC engines, we figured out that Under certain circumstances, it is needed for the SPI controller to check INT_TX_EMPTY and INT_RX_NOT_EMPTY in both receive and transmit path (not only in the receive path). The delay penalty being negligible, move this code in the common path. Fixes: b942d80b ("spi: Add MXIC controller driver") Cc: stable@vger.kernel.org Suggested-by:
Mason Yang <masonccyang@mxic.com.tw> Signed-off-by:
-
Miquel Raynal authored
In order for pipelined ECC engines to be able to enable/disable the ECC engine only when needed and avoid races when future parallel-operations will be supported, we need to provide the information about the use of the ECC engine in the direct mapping hooks. As direct mapping configurations are meant to be static, it is best to create two new mappings: one for regular 'raw' accesses and one for accesses involving correction. It is up to the driver to use or not the new ECC enable boolean contained in the spi-mem operation. As dirmaps are not free (they consume a few pages of MMIO address space) and because these extra entries are only meant to be used by pipelined engines, let's limit their use to this specific type of engine and save a bit of memory with all the other setups. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-9-miquel.raynal@bootlin.com
-
Miquel Raynal authored
As we will soon tweak the dirmap creation to act a little bit differently depending on the picked ECC engine, we need to initialize dirmaps after ECC engines. This should not have any effect as dirmaps are not yet used at this point. Signed-off-by:
-
Miquel Raynal authored
Soon the SPI-NAND core will need a way to request a SPI controller to enable ECC support for a given operation. This is because of the pipelined integration of certain ECC engines, which are directly managed by the SPI controller itself. Introduce a spi_mem_op additional field for this purpose: ecc. So far this field is left unset and checked to be false by all the SPI controller drivers in their ->supports_op() hook, as they all call spi_mem_default_supports_op(). Signed-off-by:
Pratyush Yadav <p.yadav@ti.com> Reviewed-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-7-miquel.raynal@bootlin.com
-
Miquel Raynal authored
Now that spi_mem_default_supports_op() has access to the static controller capabilities (relating to memory operations), and now that these capabilities have been filled by the relevant controllers, there is no need for a specific helper checking only DTR operations, so let's just kill spi_mem_dtr_supports_op() and simply use spi_mem_default_supports_op() instead. Signed-off-by:
-
Miquel Raynal authored
This controller has DTR support, so advertize it with a capability now that the spi-controller structure contains this new field. This will later be used by the core to discriminate whether an operation is supported or not, in a more generic way than having different helpers. Signed-off-by:
-
Miquel Raynal authored
This controller has DTR support, so advertize it with a capability now that the spi-controller structure contains this new field. This will later be used by the core to discriminate whether an operation is supported or not, in a more generic way than having different helpers. Signed-off-by:
-
Miquel Raynal authored
Controllers can now provide a spi-mem capabilities structure. Let's make use of it in spi_mem_controller_default_supports_op(). As we want to check for DTR operations as well as normal operations in a single helper, let's pull the necessary checks from spi_mem_dtr_supports_op() for now. However, because no controller provide these extra capabilities, this change has no effect so far. Signed-off-by:
-
Miquel Raynal authored
Create a spi_controller_mem_caps structure and put it within the spi_controller structure close to the spi_controller_mem_ops strucure. So far the only field in this structure is the support for dtr operations, but soon we will add another parameter. Also create a helper to parse the capabilities and check if the requested capability has been set or not. Signed-off-by:
-
Miquel Raynal authored
Introduce the support for another possible configuration: the ECC engine may work as DMA master (pipelined) and move itself the data to/from the NAND chip into the buffer, applying the necessary corrections/computations on the fly. This driver offers an ECC engine implementation that must be instatiated from a SPI controller driver. Signed-off-by:
-
- Feb 09, 2022
-
-
Miquel Raynal authored
In a pipelined engine situation, we might either have the host which internally has support for error correction, or have it using an external hardware block for this purpose. In the former case, the host is also the ECC engine. In the latter case, it is not. In order to get the right pointers on the right devices (for example: in order to devm_* allocate variables), let's introduce this helper which can safely be called by pipelined ECC engines in order to retrieve the right device structure. Signed-off-by:
-
Miquel Raynal authored
Some SPI-NAND chips do not support on-die ECC. For these chips, correction must apply on the SPI controller end. In order to avoid doing all the calculations by software, Macronix provides a specific engine that can offload the intensive work. Add Macronix ECC engine support, this engine can work in conjunction with a SPI controller and a raw NAND controller, it can be pipelined or external and supports linear and syndrome layouts. Right now the simplest configuration is supported: SPI controller external and linear ECC engine. Signed-off-by:
-
- Feb 07, 2022
-
-
Miquel Raynal authored
Reduce the number of exported symbols by replacing: - mtd_expert_analysis_warning (the error string) - mtd_expert_analysis_mode (the boolean) with a single helper: - mtd_check_expert_analysis_mode Calling this helper will both check/return the content of the internal boolean -which is not exported anymore- and as well conditionally WARN_ONCE() the user, like it was done before. While on this function, make the error string local to the helper and set it const. Only export this helper when CONFIG_DEBUG_FS is defined to limit the growth of the Linux kernel size only for a debug feature on production kernels. Mechanically update all the consumers. Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Mark Brown authored
Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e ("spi: Revert modalias changes") Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Mark Brown authored
Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e ("spi: Revert modalias changes") Signed-off-by:
-
- Feb 01, 2022
-
-
Miquel Raynal authored
On non-OF enabled platforms (CONFIG_OF is not set), of_match_node() will expand to NULL. The of_device_id array pointed by the macro will then be left unused. Let's mark the array __maybe_unused in this case to prevent compiler warnings. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/linux-mtd/20220127110802.1064963-1-miquel.raynal@bootlin.com
-
Miquel Raynal authored
of_match_ptr() either expands to NULL if !CONFIG_OF, or is transparent otherwise. There are several drivers using this macro which keep their of_device_id array enclosed within an #ifdef CONFIG_OF check, these are considered fine. However, When misused, the of_device_id array pointed by this macro will produce a warning because it is finally unused when compiled without OF support. A number of fixes are possible: - Always depend on CONFIG_OF, but this will not always work and may break boards. - Enclose the compatible array by #ifdef's, this may save a bit of memory but will reduce build coverage. - Tell the compiler the array may be unused, if this can be avoided, let's not do this. - Just drop the macro, setting the of_device_id array for a non OF enabled platform is not an issue, it will just be unused. The latter solution seems the more appropriate, so let's use it. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by:
-
- Jan 26, 2022
-
-
David Decotigny authored
With some spi devices, the heavy cpu usage due to polling the spi registers may lead to netdev timeouts, RCU complaints, etc. This can be acute in the absence of CONFIG_PREEMPT. This patch allows to give enough breathing room to avoid those incorrectly detected netdev timeouts for example. Example splat on 5.10.92: [ 828.399306] rcu: INFO: rcu_sched self-detected stall on CPU ... [ 828.419245] Task dump for CPU 1: [ 828.422465] task:kworker/1:1H state:R running task on cpu 1 stack: 0 pid: 76 ppid: 2 flags:0x0000002a [ 828.433132] Workqueue: kblockd blk_mq_run_work_fn [ 828.437820] Call trace: ... [ 828.512267] spi_mem_exec_op+0x4d0/0xde0 [ 828.516184] spi_mem_dirmap_read+0x180/0x39c [ 828.520443] spi_nor_read_data+0x428/0x7e8 [ 828.524523] spi_nor_read+0x154/0x214 [ 828.528172] mtd_read_oob+0x440/0x714 [ 828.531815] mtd_read+0xac/0x120 [ 828.535030] mtdblock_readsect+0x178/0x230 [ 828.539102] mtd_blktrans_work+0x9fc/0xf28 [ 828.543177] mtd_queue_rq+0x1ac/0x2e4 [ 828.546827] blk_mq_dispatch_rq_list+0x2cc/0xa44 [ 828.551419] blk_mq_do_dispatch_sched+0xb0/0x7cc [ 828.556010] __blk_mq_sched_dispatch_requests+0x350/0x494 [ 828.561372] blk_mq_sched_dispatch_requests+0xac/0xe4 [ 828.566387] __blk_mq_run_hw_queue+0x130/0x254 [ 828.570806] blk_mq_run_work_fn+0x50/0x60 [ 828.574814] process_one_work+0x578/0xf1c [ 828.578814] worker_thread+0x5dc/0xea0 [ 828.582547] kthread+0x270/0x2d4 [ 828.585765] ret_from_fork+0x10/0x30 Signed-off-by:
David Decotigny <ddecotig@google.com> Reviewed-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
- Jan 23, 2022
-
-
Patrick Williams authored
The aspeed-smc can have multiple SPI devices attached to it in the device tree. If one of the devices is missing or failing the entire probe will fail and all MTD devices under the controller will be removed. On OpenBMC this results in a kernel panic due to missing rootfs: [ 0.538774] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency [ 0.540471] aspeed-smc 1e620000.spi: w25q01jv-iq (131072 Kbytes) [ 0.540750] aspeed-smc 1e620000.spi: CE0 window [ 0x20000000 - 0x28000000 ] 128MB [ 0.540943] aspeed-smc 1e620000.spi: CE1 window [ 0x28000000 - 0x2c000000 ] 64MB [ 0.541143] aspeed-smc 1e620000.spi: read control register: 203b0041 [ 0.581442] 5 fixed-partitions partitions found on MTD device bmc [ 0.581625] Creating 5 MTD partitions on "bmc": [ 0.581854] 0x000000000000-0x0000000e0000 : "u-boot" [ 0.584472] 0x0000000e0000-0x000000100000 : "u-boot-env" [ 0.586468] 0x000000100000-0x000000a00000 : "kernel" [ 0.588465] 0x000000a00000-0x000006000000 : "rofs" [ 0.590552] 0x000006000000-0x000008000000 : "rwfs" [ 0.592605] aspeed-smc 1e620000.spi: Using 50 MHz SPI frequency [ 0.592801] aspeed-smc 1e620000.spi: unrecognized JEDEC id bytes: 00 00 00 00 00 00 [ 0.593039] Deleting MTD partitions on "bmc": [ 0.593175] Deleting u-boot MTD partition [ 0.637929] Deleting u-boot-env MTD partition [ 0.829527] Deleting kernel MTD partition [ 0.856902] Freeing initrd memory: 1032K [ 0.866428] Deleting rofs MTD partition [ 0.906264] Deleting rwfs MTD partition [ 0.986628] aspeed-smc 1e620000.spi: Aspeed SMC probe failed -2 [ 0.986929] aspeed-smc: probe of 1e620000.spi failed with error -2 ... [ 2.936719] /dev/mtdblock: Can't open blockdev mount: mounting /dev/mtdblock on run/initramfs/ro failed: No such file or directory [ 2.963030] MTD: Couldn't look up '/dev/mtdblock': -2 mount: mounting /dev/mtdblock on run/initramfs/rw failed: No such file or directory Mounting read-write /dev/mtdblock filesystem failed. Please fix and run mount /dev/mtdblock run/initramfs/rw -t jffs2 -o rw or perform a factory reset with the clean-rwfs-filesystem option. Fatal error, triggering kernel panic! [ 3.013047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 Many BMC designs have two flash chips so that they can handle a hardware failure of one of them. If one chip failed, it doesn't do any good to have redundancy if they all get removed anyhow. Improve the resilience of the probe function to handle one of the children being missing or failed. Only in the case where all children fail to probe should the controller be failed out. Signed-off-by:
Patrick Williams <patrick@stwcx.xyz> Signed-off-by:
-
Miquel Raynal authored
Introduce nand_to_ecc_ctx() which will allow to easily jump to the private pointer of an ECC context given a NAND device. This is very handy, from the prepare or finish ECC hook, to get the internal context out of the NAND device object. Signed-off-by:
-
Miquel Raynal authored
Add the necessary helpers to register/unregister hardware ECC engines that will be called from ECC engine drivers. Also add helpers to get the right engine from the user perspective. Keep a reference of the in use ECC engine in order to prevent modules to be unloaded. Put the reference when the engine gets retired. A static list of hardware (only) ECC engines is setup to keep track of the registered engines. Signed-off-by:
-
Mason Yang authored
Macronix SPI-NAND chips might benefit from an external ECC engine. Such an engine might need to access random columns, thus needing to use random commands (0x84 instead of 0x02). Signed-off-by:
-
Miquel Raynal authored
Describe Macronix NAND ECC engine. This engine may be used as an external engine or can be pipelined with either a raw NAND controller or a SPI controller. Both hardware designs with a SPI controller are shown in the examples. Signed-off-by:
-
Miquel Raynal authored
This SPI controller supports interacting with an external ECC engine. The nand-ecc-engine property already exist in the NAND world but also applies to SPI controller nodes which have external correction capabilities like Macronix's. Signed-off-by:
-
Miquel Raynal authored
Straightforward conversion from regular text to yaml schema of the Macronix SPI controller DT bindings. Signed-off-by:
-
Miquel Raynal authored
The interrupt property is not mandatory at all, this property should not be part of the required properties list, so move it into the optional properties list. Fixes: 326e5c8d ("dt-binding: spi: Document Macronix controller bindings") Signed-off-by:
-
Miquel Raynal authored
When looking at compatible prefixes, Macronix is sometimes referred as "mxicy": - mxicy,mx25r1635f - mxicy,mx25u6435f - mxicy,mx25v8035f - mxicy,mx25f0a-spi and sometimes as "mxic": - mxic,multi-itfc-v009-nand-controller - mxic,enable-randomizer-otp The oldest prefix that is also the one preferred by Macronix engineers is "mxicy", so document the other one and mark it deprecated. Signed-off-by:
-
Miquel Raynal authored
Let's get rid of spi-nand.txt by converting it to yaml schema. While at converting this file, let's actually pull all the generic properties from nand-chip.yaml which might apply to a SPI-NAND chip. Signed-off-by:
-
Miquel Raynal authored
Move the NAND chip description out of the NAND controller file. Indeed, a subsequent part of the properties supported by a raw NAND chip are also supported by SPI-NAND chips. So let's create a generic NAND chip description which will be pulled by nand-controller.yaml and later by spi-nand.yaml as well. Signed-off-by:
-
Miquel Raynal authored
Harmonize the different properties in this file by: * dropping the non-necessary allOf's * always defining the keywords in the following order: - first the "description" (when relevant), - then the "type"/"$ref" and the other generic keywords ("enum", "default", etc). Signed-off-by: -
Miquel Raynal authored
The controller properties should be in the controller 'parent' node, while properties in the children nodes are specific to the NAND *chip*. This error was already present during the yaml conversion. Fixes: 2d472aba ("mtd: nand: document the NAND controller/NAND chip DT representation") Signed-off-by:
-
