Re: [PATCH 2/2] usb: dwc3: gadget: restart the transfer if a isoc request is queued too late

[Michael Olbrich <m.olbrich@pengutronix.de>]

On Wed, Nov 13, 2019 at 03:55:01AM +0000, Thinh Nguyen wrote:
> Michael Olbrich wrote:
> > Currently, most gadget drivers handle isoc transfers on a best effort
> > bases: If the request queue runs empty, then there will simply be gaps in
> > the isoc data stream.
> >
> > The UVC gadget depends on this behaviour. It simply provides new requests
> > when video frames are available and assumes that they are sent as soon as
> > possible.
> >
> > The dwc3 gadget currently works differently: It assumes that there is a
> > contiguous stream of requests without any gaps. If a request is too late,
> > then it is dropped by the hardware.
> > For the UVC gadget this means that a live stream stops after the first
> > frame because all following requests are late.
> 
> Can you explain little more how UVC gadget fails?
> dwc3 controller expects a steady stream of data otherwise it will result 
> in missed_isoc status, and it should be fine as long as new requests are 
> queued. The controller doesn't just drop the request unless there's some 
> other failure.

UVC (with a live stream) does not fill the complete bandwidth of an
isochronous endpoint. Let's assume for the example that one video frame
fills 3 requests. Because it is a live stream, there will be a gap between
video frames. This is unavoidable, especially for compressed video. So the
UVC gadget will have requests for the frame numbers 1 2 3 5 6 7 9 10 11 13 14
15 and so on.
The dwc3 hardware tries to send those with frame numbers 1 2 3 4 5 6 7 8 9
10 11 12. So except for the fist few requests, all are late and result in a
missed_isoc. I tried to just ignore the missed_isoc but that did not work
for me. I only received the first frame at the other end.
Maybe I missing something here, i don't have access to the hardware
documentation, so I can only guess from the existing driver.

Regards,
Michael

> > This patch changes the behaviour of the dwc3 gadget driver to match the
> > expectations. If a request arrives too late, then the transfer will be
> > restart to create the needed gap.
> >
> > A request is late if:
> > 1. There are currently no requests queued in the hardware
> > 2. The current frame number provided by DSTS does not match the frame
> >     number returned by the last transfer.
> >
> > If this happens transfers are stopped. The following XferNotReady provides
> > the new correct frame number and restarts the transfer.
> >
> > Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
> > ---
> >   drivers/usb/dwc3/gadget.c | 8 ++++++++
> >   1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index ac4673d91939..eb7f09929f28 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -1473,6 +1473,14 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req)
> >   				return __dwc3_gadget_start_isoc(dep);
> >   			}
> >   		}
> > +		if ((dep->flags & DWC3_EP_TRANSFER_STARTED) &&
> > +		    list_empty(&dep->started_list) &&
> > +		    ((dep->frame_number & 0x3fff) !=
> > +		    __dwc3_gadget_get_frame(dwc))) {
> > +			dwc3_stop_active_transfer(dep, true, true);
> > +			dep->flags = DWC3_EP_ENABLED;
> > +			return 0;
> > +		}
> >   	}
> >   
> >   	return __dwc3_gadget_kick_transfer(dep, false);
> 
> BR,
> Thinh
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |