On Thu, 14 Apr 2005 11:33:00 -0400 (EDT) Alan Stern <[EMAIL PROTECTED]> wrote:
> > > What about the question of making sure that I/O operations complete > > > before > > > starting a delay loop, like this: > > > > > > outw(..., ...); > > > mb(); > > > udelay(10); > > > > > > Is the mb() sufficient to insure that the data will be written to the > > > device before the udelay() call begins? > > > > The mb() has nothing to do with outw() in theory, although implementations > > may accomplish it as a side effect. Just drop the mb(). > > Is it true then, on all architectures, that the hardware will complete the > outw() _before_ the CPU executes the udelay() routine, even without the > mb()? It should be true, but I cannot guarantee that all architectures are bugless. > Or does it not really matter, because the outw() will complete within a > handful of CPU cycles anyway, long before the 10 us delay is over? It does matter quite a lot. Write accesses can get stuck in various pipelines to hundreds or thousands of clocks, if you allow it to happen. In fact, some hardware may even forget to drain unless you tell it explicitly. > I want to avoid pathological situations where the hardware reorders the > I/O write to occur _after_ the delay loop. Apparently some architectures > have very loose ordering guarantees for I/O operations with respect to > memory operations. All of CPUs have overrides, it's just a matter of architecture maintainer understanding basic concepts and being able to implement them in real life. I have trust in Paulus and Andi, but for example Bacchus and RMK are way too overloaded to resist inflow of vendor hacks. So, ARM and MIPS are suspects, especially on exotic chips, SOCs, etc. Also, always keep in mind the difference between outw and writew in this regard. -- Pete ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
