On Mon, Nov 19, 2012 at 06:59:54PM +0530, Bhavik Kothari wrote: > Hi Sarah, > > Please find answers as aligned, > > On Fri, Nov 16, 2012 at 11:36 PM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx > > wrote: > > > On Fri, Nov 16, 2012 at 10:19:01AM -0500, Alan Stern wrote: > > > On Thu, 15 Nov 2012, Greg KH wrote: > > > > > > > On Wed, Nov 07, 2012 at 06:36:46PM +0530, Bhavik Kothari wrote: > > > > > Hi Greg, > > > > > > > > > > Our host controller sets PRC and CSC bits at the time of initialization > > > > > even though no USB device is attached. Why are you setting CSC on initialization? Section 14.9.1.2.3 says that the ports should start out in the disconnected state. Your host should have no knowledge of the previous states before the host power up, so why would there be a connect change? > > > > > At the time of initialization, > > > > > hub_probe() gets called and in-turn it calls hub_activate(). > > > > > hub_activate() clears the CSC bit, but PRC bit does not get cleared (in > > > > > linux 3.6.1). hub_events() has functionality to clear the PRC bit, but > > > > > initially there is no events from HUB, so hub_events() may not clear the > > > > > PRC bit. Due to this behavior, when we try to insert a USB device, > > > > > interrupt does not generate (because, earlier, PRC bit was set and not > > > > > cleared) and USB device does not get enumerated. > > > > Does your host controller wait until the port reset is complete (and the > > PRC or BH reset change bits are set) before clearing CMD_RESET? > > > > > No, our Host controller does not wait till PRC or BH bit gets set. However, > these bits need to be clear to get an event from the root hub port. I've been re-reading the xHCI 1.0 spec with the latest updates from June 2011. It's not clear to me that the host controller needs to drive a hot or warm reset when the host controller reset (HCRST) is set by software. The section also says of the disconnected state: "If a port has transitioned to this state *from the Powered-off or Disabled states* due to the assertion of HCRST by software, then a Hot or Warm Reset shall be issued by the port when its LTSSM enters to the Rx.Detect state or after a receiver detection in the Rx.Detect state. The assertion of HCRST = ‘1’ shall cause the port to remain in the Disconnected state." On initialization, the port is in the disconnected state. Then HCRST gets set, and you stay in the disconnected state. Since you're not transitioning from the powered-off or disabled states, you don't need to drive a port reset. As you noted, the June update removed this sentence: "Software shall check the Port Reset (PR) flag to ensure that the Warm Reset is complete before issuing any commands to a port." And added this sentence: > According to spec, section 4.19.1.2.3 Disconnected (initially host > controller should be in Disconnected), "An xHC implementation may assert > WPR or PR to reflect the associated reset operation if HCRST is asserted > while the port is in the Disconnected state." So, if hub_activate() clears > PR bit, then it may not create any problem. According to that sentence, your host does have the right to set PR, and thus PRC on host controller reset. > Please let us know, what should be the proper approach to clear PR bit. On host controller reset, the xHCI driver should check if PR or WPR is set. If so, it should wait for the port reset change bit to be set. Then the code should unconditionally clear both the port reset change bit and the warm port reset change bit. The change bit clearing needs to be unconditional because the port reset may have completed by the time the xHCI driver gets around to reading the port registers. As I mentioned, this needs to be done in the xHCI driver, not in the USB core, since external hubs and (most) xHCI hosts do not set PRC or WRC on initialization. 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
