In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the current
`delay_usecs` with `delay` for this driver.
The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
that both `delay_usecs` & `delay` are used (in this order to preserve
backwards compatibility).
[1] commit bebcfd272d ("spi: introduce `delay` field for
`spi_transfer` + spi_transfer_delay_exec()")
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
Link: https://lore.kernel.org/r/20200227143931.20688-1-sergiu.cuciurean@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Ericsson U300 platform was one of two ARM929 based SoC platforms for
mobile phones in ST-Ericsson after the merger of Ericsson with ST-NXP
into ST-Ericsson, the other one being the ST Nomadik.
The platform was not widely adopted in Linux based systems and was
replaced with the far superior ST-Ericsson U8500 in 2011, but Linus
Walleij kept maintaining the code for the whole time.
Linus continues to use the Nomadik machine, but decided to drop
u300 from the kernel as part of this year's spring cleaning.
Thanks for having maintained it all these years.
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/lkml/CACRpkdbJkiHR9FSfJTH_5d_qRU1__dRXHM1TL40iqNRKbGQfrQ@mail.gmail.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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/
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>
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>
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>
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>
