Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	Arnd Bergmann <arnd@arndb.de>, Frank Li <Frank.li@nxp.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	linux-spi@vger.kernel.org, imx@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] spi: spi-fsl-dspi: Use non-coherent memory for DMA
Date: Thu, 12 Jun 2025 16:47:26 +0100	[thread overview]
Message-ID: <78d77dd0-2ddb-4074-8f2a-debc7bc41fe1@linaro.org> (raw)
In-Reply-To: <56b158fa-5fd6-4582-8ca1-296863d6d2a8@sirena.org.uk>



On 12/06/2025 3:43 pm, Mark Brown wrote:
> On Thu, Jun 12, 2025 at 03:14:32PM +0100, James Clark wrote:
>> On 12/06/2025 12:15 pm, Vladimir Oltean wrote:
> 
>>> FWIW, the XSPI FIFO performance should be higher.
> 
>> This leads me to realise a mistake in my original figures. My head was stuck
>> in target mode where we use DMA so I forgot to force DMA in host mode to run
>> the performance tests. The previous figures were all XSPI mode and the small
>> difference in performance could have been just down to the layout of the
>> code changing?
> 
>> Changing it to DMA mode gives figures that make much more sense:
> 
> If not having DMA mode is making this much of a difference shouldn't the
> driver just do that?  I'm not seeing runtime configuration in the driver
> so I guess this is local hacking...
> 

Yes just changed locally.

>> So for small transfers XSPI is slightly better but for large ones DMA is
>> much better, with non-coherent memory giving another 800kbps gain. Perhaps
>> we could find the midpoint and then auto select the mode depending on the
>> size, but maybe there is latency to consider too which could be important.
> 
> This is a fairly normal pattern, it's a big part of why the can_dma()
> callback is per transfer - so you can do a copybreak and use PIO for
> smaller transfers where the overhead of setting up DMA is often more
> than the overhead of just doing PIO.

Makes sense. Although for some reason two devices already use DMA for 
host mode and it's not that clear to me what the reason is.


  reply	other threads:[~2025-06-12 15:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-09 15:32 [PATCH 0/4] spi: spi-fsl-dspi: Target mode improvements James Clark
2025-06-09 15:32 ` [PATCH 1/4] spi: spi-fsl-dspi: Clear completion counter before initiating transfer James Clark
2025-06-10 11:34   ` Vladimir Oltean
2025-06-10 15:41     ` James Clark
2025-06-10 21:01       ` Vladimir Oltean
2025-06-10 21:31         ` Vladimir Oltean
2025-06-11  9:12           ` James Clark
2025-06-09 15:32 ` [PATCH 2/4] spi: spi-fsl-dspi: Use non-coherent memory for DMA James Clark
2025-06-10  8:26   ` Arnd Bergmann
2025-06-10  9:03     ` James Clark
2025-06-10 15:15   ` Frank Li
2025-06-10 15:46     ` James Clark
2025-06-13 15:56       ` David Laight
2025-06-10 15:48     ` Arnd Bergmann
2025-06-10 15:56       ` Frank Li
2025-06-11  9:01         ` Vladimir Oltean
2025-06-12 11:05           ` James Clark
2025-06-12 11:15             ` Vladimir Oltean
2025-06-12 14:14               ` James Clark
2025-06-12 14:23                 ` Vladimir Oltean
2025-06-12 14:28                   ` James Clark
2025-06-12 14:31                     ` Vladimir Oltean
2025-06-12 14:35                       ` James Clark
2025-06-12 14:36                 ` Vladimir Oltean
2025-06-12 15:36                   ` James Clark
2025-06-12 15:37                     ` James Clark
2025-06-12 14:43                 ` Mark Brown
2025-06-12 15:47                   ` James Clark [this message]
2025-06-12 15:51                     ` Vladimir Oltean
2025-06-12 15:40                 ` Arnd Bergmann
2025-06-12 11:15             ` Arnd Bergmann
2025-06-09 15:32 ` [PATCH 3/4] spi: spi-fsl-dspi: Increase DMA buffer size James Clark
2025-06-09 15:32 ` [PATCH 4/4] spi: spi-fsl-dspi: Report FIFO overflows as errors James Clark
2025-06-10 21:52   ` Vladimir Oltean
2025-06-11 14:40     ` James Clark
2025-06-11 14:56       ` Vladimir Oltean
2025-06-11 15:00         ` James Clark
2025-06-30 11:40 ` [PATCH 0/4] spi: spi-fsl-dspi: Target mode improvements Mark Brown
2025-06-30 12:23   ` James Clark
2025-06-30 12:25     ` Mark Brown
2025-06-30 12:36       ` James Clark
2025-06-30 12:40         ` Mark Brown
2025-06-30 12:54           ` 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=78d77dd0-2ddb-4074-8f2a-debc7bc41fe1@linaro.org \
    --to=james.clark@linaro.org \
    --cc=Frank.li@nxp.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=imx@lists.linux.dev \
    --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