From: Alan Stern <stern@rowland.harvard.edu>
To: David Brownell <david-b@pacbell.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Nicolas DET <nd@bplan-gmbh.de>,
USB development list <linux-usb-devel@lists.sourceforge.net>,
linux-mm@kvack.org
Subject: Re: [linux-usb-devel] Patch for UHCI driver (from kernel 2.6.6).
Date: Tue, 15 Jun 2004 12:35:25 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.0406151221220.1960-100000@ida.rowland.org> (raw)
In-Reply-To: <40CE2E24.5060207@pacbell.net>
On Mon, 14 Jun 2004, David Brownell wrote:
> Seems like the dma_alloc_coherent() API spec can't be
> implemented on such machines then, since it's defined
> to return memory(*) such that:
>
> ... a write by either the device or the processor
> can immediately be read by the processor or device
> without having to worry about caching effects.
>
> Seems like the documentation should change to explain
> under what circumstances "coherent" memory will exhibit
> cache-incoherent behavior, and how to cope with that.
> (Then lots of drivers would need to change.)
>
> OR ... maybe the bug is just that those PPC processors
> can't/shouldn't claim to implement that API. At which
> point all drivers relying on that API (including all
> the USB HCDs and many of the USB drivers) stop working.
>
> - Dave
>
> (*) DMA-API.txt uses two terms for this: "coherent" and "consistent".
> DMA-mapping.txt only uses "consistent".
That text strikes me as rather ambiguous. Maybe it's intended to mean
that a write by either side can be read immediately by the other side, and
the values read will be the ones written (i.e., the read won't get stale
data from some cache). It doesn't specify what happens to the other data
bytes in the same cache line which _weren't_ written -- maybe they'll be
messed up.
In other words, with "coherent" or "consistent" memory (there is some
technical distinction between the two terms but I don't know what it is)
you don't have to worry about reading stale data from a cache, but you
might still have to worry about data unintentionally being overwritten
with garbage.
Clearly this is not a tremendously useful guarantee, but I guess it's
better than nothing.
Maybe someone on linux-mm can clarify things for the rest of us. For
anyone interested, this thread started with:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108728413809788&w=2
Alan Stern
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next parent reply other threads:[~2004-06-15 16:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <40CE2E24.5060207@pacbell.net>
2004-06-15 16:35 ` Alan Stern [this message]
2004-06-15 17:08 ` David Brownell
2004-06-15 17:23 ` Duncan Sands
2004-06-15 19:35 ` Alan Stern
2004-06-15 20:33 ` David Brownell
2004-06-15 21:12 ` Alan Stern
2004-06-15 21:40 ` Guennadi Liakhovetski
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=Pine.LNX.4.44L0.0406151221220.1960-100000@ida.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=david-b@pacbell.net \
--cc=linux-mm@kvack.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=nd@bplan-gmbh.de \
/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