Paul Brook wrote:
Given that OHCI is much more complex than UHCI (both the code and the spec)
I decided to give up on OHCI, at least for now. I noticed Codesourcery
copyright on OHCI. Did you have anything to do with the OHCI implementation?
Yes, I wrote the current OHCI support, based on some initial patches by
Gianni.
Great. So do you have spare cycles to add decent async support to it ?
I found OHCI to be much easier to deal with than than UHCI. The low-level bits
of the USB protocol are fairly nasty. UHCI is a cheap and nasty host
solution, which directly exposes (and requires faking of) all the nasty low
level details and timing.
OHCI is a higher level interface which I found makes it much easier to
actually implement things sanely in a virtual environment.
Four days ago :) I would've completely agreed with you. But once I
figured out a ridiculously simple way to match outstanding transactions
against current QHs and TDs (ED/TD in the OHCI terms) I changed my
opinion. I mean in general OHCI does seem better. But cheap does not
necessarily mean bad. In this case it means _simple_. Last Friday I made
asynchronous ISOC transactions work reliably and both UHCI and usb-linux
code is very generic and does not need any special logic for isoc which
is nice.
Unless I'm missing something OCHI also exposes USB frame timing when it
comes to ISOC and interrupt transactions, and is fairly similar to UHCI
in that regard.
btw With the new UHCI code there is really no need to fake any USB
timing in the UHCI. I simply match transactions by tokens (which encodes
addr/endpoit/size/etc) and use QH/TD structure just to determine how the
frame is composed. Yes there is per frame timer, but all it does it just
updates pending transactions and submits new ones. OHCI also needs a
timer to handle ISOC transactions.
So overall I think UHCI is totally usable and sane now. And what I like
the most is that it's very simple. It's almost 2:1 ratio, code size
wise, with OHCI vs UHCI once I added support for multiple async
transactions to both (like I did not finish OHCI).
So we'd definitely need to work on OHCI if it's important for some
platforms.
I consider OHCI to be important. x86 is abut the only target foolish enough to
use UHCI.
I think we need both for ultimate compatibility.
We also need EHCI otherwise XP keeps telling me "dude, you plugged
device XYZ into the wrong port" :).
Max
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html