[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Max Krasnyansky
Subject: Re: [Qemu-devel] [PATCH 5/5] husb: rewrite Linux host USB layer, fully async operation
Date: Mon, 18 Aug 2008 11:40:09 -0700
User-agent: Thunderbird (X11/20080501)

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

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" :).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]