From: Ralf Baechle <ralf@linux-mips.org>
To: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>,
linux-arch@vger.kernel.org
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
dan.j.williams@intel.com, linux-kernel@vger.kernel.org,
maciej.sosnowski@intel.com
Subject: Re: [PATCH] dmatest: flush and invalidate destination buffer before DMA
Date: Fri, 9 Jan 2009 11:19:36 +0000 [thread overview]
Message-ID: <20090109111936.GB17948@linux-mips.org> (raw)
In-Reply-To: <20090108093603.691c1200@hskinnemoen-d830>
On Thu, Jan 08, 2009 at 09:36:03AM +0100, Haavard Skinnemoen wrote:
> In the general case, however, I think MIPS has a bug: I've seen drivers
> DMA to/from tiny buffers stored inside another struct. This is legal
> because the driver can guarantee that the other fields in the struct
> aren't accessed in the mean time, but any fields sharing a cacheline
> with the buffer must be written back before the lines are invalidated.
Depending on the implementation details, the use of such a struct might be
relying on implementation-specific behaviour. This is what
Documentation/DMA-API.txt has to say:
[...]
int
dma_get_cache_alignment(void)
Returns the processor cache alignment. This is the absolute minimum
alignment *and* width that you must observe when either mapping
memory or doing partial flushes.
Notes: This API may return a number *larger* than the actual cache
line, but it will guarantee that one or more cache lines fit exactly
into the width returned by this call. It will also always be a power
of two for easy alignment.
[...]
Since dma_get_cache_alignment() is a function not a constant its result
can't be used in the definition of a struct unless possibly excessive
padding is used.
The debate has shown that we problably need BUG_ON() assertions in the
DMA API implementations to catch this sort of dangerous use.
Ralf
next prev parent reply other threads:[~2009-01-09 12:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-26 15:31 [PATCH] dmatest: flush and invalidate destination buffer before DMA Atsushi Nemoto
2008-12-27 10:10 ` Haavard Skinnemoen
2008-12-28 17:53 ` Atsushi Nemoto
2009-01-05 18:31 ` Dan Williams
2009-01-06 1:14 ` Atsushi Nemoto
2009-01-06 1:29 ` Dan Williams
2009-01-06 2:06 ` Atsushi Nemoto
2009-01-08 4:43 ` Atsushi Nemoto
2009-01-08 8:36 ` Haavard Skinnemoen
2009-01-08 17:20 ` Dan Williams
2009-01-09 8:30 ` Atsushi Nemoto
2009-01-10 0:39 ` Dan Williams
2009-01-09 11:19 ` Ralf Baechle [this message]
2009-01-09 22:27 ` Russell King
2009-01-11 18:44 ` Ralf Baechle
2009-01-11 18:44 ` Ralf Baechle
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=20090109111936.GB17948@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=anemo@mba.ocn.ne.jp \
--cc=dan.j.williams@intel.com \
--cc=haavard.skinnemoen@atmel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.sosnowski@intel.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 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.