qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions


From: Kevin Wolf
Subject: Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions
Date: Wed, 26 May 2010 15:23:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4

Am 26.05.2010 15:06, schrieb David S. Ahern:
> 
> 
> On 05/26/2010 06:48 AM, Gerd Hoffmann wrote:
>>
>>   Hi,
>>
>>>> USB devices can support both 1.1 and 2.0, right?  Who decides which
>>>> protocol is used then?  I think the OS can speak 1.1 to the device even
>>>> in case a ehci controller is present (but unused by the OS), right?
>>>
>>> AFAIK the OS must tell the EHCI that it should hand the device off to
>>> the UHCI/OHCI companion before it can use it there.
>>
>> Huh?  Compatibility-wise it makes sense to do it the other way around
>> (i.e. have it @ UHCI/OHCI by default and move to EHCI on request), so a
>> OS which knows nothing about EHCI can cope.

Ah, the page referenced by David explains this, so what I knew is only
half of it. There is a Configured Flag that tells if the EHCI is used -
and only when the OS has activated the EHCI this way it needs to
explicitly hand off per device.

>>> If they should be accessed via the EHCI or a companion controller
>>> depends on what the OS requests. And USB 2.0 says that any device that
>>> supports High Speed must also support Full Speed and therefore be
>>> accessible using the companion (at least that's what I understand).
>>
>> Hmm, ok, so no shortcut even for emulated devices.  Not that it would
>> have helped much as we have to cover host devices anyway.
>>
>> Also I think one ehci controller can have multiple uhci companion
>> controllers.  At least lspci on my T60 suggests that:

Yes, I think any number is allowed, and from a specification point of
view it's even okay to have no companion controller at all. You just
couldn't use Low/Full Speed devices in the ports of that controller then.

>> 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>> Controller #1 (rev 02)
>> 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>> Controller #2 (rev 02)
>> 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>> Controller #3 (rev 02)
>> 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>> Controller #4 (rev 02)
>> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
>> Controller (rev 02)
>>
>> cheers,
>>   Gerd
>>
> 
> Yes, that is the ehci feature to be implemented.
> 
> My understanding is that the port routing happens internally to the host
> controller based on device speed - section 4.2 (pag 64) of:
> http://www.intel.com/technology/usb/download/ehci-r10.pdf

The routing may happen internally, but the OHCI/UHCI appears just like a
normal controller to the OS. You can't access the devices on a companion
with your EHCI driver.

> ehci does have more overhead from an emulation perspective, so it would
> be best to keep mice, keyboard, serial ports, etc on the uhci/ohci bus
> and have storage devices and webcams and such on ehci. And any
> transition should happen automagically within the device model.

I think in reality things like keyboards are Low Speed anyway, so they
would need to be handed off to a OHCI/UHCI anyway.

Any transition between High Speed (directly handled by EHCI) and
Low/Full Speed (OHCI/UHCI companion controller) must not happen
automagically, but be requested by the guest OS. And you probably don't
want to re-implement UHCI or OHCI inside the EHCI emulation, so you
can't keep things inside the EHCI device model.

Kevin



reply via email to

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