Re: [Qemu-devel] [PATCH 5/5] husb: rewrite Linux host USB layer, fully async operation

[Max Krasnyansky <maxk@kernel.org>]

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