All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: DMA_NONCOHERENT and dma_map_single
Date: Mon, 19 Jan 2004 00:05:19 +0100	[thread overview]
Message-ID: <20040118230519.GA31919@linux-mips.org> (raw)
In-Reply-To: <20040118195006.GA22616@sonycom.com>

On Sun, Jan 18, 2004 at 08:50:06PM +0100, Dimitri Torfs wrote:

>   dma_map_single() is supposed to be called on a buffer that exactly
>   starts and ends on a cacheline boundary, otherwise "bad things"
>   (e.g. overwrite of data that was written by device, ...) (especially
>   on dma non-coherent systems) may happen. 
> 
>   So what should be done when dma_map_single is not called
>   with a sane (ptr, size) argument ?
> 
>     - is the driver (caller) considered buggy and should we return a 0
>       return-value ?
>     - is the driver (caller) considered buggy but we do the mapping
>       anyway, hoping that the driver has not/will not touched/touch
>       the boundary cachelines ?

The driver is considered buggy;  dma_map_single's behaviour is undefined so
it's perfectly ok if it paints neighbour's cat pink ;-)

>     - should we take appropriate actions to make sure the
>       cache-effects do not come into play (e.g. by using some kind of
>       bounce buffer) ?

Technically bounce buffers can be handled inside dma_map_single & co but
it's not a good idea.  Better set the appropriate flags so higher levels
can allocate memory with the appropriate GFP_* flags and thereby hopefully
avoid overly frequent buffer bouncing.

  Ralf

      reply	other threads:[~2004-01-18 23:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-18 19:50 DMA_NONCOHERENT and dma_map_single Dimitri Torfs
2004-01-18 23:05 ` Ralf Baechle [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=20040118230519.GA31919@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=dimitri@sonycom.com \
    --cc=linux-mips@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.