[ re why a separate list of URBs vs checking the schedule ] > Actually, you *MUST* maintain a list of outstanding URB's. Since the HC > doesn't tell the HCD which URB's have completed, we need to check all of > them to determine which one's completed.
It does say which TDs have completed though ... and as I pointed out, that's quite sufficient for knowing which URBs completed. It may even be less work to check the schedule than the list of all URBs. (It's possible to skip chunks of the periodic schedule, and the URBs held there.) > The only other solution is to walk the schedule, but that requires > complicated code to convert bus addresses into kernel addresses. Not to > mention it's effectively a list anyway and it still needs a lock. Or maintain a "shadow schedule" which is what EHCI does. Much simpler and more efficient ... only OHCI needs that annoying done-list processing, which requires a bus_to_virt() analogue. > The reason we don't do it that way is because it's dumb. I'm sure if you > try to implement what you're proposing you'll see just how complicated > it is. On the contrary (and as I've already said) -- I did implement it, which is how I know it's a lot simpler. And why I thought it was worth commenting on the relative complexity of _both_ UHCI drivers. (Or were you meaning "dumb" in the sense of "good because it's so simple/effective"? As in "smart clients, dumb servers"? :) > However, when we drop the lock, the other CPU's are free to do pretty > much anything to the list. Like I said ... that's fine, and it needn't cause any confusion unless whatever code scans the schedule is being buggy. Heck, it's an exact corrollary of the problem of updating the hardware's view of that same schedule: if the one problem can be solved, so can the other. > Plus, you still need a lock to prevent multiple CPU's from modifying the > schedule. Only one lock is needed, no more. Adding more (to get finer lock granularity) sometimes helps with performance, but that's not what you've argued. > What I did say is that they have implemented the necessary the logic > that you're advocating and it's hacky, kludgy, contains arbitrary > processing limits and nothing like it is ever going to see uhci.c. You must have been reading what someone else wrote. For starters, the "usb-uhci" codebase does _not_ implement the approach I sketched. And that approach certainly is neither hacky, nor kludgey, nor even a vague bit posessed of arbitrary processing limits. > I'm looking at the ehci-hcd driver right now and I'm not sure how you > can be sure it's safe. Perhaps it's just you haven't seen any problems > because of the lack of USB 2.0 devices? But you have the same locking > problems with lists that usb-uhci does, except you don't even try to > jump through hoops to workaround it. Since that driver isn't structured like the "usb-uhci" driver, there is no way it could have the same locking problems ... or need the same kind of hoop-jumping. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
