> > On Thu, 10 May 2012, Quach, Brian wrote: > >> >> Hello, >> >> >> >> I work for Texas Instruments on the group that develops our USB >> >> 3.0 products. Recently, we discovered a timing issue in our USB3.0 >> >> re-drivers that can delay the negotiation between a device and the >> >> host past the usual handshake timeout, and if that happens on the >> >> first insertion, the host controller port will enter in Compliance >> >> mode as per the xHCI spec. The host controller does not generate a >> >> Port Status Change (PSC) event as a result of a transition to >> >> compliance mode so the only way method to detect and resolve the >> >> issue is to periodically poll the port to check for compliance >> >> mode and issue a Warm Reset to recover the port. This polling is >> >> only required if the port had never previously entered U0. >> > >> >That sounds like a broken host controller, doesn't it? >> >> No, that is proper host controller behavior. The unwanted compliance >> mode is a side effect of an additional delay added by the redriver. >> It only happens very occasionally and was discovered during stress >> testing. This redriver has already shipped in many end-user systems >> and would affect ANY host controller. > > For those of us not intimately involved in hardware design, can you > explain: What is a redriver? Hello Alan, A redriver is a device designed to minimize signal degradation on long layout traces or cables. In other words, it strengths and equalize the signal. This is the device in question: http://www.ti.com/product/sn65lvpe502cp As an example, a redriver is commonly used between the xHCI Host Controller and the front panel USB 3.0 connectors. > > 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
