[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEhVsrEk0qv+38r3@lizhi-Precision-Tower-5810>
Date: Tue, 10 Jun 2025 11:56:34 -0400
From: Frank Li <Frank.li@....com>
To: Arnd Bergmann <arnd@...db.de>
Cc: James Clark <james.clark@...aro.org>,
Vladimir Oltean <olteanv@...il.com>,
Mark Brown <broonie@...nel.org>,
Vladimir Oltean <vladimir.oltean@....com>,
linux-spi@...r.kernel.org, imx@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] spi: spi-fsl-dspi: Use non-coherent memory for DMA
On Tue, Jun 10, 2025 at 05:48:40PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 10, 2025, at 17:15, Frank Li wrote:
> > On Mon, Jun 09, 2025 at 04:32:39PM +0100, James Clark wrote:
> >> Using coherent memory here isn't functionally necessary.
> >> Because the
> >> change to use non-coherent memory isn't overly complex and only a few
> >> synchronization points are required, we might as well do it while fixing
> >> up some other DMA issues.
> >
> > Any beanfit by use on-coherent memory here?
>
> The driver copies data in and out of a coherent buffer by default. This is
> fine if the buffer is only a few bytes in size, but for large transfers
> this is quite slow because this bypasses the cache for any DMA master
> that is marked as not "dma-coherent" in devicetree.
I see, non-coherent memory use cachable normal memory page. but coherent
use non-cachable normal memory page.
Can you add performance beneafit information after use non-coherent memory
in commit message to let reviewer easily know your intention.
Frank
>
> Patch 3/4 changes the size from a few bytes to many pages of memory,
> so it's access the buffer in cache first and manually maintain
> coherency.
>
> Arnd
Powered by blists - more mailing lists