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