From: Jon Hunter <jonathanh@nvidia.com>
To: Vishwaroop A <va@nvidia.com>,
Thierry Reding <thierry.reding@kernel.org>,
Mark Brown <broonie@kernel.org>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
Sowjanya Komatineni <skomatineni@nvidia.com>,
Breno Leitao <leitao@debian.org>,
Suresh Mangipudi <smangipudi@nvidia.com>,
Krishna Yarlagadda <kyarlagadda@nvidia.com>,
linux-tegra@vger.kernel.org, linux-spi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] spi: tegra210-quad: Cache TRANS_STATUS in ISR for timeout handler
Date: Tue, 19 May 2026 10:27:55 +0100 [thread overview]
Message-ID: <afa3819e-cf0d-478e-8813-ee1aa1b2156e@nvidia.com> (raw)
In-Reply-To: <20260518160739.3286438-3-va@nvidia.com>
On 18/05/2026 17:07, Vishwaroop A wrote:
> On heavily loaded systems, workqueue scheduling delays can exceed the
> transfer timeout even though hardware completes the transfer in
> microseconds. The timeout handler cannot distinguish between a real
> hardware timeout and a delayed workqueue, causing false timeout errors.
Can you explain this better? Ie. exactly how does this occur?
> Cache QSPI_TRANS_STATUS in the ISR before clearing it, allowing the
> timeout handler to check if hardware completed (QSPI_RDY set) versus
> a real timeout (QSPI_RDY not set). This prevents false timeout errors
> when the hardware completes but the workqueue is delayed.
The workqueue was introduced in patch 1/3. Did this problem already
exist with the threaded IRQ?
>
> Signed-off-by: Vishwaroop A <va@nvidia.com>
> ---
> drivers/spi/spi-tegra210-quad.c | 42 ++++++++++++++++++++-------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
> index a551c7a7f6c4..6148267a51cd 100644
> --- a/drivers/spi/spi-tegra210-quad.c
> +++ b/drivers/spi/spi-tegra210-quad.c
> @@ -214,6 +214,7 @@ struct tegra_qspi {
> u32 tx_status;
> u32 rx_status;
> u32 status_reg;
> + u32 trans_status;
> bool is_packed;
> bool use_dma;
>
> @@ -854,6 +855,7 @@ static u32 tegra_qspi_setup_transfer_one(struct spi_device *spi, struct spi_tran
> tqspi->cur_rx_pos = 0;
> tqspi->cur_tx_pos = 0;
> tqspi->curr_xfer = t;
> + tqspi->trans_status = 0;
> spin_unlock_irqrestore(&tqspi->lock, flags);
>
> if (is_first_of_msg) {
> @@ -1068,26 +1070,32 @@ static irqreturn_t handle_dma_based_xfer(struct tegra_qspi *tqspi);
> */
> static int tegra_qspi_handle_timeout(struct tegra_qspi *tqspi)
> {
> + unsigned long flags;
> irqreturn_t ret;
> - u32 status;
> + u32 trans_status;
This variable is only used once and so seem unnecessary to have a local
variable for this.
>
> - /* Check if hardware actually completed the transfer */
> - status = tegra_qspi_readl(tqspi, QSPI_TRANS_STATUS);
> - if (!(status & QSPI_RDY))
> + spin_lock_irqsave(&tqspi->lock, flags);
> +
> + trans_status = tqspi->trans_status;
> + if (!(trans_status & QSPI_RDY)) {
> + spin_unlock_irqrestore(&tqspi->lock, flags);
> return -ETIMEDOUT;
> + }
>
> /*
> - * Hardware completed but interrupt was lost/delayed. Manually
> - * process the completion by calling the appropriate handler.
> + * ISR or workqueue may have already completed the transfer
> + * and NULLed curr_xfer between the completion timeout and now.
> */
> + if (!tqspi->curr_xfer) {
> + spin_unlock_irqrestore(&tqspi->lock, flags);
> + return 0;
> + }
> +
> + spin_unlock_irqrestore(&tqspi->lock, flags);
> +
> dev_warn_ratelimited(tqspi->dev,
> "QSPI interrupt timeout, but transfer complete\n");
>
> - /* Clear the transfer status */
> - status = tegra_qspi_readl(tqspi, QSPI_TRANS_STATUS);
> - tegra_qspi_writel(tqspi, status, QSPI_TRANS_STATUS);
> -
> - /* Manually trigger completion handler */
> if (!tqspi->is_curr_dma_xfer)
> ret = handle_cpu_based_xfer(tqspi);
> else
> @@ -1227,9 +1235,9 @@ static int tegra_qspi_combined_seq_xfer(struct tegra_qspi *tqspi,
>
> if (ret == 0) {
> /*
> - * Check if hardware completed the transfer
> - * even though interrupt was lost or delayed.
> - * If so, process the completion and continue.
> + * Check if hardware completed the transfer even though
> + * workqueue was delayed. If so, process completion and
> + * continue.
Shouldn't this part be part of patch 1/3 because the introduced the
workqueue?
> */
> ret = tegra_qspi_handle_timeout(tqspi);
> if (ret < 0) {
> @@ -1346,8 +1354,8 @@ static int tegra_qspi_non_combined_seq_xfer(struct tegra_qspi *tqspi,
> if (ret == 0) {
> /*
> * Check if hardware completed the transfer even though
> - * interrupt was lost or delayed. If so, process the
> - * completion and continue.
> + * workqueue was delayed. If so, process completion and
> + * continue.
Same here.
> */
> ret = tegra_qspi_handle_timeout(tqspi);
> if (ret < 0) {
> @@ -1642,6 +1650,8 @@ static irqreturn_t tegra_qspi_isr(int irq, void *context_data)
> if (!(status & QSPI_RDY))
> return IRQ_NONE;
>
> + tqspi->trans_status = status;
> +
> spin_lock(&tqspi->lock);
> tqspi->status_reg = tegra_qspi_readl(tqspi, QSPI_FIFO_STATUS);
> tegra_qspi_mask_clear_irq(tqspi);
--
nvpublic
next prev parent reply other threads:[~2026-05-19 9:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 16:07 [PATCH 0/3] spi: tegra210-quad: Improve interrupt handling for loaded systems Vishwaroop A
2026-05-18 16:07 ` [PATCH 1/3] spi: tegra210-quad: Convert to hard IRQ with high-priority workqueue Vishwaroop A
2026-05-19 9:15 ` Jon Hunter
2026-05-18 16:07 ` [PATCH 2/3] spi: tegra210-quad: Cache TRANS_STATUS in ISR for timeout handler Vishwaroop A
2026-05-19 9:27 ` Jon Hunter [this message]
2026-05-18 16:07 ` [PATCH 3/3] spi: tegra210-quad: Process small PIO transfers in hard IRQ context Vishwaroop A
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afa3819e-cf0d-478e-8813-ee1aa1b2156e@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=broonie@kernel.org \
--cc=kyarlagadda@nvidia.com \
--cc=ldewangan@nvidia.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=skomatineni@nvidia.com \
--cc=smangipudi@nvidia.com \
--cc=thierry.reding@kernel.org \
--cc=va@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox