On Thu, 30 Apr 2020, Thinh Nguyen wrote: > 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 Why does it need to know this? Why can't it start on a different stream at any time? > 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. What's wrong with just assuming _every_ usb_request is the last one of its transfer? Then you wouldn't have to add a new flag or change the existing function drivers. Alan Stern
