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

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

Hi,

On Mon, Oct 30, 2023, Michael Grzeschik wrote:
> Hi Thinh,
> 
> On Thu, Sep 07, 2023 at 11:33:26PM +0000, Thinh Nguyen wrote:
> > On Thu, Sep 07, 2023, Michael Grzeschik wrote:
> > > 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.
> 
> I was not lucky with that parameters. Under heavy memory load the
> system still runs into fifo underruns.
> 
> > > 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.
> 
> So changing the req_size to smaller chunks indeed did increase the
> stability. The main misunderstanding here was that the that not every
> request corresponds with the timeslot of one interval.
> 
> After reading this thread once again, it is clear that this is not the
> case and we still find all possible bandwidth by decreasing the size of
> each request.

That's right.

> 
> The main takeway was that with the hardware will cache several
> trbs into the queue. So when there are not enough trbs available
> because they are just to big, the fifo runs into underruns.
> 
> In our case with the high memory bandwidth usage, the trbs could
> probably not even read out that few trbs in time and did trigger
> the case earlier.
> 
> So with smaller requests the fifo will be filled with more smaller
> trbs and does not run out that fast, since more trbs are cached to
> begin with.
> 
> One more question: Does the caching amount of the fifo directly
> correlate with the endpoint setting in DWC3_DEPCFG_BURST_SIZE then?
> 

No. The cache I was referring to is the cache for TRBs, and the caching
of TRBs is not related to DWC3_DEPCFG_BURST_SIZE.

BR,
Thinh