On 05/26/2010 07:23 AM, Kevin Wolf wrote: > 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
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. David