All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@sig21.net>
To: "David S. Ahern" <daahern@cisco.com>
Cc: Kevin Wolf <kwolf@redhat.com>, 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 21:54:15 +0200	[thread overview]
Message-ID: <20100526195415.GA29848@sig21.net> (raw)
In-Reply-To: <4BFD2981.4060902@cisco.com>

On Wed, May 26, 2010 at 08:00:33AM -0600, David S. Ahern wrote:
> On 05/26/2010 07:23 AM, Kevin Wolf wrote:
> > Am 26.05.2010 15:06, schrieb David S. Ahern:
> >>
> >> 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.
...
> > 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.
> 
> I'm still confused by the guest OS interaction -- more code/spec reading
> I guess.
> 
> Key points are that lspci in the VM shows both buses, and the qemu
> monitor would still scan both buses and show devices. And definitely no
> code duplication - some kind of movement to current uhci/ohci ports is
> what I am after.

My understanding of the EHCI spec: It's best to see the
port router as a seperate device.  USB devices are not
connected directly to EHCI or [UO]HCI, they are connected
to the port router.  If the port routing is changed
one of the HCs will see a connect event, the other one
a disconnect event, i.e. the handling is as if you
had unplugged the cable from one HC and plugged in into
the other HC.

By default the bus is connected to [OU]HCI, but when the
OS loads an EHCI driver it will set the Configured Flag to change
the default routing to EHCI.  If the EHCI driver determines
a device is not high speed, it will change the routing for
that port back to [UO]HCI.  The port router will see a physical
unplug event so the EHCI driver can change the routing back to
EHCI on unplug.

I think a typical EHCI controller has more ports than a UHCI
or OHCI controller, this is why you see more companion controllers
in lspci.  I think this doesn't matter, the key point is that
there is a fixed connection in hw for each port to the port router.


Johannes

      reply	other threads:[~2010-05-26 19:54 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
2010-05-26 14:00           ` David S. Ahern
2010-05-26 19:54             ` Johannes Stezenbach [this message]

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=20100526195415.GA29848@sig21.net \
    --to=js@sig21.net \
    --cc=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 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.