From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42363 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHMgZ-0006vg-If for qemu-devel@nongnu.org; Wed, 26 May 2010 15:54:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHMgV-0004fm-QB for qemu-devel@nongnu.org; Wed, 26 May 2010 15:54:36 -0400 Received: from bar.sig21.net ([80.81.252.164]:60661) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHMgV-0004fD-L6 for qemu-devel@nongnu.org; Wed, 26 May 2010 15:54:35 -0400 Date: Wed, 26 May 2010 21:54:15 +0200 From: Johannes Stezenbach Subject: Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions Message-ID: <20100526195415.GA29848@sig21.net> References: <4BFBD33F.7010403@cisco.com> <4BFD0A60.10408@redhat.com> <4BFD1337.6000106@redhat.com> <4BFD1895.1050405@redhat.com> <4BFD1CC7.3010208@cisco.com> <4BFD20E4.9000805@redhat.com> <4BFD2981.4060902@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BFD2981.4060902@cisco.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "David S. Ahern" Cc: Kevin Wolf , Gerd Hoffmann , qemu-devel 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