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 v6 6/7] spi: spi-fsl-dspi: Increase target mode DMA buffer size
Date: Tue, 02 Sep 2025 13:44:58 +0100	[thread overview]
Message-ID: <20250902-james-nxp-spi-dma-v6-6-f7aa2c5e56e2@linaro.org> (raw)
In-Reply-To: <20250902-james-nxp-spi-dma-v6-0-f7aa2c5e56e2@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 6bf87ef01c13..3d29285c772c 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -675,7 +675,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-09-02 12:46 UTC|newest]

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

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=20250902-james-nxp-spi-dma-v6-6-f7aa2c5e56e2@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).