Nicolas DET wrote:
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.
Except that the UHCI spec is clear that in a given QH (or TD),
only one word is modified and the others are read-only. So
I see no way that "real UHCI" would ever write more than one
32-bit word at a time. Whose UHCI silicon is this, and do you
know for a fact that something is doing a PCI burst write?
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.
One I want to see answered, since it seems like the alloc_coherent()
implementation on that one platform is most likely broken ... since
it's implementing alloc_noncoherent() instead. There _are_ platforms
that can't implement coherent memory. And for now, they have a
hard time with USB.
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.
It's a fine thing to have the fields near what the HC writes be
read-only as much as possible. But with memory that's coherent,
that shouldn't affect correctness.
If the HCDs need to work on platforms that only have noncoherent
memory ... that's another story, and correctness involves the
sort of cacheline-worrying you describe.
- 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
