On Wed, Sep 26, 2012 at 03:14:59PM -0400, Alan Stern wrote: > On Wed, 26 Sep 2012, Sarah Sharp wrote: > > On Wed, Sep 26, 2012 at 05:31:43PM +0200, Oliver Neukum wrote: > > > And it seems to me that in many cases, namely > > > EHCI with companion controllers and XHCI controllers that implement > > > a vendor specific switching option, we could switch the ports so that > > > a minimum number of controllers is connected to ports that are not switched > > > off. > > > > It would be nice to have only one powered host controller, I agree. But > > I'm not sure the idea would actually help systems with the EHCI/xHCI > > port switching. > > > > We would want to leave any powered port under the xHCI host controller, > > because we want USB 3.0 devices to connect at SuperSpeed. If we can't > > switch over the EHCI ports to xHCI, it's either because there isn't a > > physical switch, or the OEM is preventing the port switchover because it > > has some internal USB device that doesn't work well under xHCI. So > > we're forced into having two powered host controllers, and there's no > > other way we can switch ports to help. > But this is starting to sound a little peculiar. Intel supports the > port-power stuff only on its most recent (i.e., not yet released) > systems. Do these same bleeding-edge systems also include the > old-style switch-xHCI-ports-back-to-EHCI mechanism? The Lynx Point chipset has the EHCI/xHCI port switchover: 1c12443 xhci: Add Lynx Point to list of Intel switchable hosts. As I said in the commit, Lynx Point has one xHCI host and two EHCI hosts. All the ports can be switched over from EHCI to xHCI, unlike with Panther Point. > If all the ports are set to xHCI and the EHCI controller doesn't have > any others then it could be powered off, assuming there's some way to > do that. Sure. It would at least be placed into host suspend at that point. But I'm not sure what software could do beyond that. The funny thing is that the OS can't actually tell if it's switched all the ports from an EHCI controller. It only gets a port mask register with the mask of the ports it's allowed to switch over. There's no mapping between those bits and which EHCI host has which port. If there's less bits set in the port mask register than there is ports on the two EHCI hosts, then the OS can't tell which EHCI host still has an unswitched port. Therefore the OS doesn't know which EHCI host is safe to power off, if any. I think we would have to leave any additional power savings mechanisms to the BIOS at that point. > > I think you run into similar issues with EHCI hosts with companion > > controllers. You want all the powered ports to be under EHCI by > > default. If you have a port under UHCI or OHCI, then it's because you > > have a connected LS/FS device. So you're stuck with an two powered host > > controllers. > > Oliver was pointing out that if none of the attached devices are FS/LS > then the companion controller and all its ports could be powered off. > The EHCI driver knows when a new FS/LS device gets attached, so it > could arrange for the companion controller to power back on at that > time. Yep, that might help on some other system with a port power off mechanism, but not for Lynx Point. I'm pretty sure Lynx Point only has EHCI rate matching hubs, and no companion controllers. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
