linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Vladimir Oltean <olteanv@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	 Vladimir Oltean <vladimir.oltean@nxp.com>,
	Arnd Bergmann <arnd@arndb.de>,
	 Larisa Grigore <larisa.grigore@nxp.com>,
	Frank Li <Frank.li@nxp.com>,  Christoph Hellwig <hch@lst.de>
Cc: linux-spi@vger.kernel.org, imx@lists.linux.dev,
	 linux-kernel@vger.kernel.org,
	James Clark <james.clark@linaro.org>
Subject: [PATCH v5 6/7] spi: spi-fsl-dspi: Increase target mode DMA buffer size
Date: Fri, 29 Aug 2025 12:46:48 +0100	[thread overview]
Message-ID: <20250829-james-nxp-spi-dma-v5-6-3246957a6ea9@linaro.org> (raw)
In-Reply-To: <20250829-james-nxp-spi-dma-v5-0-3246957a6ea9@linaro.org>

When the device is configured as a target, the host won't stop sending
data while we're draining the buffer which leads to FIFO underflows
and corruption.

Increase the DMA buffer size to the maximum words that edma can
transfer once to reduce the chance of this happening.

In host mode, the driver is able to split up a transfer into smaller
chunks so we don't need to increase the size. While in target mode, the
length of the transfer is determined by the remote host and can be
larger than whatever default buffer size we pick. Keeping the buffer
small in host mode avoids wasting memory, but allocating the largest
possible in target mode gives the lowest possible chance of dropping any
data from the host.

While we could allocate per-transfer using the exact size of the
transfer, 128K is quite a large allocation and there is a chance it
could fail due to memory fragmentation unless it's allocated once at
init time.

Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
 drivers/spi/spi-fsl-dspi.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 0e5f65d58342..3b652d744492 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -673,7 +673,18 @@ static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
 		goto err_tx_channel;
 	}
 
-	dma->bufsize = PAGE_SIZE;
+	if (spi_controller_is_target(dspi->ctlr)) {
+		/*
+		 * In target mode we have to be ready to receive the maximum
+		 * that can possibly be transferred at once by EDMA without any
+		 * FIFO underflows.
+		 */
+		dma->bufsize = min(dma_get_max_seg_size(dma->chan_rx->device->dev),
+				   dma_get_max_seg_size(dma->chan_tx->device->dev)) *
+			       DMA_SLAVE_BUSWIDTH_4_BYTES;
+	} else {
+		dma->bufsize = PAGE_SIZE;
+	}
 
 	dma->tx_dma_buf = dma_alloc_noncoherent(dma->chan_tx->device->dev,
 						dma->bufsize, &dma->tx_dma_phys,

-- 
2.34.1


  parent reply	other threads:[~2025-08-29 11:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 11:46 [PATCH v5 0/7] spi: spi-fsl-dspi: Target mode improvements James Clark
2025-08-29 11:46 ` [PATCH v5 1/7] spi: fsl-dspi: Avoid using -EINPROGRESS error code James Clark
2025-08-29 12:54   ` Vladimir Oltean
2025-09-01  9:10     ` James Clark
2025-08-29 11:46 ` [PATCH v5 2/7] spi: fsl-dspi: Store status directly in cur_msg->status James Clark
2025-08-29 11:46 ` [PATCH v5 3/7] spi: spi-fsl-dspi: Stub out DMA functions James Clark
2025-08-29 14:26   ` Vladimir Oltean
2025-09-01  9:09     ` James Clark
2025-09-01 13:03       ` Vladimir Oltean
2025-08-29 11:46 ` [PATCH v5 4/7] spi: spi-fsl-dspi: Use non-coherent memory for DMA James Clark
2025-08-29 14:29   ` Vladimir Oltean
2025-08-29 11:46 ` [PATCH v5 5/7] spi: spi-fsl-dspi: Use whole page for DMA buffers James Clark
2025-08-29 11:46 ` James Clark [this message]
2025-08-29 11:46 ` [PATCH v5 7/7] spi: spi-fsl-dspi: Report FIFO overflows as errors James Clark

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=20250829-james-nxp-spi-dma-v5-6-3246957a6ea9@linaro.org \
    --to=james.clark@linaro.org \
    --cc=Frank.li@nxp.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=hch@lst.de \
    --cc=imx@lists.linux.dev \
    --cc=larisa.grigore@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=vladimir.oltean@nxp.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;
as well as URLs for NNTP newsgroup(s).