Re: [PATCH 0/5] spi: tegra114: chip-select fixes and PIO-only probe

[Karl Mehltretter]

On Wed, Oct 21, 2026 at 10:14:06AM +0000, Vishwaroop A wrote:
> The delay runs after CS is dropped. A mid-message cs_change drops CS
> and never drives it active again. When the last transfer holds CS,
> the next message can turn hardware CS back on and drop the line.
> TIS-SPI under spi_bus_lock() needs CS held across those messages.
> Multi-transfer messages already use software CS; patch 4 only moves
> that choice so patch 5 can keep it.
>
> Patch 1 is separate. A missing "dmas" property fails probe even
> though PIO works, so fall back to PIO.

Tested on Jetson Nano (Tegra210) on v7.3-rc2 (5b0764a53235) with
7000d400.spi (DMA enabled) and 7000d600.spi ("dmas" omitted from DT):

1. PIO fallback (patch 1/5):
   - Unpatched: 7000d600.spi fails probe with:
     spi-tegra114 7000d600.spi: error -19: Dma channel is not available
   - With series: 7000d600.spi logs:
     spi-tegra114 7000d600.spi: 'dmas' is required by the binding, falling back to PIO
     and completes 128-byte PIO transfers on /dev/spidev1.0.

2. Mid-message cs_change reassertion (patch 3/5):
   - Two-transfer SPI_IOC_MESSAGE(2) on 7000d400.spi (SPI_MODE_0,
     active-low CS0) with cs_change = 1 on both transfers:
   - Unpatched: SPI_COMMAND1 (0x7000d400) after the message is
     0x40701827 (SPI_CS_SW_HW = 1, SPI_CS_SW_VAL = 1), leaving CS
     deasserted high during the second transfer.
   - With series: SPI_COMMAND1 is 0x40601827 (SPI_CS_SW_HW = 1,
     SPI_CS_SW_VAL = 0, CS reasserted low before the second transfer).

3. Per-transfer delay order and keeping software CS across messages
   (patches 2/5, 4/5 and 5/5):
   - Immediately following the cs_change = 1 message above, a
     single-transfer SPI_IOC_MESSAGE(1) with cs_change = 0 and
     delay_usecs = 40000 was submitted while sampling SPI_COMMAND1 at
     15 ms into the 40 ms delay window:
   - Unpatched: SPI_COMMAND1 at 15 ms is already reset to 0x40400000
     (SPI_CS_SW_HW = 0) because tegra_spi_transfer_end() ran before
     spi_transfer_delay_exec() and the transfer switched to hardware CS.
   - With series: SPI_COMMAND1 at 15 ms is 0x40601827 (SPI_CS_SW_HW = 1,
     SPI_CS_SW_VAL = 0), holding software CS active during delay_usecs,
     and returns to 0x40400000 after delay_usecs completes.

Tested-by: Karl Mehltretter <kmehltretter@xxxxxxxxx>

Thanks,
Karl