Hi, Alan Stern wrote: > On Thu, 30 Apr 2020, Thinh Nguyen wrote: > >> Peter Chen wrote: >>> If 'transfer size' here is software concept, why controller needs to know? The general >>> controller internal logic doesn't care class protocol, it only cares TRB chain software prepares. >> While some controllers don't have the concept of this, DWC_usb3x does. >> It has a notion of starting and ending a transfer. While a transfer is >> started, the endpoint uses a resource. It releases that resource when >> the transfer completes. So far, dwc3 implemented in such a way that bulk >> transfers are always in-progress and don't complete. That's fine so far, >> but it's not the case with streams. > This is peculiar. I haven't heard of any other controller doing this. > > What does the controller use this resource for? Would anything go > wrong if you told the controller that each transfer was a single > usb_request? It's no problem. Each transfer can be a single request. Just set the request->is_last. (Refer to [patch 2/5] for f_tcm). The issue here is that the controller needs to know when a stream completes so it can start on a different stream. In the controller driver, this is done by setting a certain control bit in the TRB indicating the last TRB of a transfer. This knowledge can only come from the function driver, which is why we need this "is_last" field. BR, Thinh
