Re: USB Host Controller no PCD interrupt and CCS and CSC update on the device disconnect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> > 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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux