#
29895ce1 |
|
13-Mar-2024 |
Florian Fainelli <florian.fainelli@broadcom.com> |
spi: Fix error code checking in spi_mem_exec_op() After commit cff49d58f57e ("spi: Unify error codes by replacing -ENOTSUPP with -EOPNOTSUPP"), our SPI NOR flashes would stop probing with the following visible in the kernel log: [ 2.196300] brcmstb_qspi f0440920.qspi: using bspi-mspi mode [ 2.210295] spi-nor: probe of spi1.0 failed with error -95 It turns out that the check in spi_mem_exec_op() was changed to check for -ENOTSUPP (old error code) or -EOPNOTSUPP (new error code), but this means that for drivers that were converted, the second condition is now true, and we stop falling through like we used to. Fix the error to check for neither error being neither -ENOTSUPP *nor* -EOPNOTSUPP. Fixes: cff49d58f57e ("spi: Unify error codes by replacing -ENOTSUPP with -EOPNOTSUPP") Reviewed-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240313194530.3150446-1-florian.fainelli@broadcom.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e63aef9c |
|
16-Feb-2024 |
Théo Lebrun <theo.lebrun@bootlin.com> |
spi: spi-mem: add statistics support to ->exec_op() calls Current behavior is that spi-mem operations do not increment statistics, neither per-controller nor per-device, if ->exec_op() is used. For operations that do NOT use ->exec_op(), stats are increased as the usual spi_sync() is called. The newly implemented spi_mem_add_op_stats() function is strongly inspired by spi_statistics_add_transfer_stats(); locking logic and l2len computation comes from there. Statistics that are being filled: bytes{,_rx,_tx}, messages, transfers, errors, timedout, transfer_bytes_histo_*. Note about messages & transfers counters: in the fallback to spi_sync() case, there are from 1 to 4 transfers per message. We only register one big transfer in the ->exec_op() case as that is closer to reality. This patch is NOT touching: - spi_async, spi_sync, spi_sync_immediate: those counters describe precise function calls, incrementing them would be lying. I believe comparing the messages counter to spi_async+spi_sync is a good way to detect ->exec_op() calls, but I might be missing edge cases knowledge. - transfers_split_maxsize: splitting cannot happen if ->exec_op() is provided. Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://msgid.link/r/20240216-spi-mem-stats-v2-1-9256dfe4887d@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
cff49d58 |
|
28-Nov-2023 |
Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> |
spi: Unify error codes by replacing -ENOTSUPP with -EOPNOTSUPP This commit updates the SPI subsystem, particularly affecting "SPI MEM" drivers and core parts, by replacing the -ENOTSUPP error code with -EOPNOTSUPP. The key motivations for this change are as follows: 1. The spi-nor driver currently uses EOPNOTSUPP, whereas calls to spi-mem might return ENOTSUPP. This update aims to unify the error reporting within the SPI subsystem for clarity and consistency. 2. The use of ENOTSUPP has been flagged by checkpatch as inappropriate, mainly being reserved for NFS-related errors. To align with kernel coding standards and recommendations, this change is being made. 3. By using EOPNOTSUPP, we provide more specific context to the error, indicating that a particular operation is not supported. This helps differentiate from the more generic ENOTSUPP error, allowing drivers to better handle and respond to different error scenarios. Risks and Considerations: While this change is primarily intended as a code cleanup and error code unification, there is a minor risk of breaking user-space applications that rely on specific return codes for unsupported operations. However, this risk is considered low, as such use-cases are unlikely to be common or critical. Nevertheless, developers and users should be aware of this change, especially if they have scripts or tools that specifically handle SPI error codes. This commit does not introduce any functional changes to the SPI subsystem or the affected drivers. Signed-off-by: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20231129064311.272422-1-acelan.kao@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9e264f3f |
|
10-Mar-2023 |
Amit Kumar Mahapatra via Alsa-devel <alsa-devel@alsa-project.org> |
spi: Replace all spi->chip_select and spi->cs_gpiod references with function call Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references with get or set API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> # Rockchip drivers Reviewed-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> # Aspeed driver Reviewed-by: Dhruva Gole <d-gole@ti.com> # SPI Cadence QSPI Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> # spi-stm32-qspi Acked-by: William Zhang <william.zhang@broadcom.com> # bcm63xx-hsspi driver Reviewed-by: Serge Semin <fancer.lancer@gmail.com> # DW SSI part Link: https://lore.kernel.org/r/167847070432.26.15076794204368669839@mailman-core.alsa-project.org Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
76a85704 |
|
09-Feb-2023 |
William Zhang <william.zhang@broadcom.com> |
spi: spi-mem: Allow controller supporting mem_ops without exec_op Currently exec_op is always required if controller driver provides mem_ops. But some controller such as bcm63xx-hsspi may only need to implement other operation like supports_op and use the default execution operation. This patch removes this restriction. Signed-off-by: William Zhang <william.zhang@broadcom.com> Link: https://lore.kernel.org/r/20230209200246.141520-13-william.zhang@broadcom.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2283679f |
|
02-Jun-2022 |
Patrice Chotard <patrice.chotard@foss.st.com> |
spi: spi-mem: Fix spi_mem_poll_status() In spi_mem_exec_op(), in case cs_gpiod descriptor is set, exec_op() callback can't be used. The same must be applied in spi_mem_poll_status(), poll_status() callback can't be used, we must use the legacy path using read_poll_timeout(). Tested on STM32mp257c-ev1 specific evaluation board on which a spi-nand was mounted instead of a spi-nor. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://lore.kernel.org/r/20220602091022.358127-1-patrice.chotard@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
8868c03f |
|
20-Apr-2022 |
Pratyush Yadav <p.yadav@ti.com> |
spi: spi-mem: check if data buffers are on stack The buffers passed in the data phase must be DMA-able. Programmers often don't realise this requirement and pass in buffers that reside on the stack. This can be hard to spot when reviewing code. Reject ops if their data buffer is on the stack to avoid this. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20220420102022.3310970-1-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3a2ac580 |
|
13-Apr-2022 |
Minghao Chi <chi.minghao@zte.com.cn> |
spi: spi-cadence-quadspi: using pm_runtime_resume_and_get instead of pm_runtime_get_sync Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20220413093656.2538504-1-chi.minghao@zte.com.cn Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a433c2cb |
|
27-Jan-2022 |
Miquel Raynal <miquel.raynal@bootlin.com> |
spi: spi-mem: Add an ecc parameter to the spi_mem_op structure 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: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-7-miquel.raynal@bootlin.com
|
#
9a15efc5 |
|
27-Jan-2022 |
Miquel Raynal <miquel.raynal@bootlin.com> |
spi: spi-mem: Kill the spi_mem_dtr_supports_op() helper 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 <miquel.raynal@bootlin.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-6-miquel.raynal@bootlin.com
|
#
cb7e96ee |
|
27-Jan-2022 |
Miquel Raynal <miquel.raynal@bootlin.com> |
spi: spi-mem: Check the controller extra capabilities 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 <miquel.raynal@bootlin.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/linux-mtd/20220127091808.1043392-3-miquel.raynal@bootlin.com
|
#
a0386bba |
|
23-Jan-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
spi: make remove callback a void function The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Claudius Heine <ch@denx.de> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC Acked-by: Marcus Folkesson <marcus.folkesson@gmail.com> Acked-by: Łukasz Stelmach <l.stelmach@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
3acbacfc |
|
01-Jun-2021 |
Yang Yingliang <yangyingliang@huawei.com> |
spi: spi-mem: fix doc warning in spi-mem.c Fix the following make W=1 warning: drivers/spi/spi-mem.c:819: warning: expecting prototype for spi_mem_driver_unregister_with_owner(). Prototype was for spi_mem_driver_unregister() instead Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210601120721.3198488-1-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c955a0cc |
|
18-May-2021 |
Patrice Chotard <patrice.chotard@foss.st.com> |
spi: spi-mem: add automatic poll status functions With STM32 QSPI, it is possible to poll the status register of the device. This could be done to offload the CPU during an operation (erase or program a SPI NAND for example). spi_mem_poll_status API has been added to handle this feature. This new function take care of the offload/non-offload cases. For the non-offload case, use read_poll_timeout() to poll the status in order to release CPU during this phase. For example, previously, when erasing large area, in non-offload case, CPU load can reach ~50%, now it decrease to ~35%. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://lore.kernel.org/r/20210518162754.15940-2-patrice.chotard@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
6ca6ad90 |
|
24-Mar-2021 |
Jay Fang <f.fangjian@huawei.com> |
spi: spi-mem: Fix code indent should use tabs where possible Fix checkpatch errors: ERROR: code indent should use tabs where possible #624: FILE: spi-mem.c:624: ERROR: code indent should use tabs where possible #626: FILE: spi-mem.c:626: ERROR: code indent should use tabs where possible #627: FILE: spi-mem.c:627: Signed-off-by: Jay Fang <f.fangjian@huawei.com> Link: https://lore.kernel.org/r/1616566602-13894-10-git-send-email-f.fangjian@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
539cf68c |
|
04-Feb-2021 |
Pratyush Yadav <p.yadav@ti.com> |
spi: spi-mem: add spi_mem_dtr_supports_op() spi_mem_default_supports_op() rejects DTR ops by default to ensure that the controller drivers that haven't been updated with DTR support continue to reject them. It also makes sure that controllers that don't support DTR mode at all (which is most of them at the moment) also reject them. This means that controller drivers that want to support DTR mode can't use spi_mem_default_supports_op(). Driver authors have to roll their own supports_op() function and mimic the buswidth checks. See spi-cadence-quadspi.c for example. Or even worse, driver authors might skip it completely or get it wrong. Add spi_mem_dtr_supports_op(). It provides a basic sanity check for DTR ops and performs the buswidth requirement check. Move the logic for checking buswidth in spi_mem_default_supports_op() to a separate function so the logic is not repeated twice. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20210204141218.32229-1-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
98621ed0 |
|
21-Dec-2020 |
Sowjanya Komatineni <skomatineni@nvidia.com> |
spi: spi-mem: Mark dummy transfers by setting dummy_data bit This patch marks dummy transfer by setting dummy_data bit to 1. Controllers supporting dummy transfer by hardware use this bit field to skip software transfer of dummy bytes and use hardware dummy bytes transfer. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1608585459-17250-6-git-send-email-skomatineni@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c02bb16b |
|
03-Nov-2020 |
Zhang Qilong <zhangqilong3@huawei.com> |
spi: spi-mem: fix reference leak in spi_mem_access_start pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in spi_mem_access_start, so we should fix it. Fixes: f86c24f479530 ("spi: spi-mem: Split spi_mem_exec_op() code") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201103140910.3482-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
a9c52d42 |
|
30-Oct-2020 |
YueHaibing <yuehaibing@huawei.com> |
spi: spi-mem: Fix passing zero to 'PTR_ERR' warning Fix smatch warning: drivers/spi/spi-mem.c:746 spi_mem_probe() warn: passing zero to 'PTR_ERR' Fixes: 5d27a9c8ea9e ("spi: spi-mem: Extend the SPI mem interface to set a custom memory name") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20201031033042.42892-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
caf72df4 |
|
23-Jun-2020 |
Pratyush Yadav <p.yadav@ti.com> |
spi: spi-mem: allow specifying a command's extension In xSPI mode, flashes expect 2-byte opcodes. The second byte is called the "command extension". There can be 3 types of extensions in xSPI: repeat, invert, and hex. When the extension type is "repeat", the same opcode is sent twice. When it is "invert", the second byte is the inverse of the opcode. When it is "hex" an additional opcode byte based is sent with the command whose value can be anything. So, make opcode a 16-bit value and add a 'nbytes', similar to how multiple address widths are handled. Some places use sizeof(op->cmd.opcode). Replace them with op->cmd.nbytes The spi-mxic and spi-zynq-qspi drivers directly use op->cmd.opcode as a buffer. Now that opcode is a 2-byte field, this can result in different behaviour depending on if the machine is little endian or big endian. Extract the opcode in a local 1-byte variable and use that as the buffer instead. Both these drivers would reject multi-byte opcodes in their supports_op() hook anyway, so we only need to worry about single-byte opcodes for now. The above two changes are put in this commit to keep the series bisectable. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200623183030.26591-3-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4c5e2bba |
|
23-Jun-2020 |
Pratyush Yadav <p.yadav@ti.com> |
spi: spi-mem: allow specifying whether an op is DTR or not Each phase is given a separate 'dtr' field so mixed protocols like 4S-4D-4D can be supported. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200623183030.26591-2-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
80300a7d |
|
15-Apr-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
spi: spi-mem: Fix Dual/Quad modes on Octal-capable devices Currently buswidths 2 and 4 are rejected for a device that advertises Octal capabilities. Allow these buswidths, just like is done for buswidth 2 and Quad-capable devices. Fixes: b12a084c8729ef42 ("spi: spi-mem: add support for octal mode I/O data transfer") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200416101418.14379-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c0e035ac |
|
28-Feb-2020 |
Tudor Ambarus <tudor.ambarus@microchip.com> |
spi: spi-mem: Compute length only when needed When adjust_op_size is defined, len is never used. Move the len computation where it's actually used. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200228160735.1565047-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
32a9d054 |
|
16-Feb-2020 |
Tudor Ambarus <tudor.ambarus@microchip.com> |
spi: spi-mem: Fix typo, s/fallback/falls back "Fallback" in one word is a noun. "Fall back" is two separate words, a verb and an adverb. Use the latter. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200216214012.1106658-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
05766050 |
|
06-Nov-2019 |
Chris Packham <chris.packham@alliedtelesis.co.nz> |
spi: spi-mem: fallback to using transfers when CS gpios are used Devices with chip selects driven via GPIO are not compatible with the spi-mem operations. Fallback to using standard spi transfers when the device is connected with a gpio CS. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20191107044235.4864-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
9d8371e2 |
|
06-Apr-2019 |
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> |
spi-mem: fix kernel-doc for spi_mem_dirmap_{read|write}() The function names in the kernel-doc comments were mistyped, with a word "dirmap" being repeated twice, so fix them. Fixes: aa167f3fed0c ("spi: spi-mem: Add a new API to support direct mapping") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
46109648 |
|
01-Apr-2019 |
Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> |
spi: spi-mem: export spi_mem_default_supports_op() Export spi_mem_default_supports_op(), so that controller drivers can use this. spi-mem driver already exports this using EXPORT_SYMBOL, but not declared it in spi-mem.h. This patch declares spi_mem_default_supports_op() in spi-mem.h and also removes the static from the function prototype. Signed-off-by: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
1fc1b636 |
|
19-Jan-2019 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Add devm_spi_mem_dirmap_{create,destroy}() Since direct mapping descriptors usually the same lifetime as the SPI MEM device adding devm_ variants of the spi_mem_dirmap_{create,destroy}() should greatly simplify error/remove path of spi-mem drivers making use of the direct mapping API. Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
bfecfd6e |
|
19-Jan-2019 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Fix a memory leak in spi_mem_dirmap_destroy() The dirmap descriptor object allocated in spi_mem_dirmap_create is never freed. Add a kfree(desc) in spi_mem_dirmap_destroy(). Fixes: aa167f3fed0c ("spi: spi-mem: Add a new API to support direct mapping") Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5c0c4ec9 |
|
19-Jan-2019 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Fix spi_mem_dirmap_destroy() kerneldoc spi_mem_dirmap_destroy() takes a single argument, remove the @info entry in the doc. Fixes: aa167f3fed0c ("spi: spi-mem: Add a new API to support direct mapping") Signed-off-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
b12a084c |
|
03-Dec-2018 |
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> |
spi: spi-mem: add support for octal mode I/O data transfer Add support for octal mode I/O data transfer in spi-mem framework. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
aa167f3f |
|
06-Nov-2018 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Add a new API to support direct mapping Most modern SPI controllers can directly map a SPI memory (or a portion of the SPI memory) in the CPU address space. Most of the time this brings significant performance improvements as it automates the whole process of sending SPI memory operations every time a new region is accessed. This new API allows SPI memory drivers to create direct mappings and then use them to access the memory instead of using spi_mem_exec_op(). Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
f86c24f4 |
|
06-Nov-2018 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Split spi_mem_exec_op() code The logic surrounding the ->exec_op() call applies to direct mapping accessors. Move this code to separate functions to avoid duplicating code. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0ebb261a |
|
06-Nov-2018 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Add SPI_MEM_NO_DATA to the spi_mem_data_dir enum When defining spi_mem_op templates we don't necessarily know the size that will be passed when the template is actually used, and basing the supports_op() check on op->data.nbytes to know whether there will be data transferred for a specific operation is this not possible. Add SPI_MEM_NO_DATA to the spi_mem_data_dir enum so that we can base our checks on op->data.dir instead of op->data.nbytes. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
aea3877e |
|
25-Sep-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
spi: spi-mem: Fix inverted logic in op sanity check On r8a7791/koelsch: m25p80 spi0.0: error -22 reading 9f m25p80: probe of spi0.0 failed with error -22 Apparently the logic in spi_mem_check_op() is wrong, rejecting the spi-mem operation if any buswidth is valid, instead of invalid. Fixes: 380583227c0c7f52 ("spi: spi-mem: Add extra sanity checks on the op param") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
38058322 |
|
20-Sep-2018 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: spi-mem: Add extra sanity checks on the op param Some combinations are simply not valid and should be rejected before the op is passed to the SPI controller driver. Add an spi_mem_check_op() helper and use it in spi_mem_exec_op() and spi_mem_supports_op() to make sure the spi-mem operation is valid. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
e757996c |
|
30-Aug-2018 |
Chuanhua Han <chuanhua.han@nxp.com> |
spi: spi-mem: Adjust op len based on message/transfer size limitations We need that to adjust the len of the 2nd transfer (called data in spi-mem) if it's too long to fit in a SPI message or SPI transfer. Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory controllers") Cc: <stable@vger.kernel.org> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
5d27a9c8 |
|
02-Aug-2018 |
Frieder Schrempf <frieder.schrempf@exceet.de> |
spi: spi-mem: Extend the SPI mem interface to set a custom memory name When porting (Q)SPI controller drivers from the MTD layer to the SPI layer, the naming scheme for the memory devices changes. To be able to keep compatibility with the old drivers naming scheme, a name field is added to struct spi_mem and a hook is added to let controller drivers set a custom name for the memory device. Example for the FSL QSPI driver: Name with the old driver: 21e0000.qspi, or with multiple devices: 21e0000.qspi-0, 21e0000.qspi-1, ... Name with the new driver without spi_mem_get_name: spi4.0 Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
c36ff266 |
|
26-Apr-2018 |
Boris Brezillon <bbrezillon@kernel.org> |
spi: Extend the core to ease integration of SPI memory controllers Some controllers are exposing high-level interfaces to access various kind of SPI memories. Unfortunately they do not fit in the current spi_controller model and usually have drivers placed in drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI memories in general. This is an attempt at defining a SPI memory interface which works for all kinds of SPI memories (NORs, NANDs, SRAMs). Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
|