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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Set the struct spi_controller max_speed_hz. This is based on the
reported source clock frequency during probe. The maximum bus clock
is half the source clock (as per the code in bcm2835_spi_transfer_one).
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210107164825.21919-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi Mark,
This patch series makes the Renesas MSIOF SPI driver fill in actual
transfer speeds and controller limits, so the SPI core can take them
into account.
This has been tested on R-Car Gen2 and Gen3.
Thanks!
Geert Uytterhoeven (2):
spi: sh-msiof: Fill in spi_transfer.effective_speed_hz
spi: sh-msiof: Fill in controller speed limits
drivers/spi/spi-sh-msiof.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Add QSPI controller support for Intel LGM SoC.
Patches to move move bindings over to
"Documentation/devicetree/bindings/spi/" directory and also added compatible
Support for Intel platform.
dt-bindings: spi: cadence-qspi: Add support for Intel lgm-qspi
(earlier patch mail thread and Ack-by)
link: "https://lore.kernel.org/lkml/5d6d1b85.1c69fb81.96938.0315@mx.google.com/"
Reference:
https://lkml.org/lkml/2020/6/1/50
---
v9:
- Vignesh review comments address and update
- Retain the patchv4 move the binding documentation from mtd to spi
directory.
- Add intel's compatible string over the legacy documentation
- Remove unused variable, CQSPI_SUPPORTS_MULTI_CHIPSELECT macro and check
- YAML convertion patch alone dropped
v8:
- As Mark suggested to add the dt-bindings documentation patches
end of the series , so dropped.
v7:
- Rob's review comments address and fixed dt-schema warning
- Pratyush review comments address and update
- DAC bit reset to 0 and 1 (enable/disable)
- tested QSI-NOR flash mx25l12805d on LGM soc, it's working after disable DAC
- Linus suggested to use 'num-cs' prperty instead of 'num-chipselect'
v6:
- Rob's review comments update
- add compatible string in properly aligned
- remove cadence-qspi extra comaptible string in example
v5:
- Rob's review comments update
- const with single compatible string kept
v4:
- Rob's review comments update
- remove '|' no formatting to preserve
- child node attributes follows under 'properties' under '@[0-9a-f]+$'.
v3:
- Pratyush review comments update
- CQSPI_SUPPORTS_MULTI_CHIPSELECT macro used instead of cqspi->use_direct_mode
- disable DAC support placed in end of controller_init
v2:
- Rob's review comments update for dt-bindings
- add 'oneOf' for compatible selection
- drop un-neccessary descriptions
- add the cdns,is-decoded-cs and cdns,rclk-en properties as schema
- remove 'allOf' in not required place
- add AdditionalProperties false
- add minItems/maxItems for qspi reset attributes
resend-v1:
- As per Mark's suggestion , reorder the patch series 1-3 driver
support patches, series 4-6 dt-bindings patches.
v1:
- initial version
Ramuthevar Vadivel Murugan (5):
spi: cadence-quadspi: Add QSPI support for Intel LGM SoC
spi: cadence-quadspi: Disable the DAC for Intel LGM SoC
spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi
dt-bindings: spi: cadence-qspi: Add support for Intel lgm-qspi
.../bindings/{mtd => spi}/cadence-quadspi.txt | 1 +
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-cadence-quadspi.c | 24 ++++++++++++++++++----
3 files changed, 22 insertions(+), 5 deletions(-)
rename Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt (97%)
--
2.11.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Simplify stm32h7_spi_prepare_fthlv() function implementation,
no functional change intended.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alain Volmat <alain.volmat@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Amelie Delaunay <amelie.delaunay@st.com>
Cc: Antonio Borneo <antonio.borneo@st.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Roman Guskov <rguskov@dh-electronics.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-spi@vger.kernel.org
Link: https://lore.kernel.org/r/20210104123114.261596-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't need to force this to be trigger high here, as the firmware
properly configures the irq flags already. Drop it to save a line.
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
Cc: Akash Asthana <akashast@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210112001301.687628-1-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently we use concrete version to determine the max_cmd_dword.
New entries should be added for compatible hardwares of new version
or on new platform, otherwise the device will use 16 dwords instead
of 64 even if it supports, which will degrade the performance.
This will decrease the compatibility and the maintainability.
Drop the switch-case statement of the version checking. Only version
less than 0x351 supports maximum 16 command dwords.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Acked-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/1610526716-14882-1-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fill in the controller speed limits, so the SPI core can use them for
validating SPI transfers, and adjust or reject transfers when needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210113101916.1147695-3-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
Fill in the effective bit rate used for transfers, so the SPI core can
calculate instead of estimate delays.
Restore "reverse Christmas tree" order of local variables while adding
new variables.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210113101916.1147695-2-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).
This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfe
DAC bit resets to 1 so there is no need to explicitly set it.
Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
Link: https://lore.kernel.org/r/20201124041840.31066-3-vadivel.muruganx.ramuthevar@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With CONFIG_PM_SLEEP disabled the rpcif_spi_pm_ops variable is still
referenced and thus increasing the size of kernel.
Fix this issue by adding CONFIG_PM_SLEEP #ifdef check around the .pm
assignment (image size is critical on RZ/A SoC's where the SRAM sizes
range 4~5 MiB).
Fixes: 9584fc95ca ("spi: rpc-if: Remove CONFIG_PM_SLEEP ifdefery")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Suggested-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20210107145329.27966-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The kernel test robot reports the following warning.
drivers/spi/spi-cadence-quadspi.c:966:24: warning: comparison of distinct pointer types ('typeof (len) *' (aka 'unsigned int *') and 'typeof (500UL) *' (aka 'unsigned long *')) [-Wcompare-distinct-pointer-types]
msecs_to_jiffies(max(len, 500UL)))) {
^~~~~~~~~~~~~~~
include/linux/minmax.h:58:19: note: expanded from macro 'max'
#define max(x, y) __careful_cmp(x, y, >)
^~~~~~~~~~~~~~~~~~~~~~
include/linux/minmax.h:42:24: note: expanded from macro '__careful_cmp'
__builtin_choose_expr(__safe_cmp(x, y), \
^~~~~~~~~~~~~~~~
include/linux/minmax.h:32:4: note: expanded from macro '__safe_cmp'
(__typecheck(x, y) && __no_side_effects(x, y))
^~~~~~~~~~~~~~~~~
include/linux/minmax.h:18:28: note: expanded from macro '__typecheck'
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
1 warning generated.
This happens because size_t is unsigned long on 64-bit platforms like
arm64 but it is unsigned int on 32-bit platforms like arm. Omitting the
"UL" would result in a warning on 64-bit platforms. Squash it by type
casting the arguments to size_t using max_t(). This way builds on both
type of platforms can be satisfied. There is no chance of any truncation
since 500 is small enough to fit into both int and long.
Fixes: f453f29397 ("spi: cadence-quadspi: Wait at least 500 ms for direct reads")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20210108181457.30291-1-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix a new warning report by build for make ARCH=MIPS allmodconfig:
drivers/spi/spi-cadence-quadspi.c: In function 'cqspi_direct_read_execute':
./include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast
18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~
./include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
32 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~~~~~~~~~
./include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
42 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~~~~~~~~~
./include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp'
58 | #define max(x, y) __careful_cmp(x, y, >)
| ^~~~~~~~~~~~~
drivers/spi/spi-cadence-quadspi.c:1153:24: note: in expansion of macro 'max'
1153 | msecs_to_jiffies(max(len, 500UL)))) {
| ^~~
"len" is unsigned,however,"500" is unsigned long.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Link: https://lore.kernel.org/r/20210107115704.3835282-1-siyanteng@loongson.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
