public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Subject: RFC non barrier versions of dma_map functions
Date: Mon, 04 Jan 2010 15:28:33 -0800	[thread overview]
Message-ID: <4B4279A1.4090706@codeaurora.org> (raw)

Hello  All,

   This is a request for extending the DMA api for efficient handling of 
multiple buffers or scatter gather mapping/unmapping operations.

   I am based on an ARMv7 device and we have a situation where we need 
to dma map multiple cached buffers for a single dma transaction.

   The current DMA api suggests the use of dma_map_single/ 
dma_unmap_single for cache consistency. On ARMv7 it performs the 
necessary cache-operations and calls data sync barrier instruction 
(DSB). In our case we would be executing multiple DSB instructions
before starting the dma operation - we need memory to be consistent
only after we map the last buffer.

   I am thinking we could define "no barrier" version's of all the 
mapping/unmapping functions and then a barrier function that results
in DSB before the dma is started.

   Here are numbers from a test ran on my board.

It kmallocs N buffers of size 'size', dirties their cache by writing
to them and calls dma_map_single that calls the arch specific clean
operations with and without DSB. In "without DSB" case a dsb is executed
after the last buffer is mapped. The time is in microseconds

size    N    map_single    map_single w/o DSB    delta
128    16    8             5                     60%
512    16    9             6                     50%
512    32    15            8                     88%
512    48    20            11                    82%
512    64    27            14                    93%
64     4     4             3                     33%
64     8     4             3                     33%
64     16    7             4                     75%
64     32    12            4                     200%
64     48    17            6                     183%
64     64    21            7                     200%
1024   16    9             7                     29%

These buffer sizes and N are very close to real world sizes the
framebuffer driver handles. Cases where N is large happen the most
often.

Clearly,we could benefit from the nobarrier versions of the cache
operations and we could use them in scatter gather mappings as well.

Since this kind of API change will affect all the platforms, I was 
directed by the arm-linux community to take this up on the linux kernel 
mailing list.

For architectures that don't need a barrier for the completions of
cache operations we can simply call the existing
dma_map_signle/dma_unmap_single.

Requesting alternative ideas or code design to get the desired 
nonbarrier versions of the mapping functions.

Thanks,
Abhijeet Dharmapurikar


             reply	other threads:[~2010-01-04 23:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-04 23:28 Abhijeet Dharmapurikar [this message]
2010-01-08  8:52 ` RFC non barrier versions of dma_map functions FUJITA Tomonori

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=4B4279A1.4090706@codeaurora.org \
    --to=adharmap@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.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