Cc'ing: Stanley Chang On Mon, Sep 04, 2023 at 12:41:33AM +0200, Michael Grzeschik wrote: >Hi Thinh > >On Fri, Sep 01, 2023 at 01:35:16AM +0000, Thinh Nguyen wrote: >>On Fri, Sep 01, 2023, Michael Grzeschik wrote: >>>I just stumbled over a similar issue we already solved for the High >>>Speed Case when streaming ISOC packages and using a multiplier higher >>>then one. Last time we saw some bad frame artefacts when using the >>>higher multiplier value. The Frames were distorted due to truncated >>>transfers. >>> >>>Since the last case we have patch >>> >>>8affe37c525d ("usb: dwc3: gadget: fix high speed multiplier setting") >>> >>>that fixes the calculation of the mult PCM1 parameter when using high >>>speed transfers. After that no truncations were reported again. >>> >>>However I came across a similar issue which is just a little less easy >>>to trigger and only occurs with Superspeed. Now, while the memory >>>bandwidth of the machine runs on higher load, the UVC frames are >>>similarly distorted when we use a multiplier higher then one. >>> >>>I looked over the implications the multiplier has on the Superspeed case >>>in the dwc3 gadget driver, but could only find some TXFIFO adjustments >>>and no other extra bits e.g. in the transfer descriptors. Do you have >>>some pointers how the multiplier parameter of the endpoint is used in >>>hardware? >>> >> >>As you already know, PCM1 is only for highspeed not Superspeed. What >>failure did the dwc3 driver reported? Missed isoc? What's the request >>transfer size? > >Yes, I see missed isoc errors. But this is just a symptom in this case. > >I can increase the maxburst or maxpacket parameters stepwise and on >one point see the flickering appear. But when I increase the TXFIFOSIZE >for the endpoint the flickering is gone again. Until I increase one of >the parameters maxpacket or maxburst to much again. > >So due to the memory bandwidth is under pressure, it seems like the >hardware is not fast enough with sending the expected data per transfer, >due to the txfifo is not long enough and needs to be refilled more >often. > >This sounds like a fifo underrun issue in the hardware. This whole issue sound like a case of stanleys patches: https://lore.kernel.org/all/20230828055212.5600-1-stanley_chang@realtek.com/ For now I was unluky while adjusting the paramaters. Are those registers anywhere documented? 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 |