Alan Stern wrote:
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.
...
That text strikes me as rather ambiguous. ...
... 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.
Actually I thought it was quite explicit: "without having
to worry about caching effects". What you described is
clearly a caching effect: caused by caching. And maybe
fixable by appropriate cache-flushing, or other cache-aware
driver logic ... making it "worry about caching effects".
Like the patch from Nicolas.
Maybe what we really need is patches to make USB switch to
dma_alloc_noncoherent(), checking dma_is_consistent() to
see whether a given QH/TD/ED/iTD/sITD/FSTN/... needs to be
explicitly flushed from cpu cache before handover to HC.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
