From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] serial: fsl_lpuart: add eDMA support
Date: Thu, 9 Jan 2014 11:58:25 +0100 [thread overview]
Message-ID: <201401091158.25902.arnd@arndb.de> (raw)
In-Reply-To: <20140109103515.164af26c@ipc1.ka-ro>
On Thursday 09 January 2014, Lothar Wa?mann wrote:
> > +static int lpuart_dma_rx(struct lpuart_port *sport)
> > +{
> > + dma_sync_single_for_device(sport->port.dev, sport->dma_rx_buf_bus,
> > + DMA_RX_BUFFER_SIZE, DMA_TO_DEVICE);
> >
> dma_alloc_coherent() (which you use to allocate the DMA rx buffer) and
> dma_symc_*() are orthogonal to each other!
> You either allocate DMA coherent memory as DMA buffer or use ordinary
> memory with the DMA streaming API (dma_map_*(), dma_sync_*()).
> See Documentation/DMA-API-HOWTO.txt
Well spotted, it took me a while to figure out what the driver actually
does mixing these two. Apparently the tx path is using the streaming
DMA API, while the rx path uses the consistent API.
I think the driver should really use the same API both ways, and it
depends on the amount of data transferred with each DMA which API
fits better. I'd say that if typical transfer is just a few dozen
bytes at most, it should perform better if you use the consistent API
with uncacheable memory buffers, because it won't have the overhead
from the cache flushes. If you often transfer kilobytes at once,
the streaming API would be faster because it avoids uncached memory
accesses.
Arnd
prev parent reply other threads:[~2014-01-09 10:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 3:04 [PATCH 0/2] serial: fsl_lpuart: add eDMA support Yuan Yao
2014-01-09 3:04 ` [PATCH 1/2] ARM: dts: vf610: lpuart: Add " Yuan Yao
2014-01-09 3:04 ` [PATCH 2/2] serial: fsl_lpuart: add " Yuan Yao
2014-01-09 8:56 ` Arnd Bergmann
2014-01-13 6:47 ` Yao Yuan
2014-01-13 8:45 ` Arnd Bergmann
2014-01-09 9:35 ` Lothar Waßmann
2014-01-09 10:58 ` Arnd Bergmann [this message]
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=201401091158.25902.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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).