David Brownell wrote:
I think most of the PowerPC machine works just like the x86.
About this one (Pegasos II), it does support cache coherency/bus
snooping.
So, IMO, dma_alloc_coherent is correct (otherwise, nothing would work,
and we would need to rewrote each Linux driver ...)
But you DID need to change a driver, since it's behaving
differently. Why are you arguing that it's correct?
This specific problem may or may not be cache coherency related. It
might just work on G3 just because it's way slower than the
G4...Especially the CPU <-> memory speed.
Another possibilitie would be that the UHCI chipset likely access to the
memory on "4 64-bit words" burst access as it requieres 16-byte boundary
alignement. If the chip write the value to the QH in "burst mode" it can
likely overwrite the software field. Cache coherency would not help in
that specific case.
How can the dma_alloc_coherent() implementation be correct if the
memory it returns has such an obvious cache effect? The definition
of that routine says the memory returned has no such cache effects.
Yet there they are -- cache effects. Something's wrong there.
Well, that's indeed a good question.
Nevertheless, I don't think it's a good idea to mix "so close" hardware
and software field. Even, if it works it should be a bit slower as the
NB may have to "merge" the two value.
Bye
-------------------------------------------------------
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
