HI, On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: > > What's the actual issue here ? Can you explain to me Sarah ? > > This may be a known issue regarding this particular host > > controller and if it is, there might already be workarounds available. > > I copy the previous content and try to make it more clear. > > When calling usb_reset_and_verify_device, hcd issue a reset command. > The reset device command make the endpoint state disabled without > releaseing the bandwidth. > > After reset is done, the HCD try to reconfigure the device to previous > active config by usb_hcd_alloc_bandwidth. > The HCD does such thing by modifying drop and add flag in input > context, and issue configure endpoint command to comoplete the > operation. > > When executing drop_endpoint, the endpoint is already in the disabled > state. > This behavior is correct according to the spec. And the HC will not > evaluate drop flag of disable endpoint,too. fair enough. > As a result, the HC can not drop the endpoint to release the > bandwidth. But if the endpoint is already dropped, why hasn't bandwidth allocation being released too ? Sarah ? > Then add_endpoint to enable these endpoints. > After all drop add flag are set, HCD sends a configure endpoint > command to complete the change. right. > Before the priodic bandiwdth is used up, the configure endpoint > command can success. > However, after reset several times, the configure endpoint command > fail with command status "not enough bandwidth". > And the HC can not correctly configure any more periodic device. this does sound like a known errata. Unfortunately there's no suggested for it. Just to make sure this is really the case, can you, somehow, make sure that no transfers are ever scheduled to any of the periodic endpoints and see if that "solves" the issue. If it turns own that this helps, then we're talking about a known errata. It will just take some time to figure out how to work around it provided there are no suggested workarounds on the errata description. I'll try to reproduce it here with a mouse (I happen to have a TUSB7340 too in my PC), if it fails the same way, I'll have a simple way to try, but meanwhile please check that preventing transfers from being scheduled to any periodic EP makes your test work. > > If the problem is related only to device reset, then it would > > have failed USB30CV Device Reset test which drives 500 Device > > Resets and checks that device reenumerates. I doubt that's > > the case though, since TI's TUSB7340 is built with a USB3 > > Certified IP. > > > > We have try two devices, both are USB-IF certified, on this host and > they fail with same scenario. > And these two devices can successfully reset several times on some > other host. that's alright, I'm just wondering how come this wasn't caught during certification... perhaps certification lab didn't use a device with periodic endpoints to run the test. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
