Merge series from Srinivas Goud <srinivas.goud@amd.com>:
Currently SPI Cadence controller works in Master mode only.
Update driver to support Slave mode and also Full duplex transfer
support in Slave mode
Currently SPI Cadence controller works only in Master mode.
Updated interrupt handler for Full duplex transfer in Slave mode.
Interrupt handler rely on the TX empty interrupt even for Slave mode
transfer due to below HW limitation.
HW limitation:
AR 65885 - SPI Controller Might Not Update RX_NEMPTY Flag, Showing
Incorrect Status Of The Receive FIFO
SPI Slave mode works in the following manner:
1. One transfer can be finished only after all transfer->len
data been transferred to master device.
2. Slave device only accepts transfer->len data. Any data longer
than this from master device will be dropped. Any data shorter than
this from master will cause SPI to be stuck due to the above behavior.
3. The stale data present in RXFIFO will be dropped in unprepared
hardware transfer function.
Signed-off-by: Srinivas Goud <srinivas.goud@amd.com>
Link: https://lore.kernel.org/r/1681825625-10265-3-git-send-email-srinivas.goud@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The cadence QSPI driver misbehaves after performing a full system suspend
resume:
...
spi-nor spi0.0: resume() failed
...
This results in a flash connected via OSPI interface after system suspend-
resume to be unusable.
fix these suspend and resume functions.
Fixes: 1406234105 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230417091027.966146-3-d-gole@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>:
Update Xilinx Versal external DMA read logic to fix random issues
- Instead of having the fixed timeout, update the read timeout based on
the length of the transfer to avoid timeout for larger data size.
- While switching between external DMA read and indirect read, disable the
SPI before configuration and enable it after configuration as recommended
by Octal-SPI Flash Controller specification.
Sai Krishna Potthuri (2):
spi: cadence-quadspi: Update the read timeout based on the length
spi: cadence-quadspi: Disable the SPI before reconfiguring
drivers/spi/spi-cadence-quadspi.c | 40 ++++++++++++++++++-------------
1 file changed, 24 insertions(+), 16 deletions(-)
--
2.25.1
The AMD Pensando Elba SoC includes a DW apb_ssi v4 controller
with device specific chip-select control. The Elba SoC
provides four chip-selects where the native DW IP supports
two chip-selects. The Elba DW_SPI instance has two native
CS signals that are always overridden.
Signed-off-by: Brad Larson <blarson@amd.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20230410184526.15990-11-blarson@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Observed random DMA timeout failures while doing back to back
transfers which involves switching the modes from DMA to NON-DMA.
This issue is observed while testing the OSPI+UBIFS file system test case
where rootfs is mounted from OSPI UBIFS partition.
To avoid this issue, disable the SPI before changing the configuration
from external DMA to NON-DMA and vice versa and reenable it after changing
the configuration.
As per the Cadence Octal SPI design specification, it is recommended to
disable the Octal-SPI enable bit before reconfiguring.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Link: https://lore.kernel.org/r/20230320095931.2651714-3-sai.krishna.potthuri@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When performing indirect read via external DMA the timeout for
completion is set equal to the read length instead of fixed timeout value.
For reads larger than 500 bytes, the timeout will continue to be
equal to the read length whereas for a small read like the Read Status
Register command, the timeout would be 1 or 2 milliseconds. This is not
enough to cover the overhead needed in setting up DMA, in that case make
sure the timeout is at least 500ms to allow DMA to finish. This solution
is inline with the timeout used for Direct read via DMA.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Link: https://lore.kernel.org/r/20230320095931.2651714-2-sai.krishna.potthuri@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>:
This patch series fixes the following bugs in spi-pci1xxxx driver:
1. Length of SPI transactions is improper
2. SPI transactions fail after suspend and resume
3. Incorrect implementation of pci1xxxx_spi_set_cs API
On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped as seen in a previous commit.
So, for large tranfers with an even size, allocate a temporary tx
buffer and byte-swap data before and after transfer.
This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.
For the time being, only do it on CPM1 as there must be a
trade-off between the CPM load reduction and the CPU load required
to byte swap the data.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/f2e981f20f92dd28983c3949702a09248c23845c.1680371809.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
For different reasons, fsl-spi driver performs bits_per_word
modifications for different reasons:
- On CPU mode, to minimise amount of interrupts
- On CPM/QE mode to work around controller byte order
For CPU mode that's done in fsl_spi_prepare_message() while
for CPM mode that's done in fsl_spi_setup_transfer().
Reunify all of it in fsl_spi_prepare_message(), and catch
impossible cases early through master's bits_per_word_mask
instead of returning EINVAL later.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/0ce96fe96e8b07cba0613e4097cfd94d09b8919a.1680371809.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
CPM has the same problem as QE so for CPM also use the fix added
by commit 0398fb7094 ("spi/spi_mpc8xxx: Fix QE mode Litte Endian"):
CPM mode uses Little Endian so words > 8 bits are byte swapped.
Workaround this by always enforcing wordsize 8 for 16 and 32 bits
words. Unfortunately this will not work for LSB transfers
where wordsize is > 8 bits so disable these for now.
Also limit the workaround to 16 and 32 bits words because it can
only work for multiples of 8-bits.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Fixes: 0398fb7094 ("spi/spi_mpc8xxx: Fix QE mode Litte Endian")
Link: https://lore.kernel.org/r/1b7d3e84b1128f42c1887dd2fb9cdf390f541bc1.1680371809.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
After fixing the error handling in the .remove() callback of the qup
driver, convert it to .remove_new() preparing to make platform driver's
remove functions return void.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230330210341.2459548-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
When using gpio based chip select the cs value can go outside the range
0 – 3. The various MX51_ECSPI_* macros did not take this into consideration
resulting in possible corruption of the configuration.
For example for any cs value over 3 the SCLKPHA bits would not be set and
other values in the register possibly corrupted.
One way to fix this is to just mask the cs bits to 2 bits. This still
allows all 4 native chip selects to work as well as gpio chip selects
(which can use any of the 4 chip select configurations).
Signed-off-by: Kevin Groeneveld <kgroeneveld@lenbrook.com>
Link: https://lore.kernel.org/r/20230318222132.3373-1-kgroeneveld@lenbrook.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Convert this driver from always returning zero in the remove callback to
the void returning variant.
Now that bcm2835_spi_remove returns no error code any more,
bcm2835_spi_shutdown() does the same thing as bcm2835_spi_remove(). So
drop the shutdown function and use bcm2835_spi_remove() as .shutdown
callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230330211022.2460233-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
An early error return from a remove callback is usally wrong. In the
case of the spi-sprd driver it's not that critical because the skipped
steps are mainly undoing the things that a successful runtime-resume
would have done.
Still it's cleaner to not exit early and not return an (mostly ignored)
error value. The second patch converts to .remove_new (which is the
motivation for this series).
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
This small series converts the spi-imx driver to .remove_new(). The
motivation for this tree-wide effort are drivers that don't properly
cleanup and return an error code. This is broken as this results in
resource leaks. The spi-imx driver is such a driver. The idea is that if
the remove callback returns void it's obvious that an early error return
is wrong.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230306065733.2170662-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230307211426.2331483-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If pm_runtime_resume_and_get() failed before this change, two error
messages were printed. One directly in sprd_spi_remove() and another
by the device core as the return value is non-zero.
The better handling of a failure to resume the device is to do the
software related cleanup anyhow and only skip hardware accesses.
This leaves the device in an unknown state, but there is nothing that can
be done about that.
Even in the error case, return zero to suppress the device core's error
message.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230307211426.2331483-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
