On Wed, Sep 06, 2023 at 12:44:02AM +0000, Thinh Nguyen wrote: >On Mon, Sep 04, 2023, Michael Grzeschik wrote: >> 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? >> > >How does his change impact isoc endpoint? His change should only affect >non-periodic endpoint. Also periodic settings is only for host. Since I did not find proper documentation of the registers I was just hoping. In the device-tree documentation stanley added he mentioned some device mode properties. As I look again it seems the RXFIFO parameters are the only one affecting device mode. So nevermind. Thanks, 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 |