On Mon, Feb 25, 2013 at 01:42:44PM +0200, Felipe Balbi wrote: > 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 ? I think we're talking past each other. :) Soar, what bandwidth allocation resources are you talking about? In the xHC hardware, or in the xHCI driver? I've been talking about resources in the hardware only, but I want to confirm we're talking about the same thing. As I understand it, the Reset Device command should drop all bandwidth allocated within the xHC hardware. Then we go back and re-add the endpoints, setting only the add flag in the input context. As Soar mentioned, this is spec-compliant, but the host eventually gives an out-of-bandwidth completion code for the Configure Endpoint command. > > 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. Or maybe they issue a Configure Endpoint command to drop all endpoints before they issue the Reset Device command? That was my proposed work-around. 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
