Re: DWC3-Gadget: Flickering with ISOC Streaming (UVC) while multiplier set on Superspeed

[Michael Grzeschik <mgr@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

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.

I am currently looking into the fifo_resize device tree paramter,
and try to figure out how the calculation is done.

 From the software design point of view, having the fifo calculation
parameterized is a bad idea. We probably want to analyze how many
endpoints are going to be used in the active gadget config and use the
finite fifo length to calculate some fair parts for every ep
once and then never touch them again. Dynamic resizing should not be
necessary or do I overlook something?

What do you think?

>Perhaps you can capture some tracepoints of the problem?

IMHO tracepoints are probably not necessary here anymore.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]