On Tue, 17 Mar 2009, David Brownell wrote: > On Tuesday 17 March 2009, Sarah Sharp wrote: > > Why are companion controllers > > difficult to deal with from a software perspective? > > They add a funky state to EHCI root hubs, which isn't > part of the standard model: "owned by companion". And then additional complication is added when the OS wants to "force" a port to be handed over to the companion. > They create init sequencing problems, when e.g. the > companion HCD grabs a port before EHCI starts and > the device gets extra resets. Not all devices like > those odd-but-valid init sequences. > > There are strange and undocumented transition states > that require some handshaking on reset signaling; > I forget the details, look at the GIT history on > the patches adding that handshaking for the oddball > bugs it fixes. There are similar problems relating to resume-from-hibernation. While the system is off, the hardware loses track of which controller owns a full-speed/low-speed device's port. Upon resume, the HCD needs to transfer ownership of the port from EHCI back to the companion at exactly the right time (after the companion has been reinitialized but before it has started checking port statuses). > They take extra system (silicion, software, irqs, RAM) > resources. UHCI for example only handles two ports > per controller, so a modern PC with ten ports needs > five such controllers ... that's not so bad with OHCI, > which can support as many ports as EHCI can, but it's > still needless complexity. This could have been handled better by the manufacturers. Although I've never seen a UHCI controller that could handle more than two ports, the specification allows up to 7 at least. Maybe this is the result of inertia on the part of the designers or limitations in the Windows driver. Alan Stern -- 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
