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
next prev parent 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).