Hi Alan, On Mon, May 25, 2015 at 10:16 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 25 May 2015, Rong Wang wrote: > >> 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. > > It seems that your customer wants to change the hardware, not the > software. Yes. We plan to do a hardware modification. But we want to make as little change as possible. So we plan to make the internal signal HostDisconnect , which is sent from PHY to indicate a disconnection event, configurable by software. We'll mask this signal at first, once the software determines that there's a disconnection event, we unmask this signal to notify the USB controller. The advantage of this implementation is that the disconnection indication signal will not go to USB controller directlly, thus no internal clean up work will be done, which will make software recovery possible. The disadvantage is that since there's no disconnection indication signal, there's no PCD interrupt and no CCS and CSC update avalable. It's totally determined by software. We don't konw whether this implementation can handle all the corner cases. BTW, how's the USB Device Controller (HS/FS) detetct the disconnection? Does it detect the disconnection by a SE0 line status or by VBUS status? Thanks! > >> > 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. > > Sometimes there are hardware problems that can not be solved in > software, or are too difficult to solve in software. I think this is > one of them. > > 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
