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. 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? Regards, Michael -- 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 |
Attachment:
signature.asc
Description: PGP signature
