RE: Not enough resource for old configuration after USB bus reset

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

 



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

HCD fill the drop/add flag of input context, and issue configure command to tell HC evaluate the flag.
The realease is done when HC evaluate drop flag.
But HCD and HC will not do drop operation since it is disabled.

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

We found this issue on our embedded system.
The driver is wrote with no periodic transfer.
So it might not solve the issue.
Thanks for the suggesstion.

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

I have do some trick on my embedded system HCD source.
Make it always not set the periodic endpoint add flag (because we don't use it on the embedded system),
And this provide us a work-around solution temporarily.
But I know this is not correct method, I just want to bypass it.

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



Best regards,
Soar
--
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