linux/drivers/spi, branch v6.4

spi: spi-geni-qcom: correctly handle -EPROBE_DEFER from dma_request_chan()

2023-06-15T13:58:45Z

Now spi_geni_grab_gpi_chan() errors are correctly reported, the -EPROBE_DEFER error should be returned from probe in case the GPI dma driver is built as module and/or not probed yet. Fixes: b59c122484ec ("spi: spi-geni-qcom: Add support for GPI dma") Fixes: 6532582c353f ("spi: spi-geni-qcom: fix error handling in spi_geni_grab_gpi_chan()") Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20230615-topic-sm8550-upstream-fix-spi-geni-qcom-probe-v2-1-670c3d9e8c9c@linaro.org Signed-off-by: Mark Brown

spi: dw: Replace incorrect spi_get_chipselect with set

2023-06-13T19:19:26Z

Commit 445164e8c136 ("spi: dw: Replace spi->chip_select references with function calls") replaced direct access to spi.chip_select with spi_*_chipselect calls but incorrectly replaced a set instance with a get instance, replace the incorrect instance. Fixes: 445164e8c136 ("spi: dw: Replace spi->chip_select references with function calls") Signed-off-by: Abe Kohandel Reviewed-by: Andy Shevchenko Acked-by: Serge Semin Link: https://lore.kernel.org/r/20230613162103.569812-1-abe.kohandel@intel.com Signed-off-by: Mark Brown

spi: fsl-dspi: avoid SCK glitches with continuous transfers

2023-06-06T15:49:20Z

The DSPI controller has configurable timing for (a) tCSC: the interval between the assertion of the chip select and the first clock edge (b) tASC: the interval between the last clock edge and the deassertion of the chip select What is a bit surprising, but is documented in the figure "Example of continuous transfer (CPHA=1, CONT=1)" in the datasheet, is that when the chip select stays asserted between multiple TX FIFO writes, the tCSC and tASC times still apply. With CONT=1, chip select remains asserted, but SCK takes a break and goes to the idle state for tASC + tCSC ns. In other words, the default values (of 0 and 0 ns) result in SCK glitches where the SCK transition to the idle state, as well as the SCK transition from the idle state, will have no delay in between, and it may appear that a SCK cycle has simply gone missing. The resulting timing violation might cause data corruption in many peripherals, as their chip select is asserted. The driver has device tree bindings for tCSC ("fsl,spi-cs-sck-delay") and tASC ("fsl,spi-sck-cs-delay"), but these are only specified to apply when the chip select toggles in the first place, and this timing characteristic depends on each peripheral. Many peripherals do not have explicit timing requirements, so many device trees do not have these properties present at all. Nonetheless, the lack of SCK glitches is a common sense requirement, and since the SCK stays in the idle state during transfers for tCSC+tASC ns, and that in itself should look like half a cycle, then let's ensure that tCSC and tASC are at least a quarter of a SCK period, such that their sum is at least half of one. Fixes: 95bf15f38641 ("spi: fsl-dspi: Add ~50ns delay between cs and sck") Reported-by: Lisa Chen (陈敏捷) Debugged-by: Lisa Chen (陈敏捷) Tested-by: Lisa Chen (陈敏捷) Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20230529223402.1199503-1-vladimir.oltean@nxp.com Signed-off-by: Mark Brown

spi: cadence-quadspi: Add missing check for dma_set_mask

2023-06-06T12:52:41Z

Add check for dma_set_mask() and return the error if it fails. Fixes: 1a6f854f7daa ("spi: cadence-quadspi: Add Xilinx Versal external DMA support") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20230606093859.27818-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown

spi: qup: Request DMA before enabling clocks

2023-05-30T12:43:31Z

It is usually better to request all necessary resources (clocks, regulators, ...) before starting to make use of them. That way they do not change state in case one of the resources is not available yet and probe deferral (-EPROBE_DEFER) is necessary. This is particularly important for DMA channels and IOMMUs which are not enforced by fw_devlink yet (unless you use fw_devlink.strict=1). spi-qup does this in the wrong order, the clocks are enabled and disabled again when the DMA channels are not available yet. This causes issues in some cases: On most SoCs one of the SPI QUP clocks is shared with the UART controller. When using earlycon UART is actively used during boot but might not have probed yet, usually for the same reason (waiting for the DMA controller). In this case, the brief enable/disable cycle ends up gating the clock and further UART console output will halt the system completely. Avoid this by requesting the DMA channels before changing the clock state. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20230518-spi-qup-clk-defer-v1-1-f49fc9ca4e02@gerhold.net Signed-off-by: Mark Brown

spi: mt65xx: make sure operations completed before unloading

2023-05-23T22:19:55Z

When unloading the spi-mt65xx kernel module during an ongoing spi-mem operation the kernel will Oops shortly after unloading the module. This is because wait_for_completion_timeout was still running and returning into the no longer loaded module: Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: [many, but spi-mt65xx is no longer there] CPU: 0 PID: 2578 Comm: block Tainted: G W O 6.3.0-next-20230428+ #0 Hardware name: Bananapi BPI-R3 (DT) pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __lock_acquire+0x18c/0x20e8 lr : __lock_acquire+0x9b8/0x20e8 sp : ffffffc009ec3400 x29: ffffffc009ec3400 x28: 0000000000000001 x27: 0000000000000004 x26: ffffff80082888c8 x25: 0000000000000000 x24: 0000000000000000 x23: ffffffc009609da8 x22: ffffff8008288000 x21: ffffff8008288968 x20: 00000000000003c2 x19: ffffff8008be7990 x18: 00000000000002af x17: 0000000000000000 x16: 0000000000000000 x15: ffffffc008d78970 x14: 000000000000080d x13: 00000000000002af x12: 00000000ffffffea x11: 00000000ffffefff x10: ffffffc008dd0970 x9 : ffffffc008d78918 x8 : 0000000000017fe8 x7 : 0000000000000001 x6 : 0000000000000000 x5 : ffffff807fb53910 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000027 x1 : 0000000000000000 x0 : 00000000000c03c2 Call trace: __lock_acquire+0x18c/0x20e8 lock_acquire+0x100/0x2a4 _raw_spin_lock_irq+0x58/0x74 __wait_for_common+0xe0/0x1b4 wait_for_completion_timeout+0x1c/0x24 0xffffffc000acc8a4 <--- used to be mtk_spi_transfer_wait spi_mem_exec_op+0x390/0x3ec spi_mem_no_dirmap_read+0x6c/0x88 spi_mem_dirmap_read+0xcc/0x12c spinand_read_page+0xf8/0x1dc spinand_mtd_read+0x1b4/0x2fc mtd_read_oob_std+0x58/0x7c mtd_read_oob+0x8c/0x148 mtd_read+0x50/0x6c ... Prevent this by completing in mtk_spi_remove if needed. Fixes: 9f763fd20da7 ("spi: mediatek: add spi memory support for ipm design") Signed-off-by: Daniel Golle Link: https://lore.kernel.org/r/ZFAF6pJxMu1z6k4w@makrotopia.org Signed-off-by: Mark Brown

spi: lpspi: disable lpspi module irq in DMA mode

2023-05-23T18:22:45Z

When all bits of IER are set to 0, we still can observe the lpspi irq events when using DMA mode to transfer data. So disable irq to avoid the too much irq events. Signed-off-by: Clark Wang Link: https://lore.kernel.org/r/20230505063557.3962220-1-xiaoning.wang@nxp.com Signed-off-by: Mark Brown

spi: spi-cadence: Interleave write of TX and read of RX FIFO

2023-05-22T10:41:05Z

When working in slave mode it seems the timing is exceedingly tight. The TX FIFO can never empty, because the master is driving the clock so zeros would be sent for those bytes where the FIFO is empty. Return to interleaving the writing of the TX FIFO and the reading of the RX FIFO to try to ensure the data is available when required. Fixes: a84c11e16dc2 ("spi: spi-cadence: Avoid read of RX FIFO before its ready") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20230518093927.711358-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown

spi: dw: Replace spi->chip_select references with function calls

2023-05-16T01:15:06Z

New set/get APIs for accessing spi->chip_select were introduced by 'commit 9e264f3f85a5 ("spi: Replace all spi->chip_select and spi->cs_gpiod references with function call")', but the 'commit 2c8606040a80 ("spi: dw: Add support for AMD Pensando Elba SoC")' uses the old interface by directly accessing spi->chip_select. So, replace all spi->chip_select references in the driver with new get/set APIs. Signed-off-by: Amit Kumar Mahapatra

spi: spi-cadence: Only overlap FIFO transactions in slave mode

2023-05-15T01:21:40Z

Commit b1b90514eaa3 ("spi: spi-cadence: Add support for Slave mode") updated the code to trigger the IRQ when the FIFO was half empty, overlapping filling more data into the FIFO and sending what is left. This appears to cause regressions on the Zynq 7000, for transactions longer than the FIFO size, below that no overlapping occurs. It would appear from my testing that any attempt to put new data into the FIFO whilst data is still transmitting causes data corruption on both send and receive. If I am reading the commit message right on commit 49530e641178 ("spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()"), that would also seem to imply this is the case. On the assumption that this isn't an issue on the platform the original slave mode support was added for, update the cdns_transfer_one to only set the watermark to 50% of the FIFO size when in slave mode. There by retaining the new behaviour for slave mode but reverting to the older behaviour when the SPI is used a master. Fixes: b1b90514eaa3 ("spi: spi-cadence: Add support for Slave mode") Signed-off-by: Charles Keepax