As the chip selects can be configured through ACPI/OF/swnode, and
the set_cs() callback will only be called when a native chip select
is being used, there is no reason for the driver to only support the
native chip select as the first chip select. Remove the check that
introduces this limitation.
Fixes: ef75e76716 ("spi: cs42l43: Add SPI controller support")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://msgid.link/r/20240306161004.2205113-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
One patch of a series of three that was sent fixing issues with the
ppc4xx driver was targeted at -next, unfortunately it being sandwiched
between two others that targeted mainline tripped up my workflow and
caused it to get merged along with the others. The ppc4xx driver is
only buildable in very limited configurations so none of the CI catches
issues with it.
Fixes: de4af897dd ("spi: ppc4xx: Fix fallout from rename in struct spi_bitbang")
Signed-off-by: Mark Brown <broonie@kernel.org>
Each SPI controller is expected to call the spi_controller_suspend() and
spi_controller_resume() callbacks at system-wide suspend and resume.
It (1) handles the kthread worker for queued controllers and (2) marks
the controller as suspended to have spi_sync() fail while the
controller is unavailable.
Those two operations do not require the controller to be active, we do
not need to increment the runtime PM usage counter.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-4-6b6af8bcbf59@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Follow kernel naming convention with regards to power-management
callback function names.
The convention in the kernel is:
- prefix_suspend means the system-wide suspend callback;
- prefix_runtime_suspend means the runtime PM suspend callback.
The same applies to resume callbacks.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-3-6b6af8bcbf59@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ->runtime_suspend() and ->runtime_resume() callbacks are not
expected to call spi_controller_suspend() and spi_controller_resume().
Remove calls to those in the cadence-qspi driver.
Those helpers have two roles currently:
- They stop/start the queue, including dealing with the kworker.
- They toggle the SPI controller SPI_CONTROLLER_SUSPENDED flag. It
requires acquiring ctlr->bus_lock_mutex.
Step one is irrelevant because cadence-qspi is not queued. Step two
however has two implications:
- A deadlock occurs, because ->runtime_resume() is called in a context
where the lock is already taken (in the ->exec_op() callback, where
the usage count is incremented).
- It would disallow all operations once the device is auto-suspended.
Here is a brief call tree highlighting the mutex deadlock:
spi_mem_exec_op()
...
spi_mem_access_start()
mutex_lock(&ctlr->bus_lock_mutex)
cqspi_exec_mem_op()
pm_runtime_resume_and_get()
cqspi_resume()
spi_controller_resume()
mutex_lock(&ctlr->bus_lock_mutex)
...
spi_mem_access_end()
mutex_unlock(&ctlr->bus_lock_mutex)
...
Fixes: 0578a6dbfe ("spi: spi-cadence-quadspi: add runtime pm support")
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-2-6b6af8bcbf59@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dev_get_drvdata() gets used to acquire the pointer to cqspi and the SPI
controller. Neither embed the other; this lead to memory corruption.
On a given platform (Mobileye EyeQ5) the memory corruption is hidden
inside cqspi->f_pdata. Also, this uninitialised memory is used as a
mutex (ctlr->bus_lock_mutex) by spi_controller_suspend().
Fixes: 2087e85bb6 ("spi: cadence-quadspi: fix suspend-resume implementations")
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://msgid.link/r/20240222-cdns-qspi-pm-fix-v4-1-6b6af8bcbf59@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There was a change in the mxs-dma engine that uses a new custom flag.
The change was not applied to the mxs spi driver.
This results in chipselect being deasserted too early.
This fixes the chipselect problem by using the new flag in the mxs-spi
driver.
Fixes: ceeeb99cd8 ("dmaengine: mxs: rename custom flag")
Signed-off-by: Ralf Schlatterbeck <rsc@runtux.com>
Link: https://msgid.link/r/20240202115330.wxkbfmvd76sy3a6a@runtux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add Intel Lunar Lake-M PCI ID to the driver list of supported devices.
This is the same controller found in previous generations.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://msgid.link/r/20240212082027.2462849-1-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MCSPI controller have few limitations regarding the transaction
size when the FIFO buffer is enabled and the WCNT feature is used
to find the end of word, in this case if WCNT is not a multiple of
the FIFO Almost Empty Level (AEL), then the FIFO empty event is not
generated correctly. In addition to this limitation, few other unknown
sequence of events that causes the FIFO empty status to not reflect the
exact status were found when FIFO is being used without DMA enabled
during extended testing in AM65x platform. Till the exact root cause
is found and fixed, revert the FIFO support without DMA.
See J721E Technical Reference Manual (SPRUI1C), section 12.1.5
for further details: http://www.ti.com/lit/pdf/spruil1
This reverts commit 75223bbea8 ("spi: omap2-mcspi: Add FIFO support
without DMA")
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Link: https://msgid.link/r/20240212120049.438495-1-vaishnav.a@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 24778be20f ("spi: convert drivers to use
bits_per_word_mask") the bits_per_word variable is only written to. The
check that was there before isn't needed any more as the spi core
ensures that only 8 bit transfers are used, so the variable can go away
together with all assignments to it.
Fixes: 24778be20f ("spi: convert drivers to use bits_per_word_mask")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240210164006.208149-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver uses several symbols declared in <linux/platform_device.h>,
e.g module_platform_driver(). Include this header explicitly now that
<linux/of_platform.h> doesn't include <linux/platform_device.h> any
more.
Fixes: ef175b29a2 ("of: Stop circularly including of_device.h and of_platform.h")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240210164006.208149-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
the driver currently fails to compile on 6.8-rc3 due to:
| spi-ppc4xx.c: In function ‘spi_ppc4xx_of_probe’:
| @346:36: error: invalid use of undefined type ‘struct platform_device’
| 346 | struct device_node *np = op->dev.of_node;
| | ^~
| ... (more similar errors)
it was working with 6.7. Looks like it only needed the include
and its compiling fine!
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://lore.kernel.org/r/3eb3f9c4407ba99d1cd275662081e46b9e839173.1707490664.git.chunkeey@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For DMA mode, the bus width of the DMA is equal to the size of data
word, so burst length should be configured as bits per word.
For CPU mode, because of the spi transfer len is in byte, so calculate
the total number of words according to spi transfer len and bits per
word, burst length should be configured as total data bits.
Signed-off-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Clark Wang <xiaoning.wang@nxp.com>
Fixes: e9b220aeac ("spi: spi-imx: correctly configure burst length when using dma")
Fixes: 5f66db08cb ("spi: imx: Take in account bits per word instead of assuming 8-bits")
Link: https://lore.kernel.org/r/20240204091912.36488-1-carlos.song@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In __spi_pump_transfer_message(), the message was not finalized in the
first error return as it is in the other error return paths. Not
finalizing the message could cause anything waiting on the message to
complete to hang forever.
This adds the missing call to spi_finalize_current_message().
Fixes: ae7d2346dc ("spi: Don't use the message queue if possible in spi_sync")
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://msgid.link/r/20240125205312.3458541-2-dlechner@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As it devm_pm_runtime_enable can fail due to memory allocations, it is
best to handle the error.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://msgid.link/r/20240124174101.2270249-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Return IRQ_NONE from the interrupt handler when no interrupt was
detected. Because an empty interrupt will cause a null pointer error:
Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000008
Call trace:
complete+0x54/0x100
hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
__handle_irq_event_percpu+0x64/0x1e0
handle_irq_event+0x7c/0x1cc
Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
Link: https://msgid.link/r/20240123071149.917678-1-liudingyuan@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the existing implementation, when executing interleaved write and read
operations in the ISR for a transfer length greater than the FIFO size,
the TXFIFO write precedes the RXFIFO read. Consequently, the initially
received data in the RXFIFO is pushed out and lost, leading to a failure
in data integrity. To address this issue, reverse the order of interleaved
operations and conduct the RXFIFO read followed by the TXFIFO write.
Fixes: 6afe2ae8dc ("spi: spi-cadence: Interleave write of TX and read of RX FIFO")
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Link: https://msgid.link/r/20231218090652.18403-1-amit.kumar-mahapatra@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If dma_request_chan() fails, no error is shown nor any information is
shown in /sys/kernel/debug/devices_deferred if -EPROBE_DEFER is returned.
Use dev_err_probe to fix both problems.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://msgid.link/r/20240110085403.457089-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SFDP read shall use the mspi reads when using the bcm_qspi_exec_mem_op()
call. This fixes SFDP parameter page read failures seen with parts that
now use SFDP protocol to read the basic flash parameter table.
Fixes: 5f195ee7d8 ("spi: bcm-qspi: Implement the spi_mem interface")
Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://msgid.link/r/20240109210033.43249-1-kamal.dasu@broadcom.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds the PCI ID of the Arrow Lake and Meteor Lake-S PCH SPI serial
flash controller. This one supports all the necessary commands Linux
SPI-NOR stack requires.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://msgid.link/r/20240122120034.2664812-3-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Turns out this "SoC" side controller does not support certain commands,
such as reading chip JEDEC ID, so the controller is pretty much unusable
in Linux. We should be using the "PCH" side controller instead. For this
reason remove this PCI ID from the list.
Fixes: c2912d42e8 ("spi: intel-pci: Add support for Meteor Lake-S SPI serial flash")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://msgid.link/r/20240122120034.2664812-2-mika.westerberg@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
One simple fix for the device unbind path in the Coldfire driver, a
conversion to use a combined get/enable helper missed removing a
disable.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmWqeNEACgkQJNaLcl1U
h9DsPAf9F6R65f13vl6xA5GJELv1oyC8/K+4qJLbn4PmJ04c7mBTEerSiAvXeuEn
aRcbEr7bUFyv3g86splGi23kHIboZv3NJxXxVVktiACfmMlALCdq3s5gl57xIgQr
e4ATBXrljxX1WI8/AdLRYLRSANqf92AQBbtPOwHMhXG2jfpIHTn6MsGvPHfoemrQ
vIApyPhvv0Deyd1W4F3T+2uIieS96eyqIF9iyiVWU9qzq7+3zxy0fUV29oipyZLg
mdWINBKMYBwUekrY/5gF9pOEENr3zSiK+YSIjKLWEFAvg65HmPDaP6qNBXo/vCKT
AszXDCb8wQEjkqE8n45yDdpVc7CZbg==
=EyrR
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v6.8-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fix from Mark Brown:
"One simple fix for the device unbind path in the Coldfire driver.
A conversion to use a combined get/enable helper missed removing a
disable"
* tag 'spi-fix-v6.8-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: coldfire-qspi: Remove an erroneous clk_disable_unprepare() from the remove function
A moderately busy release for SPI, the main core update was the merging
of support for multiple chip selects, used in some flash configurations.
There were also big overhauls for the AXI SPI Engine and PL022 drivers,
plus some new device support for ST.
There's a few patches for other trees, API updates to allow the
multiple chip select support and one of the naming modernisations
touched a controller embedded in the USB code.
- Support for multiple chip selects.
- A big overhaul for the AXI SPI engine driver, modernising it and
adding a bunch of new features.
- Modernisation of the PL022 driver, fixing some issues with submitting
messages while in atomic context in the process.
- Many drivers were converted to use new APIs which avoid outdated
terminology for devices and controllers.
- Support for ST Microelectronics STM32F7 and STM32MP25, and Renesas
RZ/Five.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmWbHmMACgkQJNaLcl1U
h9CpSwf+O981469g1twyEpq5PJlNgdXmrKUpezcC18X4DLXmlf5hoCsHUFIU2DuX
oBZuUQVp1KaEzJ4LX1giAOTuhfwPAItGR+/JMs6VxT/V0MMCHaNYcU5zLHXacDFL
URU7hyyhxUp9PzGNI/IEQH2DPv3QVX8Z1CVQQNQpnTsvbpBEF/osxB3SdWg65Y4J
B9nEW5hnyDsjxQVzjwCMFsy1vJeaBkP++zdPhPGE4RaNcweX+hksVRWVJ3DqUuJC
u4IyO5Hmduqmyjyc7MEV6lekecnyHc72WIzFXJpy0FOW0CstOQD59D5Fnbdvbb9i
mm3IJ1Vh/oepZBNPAmHCPqMEAqr5ZQ==
=49Kh
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"A moderately busy release for SPI, the main core update was the
merging of support for multiple chip selects, used in some flash
configurations. There were also big overhauls for the AXI SPI Engine
and PL022 drivers, plus some new device support for ST.
There's a few patches for other trees, API updates to allow the
multiple chip select support and one of the naming modernisations
touched a controller embedded in the USB code.
- Support for multiple chip selects.
- A big overhaul for the AXI SPI engine driver, modernising it and
adding a bunch of new features.
- Modernisation of the PL022 driver, fixing some issues with
submitting messages while in atomic context in the process.
- Many drivers were converted to use new APIs which avoid outdated
terminology for devices and controllers.
- Support for ST Microelectronics STM32F7 and STM32MP25, and Renesas
RZ/Five"
* tag 'spi-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (83 commits)
spi: stm32: add st,stm32mp25-spi compatible supporting STM32MP25 soc
dt-bindings: spi: stm32: add st,stm32mp25-spi compatible
spi: stm32: use dma_get_slave_caps prior to configuring dma channel
spi: axi-spi-engine: fix struct member doc warnings
spi: pl022: update description of internal_cs_control()
spi: pl022: delete description of cur_msg
spi: dw: Remove Intel Thunder Bay SOC support
spi: dw: Remove Intel Thunder Bay SOC support
spi: sh-msiof: Enforce fixed DTDL for R-Car H3
spi: ljca: switch to use devm_spi_alloc_host()
spi: cs42l43: switch to use devm_spi_alloc_host()
spi: zynqmp-gqspi: switch to use modern name
spi: zynq-qspi: switch to use modern name
spi: xtensa-xtfpga: switch to use modern name
spi: xlp: switch to use modern name
spi: xilinx: switch to use modern name
spi: xcomm: switch to use modern name
spi: uniphier: switch to use modern name
spi: topcliff-pch: switch to use modern name
spi: wpcm-fiu: switch to use devm_spi_alloc_host()
...
The commit in Fixes has changed a devm_clk_get()/clk_prepare_enable() into
a devm_clk_get_enabled().
It has updated the error handling path of the probe accordingly, but the
remove has been left unchanged.
Remove now the redundant clk_disable_unprepare() call from the remove
function.
Fixes: a90a987ebe ("spi: use devm_clk_get_enabled() in mcfqspi_probe()")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://msgid.link/r/6670aed303e1f7680e0911387606a8ae069e2cef.1704464447.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the STM32MP25:
- Burst should not be enabled with the new DMA used on STM32MP25.
- STM32MP25 SPI8 has a limited feature set, it can only send words of
8 or 16 bits and with a maximum words number of 1024.
Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Link: https://msgid.link/r/20231218155721.359198-4-alain.volmat@foss.st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current Atmel SPI controller driver (v2) behaves incorrectly when
using two SPI devices with different clock polarities and GPIO CS.
When switching from one device to another, the controller driver first
enables the CS and then applies whatever configuration suits the targeted
device (typically, the polarities). The side effect of such order is the
apparition of a spurious clock edge after enabling the CS when the clock
polarity needs to be inverted wrt. the previous configuration of the
controller.
This parasitic clock edge is problematic when the SPI device uses that edge
for internal processing, which is perfectly legitimate given that its CS
was asserted. Indeed, devices such as HVS8080 driven by driver gpio-sr in
the kernel are shift registers and will process this first clock edge to
perform a first register shift. In this case, the first bit gets lost and
the whole data block that will later be read by the kernel is all shifted
by one.
Current behavior:
The actual switching of the clock polarity only occurs after the CS
when the controller sends the first message:
CLK ------------\ /-\ /-\
| | | | | . . .
\---/ \-/ \
CS -----\
|
\------------------
^ ^ ^
| | |
| | Actual clock of the message sent
| |
| Change of clock polarity, which occurs with the first
| write to the bus. This edge occurs when the CS is
| already asserted, and can be interpreted as
| the first clock edge by the receiver.
|
GPIO CS toggle
This issue is specific to this controller because while the SPI core
performs the operations in the right order, the controller however does
not. In practice, the controller only applies the clock configuration right
before the first transmission.
So this is not a problem when using the controller's dedicated CS, as the
controller does things correctly, but it becomes a problem when you need to
change the clock polarity and use an external GPIO for the CS.
One possible approach to solve this problem is to send a dummy message
before actually activating the CS, so that the controller applies the clock
polarity beforehand.
New behavior:
CLK ------\ /-\ /-\ /-\ /-\
| | | ... | | | | ... | |
\------/ \- -/ \------/ \- -/ \------
CS -\/-----------------------\
|| |
\/ \---------------------
^ ^ ^ ^ ^
| | | | |
| | | | Expected clock cycles when
| | | | sending the message
| | | |
| | | Actual GPIO CS activation, occurs inside
| | | the driver
| | |
| | Dummy message, to trigger clock polarity
| | reconfiguration. This message is not received and
| | processed by the device because CS is low.
| |
| Change of clock polarity, forced by the dummy message. This
| time, the edge is not detected by the receiver.
|
This small spike in CS activation is due to the fact that the
spi-core activates the CS gpio before calling the driver's
set_cs callback, which deactivates this gpio again until the
clock polarity is correct.
To avoid having to systematically send a dummy packet, the driver keeps
track of the clock's current polarity. In this way, it only sends the dummy
packet when necessary, ensuring that the clock will have the correct
polarity when the CS is toggled.
There could be two hardware problems with this patch:
1- Maybe the small CS activation peak can confuse SPI devices
2- If on a design, a single wire is used to select two devices depending
on its state, the dummy message may disturb them.
Fixes: 5ee36c9898 ("spi: atmel_spi update chipselect handling")
Cc: <stable@vger.kernel.org>
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Link: https://msgid.link/r/20231204154903.11607-1-louis.chauvet@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove Intel Thunder Bay specific code as the product got cancelled and
there are no end customers or users.
Signed-off-by: Nandhini Srikandan <nandhini.srikandan@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://msgid.link/r/20231213060836.29203-2-nandhini.srikandan@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Documentation says only DTDL of 200 is allowed for this SoC.
Fixes: 4286db8456 ("spi: sh-msiof: Add R-Car Gen 2 and 3 fallback bindings")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://msgid.link/r/20231212081239.14254-1-wsa+renesas@sang-engineering.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Nam Cao <namcao@linutronix.de>:
The driver was refactored in 9b2ef250b3 ("spi: spl022: switch to use
default spi_transfer_one_message()"), and some variables are now unused
because of that. Clean them up.
