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



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

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.

David

  reply	other threads:[~2010-05-26 13:06 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 [this message]
2010-05-26 13:23         ` Kevin Wolf
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=4BFD1CC7.3010208@cisco.com \
    --to=daahern@cisco.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@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).