IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This series adds Tegra210, Tegra186, and Tegra194 Quad SPI driver and
enables Quad SPI on Jetson Nano and Jetson Xavier NX.
QSPI controller is available on Tegra210, Tegra186 and Tegra194.
Tegra186 and Tegra194 has additional feature of combined sequence mode
where command, address and data can all be transferred in a single transfer.
Combined sequence mode is useful only when using DMA mode transfer.
This series does not have combined sequence mode feature as Tegra186/Tegra194
GPCDMA driver is not upstreamed yet.
This series includes
- dt-binding document
- QSPI driver for Tegra210/Tegra186/Tegra194
- Enables QSPI on Jetson Nano and Jetson Xavier NX.
Delta between patch versions:
[v5]: Simplified implementation in Patch-0006
[v4]: Updated dummy cycles implementation based on v3 feedback
- Added dummy_data bit field int spi_transfer to indicate corresponding
transfer is dummy bytes transfer.
- Updated Tegra QSPI transfer_one_message to identify dummy transfer and
to use HW supported dummy bytes transfer when dummy cycles are with in
Tegra QSPI supported max HW dummy cycles otherwise fallsback to transfer
dummy bytes from software.
- Updated dt-bindings based on v3 feedback.
[v3]: v2 has some mixed patches sent out accidentally.
v3 sends proper patches with fixes mentioned in v2.
[v2]: below v1 feedback
- Added SPI_MASTER_USES_HW_DUMMY_CYCLES flag for controllers supporting
hardware dummy cycles and skips dummy bytes transfer from software for
these controllers.
- Updated dt-binding doc with tx/rx tap delay properties.
- Added qspi_out clock to dt-binding doc which will be used later with
ddr mode support.
- All other v1 feedback on some cleanup.
Sowjanya Komatineni (9):
dt-bindings: clock: tegra: Add clock ID TEGRA210_CLK_QSPI_PM
dt-bindings: spi: Add Tegra Quad SPI device tree binding
MAINTAINERS: Add Tegra Quad SPI driver section
spi: tegra210-quad: Add support for Tegra210 QSPI controller
spi: spi-mem: Mark dummy transfers by setting dummy_data bit
spi: tegra210-quad: Add support for hardware dummy cycles transfer
arm64: tegra: Enable QSPI on Jetson Nano
arm64: tegra: Add QSPI nodes on Tegra194
arm64: tegra: Enable QSPI on Jetson Xavier NX
.../bindings/spi/nvidia,tegra210-quad.yaml | 117 ++
MAINTAINERS | 8 +
.../dts/nvidia/tegra194-p3509-0000+p3668-0000.dts | 12 +
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 28 +
arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 12 +
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 5 +-
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-mem.c | 1 +
drivers/spi/spi-tegra210-quad.c | 1410 ++++++++++++++++++++
include/dt-bindings/clock/tegra210-car.h | 2 +-
include/linux/spi/spi.h | 2 +
12 files changed, 1604 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
create mode 100644 drivers/spi/spi-tegra210-quad.c
--
2.7.4
Tegra Quad SPI controller hardware supports sending dummy bytes based
on programmed dummy clock cycles after the actual transfer bytes.
This patch adds this support of hardware dummy bytes transfer and
skips transfer of dummy bytes from the software.
For dummy cycles more than Tegra Quad SPI hardware maximum dummy
cycles limit, driver transfers dummy bytes from the software.
Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
Link: https://lore.kernel.org/r/1608585459-17250-7-git-send-email-skomatineni@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Double Transfer Rate (DTR) mode transfers data twice per clock cycle.
Add support for parsing DTR ops and set up the registers to allow it.
Most SPI NOR flashes expect 2 byte commands. Parse the 2-byte opcode
from SPI MEM and set it up in the CQSPI_REG_OP_EXT_LOWER register.
Increment the delay needed before issuing indirect writes because larger
delay is needed for DTR mode. With the current delay some writes end up
missing.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-8-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When performing a direct read via DMA the timeout for completion is set
equal to the read length. This is fine for larger reads. 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.
Make sure the timeout is at least 500 ms to allow DMA ample time to
finish. For reads larger than 500 bytes, the timeout will continue to be
equal to the read length.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20201222184425.7028-7-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The default SPI MEM supports_op hook rejects DTR ops by default. Add a
simple supports_op hook that very closely imitates the SPI MEM one. It
will be extended in later commits to allow DTR ops.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-6-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI MEM deals with dummy bytes but the controller deals with dummy
cycles. Multiplying bytes by 8 is correct if the dummy phase uses 1S
mode since 1 byte will be sent in 8 cycles. But if the dummy phase uses
4S mode then 1 byte will be sent in 2 cycles.
To correctly translate dummy bytes to dummy cycles, the dummy buswidth
also needs to be taken into account. Divide 8 by the buswidth to get the
correct multiplier for getting the number of cycles.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-5-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If a command does not have an address phase it goes via the STIG path.
The dummy cycles are not initialized for the STIG commands. As a result,
STIG commands with dummy cycles will not work.
Initialize the dummy cycle field before issuing the STIG command to make
sure it is sent correctly. Move the code to calculate dummy cycle value
to a separate function so it is not repeated twice. DTR support will add
some more logic here to it is worth it to extract it out in a function.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-4-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The controller can only support up to 31 dummy cycles. If the command
requires more it falls back to using 31. This command is likely to fail
because the correct number of cycles are not waited upon. Rather than
silently issuing an incorrect command, fail loudly so the caller can get
a chance to find out the command can't be supported by the controller.
Fixes: 1406234105 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller")
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As of commit 9326e4f1e5 ("spi: Limit the spi device max speed to
controller's max speed"), the SPI device max speed is set to the
controller's max speed if it is larger. The Cadence QSPI controller does
not set the controller's max speed so it is left at its initial value of
0. This means the SPI device max speed is always set to 0.
The SPI device max speed is used to calculate the baud rate divider when
performing an operation. If this speed is 0, the default divider of 32
is used. No matter what speed is specified by the device tree property
'spi-max-frequency', the device will always operate at ref_clk / 32.
Fix this by setting master->max_speed_hz to the ref clock speed so the
correct divider can be calculated.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20201222184425.7028-2-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With the introduction of the 'include/uapi/linux/spi/spi.h' header, the
type of the macros are enforced to 'unsigned long int' via the _BITUL()
macro.
This causes some -Wformat warnings in the spi-stm32 driver.
This patch adds a double-negation operator to the bit-masks. Essentially,
the important values for debugging are 0 or 1, while masking them directly
would show 0 or BIT(x) values.
This way, the type of the arguments are automatically re-cast.
Fixes: f7005142da ("spi: uapi: unify SPI modes into a single spi.h header")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210104143103.56510-1-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SPI driver for the Renesas RPC-IF is present on the RZ/G2
Series. Add that to the description.
Suggested-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210102115412.3402059-3-aford173@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The xfer waiting time is the result of xfer->len / xfer->speed_hz. This
patch makes the assumption of 100khz xfer speed if the xfer->speed_hz is
not assigned and stays 0. This avoids the divide by 0 issue and ensures
a reasonable tolerant waiting time.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Link: https://lore.kernel.org/r/1609723749-3557-1-git-send-email-yilun.xu@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use __maybe_unused for the suspend()/resume() hooks and get rid of
the CONFIG_PM_SLEEP ifdefery to improve the code.
Suggested-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Acked-by: Pavel Machek <pavel@denx.de>
Link: https://lore.kernel.org/r/20201230145708.28544-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
will be overwritten by zero. Make sure spi->controller->max_speed_hz
is not zero when clamping spi->max_speed_hz.
Put the spi->controller->max_speed_hz non-zero check higher in the if,
so that we avoid a superfluous init to zero when both spi->max_speed_hz
and spi->controller->max_speed_hz are zero.
Fixes: 9326e4f1e5 ("spi: Limit the spi device max speed to controller's max speed")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201216092321.413262-1-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the return value for altera_spi_txrx. It should return
1 for interrupt transfer mode, and return 0 for polling transfer mode.
The altera_spi_txrx() implements the spi_controller.transfer_one
callback. According to the spi-summary.rst, the transfer_one should
return 0 when transfer is finished, return 1 when transfer is still in
progress.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Link: https://lore.kernel.org/r/1609219662-27057-2-git-send-email-yilun.xu@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Transmit/receive only is a valid SPI mode. For example, the MOSI/TX line
might be missing from an ADC while for a DAC the MISO/RX line may be
optional. This patch adds these two new modes: SPI_NO_TX and
SPI_NO_RX. This way, the drivers will be able to identify if any of
these two lines is missing and to adjust the transfers accordingly.
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20201221152936.53873-2-alexandru.ardelean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SPI devices, require toggling the CS every transferred byte.
Enable such possibility in the spi-orion driver.
Note that in order to use it, in the driver of a secondary device
attached to this controller, the SPI bus 'mode' field must be
updated with SPI_CS_WORD flag before calling spi_setup() routine.
In addition to that include a work-around - some devices, such as
certain models of SLIC (Subscriber Line Interface Card),
may require extra delay after CS toggling, so add a minimal
timing relaxation in relevant places.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Link: https://lore.kernel.org/r/20201223103827.29721-3-kostap@marvell.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The spi-orion driver disables its clocks whenever it is not used.
In usual case during boot (i.e. using SPI flash) it is not a problem,
as the child device driver is present and probed along with
spi_register_master() execution.
However in case the child device driver is not ready
(e.g. when its type is module_spi_driver) the spi_setup() callback
can be called after the spi-orion probe. It may happen,
that as a result there will be an attempt to access controller's
registers with the clocks disabled.
Prevent such situations and make sure the clocks are on,
each time the spi_setup() is called.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Link: https://lore.kernel.org/r/20201223103827.29721-2-kostap@marvell.com
Signed-off-by: Mark Brown <broonie@kernel.org>
if cur_bpw <= 8 and xfer_len < 4 then the value of fthlv will be 1 and
SPI registers content may have been lost.
* If SPI data register is accessed as a 16-bit register and DSIZE <= 8bit,
better to select FTHLV = 2, 4, 6 etc
* If SPI data register is accessed as a 32-bit register and DSIZE > 8bit,
better to select FTHLV = 2, 4, 6 etc, while if DSIZE <= 8bit,
better to select FTHLV = 4, 8, 12 etc
Signed-off-by: Roman Guskov <rguskov@dh-electronics.com>
Fixes: dcbe0d84df ("spi: add driver for STM32 SPI controller")
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20201221123532.27272-1-rguskov@dh-electronics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If we're using geni to manage the chip select line (don't do it--use a
GPIO!) and we happen to get a timeout waiting for the chip select
command to be completed, no errors are printed even though things
might not be in the best shape. Let's add a print.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.4.I666b37646de9652cef438ac7c2c6c2053367fc6b@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
If we get a timeout sending then this happens:
spi_transfer_one_message()
->transfer_one() AKA spi_geni_transfer_one()
setup_fifo_xfer()
mas->cur_xfer = non-NULL
spi_transfer_wait() => TIMES OUT
if (msg->status != -EINPROGRESS)
goto out
if (ret != 0 ...)
spi_set_cs()
->set_cs AKA spi_geni_set_cs()
# mas->cur_xfer is non-NULL
The above happens _before_ the SPI core calls ->handle_err() AKA
handle_fifo_timeout().
Unfortunately that won't work so well on geni. If we got a timeout
transferring then it's likely that our interrupt handler is blocked,
but we need that same interrupt handler to run and the command channel
to be unblocked in order to adjust the chip select. Trying to set the
chip select doesn't crash us but ends up confusing our state machine
and leads to messages like: Premature done. rx_rem = 32 bpw8
Let's just drop the chip select request in this case. We can detect
the case because cur_xfer is non-NULL--it would have been set to NULL
in the interrupt handler if the previous transfer had finished. Sure,
we might leave the chip select in the wrong state but it's likely it
was going to fail anyway and this avoids getting the driver even more
confused about what it's doing.
The SPI core in general assumes that setting chip select is a simple
operation that doesn't fail. Yet another reason to just reconfigure
the chip select line as GPIOs.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.3.I07afdedcc49655c5d26880f8df9170aac5792378@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
If we got a timeout when trying to send an abort command then it means
that we just got 3 timeouts in a row:
1. The original timeout that caused handle_fifo_timeout() to be
called.
2. A one second timeout waiting for the cancel command to finish.
3. A one second timeout waiting for the abort command to finish.
SPI is clocked by the controller, so nothing (aside from a hardware
fault or a totally broken sequencer) should be causing the actual
commands to fail in hardware. However, even though the hardware
itself is not expected to fail (and it'd be hard to predict how we
should handle things if it did), it's easy to hit the timeout case by
simply blocking our interrupt handler from running for a long period
of time. Obviously the system is in pretty bad shape if a interrupt
handler is blocked for > 2 seconds, but there are certainly bugs (even
bugs in other unrelated drivers) that can make this happen.
Let's make things a bit more robust against this case. If we fail to
abort we'll set a flag and then we'll block all future transfers until
we have no more interrupts pending.
Fixes: 561de45f72 ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.2.Ibade998ed587e070388b4bf58801f1107a40eb53@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
In commit 7ba9bdcb91 ("spi: spi-geni-qcom: Don't keep a local state
variable") we changed handle_fifo_timeout() so that we set
"mas->cur_xfer" to NULL to make absolutely sure that we don't mess
with the buffers from the previous transfer in the timeout case.
Unfortunately, this caused the IRQ handler to dereference NULL in some
cases. One case:
CPU0 CPU1
---- ----
setup_fifo_xfer()
geni_se_setup_m_cmd()
<hardware starts transfer>
<transfer completes in hardware>
<hardware sets M_RX_FIFO_WATERMARK_EN in m_irq>
...
handle_fifo_timeout()
spin_lock_irq(mas->lock)
mas->cur_xfer = NULL
geni_se_cancel_m_cmd()
spin_unlock_irq(mas->lock)
geni_spi_isr()
spin_lock(mas->lock)
if (m_irq & M_RX_FIFO_WATERMARK_EN)
geni_spi_handle_rx()
mas->cur_xfer NULL dereference!
tl;dr: Seriously delayed interrupts for RX/TX can lead to timeout
handling setting mas->cur_xfer to NULL.
Let's check for the NULL transfer in the TX and RX cases and reset the
watermark or clear out the fifo respectively to put the hardware back
into a sane state.
NOTE: things still could get confused if we get timeouts all the way
through handle_fifo_timeout() and then start a new transfer because
interrupts from the old transfer / cancel / abort could still be
pending. A future patch will help this corner case.
Fixes: 561de45f72 ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.1.I99ee04f0cb823415df59bd4f550d6ff5756e43d6@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Collected patches from the two series below and associated tags so they
can be merged in one pile through the spi tree. Merry December!
SPI: https://lore.kernel.org/r/20201202214935.1114381-1-swboyd@chromium.org
cros-ec: https://lore.kernel.org/r/20201203011649.1405292-1-swboyd@chromium.org
Cc: Akash Asthana <akashast@codeaurora.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Gwendal Grignou <gwendal@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Alexandru M Stan <amstan@chromium.org>
Stephen Boyd (3):
platform/chrome: cros_ec_spi: Don't overwrite spi::mode
platform/chrome: cros_ec_spi: Drop bits_per_word assignment
spi: spi-geni-qcom: Use the new method of gpio CS control
drivers/platform/chrome/cros_ec_spi.c | 2 --
drivers/spi/spi-geni-qcom.c | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
base-commit: b650545978
--
https://chromeos.dev
Let's set the 'use_gpio_descriptors' field so that we use the new way of
requesting the CS GPIOs in the core. This allows us to avoid having to
configure the CS pins in "output" mode with an 'output-enable' pinctrl
setting.
Cc: Akash Asthana <akashast@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201204193540.3047030-4-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The Canaan Kendryte K210 RISC-V SoC includes a DW apb_ssi v4 controller
which is documented to have a 32 words deep TX and RX FIFO. The FIFO
length detection in spi_hw_init() correctly detects this value.
However, when the controller RX FIFO is filled up to 32 entries
(RXFLR = 32), an RX FIFO overrun error occurs. This likely due to a
hardware bug which can be avoided by force setting the fifo_len field of
struct dw_spi to 31.
Define the dw_spi_canaan_k210_init() function to force set fifo_len to
31 when the device node compatible string is "canaan,k210-spi".
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20201206011817.11700-4-damien.lemoal@wdc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward
define a 32-bits maximum transfer size synthesis parameter
(SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration
(SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32,
the layout of the ctrlr0 register changes, moving the data frame format
field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size
can be up to 32-bits.
To support this new format, introduce the DW SPI capability flag
DW_SPI_CAP_DFS32 to indicate that a controller is configured with
SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis
parameter not accessible through a register, the detection of this
parameter value is done in spi_hw_init() by writing and reading the
ctrlr0 register and testing the value of bits [3..0]. These bits are
ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection.
If a DFS32 capable SPI controller is detected, the new field dfs_offset
in struct dw_spi is set to SPI_DFS32_OFFSET (16).
dw_spi_update_config() is modified to set the data frame size field at
the correct position is the CTRLR0 register, as indicated by the
dfs_offset field of the dw_spi structure.
The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave
controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI
capability flag set. However, for these ssi controllers, the dfs_offset
field is set to 0 as before (as per specifications).
Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag
set, dw_spi_add_host() extends the value of bits_per_word_mask from
16-bits to 32-bits. dw_reader() and dw_writer() are also modified to
handle 32-bits iTX/RX FIFO words.
Suggested-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Starting with the move of the atmel-quadspi driver under SPI,
the following error could be seen when mounting a 16MByte ubifs:
UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type
1/4 fixes AHB accesses. The rest of the patches are small optimizations.
Tested on both sama5d2 and sam9x60.
Tudor Ambarus (4):
spi: atmel-quadspi: Fix AHB memory accesses
spi: atmel-quadspi: Drop superfluous set of QSPI_IFR_APBTFRTYP_READ
spi: atmel-quadspi: Write QSPI_IAR only when needed
spi: atmel-quadspi: Move common code outside of if else
drivers/spi/atmel-quadspi.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--
2.25.1
base-commit: 3650b228f8
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
atmel_qspi_remove() accesses the driver's private data after calling
spi_unregister_controller() even though that function releases the last
reference on the spi_controller and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.
Fixes: 2d30ac5ed6 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.0+
Cc: Piotr Bugalski <bugalski.piotr@gmail.com>
Link: https://lore.kernel.org/r/4b05c65cf6f1ea3251484fe9a00b4c65478a1ae3.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to devm_spi_register_master() fails on probe of the NPCM FIU
SPI driver, the clock "fiu->clk" is erroneously not unprepared and
disabled. Fix it.
Fixes: ace55c411b ("spi: npcm-fiu: add NPCM FIU controller driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.4+
Cc: Tomer Maimon <tmaimon77@gmail.com>
Link: https://lore.kernel.org/r/9ae62f4e1cfe542bec57ac2743e6fca9f9548f55.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to devm_spi_register_controller() fails on probe of the
Qualcomm Atheros AR934x/QCA95xx SPI driver, the spi_controller struct is
erroneously not freed. Fix by switching over to the new
devm_spi_alloc_master() helper.
Moreover, the controller's clock is enabled on probe but not disabled if
any of the subsequent probe steps fail.
Finally, there's an ordering issue in ar934x_spi_remove() wherein the
clock is disabled even though the controller is not yet unregistered.
It is unregistered after ar934x_spi_remove() by the devres framework.
As long as it is not unregistered, SPI transfers may still be ongoing
and disabling the clock may break them. It is not possible to use
devm_spi_register_controller() in this case, so move to the non-devm
variant.
All of these bugs have existed since the driver was first introduced,
so it seems fair to fix them together in a single commit.
Fixes: 047980c582 ("spi: add driver for ar934x spi controller")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.7+
Cc: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/1d58367d74d55741e0c2730a51a2b65012c8ab33.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to device_reset() or devm_spi_register_controller() fail on
probe of the MediaTek MT7621 SPI driver, the spi_controller struct is
erroneously not freed. Fix by switching over to the new
devm_spi_alloc_master() helper.
Additionally, there's an ordering issue in mt7621_spi_remove() wherein
the spi_controller is unregistered after disabling the SYS clock.
The correct order is to call spi_unregister_controller() *before* this
teardown step because bus accesses may still be ongoing until that
function returns.
All of these bugs have existed since the driver was first introduced,
so it seems fair to fix them together in a single commit.
Fixes: 1ab7f2a435 ("staging: mt7621-spi: add mt7621 support")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.17+
Link: https://lore.kernel.org/r/72b680796149f5fcda0b3f530ffb7ee73b04f224.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 702b15cb97 ("spi: mt7621: fix missing clk_disable_unprepare()
on error in mt7621_spi_probe") sought to disable the SYS clock on probe
errors, but only did so for 2 of 3 potentially failing calls: The clock
needs to be disabled on failure of devm_spi_register_controller() as
well.
Moreover, the commit purports to fix a bug in commit cbd66c626e ("spi:
mt7621: Move SPI driver out of staging") but in reality the bug has
existed since the driver was first introduced.
Fixes: 1ab7f2a435 ("staging: mt7621-spi: add mt7621 support")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.17+: 702b15cb97: spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe
Cc: <stable@vger.kernel.org> # v4.17+
Cc: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://lore.kernel.org/r/36ad42760087952fb7c10aae7d2628547c26a7ec.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to devm_gpiod_get_optional() fails on probe of the NXP
SC18IS602/603 SPI driver, the spi_master struct is erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: f99008013e ("spi: sc18is602: Add reset control via gpio pin.")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.9+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Phil Reid <preid@electromag.com.au>
Link: https://lore.kernel.org/r/d5f715527b894b91d530fe11a86f51b3184a4e1a.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to devm_clk_get(), devm_spi_register_master() or
clk_prepare_enable() fail on probe of the Mikrotik RB4xx SPI driver,
the spi_master struct is erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: 05aec35787 ("spi: Add SPI driver for Mikrotik RB4xx series boards")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.2+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.2+
Cc: Bert Vermeulen <bert@biot.com>
Link: https://lore.kernel.org/r/369bf26d71927f60943b1d9d8f51810f00b0237d.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to devm_spi_register_master() fails on probe of the GPIO SPI
driver, the spi_master struct is erroneously not freed:
After allocating the spi_master, its reference count is 1. The driver
unconditionally decrements the reference count on unbind using a devm
action. Before calling devm_spi_register_master(), the driver
unconditionally increments the reference count because on success,
that function will decrement the reference count on unbind. However on
failure, devm_spi_register_master() does *not* decrement the reference
count, so the spi_master is leaked.
The issue was introduced by commits 8b797490b4 ("spi: gpio: Make sure
spi_master_put() is called in every error path") and 79567c1a32 ("spi:
gpio: Use devm_spi_register_master()"), which sought to plug leaks
introduced by 9b00bc7b90 ("spi: spi-gpio: Rewrite to use GPIO
descriptors") but missed this remaining leak.
The situation was later aggravated by commit d3b0ffa1d7 ("spi: gpio:
prevent memory leak in spi_gpio_probe"), which introduced a
use-after-free because it releases a reference on the spi_master if
devm_add_action_or_reset() fails even though the function already
does that.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: 9b00bc7b90 ("spi: spi-gpio: Rewrite to use GPIO descriptors")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.1-: 8b797490b4: spi: gpio: Make sure spi_master_put() is called in every error path
Cc: <stable@vger.kernel.org> # v5.1-: 45beec3519: spi: bitbang: Introduce spi_bitbang_init()
Cc: <stable@vger.kernel.org> # v5.1-: 79567c1a32: spi: gpio: Use devm_spi_register_master()
Cc: <stable@vger.kernel.org> # v5.4-: d3b0ffa1d7: spi: gpio: prevent memory leak in spi_gpio_probe
Cc: <stable@vger.kernel.org> # v4.17+
Cc: Navid Emamdoost <navid.emamdoost@gmail.com>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Link: https://lore.kernel.org/r/86eaed27431c3d709e3748eb76ceecbfc790dd37.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to devm_spi_register_controller() fails on probe of the
MediaTek SPI NOR driver, the spi_controller struct is erroneously not
freed.
Since commit a1daaa991e ("spi: spi-mtk-nor: use dma_alloc_coherent()
for bounce buffer"), the same happens if the call to
dmam_alloc_coherent() fails.
Since commit 3bfd9103c7 ("spi: spi-mtk-nor: Add power management
support"), the same happens if the call to mtk_nor_enable_clk() fails.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: 881d1ee9fe ("spi: add support for mediatek spi-nor controller")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Ikjoon Jang <ikjn@chromium.org>
Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.7+
Cc: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/d5b9f0289465394e73dedb8ec51e180a8f1dffc9.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to devm_clk_get() or devm_ioremap_resource() fail on probe
of the Macronix SPI driver, the spi_master struct is erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: b942d80b0a ("spi: Add MXIC controller driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.0+
Cc: Mason Yang <masonccyang@mxic.com.tw>
Link: https://lore.kernel.org/r/4fa6857806e7e75741c05d057ac9df3564460114.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
rpcif_spi_remove() accesses the driver's private data after calling
spi_unregister_controller() even though that function releases the last
reference on the spi_controller and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.
Fixes: eb8d6d464a ("spi: add Renesas RPC-IF driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.9+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.9+
Cc: Sergei Shtylyov <s.shtylyov@omprussia.ru>
Link: https://lore.kernel.org/r/c5da472c28021da2f6517441685cef033d40b140.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
pxa2xx_spi_remove() accesses the driver's private data after calling
spi_unregister_controller() even though that function releases the last
reference on the spi_controller and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master/slave() helper
which keeps the private data accessible until the driver has unbound.
Fixes: 32e5b57232 ("spi: pxa2xx: Fix controller unregister order")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v2.6.17+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v2.6.17+: 32e5b57232: spi: pxa2xx: Fix controller unregister order
Cc: <stable@vger.kernel.org> # v2.6.17+
Link: https://lore.kernel.org/r/5764b04d4a6e43069ebb7808f64c2f774ac6f193.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
spi_sh_remove() accesses the driver's private data after calling
spi_unregister_master() even though that function releases the last
reference on the spi_master and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.
Fixes: 680c1305e2 ("spi/spi_sh: use spi_unregister_master instead of spi_master_put in remove path")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v3.0+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v3.0+
Cc: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/6d97628b536baf01d5e3e39db61108f84d44c8b2.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
qcom_qspi_remove() accesses the driver's private data after calling
spi_unregister_master() even though that function releases the last
reference on the spi_master and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.
Fixes: f79a158d37 ("spi: spi-qcom-qspi: Use OPP API to set clk/perf state")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.9+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.9+
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Link: https://lore.kernel.org/r/b6d3c4dce571d78a532fd74f27def0d5dc8d8a24.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
spi_geni_remove() accesses the driver's private data after calling
spi_unregister_master() even though that function releases the last
reference on the spi_master and thereby frees the private data.
Moreover, since commit 1a9e489e61 ("spi: spi-geni-qcom: Use OPP API to
set clk/perf state"), spi_geni_probe() leaks the spi_master allocation
if the calls to dev_pm_opp_set_clkname() or dev_pm_opp_of_add_table()
fail.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound and also
avoids the spi_master leak on probe.
Fixes: 561de45f72 ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.20+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.20+
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Girish Mahadevan <girishm@codeaurora.org>
Link: https://lore.kernel.org/r/dfa1d8c41b8acdfad87ec8654cd124e6e3cb3f31.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
davinci_spi_remove() accesses the driver's private data after it's been
freed with spi_master_put().
Fix by moving the spi_master_put() to the end of the function.
Fixes: fe5fd25409 ("spi: davinci: Use dma_request_chan() for requesting DMA channel")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: <stable@vger.kernel.org> # v4.7+
Link: https://lore.kernel.org/r/412f7eb1cf8990e0a3a2153f4c577298deab623e.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
QSPI_IFR is set as the last QSPI Instruction Frame register
regardless of the sama5d2 or sam9x60 version of the IP. Move
the writing of QSPI_IFR outside of the IP specific code.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201207135959.154124-5-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
That bit describes the APB transfer type. We are writing
serial memory registers via AHB acesses, that bit does not
make sense in the current context.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201207135959.154124-3-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Following error was seen when mounting a 16MByte ubifs:
UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type
QSPI_IFR.TFRTYP was not set correctly. When data transfer is enabled
and one wants to access the serial memory through AHB in order to:
- read in the serial memory, but not a memory data, for example
a JEDEC-ID, QSPI_IFR.TFRTYP must be written to '0' (both sama5d2
and sam9x60).
- read in the serial memory, and particularly a memory data,
TFRTYP must be written to '1' (both sama5d2 and sam9x60).
- write in the serial memory, but not a memory data, for example
writing the configuration or the QSPI_SR, TFRTYP must be written
to '2' for sama5d2 and to '0' for sam9x60.
- write in the serial memory in particular to program a memory data,
TFRTYP must be written to '3' for sama5d2 and to '1' for sam9x60.
Fix the setting of the QSPI_IFR.TFRTYP field.
Fixes: 2d30ac5ed6 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver")
Cc: <stable@vger.kernel.org> # v5.0+
Reported-by: Tom Burkart <tom@aussec.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201207135959.154124-2-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: abf0090753 ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/1607071357-33378-1-git-send-email-zhangchangzhong@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If cs-gpios property is used in devicetree then ctlr->num_chipselect value
may be changed by spi_get_gpio_descs().
So use ctlr->max_native_cs instead of ctlr->num_chipselect to set SPI_MCR
Fixes: 4fcc7c2292 (spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR)
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Link: https://lore.kernel.org/r/20201201085916.63543-1-fido_max@inbox.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 0f0581b24b ("spi: fsl: Convert to use CS GPIO descriptors")
broke the use of the SPISEL_BOOT signal as a chip select on the
MPC8309.
pdata->max_chipselect, which becomes master->num_chipselect, must be
initialized to take into account the possibility that there's one more
chip select in use than the number of GPIO chip selects.
Cc: stable@vger.kernel.org # v5.4+
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Fixes: 0f0581b24b ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Link: https://lore.kernel.org/r/20201127152947.376-1-rasmus.villemoes@prevas.dk
Signed-off-by: Mark Brown <broonie@kernel.org>
I mistakenly added the select attributes to the SPI_DW_BT1_DIRMAP config
instead of having them defined in SPI_DW_BT1. If the kernel doesn't have
the MULTIPLEXER and MUX_MMIO configs manually enabled and the
SPI_DW_BT1_DIRMAP config hasn't been selected, Baikal-T1 SPI device will
always fail to be probed by the driver. Fix that and the error reported by
the test robot:
>> ld.lld: error: undefined symbol: devm_mux_control_get
>>> referenced by spi-dw-bt1.c
>>> spi/spi-dw-bt1.o:(dw_spi_bt1_sys_init) in archive drivers/built-in.a
by moving the MULTIPLEXER/MUX_MMIO configs selection to the SPI_DW_BT1
config.
Link: https://lore.kernel.org/lkml/202011161745.uYRlekse-lkp@intel.com/
Link: https://lore.kernel.org/linux-spi/20201116040721.8001-1-rdunlap@infradead.org/
Fixes: abf0090753 ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201127144612.4204-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
fixed the coccicheck:
drivers/spi/spi-dw-bt1.c:220:27-30: ERROR: Missing
resource_size with mem.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/1606114975-31362-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When SPI DW memory ops support was introduced, there was a check for
excluding controllers which supplied their own CS function. Even so,
the mem_ops pointer is *always* presented to the SPI core.
This causes the SPI core sanity check in spi_controller_check_ops() to
refuse registration, since a mem_ops pointer is being supplied without
an exec_op member function.
The end result is failure of the SPI DW driver on sparx5 and similar
platforms.
The fix in the core SPI DW driver is to avoid presenting the mem_ops
pointer if the exec_op function is not set.
Fixes: 6423207e57 (spi: dw: Add memory operations support)
Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20201120213414.339701-1-lars.povlsen@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Shutdown bus function might be called on the unbound device, so add a
check if there is a driver before calling its shutdown function.
This fixes following kernel panic obserbed during system reboot:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
...
Call trace:
spi_shutdown+0x10/0x38
kernel_restart_prepare+0x34/0x40
kernel_restart+0x14/0x88
__do_sys_reboot+0x148/0x248
__arm64_sys_reboot+0x1c/0x28
el0_svc_common.constprop.3+0x74/0x198
do_el0_svc+0x20/0x98
el0_sync_handler+0x140/0x1a8
el0_sync+0x140/0x180
Code: f9403402 d1008041 f100005f 9a9f1021 (f9400c21)
---[ end trace 266c07205a2d632e ]---
Fixes: 9db34ee64c (spi: Use bus_type functions for probe, remove and shutdown)
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20201124131523.32287-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If set active without increase the usage count of pm, the dont use
autosuspend function will call the suspend callback to close the two
clocks of spi because the usage count is reduced to -1.
This will cause the warning dump below when the defer-probe occurs.
[ 129.379701] ecspi2_root_clk already disabled
[ 129.384005] WARNING: CPU: 1 PID: 33 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0
So add the get noresume function before set active.
Fixes: 43b6bf406c spi: imx: fix runtime pm support for !CONFIG_PM
Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
Link: https://lore.kernel.org/r/20201124085247.18025-1-xiaoning.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Given the case that bootloader(such as UEFI)'s FSPI driver might not
handle all interrupts before loading kernel, those legacy interrupts
would assert immidiately once kernel's FSPI driver enable them. Further,
if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler()
would call complete(&f->c) to notify others. However, f->c might not be
initialized yet at that time, then cause kernel panic.
Of cause, we should fix this issue within bootloader. But it would be
better to have this pacth to make dirver more robust (by clearing all
interrupt status bits before enabling interrupts).
Suggested-by: Han Xu <han.xu@nxp.com>
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
I've discovered that due to the recent commit 49d7d695ca ("spi: dw:
Explicitly de-assert CS on SPI transfer completion") a concurrent usage of
the spidev devices with different chip-selects causes the "SPI transfer
timed out" error. The root cause of the problem has turned to be in a race
condition of the SPI-transfer execution procedure and the spi_setup()
method being called at the same time. In particular in calling the
spi_set_cs(false) while there is an SPI-transfer being executed. In my
case due to the commit cited above all CSs get to be switched off by
calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
of the spi_setup() being called while there is an SPI-transfer being
executed for two different SPI peripheral devices of the same controller
may happen not only for the spidev driver, but for instance for MMC SPI +
some another device, or spi_setup() being called from an SPI-peripheral
probe method while some other device has already been probed and is being
used by a corresponding driver...
Of course I could have provided a fix affecting the DW APB SSI driver
only, for instance, by creating a mutual exclusive access to the set_cs
callback and setting/clearing only the bit responsible for the
corresponding chip-select. But after a short research I've discovered that
the problem most likely affects a lot of the other drivers:
- drivers/spi/spi-sun4i.c - RMW the chip-select register;
- drivers/spi/spi-rockchip.c - RMW the chip-select register;
- drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR.
- drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR.
- drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize
the bus config changes, but still isn't protected from the race
condition described above;
- drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the
CS state in HW;
- drivers/spi/spi-orion.c - RMW a chip-select register;
- drivers/spi/spi-cadence.c - RMW a chip-select register;
- drivers/spi/spi-armada-3700.c - RMW a chip-select register;
- drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register;
- drivers/spi/spi-sun6i.c - RMW a chip-select register;
- drivers/spi/spi-synquacer.c - RMW a chip-select register;
- drivers/spi/spi-altera.c - directly sets the chip-select state;
- drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and
writes it to HW;
- drivers/spi/spi-mt65xx.c - RMW some CSR;
- drivers/spi/spi-jcore.c - directly sets the chip-selects state;
- drivers/spi/spi-mt7621.c - RMW a chip-select register;
I could have missed some drivers, but a scale of the problem is obvious.
As you can see most of the drivers perform an unprotected
Read-modify-write chip-select register modification in the set_cs callback.
Seeing the spi_setup() function is calling the spi_set_cs() and it can be
executed concurrently with SPI-transfers exec procedure, which also calls
spi_set_cs() in the SPI core spi_transfer_one_message() method, the race
condition of the register modification turns to be obvious.
To sum up the problem denoted above affects each driver for a controller
having more than one chip-select lane and which:
1) performs the RMW to some CS-related register with no serialization;
2) directly disables any CS on spi_set_cs(dev, false).
* the later is the case of the DW APB SSI driver.
The controllers which equipped with a single CS theoretically can also
experience the problem, but in practice will not since normally the
spi_setup() isn't called concurrently with the SPI-transfers executed on
the same SPI peripheral device.
In order to generically fix the denoted bug I'd suggest to serialize an
access to the controller IO by taking the IO mutex in the spi_setup()
callback. The mutex is held while there is an SPI communication going on
on the SPI-bus of the corresponding SPI-controller. So calling the
spi_setup() method and disabling/updating the CS state within it would be
safe while there is no any SPI-transfers being executed. Also note I
suppose it would be safer to protect the spi_controller->setup() callback
invocation too, seeing some of the SPI-controller drivers update a HW
state in there.
Fixes: 49d7d695ca ("spi: dw: Explicitly de-assert CS on SPI transfer completion")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver core ignores the return value of struct device_driver::remove
(because in general there is nothing that can be done about that). So
add a warning when an spi driver returns an error.
This simplifies the quest to make struct device_driver::remove return void.
A consequent change would be to make struct spi_driver::remove return void,
but I'm keeping this quest for later (or someone else).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20201119161604.2633521-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The eventual goal is to get rid of the callbacks in struct
device_driver. Other than not using driver callbacks there should be no
side effect of this patch.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20201119161604.2633521-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Consider an spi driver with a .probe but without a .remove callback (e.g.
rtc-ds1347). The function spi_drv_probe() is called to bind a device and
so dev_pm_domain_attach() is called. As there is no remove callback
spi_drv_remove() isn't called at unbind time however and so calling
dev_pm_domain_detach() is missed and the pm domain keeps active.
To fix this always use both spi_drv_probe() and spi_drv_remove() and
make them handle the respective callback not being set. This has the
side effect that for a (hypothetical) driver that has neither .probe nor
remove the clk and pm domain setup is done.
Fixes: 33cf00e570 ("spi: attach/detach SPI device to the ACPI power domain")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20201119161604.2633521-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in mxs_spi_probe, so we should fix it.
Fixes: b7969caf41 ("spi: mxs: implement runtime pm")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201106012421.95420-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since 5.10-rc1 i.MX is a devicetree-only platform and the existing
.id_table support in this driver was only useful for old non-devicetree
platforms.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201116202606.29888-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to of_match_device(), of_alias_get_id(),
devm_ioremap_resource(), devm_regmap_init_mmio() or devm_clk_get()
fail on probe of the NPCM FIU SPI driver, the spi_controller struct is
erroneously not freed.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: ace55c411b ("spi: npcm-fiu: add NPCM FIU controller driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.4+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.4+
Cc: Tomer Maimon <tmaimon77@gmail.com>
Link: https://lore.kernel.org/r/a420c23a363a3bc9aa684c6e790c32a8af106d17.1605512876.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
It turns out the IRQs most like can be unmasked before the controller is
enabled with no problematic consequences. The manual doesn't explicitly
state that, but the examples perform the controller initialization
procedure in that order. So the commit da8f58909e ("spi: dw: Unmask IRQs
after enabling the chip") hasn't been that required as I thought. But
anyway setting the IRQs up after the chip enabling still worth adding
since it has simplified the code a bit. The problem is that it has
introduced a potential bug. The transfer handler pointer is now
initialized after the IRQs are enabled. That may and eventually will cause
an invalid or uninitialized callback invocation. Fix that just by
performing the callback initialization before the IRQ unmask procedure.
Fixes: da8f58909e ("spi: dw: Unmask IRQs after enabling the chip")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201117094054.4696-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
MT8192 spi-nor is an independent sub system, we need extra control axi
bus clock for it. Add support for the additional axi clock to allow it
to be configured appropriately.
Signed-off-by: bayi cheng <bayi.cheng@mediatek.com>
Tested-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/1605084902-13151-2-git-send-email-bayi.cheng@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix to return the error code from
devm_reset_control_get_optional_exclusive() instaed of 0
in cqspi_probe().
Fixes: 31fb632b5d ("spi: Move cadence-quadspi driver to drivers/spi/")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20201116141836.2970579-1-chengzhihao1@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clang warns:
drivers/spi/spi-bcm2835aux.c:532:50: warning: variable 'err' is
uninitialized when used here [-Wuninitialized]
dev_err(&pdev->dev, "could not get clk: %d\n", err);
^~~
./include/linux/dev_printk.h:112:32: note: expanded from macro 'dev_err'
_dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~
drivers/spi/spi-bcm2835aux.c:495:9: note: initialize the variable 'err'
to silence this warning
int err;
^
= 0
1 warning generated.
Restore the assignment so that the error value can be used in the
dev_err statement and there is no uninitialized memory being leaked.
Fixes: e13ee6cc47 ("spi: bcm2835aux: Fix use-after-free on unbind")
Link: https://github.com/ClangBuiltLinux/linux/issues/1199
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20201113180701.455541-1-natechancellor@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Here's my proposal to fix the use-after-free bugs reported by
Sascha Hauer and Florian Fainelli:
I scrutinized all SPI drivers in the v5.10 tree:
* There are 9 drivers with a use-after-free in the ->remove() hook
caused by accessing driver private data after spi_unregister_controller().
* There are 8 drivers which leak the spi_controller in the ->probe()
error path because of a missing spi_controller_put().
I'm introducing devm_spi_alloc_master/slave() which automatically
calls spi_controller_put() on ->remove(). This fixes both classes
of bugs while at the same time reducing code amount and complexity
in the ->probe() hook.
I propose that spi_controller_unregister() should no longer release
a reference on the spi_controller. Instead, drivers need to either
do it themselves or use one of the devm functions introduced herein.
The vast majority of drivers can be converted to the devm functions.
See the commit message of patch [1/4] for the rationale and details.
Enclosed are patches for 3 Broadcom drivers.
Patches for the other drivers are on this branch:
https://github.com/l1k/linux/commits/spi_fixes
@Florian Fainelli: Could you verify that there are no KASAN splats or
leaks with these patches? Unfortunately I do not have any SPI-capable
hardware at my disposal right now, so can only compile-test. You may
want to augment spi_controller_release() with a printk() to log when
the spi_controller is freed.
@Mark Brown: Patches [2/4] to [4/4] reference the SHA-1 of patch [1/4]
in their stable tags. Because the hash is unknown to me until you apply
the patch, I've used "123456789abc" as a placeholder. You'll have to
replace the hash if/when applying. Alternatively, only apply patch [1/4]
and I'll repost the other patches with the hash fixed up.
Thanks!
Lukas Wunner (4):
spi: Introduce device-managed SPI controller allocation
spi: bcm2835: Fix use-after-free on unbind
spi: bcm2835aux: Fix use-after-free on unbind
spi: bcm-qspi: Fix use-after-free on unbind
drivers/spi/spi-bcm-qspi.c | 34 ++++++++-------------
drivers/spi/spi-bcm2835.c | 24 +++++----------
drivers/spi/spi-bcm2835aux.c | 21 +++++--------
drivers/spi/spi.c | 58 +++++++++++++++++++++++++++++++++++-
include/linux/spi/spi.h | 19 ++++++++++++
5 files changed, 103 insertions(+), 53 deletions(-)
--
2.28.0
Normally the last reference on an spi_controller is released by
spi_unregister_controller(). In the case of the i.MX lpspi driver,
the spi_controller is registered with devm_spi_register_controller(),
so spi_unregister_controller() is invoked automatically after the driver
has unbound.
However the driver already releases the last reference in
fsl_lpspi_remove() through a gratuitous call to spi_master_put(),
causing a use-after-free when spi_unregister_controller() is
subsequently invoked by the devres framework.
Fix by dropping the superfluous spi_master_put().
Fixes: 944c01a889 ("spi: lpspi: enable runtime pm for lpspi")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.2+
Cc: Han Xu <han.xu@nxp.com>
Link: https://lore.kernel.org/r/ab3c0b18bd820501a12c85e440006e09ec0e275f.1604874488.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to devm_platform_ioremap_resource(), irq_of_parse_and_map()
or devm_request_irq() fail on probe of the ST SSC4 SPI driver, the
runtime PM disable depth is incremented even though it was not
decremented before. Fix it.
Fixes: cd050abeba ("spi: st-ssc4: add missed pm_runtime_disable")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.5+
Cc: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/fbe8768c30dc829e2d77eabe7be062ca22f84024.1604874488.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to devm_request_irq() or devm_spi_register_master() fail
on probe of the PIC32 SPI driver, the DMA channels requested by
pic32_spi_dma_prep() are erroneously not released. Plug the leak.
Fixes: 1bcb9f8ceb ("spi: spi-pic32: Add PIC32 SPI master driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.7+
Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
Link: https://lore.kernel.org/r/9624250e3a7aa61274b38219a62375bac1def637.1604874488.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to platform_get_irq() or devm_request_irq() fail on probe
of the SynQuacer SPI driver, the clock "sspi->clk" is erroneously not
unprepared and disabled.
If the clock rate "master->max_speed_hz" cannot be determined, the same
happens and in addition the spi_master struct is not freed.
Fix it.
Fixes: b0823ee35c ("spi: Add spi driver for Socionext SynQuacer platform")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.3+
Cc: Masahisa Kojima <masahisa.kojima@linaro.org>
Link: https://lore.kernel.org/r/232281df1ab91d8f0f553a62d5f97fc264ace4da.1604874488.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
bcm_qspi_remove() calls spi_unregister_master() even though
bcm_qspi_probe() calls devm_spi_register_master(). The spi_master is
therefore unregistered and freed twice on unbind.
Moreover, since commit 0392727c26 ("spi: bcm-qspi: Handle clock probe
deferral"), bcm_qspi_probe() leaks the spi_master allocation if the call
to devm_clk_get_optional() fails.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound and also
avoids the spi_master leak on probe.
While at it, fix an ordering issue in bcm_qspi_remove() wherein
spi_unregister_master() is called after uninitializing the hardware,
disabling the clock and freeing an IRQ data structure. The correct
order is to call spi_unregister_master() *before* those teardown steps
because bus accesses may still be ongoing until that function returns.
Fixes: fa236a7ef2 ("spi: bcm-qspi: Add Broadcom MSPI driver")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.9+: 123456789abc: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Kamal Dasu <kdasu.kdev@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/5e31a9a59fd1c0d0b795b2fe219f25e5ee855f9d.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
bcm2835aux_spi_remove() accesses the driver's private data after calling
spi_unregister_master() even though that function releases the last
reference on the spi_master and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.
Fixes: b9dd3f6d41 ("spi: bcm2835aux: Fix controller unregister order")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.4+: 123456789abc: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.4+: b9dd3f6d41: spi: bcm2835aux: Fix controller unregister order
Cc: <stable@vger.kernel.org> # v4.4+
Link: https://lore.kernel.org/r/b290b06357d0c0bdee9cecc539b840a90630f101.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
bcm2835_spi_remove() accesses the driver's private data after calling
spi_unregister_controller() even though that function releases the last
reference on the spi_controller and thereby frees the private data.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.
Fixes: f8043872e7 ("spi: add driver for BCM2835")
Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v3.10+: 123456789abc: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v3.10+
Cc: Vladimir Oltean <olteanv@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/ad66e0a0ad96feb848814842ecf5b6a4539ef35c.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI driver probing currently comprises two steps, whereas removal
comprises only one step:
spi_alloc_master()
spi_register_controller()
spi_unregister_controller()
That's because spi_unregister_controller() calls device_unregister()
instead of device_del(), thereby releasing the reference on the
spi_controller which was obtained by spi_alloc_master().
An SPI driver's private data is contained in the same memory allocation
as the spi_controller struct. Thus, once spi_unregister_controller()
has been called, the private data is inaccessible. But some drivers
need to access it after spi_unregister_controller() to perform further
teardown steps.
Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which
release a reference on the spi_controller struct only after the driver
has unbound, thereby keeping the memory allocation accessible. Change
spi_unregister_controller() to not release a reference if the
spi_controller was allocated by one of these new devm functions.
The present commit is small enough to be backportable to stable.
It allows fixing drivers which use the private data in their ->remove()
hook after it's been freed. It also allows fixing drivers which neglect
to release a reference on the spi_controller in the probe error path.
Long-term, most SPI drivers shall be moved over to the devm functions
introduced herein. The few that can't shall be changed in a treewide
commit to explicitly release the last reference on the controller.
That commit shall amend spi_unregister_controller() to no longer release
a reference, thereby completing the migration.
As a result, the behaviour will be less surprising and more consistent
with subsystems such as IIO, which also includes the private data in the
allocation of the generic iio_dev struct, but calls device_del() in
iio_device_unregister().
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in sprd_spi_remove, so we should fix it.
Fixes: e7d973a31c ("spi: sprd: Add SPI driver for Spreadtrum SC9860")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20201106015035.139574-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the case that the SPI mux isn't set, the transfer_one_message
function returns without finalizing the message. This means that
the transfer never completes, resulting in hung tasks and an
eventual kernel panic. Fix it by finalizing the transfer in this
case.
Fixes: 9211a441e6 ("spi: fsi: Check mux status before transfers")
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20201110214736.25718-1-eajames@linux.ibm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit f3186dd876 ("spi: Optionally use GPIO descriptors for CS GPIOs")
introduced the optional use of GPIO descriptors for chip selects.
A side-effect of this change: when a SPI bus uses GPIO descriptors,
all its client devices have SPI_CS_HIGH set in spi->mode. This flag is
required for the SPI bus to operate correctly.
This unfortunately breaks many client drivers, which use the following
pattern to configure their underlying SPI bus:
static int client_device_probe(struct spi_device *spi)
{
...
spi->mode = SPI_MODE_0;
spi->bits_per_word = 8;
err = spi_setup(spi);
..
}
In short, many client drivers overwrite the SPI_CS_HIGH bit in
spi->mode, and break the underlying SPI bus driver.
This is especially true for Freescale/NXP imx ecspi, where large
numbers of spi client drivers now no longer work.
Proposed fix:
-------------
When using gpio descriptors, depend on gpiolib to handle CS polarity.
Existing quirks in gpiolib ensure that this is handled correctly.
Existing gpiolib behaviour will force the polarity of any chip-select
gpiod to active-high (if 'spi-active-high' devicetree prop present) or
active-low (if 'spi-active-high' absent). Irrespective of whether
the gpio is marked GPIO_ACTIVE_[HIGH|LOW] in the devicetree.
Loose ends:
-----------
If this fix is applied:
- is commit 138c9c32f0
("spi: spidev: Fix CS polarity if GPIO descriptors are used")
still necessary / correct ?
Fixes: f3186dd876 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201106150706.29089-1-TheSven73@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in callers(spi_imx_prepare_message and
spi_imx_remove), so we should fix it.
Fixes: 525c9e5a32 ("spi: imx: enable runtime pm support")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201102145835.4765-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to of_device_get_match_data() fails on probe of the Atmel
QuadSPI driver, the clock "aq->pclk" is erroneously not unprepared and
disabled. Fix it.
Fixes: 2e5c888873 ("spi: atmel-quadspi: add support for sam9x60 qspi controller")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.1+
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/8f8dc2815aa97b2378528f08f923bf81e19611f0.1604874488.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the missing clk_disable_unprepare() before return
from bcm63xx_hsspi_resume in the error handling case when
fails to prepare and enable bs->pll_clk.
Fixes: 0fd85869c2 ("spi/bcm63xx-hsspi: keep pll clk enabled")
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://lore.kernel.org/r/20201103074911.195530-1-miaoqinglang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in two callers(tegra_spi_setup and
tegra_spi_resume), so we should fix it.
Fixes: f333a331ad ("spi/tegra114: add spi driver")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201103141306.5607-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in tegra_sflash_resume, so we should fix it.
Fixes: 8528547bcc ("spi: tegra: add spi driver for sflash controller")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201103141323.5841-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in two callers(tegra_slink_setup and
tegra_slink_resume), so we should fix it.
Fixes: dc4dc36056 ("spi: tegra: add spi driver for SLINK controller")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201103141345.6188-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the missing clk_disable_unprepare() before return
from mt7621_spi_probe in the error handling case.
Fixes: cbd66c626e ("spi: mt7621: Move SPI driver out of staging")
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://lore.kernel.org/r/20201103074912.195576-1-miaoqinglang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in ti_qspi_setup, so we should fix it.
Fixes: 505a14954e ("spi/qspi: Add qspi flash controller")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201103140947.3815-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in two callers(stm32_qspi_exec_op and
stm32_qspi_setup), so we should fix it.
Fixes: 9d282c17b0 ("spi: stm32-qspi: Add pm_runtime support")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Link: https://lore.kernel.org/r/20201106015357.141235-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Removing the duplicate gpio chip select level handling in
bcm2835_spi_setup() left the lflags variable uninitialized. Avoid trhe
use of such variable by passing default flags to
gpiochip_request_own_desc().
Fixes: 5e31ba0c05 ("spi: bcm2835: fix gpio cs level inversion")
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/r/20201105090615.620315-1-martin@geanix.com
Signed-off-by: Mark Brown <broonie@kernel.org>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in stm32_spi_resume, so we should fix it.
Fixes: db96bf976a ("spi: stm32: fixes suspend/resume management")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Reviewed-by: Alain Volmat <alain.volmat@st.com>
Link: https://lore.kernel.org/r/20201106015217.140476-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: f86c24f479 ("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>
Since commit 530b5affc6 ("spi: fsl-dspi: fix use-after-free in
remove path"), this driver causes a "NULL pointer dereference"
in dspi_suspend/resume.
This is because since this commit, the drivers private data point to
"dspi" instead of "ctlr", the codes in suspend and resume func were
not modified correspondly.
Fixes: 530b5affc6 ("spi: fsl-dspi: fix use-after-free in remove path")
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20201103020546.1822-1-qiang.zhao@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix smatch warning:
drivers/spi/spi-mem.c:746 spi_mem_probe() warn: passing zero to 'PTR_ERR'
Fixes: 5d27a9c8ea ("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>
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in img_spfi_resume, so we should fix it.
Fixes: deba25800a ("spi: Add driver for IMG SPFI controller")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201102145651.3875-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The IP's DMA capabilities are described in the SoC dtsi, to spare
users duplicating the DMA bindings in their board device tree. Users
that don't want to use DMA, have to overwrite the DMA bindings in
their board device tree. An example is:
commit ddcdaeb882 ("ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and UART flx4 functions")
When the DMA bindings are overwritten, one could see on the console:
atmel_spi fc018400.spi: error -ENODEV: No TX DMA channel, DMA is disabled
atmel_spi fc018400.spi: Atmel SPI Controller using PIO only
Choosing to not use DMA is not a reason to print an error message.
More, the user is already informed when PIO is used: "Atmel SPI Controller
using PIO only". Downgrade to dev_dbg when dma_request_chan() fails.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201030121116.869105-1-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The work on improving gpio chip-select in spi core, and the following
fixes, has caused the bcm2835 spi driver to use wrong levels. Fix this
by simply removing level handling in the bcm2835 driver, and let the
core do its work.
Fixes: 3e5ec1db8b ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS")
Cc: <stable@vger.kernel.org>
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/r/20201014090230.2706810-1-martin@geanix.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If SPI is used for periodic polling any sensor, significant delays
sometimes appear. Switching on module clocks during resume lead to delays.
Enabling autosuspend mode causes the controller to not suspend between
SPI transfers and the delays disappear.
The commit also remove unnecessary call to pm_runtime_idle() used
to explicit put device to suspended state. Without pm_runtime_idle() PM
core will put device in the suspended state just after probe() returns.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201019150343.2520-1-akochetkov@lintech.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
If SPI is used for periodic polling any sensor, significant delays
sometimes appear. Switching on module clocks during resume lead to delays.
Enabling autosuspend mode causes the controller to not suspend between
SPI transfers and the delays disappear.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Link: https://lore.kernel.org/r/20201016085014.31667-1-al.kochet@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DMA-based transfer will be enabled if data length is larger than FIFO size
(64 bytes for A64). This greatly reduce number of interrupts for
transferring data.
For smaller data size PIO mode will be used. In PIO mode whole buffer will
be loaded into FIFO.
If driver failed to request DMA channels then it fallback for PIO mode.
Tested on SOPINE (https://www.pine64.org/sopine/)
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20201022075221.23332-1-akochetkov@lintech.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
SoC changes, a substantial part of this is cleanup of some of the older
platforms that used to have a bunch of board files. In particular:
- Removal of non-DT i.MX platforms that haven't seen activity in years,
it's time to remove them.
- A bunch of cleanup and removal of platform data for TI/OMAP platforms,
moving over to genpd for power/reset control (yay!)
- Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
closer to multiplatform support (not quite there yet, but getting
close).
THere are a few other changes too, smaller fixlets, etc. For new
platform support, the primary ones re:
- New SoC: Hisilicon SD5203, ARM926EJ-S platform.
- Cpufreq support for i.MX7ULP
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAl+TT4gPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx322MP/1mI56SyOFx30AqtWBPSjHJp+DzhOObyb4vD
ndYuicBIn9tJwvVRBBZkfsbIU8EENVwrN3hOpesaj9L7xiqOqKakcnyC1REYmpIs
8XBDfdZzy5PrMHIu3fF1ZDCQyO7KndGf5DfLVxJtcf1tSPQyQCuIA3FtS6d8Bxnz
r491+om67ucnlFD5X0Spm3RdZH+ECmXx2iXwoS0Zi7P+X+S+ovG8wBV/X0ggeoBc
Zgi4W01SiRupmSVZ6PA7FvWaLGQErQAALQOcFtMcFgjeWzc1v2QzcURELH8JW7ro
72AH9st1Kvi3hoN2HNNzUnNUdQvZ+AdH8skMIpN/e1cBYqYStAF3gm/R9h+iVHbG
GMmgzXHAFErfAW2UcF8tq1CzvQ5ChcTLNXdeoa8CeQbcDfocF3EyuKSPuDH+ve0H
kk4tPesTAc6XCEVwLaGnoC75sdum5mSi8h9vqhln2KCdeTY7jxzH9YGHjm71Supb
kV9vqo5Q5U/c5l2nU4r5q/DZdIahKsk3HIQZ0iG7BifAzamaTh4uyLVjtM6HSwNz
tdHZaxoHd/PLI5IoeggFelx6qgvK5qVRLP0evgOdTLRFLj/ZbrOf0Q7DjdTy2BjZ
Lgq461QqNapOzxq43G2IDT2+P62Q1+d+YLCKBgaGQaJicyU5m9STCNo3UBb1qH1h
W6UwGF5z
=0+Ee
-----END PGP SIGNATURE-----
Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC platform updates from Olof Johansson:
"SoC changes, a substantial part of this is cleanup of some of the
older platforms that used to have a bunch of board files.
In particular:
- Remove non-DT i.MX platforms that haven't seen activity in years,
it's time to remove them.
- A bunch of cleanup and removal of platform data for TI/OMAP
platforms, moving over to genpd for power/reset control (yay!)
- Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
closer to multiplatform support (not quite there yet, but getting
close).
There are a few other changes too, smaller fixlets, etc. For new
platform support, the primary ones are:
- New SoC: Hisilicon SD5203, ARM926EJ-S platform.
- Cpufreq support for i.MX7ULP"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits)
ARM: mstar: Select MStar intc
ARM: stm32: Replace HTTP links with HTTPS ones
ARM: debug: add UART early console support for SD5203
ARM: hisi: add support for SD5203 SoC
ARM: omap3: enable off mode automatically
clk: imx: imx35: Remove mx35_clocks_init()
clk: imx: imx31: Remove mx31_clocks_init()
clk: imx: imx27: Remove mx27_clocks_init()
ARM: imx: Remove unused definitions
ARM: imx35: Retrieve the IIM base address from devicetree
ARM: imx3: Retrieve the AVIC base address from devicetree
ARM: imx3: Retrieve the CCM base address from devicetree
ARM: imx31: Retrieve the IIM base address from devicetree
ARM: imx27: Retrieve the CCM base address from devicetree
ARM: imx27: Retrieve the SYSCTRL base address from devicetree
ARM: s3c64xx: bring back notes from removed debug-macro.S
ARM: s3c24xx: fix Wunused-variable warning on !MMU
ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
MAINTAINERS: mark linux-samsung-soc list non-moderated
ARM: imx: Remove remnant board file support pieces
...
525c9e5a32 introduced pm_runtime support for the i.MX SPI driver. With
this pm_runtime is used to bring up the clocks initially. When CONFIG_PM
is disabled the clocks are no longer enabled and the driver doesn't work
anymore. Fix this by enabling the clocks in the probe function and
telling pm_runtime that the device is active using
pm_runtime_set_active().
Fixes: 525c9e5a32 spi: imx: enable runtime pm support
Tested-by: Christian Eggers <ceggers@arri.de> [tested for !CONFIG_PM only]
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20201021104513.21560-1-s.hauer@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
The amount of changes is smaller at this round (what a surprise),
but lots of activity is seen. Most of changes are about ASoC
driver development, especially Intel platforms.
Here are some highlights:
General:
* Replace all tasklet usages with other alternatives
* Cleanup of the ASoC error unwinding code
* Fixes for trivial issues caught by static checker
* Spell fixes allover the places
ALSA Core:
* Lockdep fix for control devices
* Fix for potential OSS sequencer mutex stalls
HD-audio and USB-audio:
* SoundBlaster AE-7 support
* Changes in quirk table for the rename handling
* Quirks for HP and ASUS machines, Pioneer DJ DJM-250MK2.
ASoC:
* Lots of updates for Intel SOF and SoundWire enablement
* Replacement of the DSP driver for some older x86 systems;
the new code was written from scratch, better maintenance
expected
* Helpers for parsing auxiluary devices from the device tree
* New support for AllWinner A64, Cirrus Logic CS4234, Mediatek
MT6359 Microchip S/PDIF TX and RX controllers, Realtek RT1015P,
and Texas Instruments J721E, TAS2110, TAS2564 and TAS2764
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl+HHD4OHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9eAw//Wgs9LfQE3rBcsGVNTHimW2cPzbdHVK1eth6N
pFT6rdEG2N+ALR0ESA26CSBniJocqxNvXYzaYT0fy+7tS/chOjhkfr6SttYPDmwc
q2u1SQIqdx41Q0DVUXYxSLVExjT4Rx96qeibLy5pi8DsbL0DOVa7PkVDl1XHXNJ0
iSZwA18gCRdezpoOCD+UF8EBplULjYfPp0xstqjaQzTCpJQ5C1xpbZdHWfhTWsKo
H98d4GL4yUUbJb5/Wi7uqiUGhPIxgBUMVkaY+uRifeNA/MGD5rUZQaf8ft6uQFUL
D5RCUksJiQfyrj++g9/mzOWVRCFZ6MvaAmEW4xwlPvTsP2uIVIqS5RH8Z2BhwjXr
J8/4gPuCtoEKbfsOOCOG9MlGsquf9LBeiH5KZ7gqb7ilu4tICR2zXtBr6U7e64Wd
LsPROQnr/+lxIlEJjlhiarf1jXMfo4glxuoLsDcIH+Baf0lTiMNoBVIZTUdJ0urq
Srh++Bk/WGvoVJe1PHp7IfhZCoBACozPXq7EifbnCsUM+cVtQtjWrydyi8k/Yona
5EfS5wQdEH6JvQirkmGJm8kNMu+e3hW2HzoJqV2Z2DUMMnCSra62KD0wPA/wRchu
mkC47875a+jgo58fq4bX9hzGi2CrE/TMYdii6I2bbAm/Mp7czXZfO0LOTWDc4Bs5
T8qt+HI=
=nWAp
-----END PGP SIGNATURE-----
Merge tag 'sound-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"The amount of changes is smaller at this round (what a surprise), but
lots of activity is seen. Most of changes are about ASoC driver
development, especially Intel platforms. Here are some highlights:
General:
- Replace all tasklet usages with other alternatives
- Cleanup of the ASoC error unwinding code
- Fixes for trivial issues caught by static checker
- Spell fixes allover the places
ALSA Core:
- Lockdep fix for control devices
- Fix for potential OSS sequencer mutex stalls
HD-audio and USB-audio:
- SoundBlaster AE-7 support
- Changes in quirk table for the rename handling
- Quirks for HP and ASUS machines, Pioneer DJ DJM-250MK2.
ASoC:
- Lots of updates for Intel SOF and SoundWire enablement
- Replacement of the DSP driver for some older x86 systems; the new
code was written from scratch, better maintenance expected
- Helpers for parsing auxiluary devices from the device tree
- New support for AllWinner A64, Cirrus Logic CS4234, Mediatek MT6359
Microchip S/PDIF TX and RX controllers, Realtek RT1015P, and Texas
Instruments J721E, TAS2110, TAS2564 and TAS2764"
* tag 'sound-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (498 commits)
ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close
ALSA: hda: fix jack detection with Realtek codecs when in D3
ALSA: fireworks: use semicolons rather than commas to separate statements
ALSA: hda: use semicolons rather than commas to separate statements
ALSA: hda/i915 - fix list corruption with concurrent probes
ASoC: dmaengine: Document support for TX only or RX only streams
ASoC: mchp-spdiftx: remove 'TX' from playback stream name
ASoC: ti: davinci-mcasp: Use &pdev->dev for early dev_warn
ASoC: tas2764: Add the driver for the TAS2764
dt-bindings: tas2764: Add the TAS2764 binding doc
ASoC: Intel: catpt: Add explicit DMADEVICES kconfig dependency
ASoC: Intel: catpt: Fix compilation when CONFIG_MODULES is disabled
ASoC: stm32: dfsdm: add actual resolution trace
ASoC: stm32: dfsdm: change rate limits
ASoC: qcom: sc7180: Add support for audio over DP
Asoc: qcom: lpass-platform : Increase buffer size
ASoC: qcom: Add support for lpass hdmi driver
Asoc: qcom: lpass:Update lpaif_dmactl members order
Asoc:qcom:lpass-cpu:Update dts property read API
ASoC: dt-bindings: Add dt binding for lpass hdmi
...
Baikal-T1 is equipped with three DW APB SSI-based MMIO SPI controllers.
Two of them are pretty much normal: with IRQ, DMA, FIFOs of 64 words
depth, 4x CSs, but the third one as being a part of the Baikal-T1 System
Boot Controller has got a very limited resources: no IRQ, no DMA, only a
single native chip-select and Tx/Rx FIFO with just 8 words depth
available. In order to provide a transparent initial boot code execution
the Boot SPI controller is also utilized by an vendor-specific IP-block,
which exposes an SPI flash direct mapping interface. Since both direct
mapping and SPI controller normal utilization are mutual exclusive only
one of these interfaces can be used to access an external SPI slave
device. That's why a dedicated mux is embedded into the System Boot
Controller. All of that is taken into account in the Baikal-T1-specific DW
APB SSI glue driver implemented by means of the DW SPI core module.
Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-22-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
A functionality of the poll-based transfer has been removed by
commit 1ceb09717e98 ("spi: dw: remove cs_control and poll_mode members
from chip_data") with a justification that "there is no user of one
anymore". It turns out one of our DW APB SSI core is synthesized with no
IRQ line attached and the only possible way of using it is to implement a
poll-based SPI transfer procedure. So we have to get the removed
functionality back, but with some alterations described below.
First of all the poll-based transfer is activated only if the DW SPI
controller doesn't have an IRQ line attached and the Linux IRQ number is
initialized with the IRQ_NOTCONNECTED value. Secondly the transfer
procedure is now executed with a delay performed between writer and reader
methods. The delay value is calculated based on the number of data words
expected to be received on the current iteration. Finally the errors
status is checked on each iteration.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-20-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In some circumstances the current implementation of the SPI memory
operations may occasionally fail even though they are executed in the
atomic context. This may happen if the system bus is relatively slow in
comparison to the SPI bus frequency, or there is a concurrent access to
it, which makes the MMIO-operations occasionally stalling before
push-pulling data from the DW APB SPI FIFOs. These two problems we've
discovered on the Baikal-T1 SoC. In order to fix them we have no choice
but to set an artificial limitation on the SPI bus speed.
Note currently this limitation will be only applicable for the memory
operations, since the standard SPI core interface is implemented with an
assumption that there is no problem with the automatic CS toggling.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-19-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Aside from the synchronous Tx-Rx mode, which has been utilized to create
the normal SPI transfers in the framework of the DW SSI driver, DW SPI
controller supports Tx-only and EEPROM-read modes. The former one just
enables the controller to transmit all the data from the Tx FIFO ignoring
anything retrieved from the MISO lane. The later mode is so called
write-then-read operation: DW SPI controller first pushes out all the data
from the Tx FIFO, after that it'll automatically receive as much data as
has been specified by means of the CTRLR1 register. Both of those modes
can be used to implement the memory operations supported by the SPI-memory
subsystem.
The memory operation implementation is pretty much straightforward, except
a few peculiarities we have had to take into account to make things
working. Since DW SPI controller doesn't provide a way to directly set and
clear the native CS lane level, but instead automatically de-asserts it
when a transfer going on, we have to make sure the Tx FIFO isn't empty
during entire Tx procedure. In addition we also need to read data from the
Rx FIFO as fast as possible to prevent it' overflow with automatically
fetched incoming traffic. The denoted peculiarities get to cause even more
problems if DW SSI controller is equipped with relatively small FIFO and
is connected to a relatively slow system bus (APB) (with respect to the
SPI bus speed). In order to workaround the problems for as much as it's
possible, the memory operation execution procedure collects all the Tx
data into a single buffer and disables the local IRQs to speed the
write-then-optionally-read method up.
Note the provided memory operations are utilized by default only if
a glue driver hasn't provided a custom version of ones and this is not
a DW APB SSI controller with fixed automatic CS toggle functionality.
Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
The DW SSI errors handling method can be generically implemented for all
types of the transfers: IRQ, DMA and poll-based ones. It will be a
function which checks the overflow/underflow error flags and resets the
controller if any of them is set. In the framework of this commit we make
use of the new method to detect the errors in the IRQ- and DMA-based SPI
transfer execution procedures.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-17-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
The parameter will be needed for another wait-done method being added in
the framework of the SPI memory operation modification in a further
commit.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-16-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
By design of the currently available native set_cs callback, the CS
de-assertion will be done only if it's required by the corresponding
controller capability. But in order to pre-fill the Tx FIFO buffer with
data during the SPI memory ops execution the SER register needs to be left
cleared before that. We'll also need a way to explicitly set and clear the
corresponding CS bit at a certain moment of the operation. Let's alter
the set_cs function then to also de-activate the CS, when it's required.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-15-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI memory operations implementation will require to have the CS register
cleared before executing the operation in order not to have the
transmission automatically started prior the Tx FIFO is pre-initialized.
Let's clear the register then on explicit controller reset to fulfil the
requirements in case of an error or having the CS left set by a bootloader
or another software.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-14-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
It's pointless to enable the chip back if the DMA setup procedure fails,
since we'll disable it on the next transfer anyway. For the same reason We
don't do that in case of a failure detected in any other methods called
from the transfer_one() method.
While at it consider any non-zero value returned from the dma_setup
callback to be erroneous as it's supposed to be in the kernel.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-13-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
It's theoretically erroneous to enable IRQ before the chip is turned on.
If IRQ handler gets executed before the chip is enabled, then any data
written to the Tx FIFO will be just ignored.
I say "theoretically" because we haven't noticed any problem with that,
but let's fix it anyway just in case...
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-12-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to make the transfer_one() callback method more readable and
for unification with the DMA-based transfer, let's detach the IRQ setup
procedure into a dedicated function. While at it rename the IRQ-based
transfer handler function to be dw_spi-prefixe and looking more like the
DMA-related one.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-11-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Current IRQ-based SPI transfer execution procedure doesn't work well at
the final stage of the execution. If all the Tx data is sent out (written
to the Tx FIFO) but there is some data left to receive, the Tx FIFO Empty
IRQ will constantly happen until all of the requested inbound data is
received. Though for a short period of time, but it will make the system
less responsive. In order to fix that let's refactor the SPI transfer
execution procedure by taking the Rx FIFO Full IRQ into account. We'll read
and write SPI transfer data each time the IRQ happens as before. If all
the outbound data is sent out, we'll disable the Tx FIFO Empty IRQ. If
there is still some data to receive, we'll adjust the Rx FIFO Threshold
level, so the next IRQ would be raised at the moment of all incoming data
being available in the Rx FIFO.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-10-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
The Tx and Rx data write/read procedure can be significantly simplified by
using Tx/Rx transfer lengths instead of the end pointers. By having the
Tx/Rx data leftover lengths (in the number of transfer words) we can get
rid of all subtraction and division operations utilized here and there in
the tx_max(), rx_max(), dw_writer() and dw_reader() methods. Such
modification will not only give us the more optimized IO procedures, but
will make the data IO methods much more readable than before.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-9-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
DW APB SSI controller can be used by the two SPI core interfaces:
traditional SPI transfers and SPI memory operations. The controller needs
to be accordingly configured at runtime when the corresponding operations
are executed. In order to do that for the both interfaces from a single
function we introduce a new data wrapper for the transfer mode, data
width, number of data frames (for the automatic data transfer) and the bus
frequency. It will be used by the update_config() method to tune the DW
APB SSI up.
The update_config() method is made exported to be used not only by the DW
SPI core driver, but by the glue layer drivers too. This will be required
in a coming further commit.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Rx sample delay can be SPI device specific, and should be synchronously
initialized with the rest of the communication and peripheral device
related controller setups. So let's move the Rx-sample delay setup into
the DW APB SSI configuration update method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-7-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
The code currently responsible for the SPI communication speed setting up
is a bit messy. Most likely for some historical reason the bus frequency
is saved in the peripheral chip private data. It's pointless now since the
custom communication speed is a SPI-transfer-specific thing and only if
there is no SPI transfer data specified (like during the SPI memory
operations) it can be taken from the SPI device structure. But even in the
later case there is no point in having the clock divider and the SPI bus
frequency saved in the chip data, because the controller can be used for
both SPI-transfer-based and SPI-transfer-less communications. From
software point of view keeping the current clock divider in an SPI-device
specific storage may give a small performance gain (to avoid sometimes a
round-up division), but in comparison to the total SPI transfer time it
just doesn't worth saving a few CPU cycles in comparison to the total SPI
transfer time while having the harder to read code. The only optimization,
which could worth preserving in the code is to avoid unnecessary DW SPI
controller registers update if it's possible. So to speak let's simplify
the SPI communication speed update procedure by removing the clock-related
fields from the peripheral chip data and update the DW SPI clock divider
only if it's really changed. The later change is reached by keeping the
effective SPI bus speed in the internal DW SPI private data.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
The SPI bus speed update functionality will be useful in another parts of
the driver too (like to implement the SPI memory operations and from the
DW SPI glue layers). Let's move it to the update_cr0() method then and
since the later is now updating not only the CTRLR0 register alter its
prototype to have a generic function name not related to CR0.
Leave the too long line with the chip->clk_div setting as is for now,
since it's going to be changed later anyway.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Indeed there is no point in detecting the SPI peripheral device parameters
and initializing the CR0 register fields each time an SPI transfer is
executed. Instead let's define a dedicated CR0 chip-data member, which
will be initialized in accordance with the SPI device settings at the
moment of setting it up.
By doing so we'll finally make the SPI device chip_data serving as it's
supposed to - to preserve the SPI device specific DW SPI configuration.
See spi-fsl-dspi.c, spi-pl022.c, spi-pxa2xx.c drivers for example of the
way the chip data is utilized.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently DWC SSI core is supported by means of setting up the
core-specific update_cr0() callback. It isn't suitable for multiple
reasons. First of all having exported several methods doing the same thing
but for different chips makes the code harder to maintain. Secondly the
spi-dw-core driver exports the methods, then the spi-dw-mmio driver sets
the private data callback with one of them so to be called by the core
driver again. That makes the code logic too complicated. Thirdly using
callbacks for just updating the CR0 register is problematic, since in case
if the register needed to be updated from different parts of the code,
we'd have to create another callback (for instance the SPI device-specific
parameters don't need to be calculated each time the SPI transfer is
submitted, so it's better to pre-calculate the CR0 data at the SPI-device
setup stage).
So keeping all the above in mind let's discard the update_cr0() callbacks,
define a generic and static dw_spi_update_cr0() method and create the
DW_SPI_CAP_DWC_SSI capability, which when enabled would activate the
alternative CR0 register layout.
While at it add the comments to the code path of the normal DW APB SSI
controller setup to make the dw_spi_update_cr0() method looking coherent.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify the dw_spi_add_host() method a bit by replacing the currently
implemented default set_cs callback setting up and later having it
overwritten by a custom function with direct if-else-based callback
assignment.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds dev_pm_ops to mtk-nor to support suspend/resume,
auto suspend delay is set to -1 by default.
Accessing registers are only permitted after its clock is enabled
to deal with unknown state of operating clk at probe time.
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20201006155010.v5.4.I68983b582d949a91866163bab588ff3c2a0d0275@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
If the SPI controller has has_dmamode = true and spi_bitbang_start() fails
in spi_imx_probe(), then the driver must release the DMA channels acquired
in spi_imx_sdma_init() by calling spi_imx_sdma_exit() in the fail path.
Fixes: f62caccd12 ("spi: spi-imx: add DMA support")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Robin Gong <b38343@freescale.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Link: https://lore.kernel.org/r/20201005132229.513119-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
s3c64xx_spi_hwinit() disables interrupts. In s3c64xx_spi_probe() after
calling s3c64xx_spi_hwinit() they are enabled with the following call.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-10-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Increase timeout by 30 ms for some wiggle room and set the minimum value
to 100 ms. This ensures a non-zero value for short transfers which
may take less than 1 ms. The timeout value does not affect
performance because it is used with a completion.
Similar formula is used in other drivers e.g. sun4i, sun6i.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-9-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make sure the cur_speed value used in s3c64xx_enable_datapath()
to configure DMA channel and in s3c64xx_wait_for_*() to calculate the
transfer timeout is set to the actual value of (half) the clock speed.
Don't change non-CMU case, because no frequency calculation errors have
been reported.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-8-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove descriptions for non-existent fields and fix indentation.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-7-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rename S3C64XX_SPI_SLAVE_* to S3C64XX_SPI_CS_* to match documentation.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201002122243.26849-6-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Report amount of pending data when a transfer stops due to errors.
Report if DMA was used to transfer data and print the status code.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-5-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Check return values in prepare_dma() and s3c64xx_spi_config() and
propagate errors upwards.
Fixes: 788437273f ("spi: s3c64xx: move to generic dmaengine API")
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-4-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix issues with DMA transfers bigger than 512 bytes on Exynos3250. Without
the patches such transfers fail.
The vendor kernel for ARTIK5 handles CS in a simmilar way.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201002122243.26849-3-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix issues with DMA transfers bigger than 512 bytes on Exynos3250. Without
the patches such transfers fail to complete. This solution to the problem
is found in the vendor kernel for ARTIK5 boards based on Exynos3250.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Link: https://lore.kernel.org/r/20201002122243.26849-2-l.stelmach@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
"program" mode on this controller can trigger up to 56 bits of data
shifting. During the operation, data in PRGDATA[0-5] will be
shifted out from MOSI, and data from MISO will be continuously filling
SHREG[0-9].
Currently this mode is used to implement transfer_one_message for 6-byte
full-duplex transfer, but it can execute a transfer for up-to 7 bytes
as long as the last byte is read only.
transfer_one_message is expected to perform full-duplex transfer,
instead of transfer with specific format. mtk_nor_spi_mem_prg is
added here to use this extra byte.
Newer version of this controller can trigger longer data shifting with
shift bytes more than PRGDATA_MAX + SHREG_MAX. This patch is implemented
with that in mind and it checks against both SHREG_MAX and PRG_CNT_MAX
for future support of new controllers.
Patch 3/3 is a fix for:
commit a59b2c7c56 ("spi: spi-mtk-nor: support standard spi properties")
which breaks supports_op logic. But it can't be separated as it depends
on patch 2/3. Fortuantely the broken commit isn't in stable yet.
Chuanhong Guo (3):
spi: spi-mtk-nor: make use of full capability of prg mode
spi: spi-mtk-nor: add helper for checking prg mode ops
spi: spi-mtk-nor: fix op checks in supports_op
drivers/spi/spi-mtk-nor.c | 179 +++++++++++++++++++++++++++++++++-----
1 file changed, 158 insertions(+), 21 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This patch implements the reporting of the effectively used speed_hz for
the transfer by setting xfer->effective_speed_hz.
See the following patch, which adds this feature to the SPI core for more
information:
commit 5d7e2b5ed5 ("spi: core: allow reporting the effectivly used speed_hz for a transfer")
Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20200921071036.2091-1-thomas.kopp@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit a59b2c7c56 ("spi: spi-mtk-nor: support standard spi properties")
tries to inverse the logic of supports_op when adding
spi_mem_default_supports_op check, but it didn't get it done properly.
There are two regressions introduced by this commit:
1. reading ops supported by program mode is rejected.
2. all ops with special controller routines are incorrectly further
checked against program mode.
This commits inverses the logic back:
1. check spi_mem_default_supports_op and reject unsupported ops first.
2. return true for ops with special controller routines.
3. check the left ops against controller program mode.
Fixes: a59b2c7c56 ("spi: spi-mtk-nor: support standard spi properties")
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/20200924152730.733243-4-gch981213@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
op checking/resizing logic for the newly added mtk_nor_spi_mem_prg is
more complicated. Add two helper functions for them:
mtk_nor_match_prg: check whether an op is supported by prg mode.
mtk_nor_adj_prg_size: adjust data size for mtk_nor_spi_mem_prg.
mtk_nor_match_prg isn't called yet because supports_op is currently
broken. It'll be used in the next fix commit.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/20200924152730.733243-3-gch981213@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
"program" mode on this controller can trigger up to 56 bits of data
shifting. During the operation, data in PRGDATA[0-5] will be
shifted out from MOSI, and data from MISO will be continuously filling
SHREG[0-9].
Currently this mode is used to implement transfer_one_message for 6-byte
full-duplex transfer, but it can execute a transfer for up-to 7 bytes
as long as the last byte is read only.
transfer_one_message is expected to perform full-duplex transfer,
instead of transfer with specific format. mtk_nor_spi_mem_prg is
added here to use this extra byte.
Newer version of this controller can trigger longer data shifting with
shift bytes more than PRGDATA_MAX + SHREG_MAX. This patch is implemented
with that in mind and it checks against both SHREG_MAX and PRG_CNT_MAX
for future support of new controllers.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/20200924152730.733243-2-gch981213@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit d5fab59cab ("spi: atmel: trivial: remove unused fields in
DMA structure"), the driver is not using any definitions from
linux/platform_data/dma-atmel.h, stop including it.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20200930145353.3043699-1-alexandre.belloni@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Originally I intended to merge a dedicated Baikal-T1 System Boot SPI
Controller driver into the kernel and leave the DW APB SSI driver
untouched. But after a long discussion (see the link at the bottom of the
letter) Mark and Andy persuaded me to integrate what we developed there
into the DW APB SSI core driver to be useful for another controllers,
which may have got the same peculiarities/problems as ours:
- No IRQ.
- No DMA.
- No GPIO CS, so a native CS is utilized.
- small Tx/Rx FIFO depth.
- Automatic CS assertion/de-assertion.
- Slow system bus.
All of them have been fixed in the framework of this patchset in some
extent at least for the SPI memory operations. As I expected it wasn't
that easy and the integration took that many patches as you can see from
the subject. Though some of them are mere cleanups or weakly related with
the subject fixes, but we just couldn't leave the code as is at some
places since we were working with the DW APB SSI driver anyway. Here is
what we did to fix the original DW APB SSI driver, to make it less messy.
First two patches are just cleanups to simplify the DW APB SSI device
initialization a bit. We suggest to discard the IRQ threshold macro as
unused and use a ternary operator to initialize the set_cs callback
instead of assigning-and-updating it.
Then we've discovered that the n_bytes field of the driver private data is
used by the DW APB SSI IRQ handler, which requires it to be initialized
before the SMP memory barrier and to be visible from another CPUs. Speaking
about the SMP memory barrier. Having one right after the shared resources
initialization is enough and there is no point in using the spin-lock to
protect the Tx/Rx buffer pointers. The protection functionality is
redundant there by the driver design. (Though I have a doubt whether the
SMP memory barrier is also required there because the normal IO-methods
like readl/writel implies a full memory barrier. So any memory operations
performed before them are supposed to be seen by devices and another CPUs.
See the patch log for details of my concern.)
Thirdly we've found out that there is some confusion in the IRQs
masking/unmasking/clearing in the SPI-transfer procedure. Multiple interrupts
are unmasked on the SPI-transfer initialization, but just TXEI is only
masked back on completion. Similarly IRQ status isn't cleared on the
controller reset, which actually makes the reset being not full and errors
prone in the controller probe procedure.
Another very important optimization is using the IO-relaxed accessors in
the dw_read_io_reg()/dw_write_io_reg() methods. Since the Tx/Rx FIFO data
registers are the most frequently accessible controller resource, using
relaxed accessors there will significantly improve the data read/write
performance. At least on Baikal-T1 SoC such modification opens up a way to
have the DW APB SSI controller working with higher SPI bus speeds, than
without it.
Fifthly we've made an effort to cleanup the code using the SPI-device
private data - chip_data. We suggest to remove the chip type from there
since it isn't used and isn't implemented right anyway. Then instead of
having a bus speed, clock divider, transfer mode preserved there, and
recalculating the CR0 fields of the SPI-device-specific phase, polarity
and frame format each time the SPI transfer is requested, we can save it
in the chip_data instance. By doing so we'll make that structure finally
used as it was supposed to by design (see the spi-fsl-dspi.c, spi-pl022.c,
spi-pxa2xx.c drivers for examples).
Sixthly instead of having the SPI-transfer specific CR0-update callback,
we suggest to implement the DW APB SSI controller capabilities approach.
By doing so we can now inject the vendor-specific peculiarities in
different parts of the DW APB SSI core driver (which is required to
implement both SPI-transfers and the SPI memory operations). This will
also make the code less confusing like defining a callback in the core
driver, setting it up in the glue layer, then calling it from the core
driver again. Seeing the small capabilities implementation embedded
in-situ is more readable than tracking the callbacks assignments. This
will concern the CS-override, Keembay master setup, DW SSI-specific CR0
registers layout capabilities.
Seventhly since there are going to be two types of the transfers
implemented in the DW APB SSI core driver, we need a common method to set
the controller configuration like, Tx/Rx-mode, bus speed, data frame size
and number of data frames to read in case of the memory operations. So we
just detached the corresponding code from the SPI-transfer-one method and
made it to be a part of the new dw_spi_update_config() function, which is
former update_cr0(). Note that the new method will be also useful for the
glue drivers, which due to the hardware design need to create their own
memory operations (for instance, for the dirmap-operations provided in the
Baikal-T System Boot SPI controller driver).
Eighthly it is the data IO procedure and IRQ-based SPI-transfer
implementation refactoring. The former one will look much simpler if the
buffers initial pointers and the buffers length data utilized instead of
the Tx/Rx buffers start and end pointers. The later one currently lacks of
valid execution at the final stage of the SPI-transfer. So if there is no
data left to send, but there is still data which needs to be received, the
Tx FIFO Empty IRQ will constantly happen until all of the requested
inbound data is received. So we suggest to fix that by taking the Rx FIFO
Empty IRQ into account.
Ninthly it's potentially errors prone to enable the DW APB SSI interrupts
before enabling the chip. It specifically concerns a case if for some
reason the DW APB SSI IRQs handler is executed before the controller is
enabled. That will cause a part of the outbound data loss. So we suggest
to reverse the order.
Tenthly in order to be able to pre-initialize the Tx FIFO with data and
only the start the SPI memory operations we need to have any CS
de-activated. We'll fulfil that requirement by explicitly clearing the CS
on the SPI transfer completion and at the explicit controller reset.
Then seeing all the currently available and potentially being created
types of the SPI transfers need to perform the DW APB SSI controller
status register check and the errors handler procedure, we've created a
common method for all of them.
Eleventhly if before we've mostly had a series of fixups, cleanups and
refactorings, here we've finally come to the new functionality
implementation. It concerns the poll-based transfer (as Baikal-T1 System
Boot SPI controller lacks a dedicated IRQ lane connected) and the SPI
memory operations implementation. If the former feature is pretty much
straightforward (see the patch log for details), the later one is a bit
tricky. It's based on the EEPROM-read (write-then-read) and the Tx-only
modes of the DW APB SSI controller, which as performing the automatic data
read and write let's us to implement the faster IO procedure than using
the Tx-Rx-mode-based approach. Having the memory-operations implemented
that way is the best thing we can currently do to provide the errors-less
SPI transfers to SPI devices with native CS attached.
Note the approach utilized here to develop the SPI memory operations can
be also used to create the "automatic CS toggle problem"-free(ish) SPI
transfers (combine SPI-message transfers into two buffers, disable
interrupts, push-pull the combined data). But we don't provide a solution
in the framework of this patchset. It is a matter of a dedicated one,
which we currently don't intend to spend our time on.
Finally at the closure of the this patchset you'll find patches, which
provide the Baikal-T1-specific DW APB SSI controllers support. The SoC has
got three SPI controllers. Two of them are pretty much normal DW APB SSI
interfaces: with IRQ, DMA, FIFOs of 64 words depth, 4x CSs. But the third
one as being a part of the Baikal-T1 System Boot Controller has got a very
limited resources: no IRQ, no DMA, only a single native chip-select and
Tx/Rx FIFOs with just 8 words depth available. In order to provide a
transparent initial boot code execution the System Boot SPI Controller is
also utilized by an vendor-specific IP-block, which exposes an SPI flash
memory direct mapping interface. Please see the corresponding patch for
details.
Link: https://lore.kernel.org/linux-spi/20200508093621.31619-1-Sergey.Semin@baikalelectronics.ru/
[1] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt,
Section "KERNEL I/O BARRIER EFFECTS"
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Lars Povlsen <lars.povlsen@microchip.com>
Cc: wuxu.wu <wuxu.wu@huawei.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (30):
spi: dw: Discard IRQ threshold macro
spi: dw: Use ternary op to init set_cs callback
spi: dw: Initialize n_bytes before the memory barrier
Revert: spi: spi-dw: Add lock protect dw_spi rx/tx to prevent
concurrent calls
spi: dw: Clear IRQ status on DW SPI controller reset
spi: dw: Disable all IRQs when controller is unused
spi: dw: Use relaxed IO-methods to access FIFOs
spi: dw: Discard DW SSI chip type storages
spi: dw: Convert CS-override to DW SPI capabilities
spi: dw: Add KeemBay Master capability
spi: dw: Add DWC SSI capability
spi: dw: Detach SPI device specific CR0 config method
spi: dw: Update SPI bus speed in a config function
spi: dw: Simplify the SPI bus speed config procedure
spi: dw: Update Rx sample delay in the config function
spi: dw: Add DW SPI controller config structure
spi: dw: Refactor data IO procedure
spi: dw: Refactor IRQ-based SPI transfer procedure
spi: dw: Perform IRQ setup in a dedicated function
spi: dw: Unmask IRQs after enabling the chip
spi: dw: Discard chip enabling on DMA setup error
spi: dw: De-assert chip-select on reset
spi: dw: Explicitly de-assert CS on SPI transfer completion
spi: dw: Move num-of retries parameter to the header file
spi: dw: Add generic DW SSI status-check method
spi: dw: Add memory operations support
spi: dw: Introduce max mem-ops SPI bus frequency setting
spi: dw: Add poll-based SPI transfers support
dt-bindings: spi: dw: Add Baikal-T1 SPI Controllers
spi: dw: Add Baikal-T1 SPI Controller glue driver
.../bindings/spi/snps,dw-apb-ssi.yaml | 33 +-
drivers/spi/Kconfig | 29 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-dw-bt1.c | 339 +++++++++
drivers/spi/spi-dw-core.c | 642 ++++++++++++++----
drivers/spi/spi-dw-dma.c | 16 +-
drivers/spi/spi-dw-mmio.c | 36 +-
drivers/spi/spi-dw.h | 85 ++-
8 files changed, 960 insertions(+), 221 deletions(-)
create mode 100644 drivers/spi/spi-dw-bt1.c
--
2.27.0
There is no point in having the commit 19b61392c5 ("spi: spi-dw: Add
lock protect dw_spi rx/tx to prevent concurrent calls") applied. The
commit author made an assumption that the problem with the rx data
mismatch was due to the lack of the data protection. While most likely it
was caused by the lack of the memory barrier. So having the
commit bfda044533 ("spi: dw: use "smp_mb()" to avoid sending spi data
error") applied would be enough to fix the problem.
Indeed the spin unlock operation makes sure each memory operation issued
before the release will be completed before it's completed. In other words
it works as an implicit one way memory barrier. So having both smp_mb()
and the spin_unlock_irqrestore() here is just redundant. One of them would
be enough. It's better to leave the smp_mb() since the Tx/Rx buffers
consistency is provided by the data transfer algorithm implementation:
first we initialize the buffers pointers, then make sure the assignments
are visible by the other CPUs by calling the smp_mb(), only after that
enable the interrupt, which handler uses the buffers.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In a further commit we'll have to get rid of the update_cr0() callback and
define a DW SSI capability instead. Since Keem Bay master/slave
functionality is controller by the CTRL0 register bitfield, we need to
first move the master mode selection into the internal corresponding
update_cr0 method, which would be activated by means of the dedicated
DW_SPI_CAP_KEEMBAY_MST capability setup.
Note this will be also useful if the driver will be ever altered to
support the DW SPI slave interface.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-11-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
There are several vendor-specific versions of the DW SPI controllers,
each of which may have some peculiarities with respect to the original
IP-core. Seeing it has already caused adding flags and a callback into the
DW SPI private data, let's introduce a generic capabilities interface to
tune the generic DW SPI controller driver up in accordance with the
particular controller specifics. It's done by converting a simple
Alpine-specific CS-override capability into the DW SPI controller
capability activated by setting the DW_SPI_CAP_CS_OVERRIDE flag.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-10-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Keeping SPI peripheral devices type is pointless since first it hasn't
been functionally utilized by any of the client drivers/code and second it
won't work for Microwire type at the very least. Moreover there is no
point in setting up the type by means of the chip-data in the modern
kernel. The peripheral devices with specific interface type need to be
detected in order to activate the corresponding frame format. It most
likely will require some peripheral device specific DT property or
whatever to find out the interface protocol. So let's remove the serial
interface type fields from the DW APB SSI controller and the SPI
peripheral device private data.
Note we'll preserve the explicit SSI_MOTO_SPI interface type setting up to
signify the only currently supported interface protocol.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-9-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In accordance with [1] the relaxed methods are guaranteed to be ordered
with respect to other accesses from the same CPU thread to the same
peripheral. This is what we need during the data read/write from/to the
controller FIFOs being executed within a single IRQ handler or a kernel
task.
Such optimization shall significantly speed the data reader and writer up.
For instance, the relaxed IO-accessors utilization on Baikal-T1 lets the
driver to support the SPI memory operations with bus frequency three-fold
faster than if normal IO-accessors would be used.
[1] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt,
Section "KERNEL I/O BARRIER EFFECTS"
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
It's a good practice to disable all IRQs if a device is fully unused. In
our case it is supposed to be done before requesting the IRQ and after the
last byte of an SPI transfer is received. In the former case it's required
to prevent the IRQ handler invocation before the driver data is fully
initialized (which may happen if the IRQs status has been left uncleared
before the device is probed). So we just moved the spi_hw_init() method
invocation to the earlier stage before requesting the IRQ. In the later
case there is just no point in having any of the IRQs enabled between SPI
transfers and when there is no SPI message currently being processed.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-7-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
It turns out the IRQ status isn't cleared after switching the controller
off and getting it back on, which may cause raising false error interrupts
if controller has been unsuccessfully used by, for instance, a bootloader
before the driver is loaded. Let's explicitly clear the interrupts status
in the dedicated controller reset method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Since n_bytes field of the DW SPI private data is also utilized by the
IRQ handler, we need to make sure it' initialization is done before the
memory barrier.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112914.26501-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In case if at least one of the requested DMA engine channels doesn't
support the hardware accelerated SG list entries traverse, the DMA driver
will most likely work that around by performing the IRQ-based SG list
entries resubmission. That might and will cause a problem if the DMA Tx
channel is recharged and re-executed before the Rx DMA channel. Due to
non-deterministic IRQ-handler execution latency the DMA Tx channel will
start pushing data to the SPI bus before the Rx DMA channel is even
reinitialized with the next inbound SG list entry. By doing so the DMA
Tx channel will implicitly start filling the DW APB SSI Rx FIFO up, which
while the DMA Rx channel being recharged and re-executed will eventually
be overflown.
In order to solve the problem we have to feed the DMA engine with SG
list entries one-by-one. It shall keep the DW APB SSI Tx and Rx FIFOs
synchronized and prevent the Rx FIFO overflow. Since in general the SPI
tx_sg and rx_sg lists may have different number of entries of different
lengths (though total length should match) we virtually split the
SG-lists to the set of DMA transfers, which length is a minimum of the
ordered SG-entries lengths.
The solution described above is only executed if a full-duplex SPI
transfer is requested and the DMA engine hasn't provided channels with
hardware accelerated SG list traverse capability to handle both SG
lists at once.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200920112322.24585-12-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to use the DMA submission and waiting methods in both generic
DMA-based SPI transfer and one-by-one DMA SG entries transmission
functions, we need to modify the dw_spi_dma_wait() and
dw_spi_dma_submit_tx()/dw_spi_dma_submit_rx() prototypes. So instead of
getting the SPI transfer object as the second argument they must accept
the exact data structure instances they imply to use. Those are the
current transfer length and the SPI bus frequency in case of
dw_spi_dma_wait(), and SG list together with number of list entries in
case of the DMA Tx/Rx submission methods.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-11-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
DW APB SSI DMA driver doesn't use the native SPI core wait API since
commit bdbdf0f063 ("spi: dw: Locally wait for the DMA transfers
completion"). Due to that the driver can now clear the DMAC register
in a single place synchronously with the DMA transactions completion
or failure. After that all the possible code paths are still covered:
1) DMA completion callbacks are executed in case if the corresponding DMA
transactions are finished. When they are, one of them will eventually wake
the SPI messages pump kernel thread and dw_spi_dma_transfer_all() method
will clean the DMAC register as implied by this patch.
2) dma_stop is called when the SPI core detects an error either returned
from the transfer_one() callback or set in the SPI message status field.
Both types of errors will be noticed by the dw_spi_dma_transfer_all()
method.
3) dma_exit is called when either SPI controller driver or the
corresponding device is removed. In any case the SPI core will first
flush the SPI messages pump kernel thread, so any pending or in-fly
SPI transfers will be finished before that.
Due to all of that let's simplify the DW APB SSI DMA driver a bit and
move the DMAC register cleanup to a single place in the
dw_spi_dma_transfer_all() method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-10-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to add an alternative method of DMA-based SPI transfer first we
need to detach the currently available one from the common code. Here we
move the normal DMA-based SPI transfer execution functionality into a
dedicated method. It will be utilized if either the DMA engine supports
an unlimited number SG entries or Tx-only SPI transfer is requested. But
currently just use it for any SPI transfer.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-9-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
It's pointless to pass the Rx and Tx transfers DMA Tx-descriptors, since
they are used in the Tx/Rx submit method only. Instead just return the
submission status from these methods. This alteration will make the code
less complex.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
We suggest to add the dmaengine_submit() return value test for errors. It
has been unnecessary while the driver was expected to be utilized in pair
with DW DMAC. But since now the driver can be used with any DMA engine, it
might be useful to track the errors on DMA submissions so not miss them
and get into an unpredictable driver behaviour.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-7-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Indeed we can freely move the dmaengine_submit() method invocation and the
Tx and Rx busy flag setting into the DMA Tx/Rx prepare methods. Since the
Tx/Rx preparation method is now mainly used for the DMA transfers
submission, here we suggest to rename it to have the _submit_{r,t}x suffix
instead.
By having this alteration applied first we implement another code
preparation before adding the one-by-one DMA SG entries transmission,
second we now have the dma_async_tx_descriptor descriptor used locally
only in the new DMA transfers submission methods (this will be cleaned up
a bit later), third we make the generic transfer method more readable,
where now the functionality of submission, execution and wait procedures
is transparently split up instead of having a preparation, intermixed
submission/execution and wait procedures.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Checking rx_buf for being NULL and returning NULL from the Rx-channel
preparation method doesn't let us to distinguish that situation from
errors happening during the Rx SG-list preparation. So it's better to make
sure that the rx_buf not-NULL and full-duplex communication is requested
prior calling the Rx preparation method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Mainly this is a preparation patch before adding one-by-one DMA SG entries
transmission. But logically the Tx and Rx DMA channels setup should be
performed in the dma_setup() callback anyway. So we'll move the DMA slave
channels src/dst burst lengths, address and address width configuration
from the Tx/Rx channels preparation methods to the dedicated functions and
then make sure it's called at the DMA setup stage.
Note we now make sure the return value of the dmaengine_slave_config()
method doesn't indicate an error. It has been unnecessary in case if Dw
DMAC is utilized as a DMA engine, since its device_config() callback
always returns zero (though it might change in future). But since DW APB
SSI driver now supports any DMA back-end we must make sure the DMA device
configuration has been successful before proceeding with further setups.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 46164fde6b ("spi: dw: Fix Rx-only DMA transfers") if DMA
interface is enabled, then Tx-buffer must be available in each SPI
transfer. It's required since in order to activate the incoming data
reception either DMA or CPU must be pushing data out to the SPI bus.
But the DW APB SSI DMA driver code is still left in state as if Tx-buffer
might be optional, which is no longer true. Let's fix it so an error would
be returned if no Tx-buffer detected and DMA Tx would be always
enabled.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Indeed the registers content doesn't get cleared when the SPI controller
is disabled and enabled. Max burst lengths aren't changed since the Rx and
Tx DMA channels are requested on init stage and are kept acquired until
the device is removed. Obviously SPI controller FIFO depth can't be
changed. Due to all of that we can safely move the DMA Transmit and
Receive data level registers initialization to the SPI controller DMA init
stage (when the SPI controller is being probed) instead of doing it for
each SPI transfer when dma_setup is called. This shall speed the DMA-based
SPI transfer initialization up a bit, particularly if the APB bus is
relatively slow.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit 530b5affc6 ("spi: fsl-dspi: fix use-after-free in remove
path") this driver causes a kernel oops:
[ 1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
[..]
[ 2.056973] Call trace:
[ 2.059425] dspi_setup+0xc8/0x2e0
[ 2.062837] spi_setup+0xcc/0x248
[ 2.066160] spi_add_device+0xb4/0x198
[ 2.069918] of_register_spi_device+0x250/0x370
[ 2.074462] spi_register_controller+0x4f4/0x770
[ 2.079094] dspi_probe+0x5bc/0x7b0
[ 2.082594] platform_drv_probe+0x5c/0xb0
[ 2.086615] really_probe+0xec/0x3c0
[ 2.090200] driver_probe_device+0x60/0xc0
[ 2.094308] device_driver_attach+0x7c/0x88
[ 2.098503] __driver_attach+0x60/0xe8
[ 2.102263] bus_for_each_dev+0x7c/0xd0
[ 2.106109] driver_attach+0x2c/0x38
[ 2.109692] bus_add_driver+0x194/0x1f8
[ 2.113538] driver_register+0x6c/0x128
[ 2.117385] __platform_driver_register+0x50/0x60
[ 2.122105] fsl_dspi_driver_init+0x24/0x30
[ 2.126302] do_one_initcall+0x54/0x2d0
[ 2.130149] kernel_init_freeable+0x1ec/0x258
[ 2.134520] kernel_init+0x1c/0x120
[ 2.138018] ret_from_fork+0x10/0x34
[ 2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
[ 2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
This is because since this commit, the allocation of the drivers private
data is done explicitly and in this case spi_alloc_master() won't set the
correct pointer.
Also move the platform_set_drvdata() to have both next to each other.
Fixes: 530b5affc6 ("spi: fsl-dspi: fix use-after-free in remove path")
Signed-off-by: Michael Walle <michael@walle.cc>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200928085500.28254-1-michael@walle.cc
Signed-off-by: Mark Brown <broonie@kernel.org>
A small collection of driver specific fixes, the fsl-espi and bcm-qspi
changes in particular have been causing breakage for users.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9uS/ETHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0HO5B/kBy15WzYCeJ1VqAq+HXliT8IvFuGMh
GgwIggHFRpqH9DBMA3PxrjHF9ULfu7wGA2hrSE6Mn2Cxnbt3qsPMU57yRuer9Zb9
ngWNID2BpbyWtXvwDcV7e+0N9ahsgynQR9aJ7JTRfhDBwsHSz9IWF+i6Aug0/I1Z
tDlEm8vhpIJcWuFKX1W7P1pLJ0y/1dqQHQh6vGajuj3c9EOuyrF1BjarfnhhokXL
iB3wdSaj6OAUmkvM4/fZdZrgMDtSoYurDSSTnl4XQPHavwqXbg64s57x/l25ye8N
Zz9lsH9nHCSrBPUnbAI4NpwlQtFx6z7aLUGJp7rcU2OSiSn6QnNc6ycF
=1ejb
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of driver specific fixes, the fsl-espi and bcm-qspi
changes in particular have been causing breakage for users"
* tag 'spi-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: bcm-qspi: Fix probe regression on iProc platforms
spi: fsl-dspi: fix use-after-free in remove path
spi: fsl-espi: Only process interrupts for expected events
spi: bcm2835: Make polling_limit_us static
spi: spi-fsl-dspi: use XSPI mode instead of DMA for DPAA2 SoCs
This series mainly add the IRQ mode support for hisi-sfc-v3xx driver, and some
cleanups for the preparation of the IRQ mode.
After this patch, the device can work in IRQ mode, or if firmware doesn't
declare irq support it will fall back to Poll mode.
Patch 1-2 refactor the .exec_op() path to make it simpler and clearer.
Patch 3 factor the definition of the interrupt bits.
Patch 4 add the IRQ support of the driver.
Yicong Yang (4):
spi: hisi-sfc-v3xx: factor out IO modes configuration
spi: hisi-sfc-v3xx: factor out bus config and transfer functions
spi: hisi-sfc-v3xx: factor out the bit definition of interrupt
register
spi: hisi-sfc-v3xx: add support for IRQ mode
drivers/spi/spi-hisi-sfc-v3xx.c | 261 +++++++++++++++++++++++++++++-----------
1 file changed, 190 insertions(+), 71 deletions(-)
--
2.8.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
CLK_TO_US macro is used to calculate potential transfer time for various
timeout handling. However it overflows on transfer bigger than 512 bytes
because it first did (len * 8 * 1000000).
This controller typically operates at 45MHz. This patch did 2 things:
1. calculate clock / 1000000 first
2. add a 4M transfer size cap so that the final timeout in DMA reading
doesn't overflow
Fixes: 881d1ee9fe ("spi: add support for mediatek spi-nor controller")
Cc: <stable@vger.kernel.org>
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/20200922114905.2942859-1-gch981213@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The controller can work with interrupts, so add support for it.
Then we can work under IRQ mode or Poll mode now, if firmware
doesn't declare the IRQ support, it will fall back to Poll mode.
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/1600950270-52536-5-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The definition of the register field in the interrupt corresponding
registers are the same. So factor them out to public place.
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/1600950270-52536-4-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In hisi_sfc_v3xx_generic_exec_op(), we will write the data to the buffer,
configure and start the transfer, read the data to the buffer and check
whether occurs an error. Factor out the config and transfer start codes
as individual functions, to make the process a bit clearer.
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/1600950270-52536-3-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Factor IO modes configuration out of hisi_sfc_v3xx_generic_exec_op()
using an IO modes lookup table. This will make the process a bit clearer
and reduce the cyclomatic complexity. Simplify the IO mode definition
macros a little bit as well.
Also add the .supports_op() method for the controller mem ops, in order
to avoid OOB access.
Acked-by: John Garry <john.garry@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/1600950270-52536-2-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch implementes the reporting of the effectivly used speed_hz for the
transfer by setting tfr->effective_speed_hz.
See the following patch, which adds this feature to the SPI core for more
information:
5d7e2b5ed5 spi: core: allow reporting the effectivly used speed_hz for a transfer
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20200917202420.1914104-1-mkl@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
spi_unregister_controller() not only unregisters the controller, but
also frees the controller. This will free the driver data with it, so
we must not access it later dspi_remove().
Solve this by allocating the driver data separately from the SPI
controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20200923131026.20707-1-s.hauer@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit 13d515c796 (spi: omap2-mcspi: Switch to
readl_poll_timeout()).
The amount of time spent polling for the MCSPI_CHSTAT bits to be set on
AM335x-icev2 platform is less than 1us (about 0.6us) in most cases, with
or without using DMA. So, in most cases the function need not sleep.
Also, setting the sleep_usecs to zero would not be optimal here because
ktime_add_us() used in readl_poll_timeout() is slower compared to the
direct addition used after the revert. So, it is sub-optimal to use
readl_poll_timeout in this case.
When DMA is not enabled, this revert results in an increase of about 27%
in throughput and decrease of about 20% in CPU usage. However, the CPU
usage and throughput are almost the same when used with DMA.
Therefore, fix this by reverting the commit which switched to using
readl_poll_timeout().
Fixes: 13d515c796 ("spi: omap2-mcspi: Switch to readl_poll_timeout()")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20200910122624.8769-1-a-govindraju@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SPIE register contains counts for the TX FIFO so any time the irq
handler was invoked we would attempt to process the RX/TX fifos. Use the
SPIM value to mask the events so that we only process interrupts that
were expected.
This was a latent issue exposed by commit 3282a3da25 ("powerpc/64:
Implement soft interrupt replay in C").
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20200904002812.7300-1-chris.packham@alliedtelesis.co.nz
Signed-off-by: Mark Brown <broonie@kernel.org>
sg_init_table zeroes its first argument, so the allocation of that argument
doesn't have to.
the semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,n,flags;
@@
x =
- kcalloc
+ kmalloc_array
(n,sizeof(*x),flags)
...
sg_init_table(x,n)
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/1600601186-7420-12-git-send-email-Julia.Lawall@inria.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
This series implements a number of fixes for the FSI-attached SPI
controller driver.
Changes since v1:
- Switch to a new compatible string for the restricted version of the
SPI controller, rather than a new boolean parameter.
Brad Bishop (3):
spi: fsi: Handle 9 to 15 byte transfers lengths
spi: fsi: Fix clock running too fast
spi: fsi: Fix use of the bneq+ sequencer instruction
Eddie James (3):
dt-bindings: fsi: fsi2spi: Add compatible string for restricted
version
spi: fsi: Implement restricted size for certain controllers
spi: fsi: Check mux status before transfers
.../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 1 +
drivers/spi/spi-fsi.c | 139 ++++++++++++++----
2 files changed, 109 insertions(+), 31 deletions(-)
--
2.26.2
Free previously allocated IRQs when return an error code of desc->setup()
which is not always successful. And simplify the code by adding a goto
label.
Fixes: 8f5c285f3e ("SPI: designware: pci: Switch over to MSI interrupts")
CC: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Jay Fang <f.fangjian@huawei.com>
Link: https://lore.kernel.org/r/1600132969-53037-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently NXP fspi driver has support of DT only. Adding ACPI
support to the driver so that it can be used by UEFI firmware
booting in ACPI mode. This driver will be probed if any firmware
will expose HID "NXP0009" in DSDT table.
Signed-off-by: kuldip dwivedi <kuldip.dwivedi@puresoftware.com>
Reviewed-by: Ashish Kumar <Ashish.Kumar@nxp.com>
Link: https://lore.kernel.org/r/20200911130331.6313-1-kuldip.dwivedi@puresoftware.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The info message was showing the mapped address of the device. To avoid
security problems, all virtual addresses are converted to __ptrval__, so
the message was useless/ugly:
[ 2.304949] xilinx_spi b0010000.spi-flash: at 0xB0010000 mapped to 0x(____ptrval____), irq=37
Use %pR instead:
[ 15.021354] xilinx_spi b0010000.spi-flash: at [mem 0xb0010000-0xb001ffff], irq=37
Signed-off-by: Ricardo Ribalda <ribalda@kernel.org>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/20200915112936.320647-1-ribalda@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The SPI controllers are not accessible if the mux isn't set. Therefore,
check the mux status before starting a transfer and fail out if it isn't
set.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200909222857.28653-7-eajames@linux.ibm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of the FSI-attached SPI controllers cannot use the loop command in
programming the sequencer due to security requirements. Check the
devicetree compatibility that indicates this condition and restrict the
size for these controllers. Also, add more transfers directly in the
sequence up to the length of the sequence register.
Fixes: bbb6b2f986 ("spi: Add FSI-attached SPI controller driver")
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200909222857.28653-6-eajames@linux.ibm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
All of the switches in N2_count_control in the counter configuration are
required to make the branch if not equal and increment command work.
Set them when using bneq+.
A side effect of this mode requires a dummy write to TDR when both
transmitting and receiving otherwise the controller won't start shifting
receive data.
It is likely not possible to avoid TDR underrun errors in this mode and
they are harmless, so do not check for them.
Fixes: bbb6b2f986 ("spi: Add FSI-attached SPI controller driver")
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200909222857.28653-4-eajames@linux.ibm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use a clock divider tuned to a 200MHz FSI bus frequency (the maximum). Use
of the previous divider at 200MHz results in corrupt data from endpoint
devices. Ideally the clock divider would be calculated from the FSI clock,
but that would require some significant work on the FSI driver. With FSI
frequencies slower than 200MHz, the SPI clock will simply run slower, but
safely.
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200909222857.28653-3-eajames@linux.ibm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The trailing <len> - 8 bytes of transfer data in this size range is no
longer ignored.
Fixes: bbb6b2f986 ("spi: Add FSI-attached SPI controller driver")
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200909222857.28653-2-eajames@linux.ibm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This eliminates the following sparse warning:
drivers/spi/spi-bcm2835.c:78:14: warning: symbol 'polling_limit_us' was
not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200912072211.602735-1-yanaijie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20200910160706.5883-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If we're sending bytes over SPI, we know the FIFO is empty at the
start of the transfer. There's no reason to wait for the interrupt
telling us to start--we can just start right away. Then if we
transmit everything in one swell foop we don't even need to bother
listening for TX interrupts.
In a test of "flashrom -p ec -r /tmp/foo.bin" interrupts were reduced
from ~30560 to ~29730, about a 3% savings.
This patch looks bigger than it is because I moved a few functions
rather than adding a forward declaration. The only actual change to
geni_spi_handle_tx() was to make it return a bool indicating if there
is more to tx.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Akash Asthana <akashast@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200912111716.1.Ied5e843fad0d6b733a1fb8bcfb364dd2fa889eb3@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
This eliminates the following sparse warning:
drivers/spi/spi-bcm2835.c:78:14: warning: symbol 'polling_limit_us' was
not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200912072211.602735-1-yanaijie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi device tree lacks DMA
channels for DSPI, so naturally, the driver fails to probe:
[ 2.945302] fsl-dspi 2100000.spi: rx dma channel not available
[ 2.951134] fsl-dspi 2100000.spi: can't get dma channels
In retrospect, this should have been obvious, because LS2080A, LS2085A
LS2088A and LX2160A don't appear to have an eDMA module at all. Looking
again at their datasheets, the CTARE register (which is specific to XSPI
functionality) seems to be documented, so switch them to XSPI mode
instead.
Fixes: 0feaf8f5af ("spi: spi-fsl-dspi: Convert the instantiations that support it to DMA")
Reported-by: Qiang Zhao <qiang.zhao@nxp.com>
Tested-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200910121532.1138596-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We always toggle the chip select manually in spi-geni-qcom so that we
can properly implement the Linux API. There's no reason to program
this to the hardware on every transfer. Program it once at init and
be done with it.
This saves some part of a microsecond of overhead on each transfer.
While not really noticeable on any real world benchmarks, we might as
well save the time.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200912140730.2.I33e571179986850b4ec17042e813d0b08fb1b9c1@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
In commit 902481a78e ("spi: spi-geni-qcom: Actually use our FIFO") I
explained that the maximum size we could program the FIFO was
"mas->tx_fifo_depth - 3" but that I chose "mas->tx_fifo_depth()"
because I was worried about decreased bandwidth.
Since that time:
* All the interconnect patches have landed, making things run at the
proper speed.
* I've done more measurements.
This lets me confirm that there's really no downside of using the FIFO
more. Specifically I did "flashrom -p ec -r /tmp/foo.bin" on a
Chromebook and averaged over several runs.
Before: It took 6.66 seconds and 59669 interrupts fired.
After: It took 6.66 seconds and 47992 interrupts fired.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200912140730.1.Ie67fa32009b94702d56232c064f1d89065ee8836@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
It is redundant to do irqsave and irqrestore in hardIRQ context.
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20200910100246.32696-1-song.bao.hua@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Broadcom QSPI driver now falls back to no MSPI_DEV support as the
default setting in the generic compatible string, explicit settings for
STB chips 7425, 7429, and 7435 can be removed.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20200910152539.45584-4-ray.jui@broadcom.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add compatible string for BRCMSTB 7445 SoCs and indicate it has MSPI rev
support.
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20200910152539.45584-2-ray.jui@broadcom.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The variable ret is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200910150410.750959-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Big cleanup for the Samsung S3C24xx and S3C64xx platforms, although it
also touches files shared with S5Pv210 and Exynos. This is mostly Arnd
Bergmann work which Krzysztof Kozlowski took over, rebased and polished.
The goal is to cleanup, merge and finally make the Samsung S3C24xx and
S3C64xx architectures multiplatform. The multiplatform did not happen
yet here - just cleaning up and merging into one arch/arm/mach-s3c
directory. However this is step forward for multiplatform or at least
to keep this code still maintainable.
This pulls also branch with changes for Samsung SoC sound drivers from
broonie/sound because the cleanups there were part of this series and
all further patches depend on them.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAl9NGucQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1zzWD/0T5JdPls++8JUK04hxkunMJO3Ye2ir/a2C
YAI2M6fbOludcPeGCRnPBZ3uTbeSOXFrV6UuSVi8EVKoAb0EV3G50XGQecmy/TVx
nq/c90gtnsODL0Kxjm0767WZl9clKaIE3+VNSyQXAhqJqXK8A1L8ovsUpQEj6fr4
vaNQi6lW7o0r98OEB14M0z59lSWjanUZ33/R22L3AsRihlJTH0Sye2+zVG85LfMD
5okekSHndt2/NCUxgLTZIkp/cD/pzmhMRZTl1zWvZPPFsbzpuB9wZt46b7vkEzuN
NgPElEB9AJgyh/28D064lER6TFhz3TcATZjmEIXX+3tYIaoA2lj60QiSejM2FyBk
U5a0DYAyzwNs4R1GSQxrKnQS1AXQ+yoDniPcyNaSmuZbxaodAs9Hjxg9KfJ2bfs5
DFfSUJhf1Uam8UYolMbXqSkhd2KQjXpkF0eLK7sGk3wanO+YEqVs777fHpwIPLmd
767PD0YN+EfDUwmXAJ5Jgv2kvOJIGul7BTgpWtbRHEaDvLHRQl5OhjsWsj9kWCFX
fx0Jz1sAUqi+gNq3XUFM88/VPEkTgejmVRULnBxqVsar5b/0BeRJEgA6Ljycv0Jv
2ux5zdMuX/+Xc4zdaJOWaL8NqRuT8nSynKXbWHTzJk4cF3p12/g3q3LOHBBLcLL6
AzTEA6iZ0w==
=bjMI
-----END PGP SIGNATURE-----
Merge tag 'samsung-soc-s3c-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc
Samsung S3C24xx and S3C64xx machine code cleanup for v5.10
Big cleanup for the Samsung S3C24xx and S3C64xx platforms, although it
also touches files shared with S5Pv210 and Exynos. This is mostly Arnd
Bergmann work which Krzysztof Kozlowski took over, rebased and polished.
The goal is to cleanup, merge and finally make the Samsung S3C24xx and
S3C64xx architectures multiplatform. The multiplatform did not happen
yet here - just cleaning up and merging into one arch/arm/mach-s3c
directory. However this is step forward for multiplatform or at least
to keep this code still maintainable.
This pulls also branch with changes for Samsung SoC sound drivers from
broonie/sound because the cleanups there were part of this series and
all further patches depend on them.
* tag 'samsung-soc-s3c-5.10' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: (62 commits)
ARM: s3c: Avoid naming clash of S3C24xx and S3C64xx timer setup
ARM: s3c: Cleanup from old plat-samsung include
ARM: s3c: make headers local if possible
ARM: s3c: move into a common directory
ARM: s3c24xx: stop including mach/hardware.h from mach/io.h
cpufreq: s3c24xx: move low-level clk reg access into platform code
cpufreq: s3c2412: use global s3c2412_cpufreq_setrefresh
ARM: s3c: remove cpufreq header dependencies
cpufreq: s3c24xx: split out registers
fbdev: s3c2410fb: remove mach header dependency
ARM: s3c24xx: bast: avoid irq_desc array usage
ARM: s3c24xx: spi: avoid hardcoding fiq number in driver
ARM: s3c24xx: include mach/irqs.h where needed
ARM: s3c24xx: move s3cmci pinctrl handling into board files
ARM: s3c24xx: move iis pinctrl config into boards
ARM: s3c24xx: move spi fiq handler into platform
ARM: s3c: adc: move header to linux/soc/samsung
ARM: s3c24xx: move irqchip driver back into platform
ARM: s3c24xx: move regs-spi.h into spi driver
ARM: s3c64xx: remove mach/hardware.h
...
Link: https://lore.kernel.org/r/20200831154751.7551-1-krzk@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
There's some driver specific fixes here plus one core fix for memory
leaks that could be triggered by a potential race condition when
cleaning up after we have split transfers to fit into what the
controller can support.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9bavQTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0JuiCACAZcBZFb6hshADoyt9YCCjQrD1+khD
AzkSuDOE6UP3SGOEBx/29QL1kE7j0V9ARC0XLVZutzZhUXbIvJ1ulgUqGgeQSnLz
ZvO/rIJiC+lsKIZQANgOBjOzWhfRzYXPOwfQwtsta5NfrP5ZafKJ5iG2C0xjnETr
Arybcx8D/EDZWKQ9PntM246J/jlmK+dsnK6wouqHlP2ulo3O4UQUxN0D5SjUC0RW
3xMH165RvIqwu0L5iCUWmzQhPuxuhk2QWpt48k3dPghmNx9XNGJuHDRI0THRxIp/
2mNRXiK0qKma4AwWO7+JJshyeXufR07HNMYfkL/d159K6QOsu1Uaq4z4
=d1ma
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"There's some driver specific fixes here plus one core fix for memory
leaks that could be triggered by a potential race condition when
cleaning up after we have split transfers to fit into what the
controller can support"
* tag 'spi-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: stm32: fix pm_runtime_get_sync() error checking
spi: Fix memory leak on splited transfers
spi: spi-cadence-quadspi: Fix mapping of buffers for DMA reads
spi: stm32: Rate-limit the 'Communication suspended' message
spi: spi-loopback-test: Fix out-of-bounds read
spi: spi-cadence-quadspi: Populate get_name() interface
MAINTAINERS: add myself as maintainer for spi-fsl-dspi driver
The arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi device tree lacks DMA
channels for DSPI, so naturally, the driver fails to probe:
[ 2.945302] fsl-dspi 2100000.spi: rx dma channel not available
[ 2.951134] fsl-dspi 2100000.spi: can't get dma channels
In retrospect, this should have been obvious, because LS2080A, LS2085A
LS2088A and LX2160A don't appear to have an eDMA module at all. Looking
again at their datasheets, the CTARE register (which is specific to XSPI
functionality) seems to be documented, so switch them to XSPI mode
instead.
Fixes: 0feaf8f5af ("spi: spi-fsl-dspi: Convert the instantiations that support it to DMA")
Reported-by: Qiang Zhao <qiang.zhao@nxp.com>
Tested-by: Qiang Zhao <qiang.zhao@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200910121532.1138596-1-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hello,
This cleans up some of the user code around calls to
dev_pm_opp_of_remove_table().
All the patches can be picked by respective maintainers directly except
for the last patch, which needs the previous two to get merged first.
These are based for 5.9-rc1.
Rajendra, Since most of these changes are related to qcom stuff, it
would be great if you can give them a try. I wasn't able to test them
due to lack of hardware.
Ulf, I had to revise the sdhci patch, sorry about that. Please pick this
one.
Diff between V1 and V2 is mentioned in each of the patches separately.
Viresh Kumar (8):
cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table()
drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table()
spi: spi-geni-qcom: Unconditionally call dev_pm_opp_of_remove_table()
spi: spi-qcom-qspi: Unconditionally call dev_pm_opp_of_remove_table()
tty: serial: qcom_geni_serial: Unconditionally call
dev_pm_opp_of_remove_table()
qcom-geni-se: remove has_opp_table
drivers/cpufreq/imx6q-cpufreq.c | 10 ++--------
drivers/gpu/drm/lima/lima_devfreq.c | 6 +-----
drivers/gpu/drm/lima/lima_devfreq.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 +++++---------
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_host.c | 8 ++------
drivers/mmc/host/sdhci-msm.c | 14 +++++---------
drivers/spi/spi-geni-qcom.c | 13 +++++--------
drivers/spi/spi-qcom-qspi.c | 15 ++++++---------
drivers/tty/serial/qcom_geni_serial.c | 13 +++++--------
include/linux/qcom-geni-se.h | 2 --
11 files changed, 31 insertions(+), 66 deletions(-)
base-commit: f4d51dffc6
--
2.25.0.rc1.19.g042ed3e048af
In spidev_read() and spidev_write(), the variable status is being
initialized with a value that is never read and it is being updated
later with a new value. The initialization is redundant and can be
removed.
Signed-off-by: Jay Fang <f.fangjian@huawei.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1599631704-53232-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
While at it, create a new label and put clkname on errors.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/b77aa0bbe82a580508e321a34da488b4b27966d0.1598594714.git.viresh.kumar@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
While at it, create a new label and put clkname on errors.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/ea0864d41277e61fa31d304fbd4cf9af6b314269.1598594714.git.viresh.kumar@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The pm_runtime_get_sync() can return either 0 or 1 on success but this
code treats 1 as a failure.
Fixes: db96bf976a ("spi: stm32: fixes suspend/resume management")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Alain Volmat <alain.volmat@st.com>
Link: https://lore.kernel.org/r/20200909094304.GA420136@mwanda
Signed-off-by: Mark Brown <broonie@kernel.org>
In the prepare_message callback the bus driver has the
opportunity to split a transfer into smaller chunks.
spi_map_msg is done after prepare_message.
Function spi_res_release releases the splited transfers
in the message. Therefore spi_res_release should be called
after spi_map_msg.
The previous try at this was commit c9ba7a16d0
which released the splited transfers after
spi_finalize_current_message had been called.
This introduced a race since the message struct could be
out of scope because the spi_sync call got completed.
Fixes this leak on spi bus driver spi-bcm2835.c when transfer
size is greater than 65532:
Kmemleak:
sg_alloc_table+0x28/0xc8
spi_map_buf+0xa4/0x300
__spi_pump_messages+0x370/0x748
__spi_sync+0x1d4/0x270
spi_sync+0x34/0x58
spi_test_execute_msg+0x60/0x340 [spi_loopback_test]
spi_test_run_iter+0x548/0x578 [spi_loopback_test]
spi_test_run_test+0x94/0x140 [spi_loopback_test]
spi_test_run_tests+0x150/0x180 [spi_loopback_test]
spi_loopback_test_probe+0x50/0xd0 [spi_loopback_test]
spi_drv_probe+0x84/0xe0
Signed-off-by: Gustav Wiklander <gustavwi@axis.com>
Link: https://lore.kernel.org/r/20200908151129.15915-1-gustav.wiklander@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The series add support for the Sparx5 SoC SPI controller in the
spi-dw-mmio.c spi driver.
v5 changes:
- rx-sample-delay-ns documentation changes from Rob Herring:
- Drop superfluous type $ref
- Add default value = 0
v4 changes:
- Changed snps,rx-sample-delay-ns to snps,rx-sample-delay-ns
suggested by Rob Herring (rockchip also has this property).
- Added support for controller-level rx-sample-delay-ns value as
well as per SPI slave value (rockchip has controller-level property).
- Dropped internal mux in favor of suggested spi-mux to
control bus inteface selection.
v3 changes:
- Added mux support for controlling SPI bus interface. This is new mux
driver, bindings and added to sparx5 base DT.
- Removed "microchip,spi-interface2" property in favour of
"mux-controls" property in SPI controller (sparx5 only).
- Changed dw_spi_sparx5_set_cs() to use the mux control instead of
directly acessing "mux" register. Associated code/defines moved to mux
driver.
- Changed dw_spi_sparx5_set_cs() to match other similar functions in
signature and avoid explicit CS toggling.
- Spun off duplicated NAND device DT chunks into separate DT file.
v2 changes:
- Moved all RX sample delay into spi-dw-core.c, using
the "snps,rx-sample-delay-ns" device property.
- Integrated Sparx5 support directly in spi-dw-mmio.c
- Changed SPI2 configuration to per-slave "microchip,spi-interface2"
property.
- Added bindings to existing snps,dw-apb-ssi.yaml file
- Dropped patches for polled mode and SPI memory operations.
Lars Povlsen (6):
spi: dw: Add support for RX sample delay register
spi: dw: Add Microchip Sparx5 support
arm64: dts: sparx5: Add SPI controller and associated mmio-mux
dt-bindings: snps,dw-apb-ssi: Add sparx5 support, plus
rx-sample-delay-ns property
arm64: dts: sparx5: Add spi-nor support
arm64: dts: sparx5: Add spi-nand devices
.../bindings/spi/snps,dw-apb-ssi.yaml | 21 ++++++
arch/arm64/boot/dts/microchip/sparx5.dtsi | 47 ++++++++++++-
.../arm64/boot/dts/microchip/sparx5_nand.dtsi | 31 ++++++++
.../boot/dts/microchip/sparx5_pcb125.dts | 30 ++++++++
.../boot/dts/microchip/sparx5_pcb134.dts | 1 +
.../dts/microchip/sparx5_pcb134_board.dtsi | 16 +++++
.../boot/dts/microchip/sparx5_pcb135.dts | 1 +
.../dts/microchip/sparx5_pcb135_board.dtsi | 16 +++++
drivers/spi/spi-dw-core.c | 26 +++++++
drivers/spi/spi-dw-mmio.c | 70 ++++++++++++++++++-
drivers/spi/spi-dw.h | 3 +
11 files changed, 260 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/microchip/sparx5_nand.dtsi
--
2.27.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Use default supports_op() to support spi-[rt]x-bus-width properties.
And check dummy op's byte length instead of its bus width for output.
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20200826091852.519138-1-ikjn@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-11-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-10-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-9-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-8-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-7-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-6-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20200901152713.18629-5-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20200901152713.18629-4-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and the error value gets printed.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20200901152713.18629-3-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If dma_request_chan() for TX channel fails with EPROBE_DEFER, the RX
channel would not be released and on next re-probe it would be requested
second time.
Fixes: 386119bc7b ("spi: sprd: spi: sprd: Add DMA mode support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20200901152713.18629-1-krzk@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds SPI support for the Sparx5 SoC, which is using the MMIO
Designware SPI controller.
The Sparx5 differs from the Ocelot version in these areas:
* The CS override is controlled by a new set of registers for
this purpose.
* The Sparx5 SPI controller has the RX sample delay register, and it
must be configured for the (SPI NAND) device on SPI2.
* The Sparx5 SPI controller has 2 different SPI bus interfaces on the
same controller (don't ask...). The "spi-mux" driver should be used
in conjunction with the SPI driver to select the appropriate bus.
Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
Link: https://lore.kernel.org/r/20200824203010.2033-3-lars.povlsen@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This add support for the RX_SAMPLE_DLY register. If enabled in the
Designware IP, it allows tuning of the rx data signal by means of an
internal rx sample fifo.
The register is controlled by the rx-sample-delay-ns DT property,
which is defined per SPI slave as well on controller level.
The controller level rx-sample-delay-ns will apply to all slaves
without the property explicitly defined.
The register is located at offset 0xf0, and if the option is not
enabled in the IP, changing the register will have no effect. The
register will only be written if any slave defines a nonzero value
(after scaling by the clock period).
Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
Link: https://lore.kernel.org/r/20200824203010.2033-2-lars.povlsen@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Buffers need to mapped to DMA channel's device pointer instead of SPI
controller's device pointer as its system DMA that actually does data
transfer.
Data inconsistencies have been reported when reading from flash
without this fix.
Fixes: ffa639e069 ("mtd: spi-nor: cadence-quadspi: Add DMA support for direct mode reads")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
Link: https://lore.kernel.org/r/20200831130720.4524-1-vigneshr@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There seems no reason to restrict testing to ARM, so remove this
constraint to improve test coverage.
Build-tested with allyesconfig on x86.
Signed-off-by: Alex Dewar <alex.dewar90@gmail.com>
Link: https://lore.kernel.org/r/20200904163709.110975-1-alex.dewar90@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
