summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin
diff options
context:
space:
mode:
authorVishwaroop A <va@nvidia.com>2026-08-13 20:00:27 +0000
committerMark Brown <broonie@kernel.org>2026-09-09 12:48:31 +0100
commit252ee24aff97cd0a14c192c200753487ed88ee24 (patch)
treeb51d1b2898165f43b5ac52f651ff1e931809818d /tools/perf/scripts/python/bin
parent1ff82c13ea9475abc51eebfb83ee54bc75c08900 (diff)
spi: tegra210-quad: Process small PIO transfers in hard IRQ context
On heavily loaded systems, workqueue scheduling delays can exceed transfer timeouts even for high-priority queues, causing false timeouts for latency-sensitive devices like TPM despite hardware completing in microseconds. Process small PIO transfers (those that complete the whole spi_transfer in a single chunk) directly in hard IRQ context instead of deferring to the workqueue. This reduces completion latency from 1000ms+ to microseconds and matches the pattern used by other SPI drivers. To avoid touching the spi_transfer object from hard IRQ context (which would race with the synchronous teardown path that clears curr_xfer on timeout), tegra_qspi_start_cpu_based_transfer() caches the "this PIO chunk completes the whole transfer" decision into a scalar tqspi->is_last_pio_chunk *before* unmasking the IRQ. The hard-IRQ fastpath consumes that scalar with READ_ONCE() and never dereferences curr_xfer or any spi_transfer fields. Multi-chunk PIO transfers are intentionally kept on the workqueue (only the final chunk sets the flag) so the fastpath can never recurse into tegra_qspi_start_cpu_based_transfer() from hard IRQ context, and DMA transfers always go through the workqueue because their completion path sleeps on the DMA engine. The fastpath also gates on the per-IRQ tx_status / rx_status locals being zero, because handle_cpu_based_xfer()'s error path calls tegra_qspi_reset() -> device_reset(), which can sleep and must not run from hard IRQ context. is_curr_dma_xfer and is_last_pio_chunk are written from process context (the transfer-start functions) and read lock-free from the hard IRQ handler and the workqueue handler, so the writes use WRITE_ONCE() and the reads use READ_ONCE() to prevent compiler tearing and silence KCSAN data-race warnings. Signed-off-by: Vishwaroop A <va@nvidia.com> Link: https://patch.msgid.link/20260813200027.2711863-4-va@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/bin')
0 files changed, 0 insertions, 0 deletions