On Thu, May 09, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > For anything except hardware registers, I'm used > to seeing devices specified so that there's never > a need to have the driver and the hardware modify > the same word of memory concurrently. (And even > for most hardware registers, too.) > > Are you saying UHCI expects that? Or is it just a > driver issue, where you've chosen a structure that > depends sub-word concurrent access rather than > one that doesn't?
If you use UHCI like it was designed, then you don't need to access the same data at the same time. Unfortunately, if you use UHCI like it was designed, you get poor USB performance or you get poor system performance. So we have some hacks which play some nasty tricks with FSBR to solve the problem. To implement this, we need to fiddle with the IOC bit while the HC is processing the schedule. Presumably it can update the word that contains the IOC bit at the same time and therein lies the race condition. JE _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
