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
