All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.