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
