On Wed, Apr 20, 2016 at 10:41:42AM +0300, Felipe Balbi wrote: > Peter Chen <hzpeterchen@xxxxxxxxx> writes: > > On Tue, Apr 19, 2016 at 10:20:33AM -0400, Alan Stern wrote: > >> On Tue, 19 Apr 2016, Felipe Balbi wrote: > >> > >> > Hi, > >> > > >> > Peter Chen <hzpeterchen@xxxxxxxxx> writes: > >> > > Hi all, > >> > > > >> > > When I review the patch [1] for adding companion controller support for > >> > > OTG framework, I am puzzled several concepts, like shared hcd and > >> > > companion controller, companion hcd, companion port, would someone > >> > > please explain them? And why EHCI/OHCI do not use shared hcd, but > >> > > xHCI uses it? Thanks. > >> > > >> > xHCI is modeled as two separate buses (High-speed and Super-speed) which > >> > *share* the same IP block. In the case of EHCI/OHCI, there is a port > >> > being handed over to the a completely separate IP. OHCI is EHCI's > >> > companion for non-HS signalling. > >> > >> That's right. In more detail: > >> > >> Companion controller and companion hcd are the same thing. They exist > >> because EHCI can only handle high speed connections; it can't handle > >> full speed or low speed. When a USB-1.1 device is plugged into an EHCI > >> controller, the EHCI controller can't handle it and so the connection > >> is handed over to the companion controller, which is either OHCI or > >> UHCI. > >> > >> xHCI doesn't have that problem; it can handle all speeds. However the > >> hardware design (not just the software design!) uses two separate > >> buses: one for SuperSpeed and one for high/full/low speed. There > >> actually are two separate sets of wires in a USB-3 cable. > >> > >> If the USB core were designed better, we would have used a single > >> usb_hcd structure for xHCI, with two usb_bus structures inside it. But > >> the structures were designed long before USB-3 was announced, and it > >> would have taken a lot of changes to make that approach work. Instead, > >> xhci-hcd uses two usb_hcd structures, each containing a single usb_bus. > >> The structure for the high/full/low-speed bus is called the primary_hcd > >> and the structure for the SuperSpeed bus is called the shared_hcd. > >> > >> As a result of xHCI's design, the same physical port on the computer > >> will show up as two different ports in the kernel: one attached to the > >> SuperSpeed hcd and one attached to the high/full/low-speed hcd. The > >> peer pointer (not companion!) in struct usb_port connects these two > >> logical ports. > >> > > > > Thanks, Alan, Felipe, Oliver. > > > > After reading the beginning content of EHCI spec, I understand what is > > companion controller. At chipidea USB2 design, it handles FS/LS by > > internal, so I have no knowledge about it. > > > > Integrated Transaction Translator (Multi Port implementations) supports > > directly connected USB legacy (USB 1.1) Full and Low speed devices > > without a companion USB 1.1 host controller or host controller driver > > software. > > > > Embedded Transaction Translator - Allows direct attachment of FS and LS > > devices in host mode without the need for a companion controller. > > TT is only required for hubs, not for roothubs. Some roothubs will > implement it to save silicon area, but regular EHCIs don't ;-) > Yes, the above contents are listed from chipidea's Reference Manual. -- Best Regards, Peter Chen -- 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
