qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "David S. Ahern" <daahern@cisco.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions
Date: Wed, 26 May 2010 13:47:44 +0200	[thread overview]
Message-ID: <4BFD0A60.10408@redhat.com> (raw)
In-Reply-To: <4BFBD33F.7010403@cisco.com>

On 05/25/10 15:40, David S. Ahern wrote:
>
> USB 2.0 leverages companion UHCI or OHCI host controllers for full and
> low speed devices. I do not see an appropriate means for doing that bus
> transition and could use some suggestions.

Hmm.  Well.  That doesn't really fit into the qdev tree model ...

> As I understand the code at this point it is a top down setup: device
> added, bus found, device attached.

Devices are always added to some bus.  In the case of usb the devices 
can also be attached/detached.  Emulated devices usually attached right 
after creating them.  Host devices are attached when a matching physical 
device shows up.

> ie., key point is the expectation that the bus to which the device is
> assigned is known early in the code path.

Yes.  You can even specify the bus you want attach the device to.

>      --------------------      --------------------
>     |   EHCI controller  |--->|    UHCI / OHCI     |
>      --------------------      --------------------
>               |                         |
>      --------------------      --------------------
>     |  USB device model  |    |  USB device model  |
>     |    (or driver )    |    |    (or driver )    |
>      --------------------      --------------------
>           high speed             full / low speed
>
>
> To know which bus to attach it to the device needs to be queried/probed
> for basic information - something the current architecture does not have.

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?

> Suggestions?

Maybe it makes more sense to look at ehci/uhci as *one* (physical) 
device with multiple interfaces?  They share the physical ports after 
all, at least on real hardware.

The tricky case is assigning host devices, right?  For the emulated ones 
we can probably could get away by simply forcing them into 2.0-only or 
1.1-only mode depending on which bus they got attached to.

cheers,
   Gerd

  reply	other threads:[~2010-05-26 11:47 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 [this message]
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
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=4BFD0A60.10408@redhat.com \
    --to=kraxel@redhat.com \
    --cc=daahern@cisco.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).