On Thu, Apr 20, 2023, Alan Stern wrote: > On Thu, Apr 20, 2023 at 02:31:25AM +0000, Thinh Nguyen wrote: > > On Wed, Apr 19, 2023, Alan Stern wrote: > > > On Wed, Apr 19, 2023 at 09:49:35PM +0000, Thinh Nguyen wrote: > > > > By the usb spec, for IN direction, if there's no data available and the > > > > host requests for data, then the device will send a zero-length data > > > > packet. > > > > > > I'm not aware of any such requirement in the USB-2 spec. The closest I > > > can find is in section 5.6.4: > > > > > > An isochronous IN endpoint must return a zero-length packet > > > whenever data is requested at a faster interval than the > > > specified interval and data is not available. > > > > > > But this specifically refers only to situations where the host asks for > > > isochonous data more frequently than the endpoint descriptor's bInterval > > > describes. > > > > This is from usb 3.2 section 4.4.8.2: > > > > Note, if an endpoint has no isochronous data to transmit when > > accessed by the host, it shall send a zero length packet in > > response to the request for data. > > Ah, but chapter 4 in the USB-3.2 spec describes only the SuperSpeed bus, > as mentioned in the first paragraph of section 4.1. So the constraint > about sending 0-length isochronous packets when no data is available > applies only to SuperSpeed connections. If a gadget is connected at > USB-2 speed, the constraint doesn't apply. Right, this may not be a requirement for usb2 speeds. Regarding our dwc3 controller, it keeps the same behavior for both usb2 and usb3x speeds, which is to automatically respond with a 0-length packet for IN isoc endpoint if the host requests and no data is available. BR, Thinh > > (And in fact, no matter what the connection speed is, there's always a > possibility that the first packet sent by the host to begin an > isochronous transfer might get lost or corrupted, in which case the > device would not send a reply in any case.) > > > > > This is what the dwc3 controller will do. So regardless whether > > > > you prepare and queue a 0-length request or not, the host will receive > > > > it. > > > > > > Even so, whether the function driver submits these 0-length isochronous > > > requests makes a difference in terms of filling the slots in the > > > schedule and preventing later requests from becoming stale. > > > > > > > That's not my point. Avi concern was how the host may interpret 0-length > > packet. My point was to note that it should behave the same as before. > > Because even without sending 0-length requests, the controller would > > already respond with 0-length packet already. > > It would be good to confirm the reasoning by checking the source code > for the UVC host driver. But I expect you are right. > > > In fact, that's what the UVC driver should be doing, by maintaining the > > request queue with dummy requests as suggested in the beginning. > > > > Perhaps there was some misunderstanding. Sending 0-length request you > > suggested is a perfectly good suggestion and UVC gadget driver should do > > that instead of relying on the workaround in the dwc3 driver. > > Agreed. > > Alan Stern
