On Fri, 2004-06-18 at 16:41, Alan Stern wrote: > On Fri, 18 Jun 2004, Benjamin Herrenschmidt wrote: > > > I think it's more likely we are dealing with an ordering issue of > > accesses to memory vs. mmio, those aren't order unless you use memory > > barriers. Actually, it's worse, you need a full mb() to order them, > > which is why lately, we made ppc64 writeX() do full sync's ... that sucks > > but it's near to impossible to get an abstract IO API that would cover > > our needs here and still make other archs happy it seems... > > I recently changed a few mb() calls to wmb(), because they only protected > data the CPU was writing to be read by the device. Do you think changing > all the wmb()'s back to mb()'s would make a difference? > > (Actually it seems likely that this is _not_ directly related to the > original problem, but it might be important anyway.)
Well, the problem on ppc is that the eieio done by wmb() (or implicitely done by all writeX IO accessors) will only order stores in the same domain. That is cacheable aren't ordered vs. non cacheables. For example, write to a descriptor in memory, then writel() to your device, that isn't guaranteed to happen in order. In this case, you indeed need an mb(), but that's a ppc thing and the race on ppc32 CPUs is quite small (though ppc64, typically POWER4 and POWER5, will eat you for lunch with their multiple deep store queues). Ben ------------------------------------------------------- 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
