Hi Considering the use case of function suspend (function driver unlinking submitted urbs) is happening. 1) If there is a data transfer but due to inactivity on to the bus suspend happened. 2) No data transfer is happening just device is suspending (unlink urbs) and resuming (resubmit urbs). For the above two cases when stop ep cmd is issued (due to unlinking of urb) which of these would happen A) controller generates transfer Event TRB (with "stopped" completion code)and then Command Completion Event for stop ep cmd. B) Controller generates command completion event for stop ep cmd. If for bother cases (1 & 2), A happens then i would like to understand a use case where B happens. I went through the spec which says : Depending on the timing of the execution of the Stop Endpoint command relative to the execution of the TDs on the ring, one of two of scenarios may result: ? If the command is executed between TDs, then the only event generated will be a Success Command Completion Event for the command. ? If a TD is in progress for the pipe when the command is executed, then a Transfer Event TRB with its Completion Code set to Stopped shall be forced for the interrupted TRB, irrespective of whether its IOC or ISP flags are set. This Transfer Event TRB will precede the Command Completion Event TRB for the command, and is referred to as the Stopped Transfer Event. But i am trying to figure out the use case for first bullet point. When running iterative suspend (unlink urbs) resume (resubmit urbs), after some cycles of suspend and resume, i see that controller stopped generating transfer Event TRB and just generating command completion event for stop ep cmd. This is causing issues with deq ptr not being moved on to the ring as set tr deq ptr cmd is not issued, just all the unlinked trbs are marked as no-op which is ultimately resulting in frequent ring expansion and ultimately system runs out of dma pool. Thanks, Hemant -- 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
