On Fri, Feb 01, 2013 at 02:09:24PM +0800, 洪崇耕 wrote: > Hi, > > According to xHCI spec Rev1 page 125, Endpoint context state diagram. > > When reset device, the endpoint state transit to disabled state. Right. And the endpoint resources are supposed to be dropped by the Reset Device command. Section 4.6.11 says the host should "Free any bandwidth allocated to the periodic endpoints" and "Free any internal resources associated with the endpoint". After the device is reset, the USB core re-instates the configuration, with alternate setting 0 for all interfaces. The xHCI driver will issue a Configure Endpoint command with the add flag set for those endpoints. According to section 4.6.6, if that command is successful, the host should set the endpoint output context state to running. Is your host setting the endpoint context state to running? Then the USB core attempts to re-instate any interfaces that weren't originally at alt setting zero. That means dropping and adding endpoints. The endpoint context state should be running at that point, so the call to drop_endpoints should succeed. If that's true, we shouldn't ever add an endpoint context twice. (However, note that your test code doesn't change any alternate interface settings before resetting the device. That means you're not running into the case in the third paragraph. Unless you're resetting a device with a driver bound to it, and the driver is re-installing a different alternate interface setting.) Are you sure the TI host and your host isn't neglecting to drop endpoint resources when the Reset Device command is handled? Sarah Sharp > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, January 31, 2013 12:22 AM > To: 洪崇耕 > Cc: linux-usb@xxxxxxxxxxxxxxx > Subject: RE: Not enough resource for old configuration after USB bus reset > > On Wed, 30 Jan 2013, [big5] x R wrote: > > > Hi all, > > > > We try to reproduce the problem on general desktop with ubuntu 12.04.1 and 12.10, and got some information below: > > > > 1. If we use xHci with Ti TUSB7340 chip, do bus reset or plug/unplug 1000+ times, the host fail to configure the device. > > If we use xHci with Fresco chip, it operats without error. > > > > 2. If the usb device contains only Control/Bulk type endpoints, it's all right. > > If it contains interrupt/isoc (periodic) endpoint, it will fail with bandwidth error. > > I check the source and find that the bandwidth_error is the TRB_completion_code of configure_endpoint command. > > > > In addition, I try to study the usb_reset_and_verify_device and want to consult the following question. > > > > When reseting a device, hcd will invoke usb_hcd_alloc_bandwidth, this > > function will drop the endpoints and add the endpoints. > > > > When executing drop_endpoint, the function shows error message xHCI called with disabled ep. > > And I confirm that ep_state of end point context is in disabled state this time. > > Why is the endpoint already disabled? It shouldn't be. > > > Then usb_hcd_alloc_bandwidth invokes add_endpoint. > > Last, sending a configure endpoint command to complete the change. > > > > The xHCI spec says configure endpoint should ignore disabled endpoints drop flag and do nothing. > > So the source is correct according to spec. > > But the overall behavior is adding the endpoint without dropping the old endpoint. > > > > Is this what we want? Don't we need dropping endpoints to release the > > bandwidth and/or resource before the endpoints goes to disabled state without freeing bandwidth? > > Yes. It would work okay if the endpoint wasn't already disabled. Can you figure out how the endpoint became disabled in the first place? > > Alan Stern > > N?妓緶r??y???匒淅炮v傂?)瑎{.n?+?極?{捱?傂n?r←屹??螐?刻俾&ｐ 埂??嶭?(剝???摃j"???m????翯z嫡??僠fㄑ搬??坍?m -- 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
