> 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.
I start to see what you're getting at. Would you elaborate
a bit? I think I'd be more enlightened if you (and/or code
comments) highlighted the cases where these tricks are
being applied.
The tricky cases would seem to be when td->status is
tweaked for "live" TDs ... but it's not clear which those
cases are. Or why "usb-uhci" can do FSBR without
relying on I/O-atomic IOC bit-set ... is it just a potential risk
of going an extra time around the FSBR ring?
- Dave
p.s. FWIW the UHCI "td->status" strongly resembles
the EHCI "qtd->hw_token". But the async schedule
(for control/bulk) is always a ring ... some aspects
of that were clearly borrowed/improved from UHCI.
(And others from OHCI ... like TDs that support I/O
for multiple pages! :)
_______________________________________________________________
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
