qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "David S. Ahern" <daahern@cisco.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions
Date: Wed, 26 May 2010 15:23:48 +0200	[thread overview]
Message-ID: <4BFD20E4.9000805@redhat.com> (raw)
In-Reply-To: <4BFD1CC7.3010208@cisco.com>

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	other threads:[~2010-05-26 13:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-25 13:40 [Qemu-devel] RFC: ehci -> uhci handoff suggestions David S. Ahern
2010-05-26 11:47 ` Gerd Hoffmann
2010-05-26 12:25   ` Kevin Wolf
2010-05-26 12:48     ` Gerd Hoffmann
2010-05-26 13:06       ` David S. Ahern
2010-05-26 13:23         ` Kevin Wolf [this message]
2010-05-26 14:00           ` David S. Ahern
2010-05-26 19:54             ` Johannes Stezenbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BFD20E4.9000805@redhat.com \
    --to=kwolf@redhat.com \
    --cc=daahern@cisco.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).