On Fri, May 05, 2023, Avichal Rakesh wrote: > > > On 5/5/23 15:39, Avichal Rakesh wrote: > > > > > > On 4/20/23 10:20, Laurent Pinchart wrote: > >> > >> As far as I understand, we have two ways forward here to avoid running > >> out of requests to send: sending data as quickly as possible (maximizing > >> the number of bytes sent in each packet) and filling up with 0-length > >> requests in-between, and spreading the data across packets. I'll call > >> the first one burst mode for lack of a better term. > >> > > > > Hey all, > > > > Apologies for the late reply. My not-so-long work took longer than expected. > > I tried the 2 (technically 3, but I'll go over it in a bit) approaches we had > > discussed above and the "burst" approach works pretty well. I'll attach that > > to this email, and send another email out with the other patch. > > > Here's the second test. This patch does the complete opposite of the previous one > and is based on Thinh mentioning that there was some logic built into DWC3 to > reschedule requests if the uvc driver does not queue a request for some time. > > It queues usb_requests in short bursts and waits until all the queued requests > have been returned before queueing up another burst of usb_requests. This was > disastrous as it saw far more ISOC failures than before. > > That likely stemmed from timing between the last request being returned and the > new burst of requests being queued, but no amount of arbitrary waiting > between last return and first queue completely eliminated the ISOC failures. > Right, if the "last request" is set with no_interrupt, then the dwc3's rescheduling workaround won't kick in, which will fail regardless the wait time before the next burst. This workaround logic in dwc3 is very basic, and it does not handle every scenario. We can improve on this logic, but as noted we should not rely on it. BR, Thinh
