Re: DWC3-Gadget: Flickering with ISOC Streaming (UVC) while multiplier set on Superspeed

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Thu, Sep 07, 2023, Michael Grzeschik wrote:
> Hi Thinh
> 
> Thanks for the update!
> 
> On Wed, Sep 06, 2023 at 11:09:03PM +0000, Thinh Nguyen wrote:
> > On Wed, Sep 06, 2023, Thinh Nguyen wrote:
> > > On Wed, Sep 06, 2023, Michael Grzeschik wrote:
> > > >
> > > > > 2) Burst setting
> > > > > 	I think this is self-explainatory. Large data request needs
> > > > > 	higher burst.
> > > >
> > > > I will have to find out if the burst setting can be changed on the
> > > > rk3568 somehow. This sounds very likely.
> > > >
> > > 
> > > The dwc3 driver checks the endpoint descriptor from the UVC function
> > > driver to setup the burst. So just setup the max 16 bursts (or 15 in the
> > > descriptor). The dwc3 controller supports that. Whether the host would
> > > do 16 bursts is another thing. Note that there's no "mult" setting for
> > > SuperSpeed.
> > 
> > Clarification: no mult setting for the dwc3 controller when operate in
> > SuperSpeed.
> 
> I was somehow mistaken by the wording "burst setting" and thought of the
> axi-bus burst setting to the controller instead of the usb3 maxburst
> setting as you ment actually.

I see. You were referring to the axi-bus burst. If your platform takes a
long time to DMA out the data, it will impact the performance also. You
can play around with GSBUSCFG0 to enable/restrict certain burst sizes to
see any improvement. However, I would expect the default
coreConfiguration values should be optimal for your platform design.

> 
> However. This is usefull input anyway. I never thought of maximizing the
> burst and packagesize and let the host side make the decision.
> But we will probably will eat up a lot of usb bandwidth by doing so.
> 
> Before your note I was somehow mistaken that the maxpacket and maxburst
> size had to correlate with the actually transfered data we queue into
> the hardware per request.

Right. The maxpacket, maxburst, and mult limit the max request data
length you can send.

> 
> > > I recall that UVC tries to pack a lot of data in a single request. All
> > > the while some intervals it would send 0-length data because of idle
> > > time. I would spread to more requests with a little less data to give
> > > the host a little more breathing room and bandwidth.
> 
> The higher load per request is due to the fact that the uvc gadget is
> using the multiplier, maxpacket and maxburst parameters for the size
> calculation of the request.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/function/uvc_video.c#n331
> 
> Since it is clear now that those parameters are not necessary coupled
> it makes total sense to split the requests into smaller chunks.
> 

Ok.

BR,
Thinh