On Fri, May 22, 2015 at 10:06 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 22 May 2015, Rong Wang wrote: > >> Hi, >> >> We have one USB 2.0 Controller on an ARM SoC, with internal PHY >> confirming to UTMI. >> The PHY would detect unexpected disconnect (amplitude of the >> differential envelop still < 625 mV) >> and assert the HostDisconnect signal to the Controller to indicate a >> disconnection event. >> When the HostDisconnect signal is asserted, the Controller will first >> do some internal clean work >> before it update CCS and CSC in PORTSCx and reports a Port Change >> Detect interrupt. >> We want to improve the situation > > Why do you want to improve the situation? What's wrong with the way it > is now? Detecting a disconnect while the differential amplitude is < > 625 mv is perfectly legal. The USB-2.0 spec requires: "Signals with > differential amplitudes <= 525 mV must never activate the Disconnection > Envelope Detector" (section 7.1.7.3). > Our customer oberserved some unexpected disconnections during the "shaking" test (user scenario simulation). They want the disconnection detection to be less sensitive (>= 625 mV). Because once the discoonection is reported, the APP SW will be re-launched and the USB device will also notify user the disconnection event, which is not accepted by our customer. >> by masking the HostDisconnect signal >> from PHY (take the >> cost into consideration), but it will cause no CCS and CSC update in >> PORTSCx, and no PCD interrupt. Thus the true disconnection only can be >> determined by an XactErr. Once the driver >> determine that it's a true disconnect, the HostDisconnect signal can >> be unmasked and the >> Controller will detect this disconnect. >> We are worried about the workaroud, since there may be many corner >> cases we have not taken into consideration, such as the race condition >> on connect and disconnect. > > It sounds like you are going to make the situation worse, not improve > it. We are going to filter the intermittent disconnection signal from PHY, but we must determine a true disconnection by driver with a retry scheme. I agree that it will make the situation more complicated because there may be many corner cases that we don't forsee and one of them may even make this workaround not workable. > >> So have you encountered this situation before? Or is there any >> suggestion on this workaround? > > I don't see any reason to make any changes. > > 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
