Balbi, >Hi, > >"Chow, Watson" <Watson.Chow@xxxxxxxxx> writes: >> Hi, >> >>>Hi, >>> >>>(please don't top-post :-) >> I have tried my best to meet the format requirement > >Thanks > >>>"Chow, Watson" <Watson.Chow@xxxxxxxxx> writes: >>>> Balbi, >>>> >>>> Thanks for your quick reply. >>>> >>>> Some questions >>>> >>>> 1. You mentioned that the max bandwidth in isoc mode (USB3.0) should be >>>> around 4Gbps. >>>> >>>> I have the below calcuation on bandwidth: >>>> In USB3.0, 1 micro frame would take 125us and can transfer max 45000 bytes >>>> So, in 1 sec, we will have 8000 micro frames >>>> >>>> Max bandwidth = 8000 x 4500 x 8 = 2.88Gbps >>>> >>>> Is my understanding correct? >>> >>>probably, It's been a while since I've dug through the spec, to be frank >>> >>>> 2. To achieve the max throughput, I need to configure the uvc gadget driver >>>> with below parameters. Am I right? >>>> >>>> # modprobe g_webcam streaming_maxpacket=3072 streaming_maxburst=15 >>>> streaming_interval=1 >>> >>>right, but there's an assumption here that the gadget will be able to >>>feed data in a timely manner. >> >> How does the DWC3 driver or the gadget driver handle the case with intermittent >> drop of the input video streaming? >> >> Any recover mechanism? > >yeah, the missed ISOC is reported to the gadget driver and that has to >queue new requests. > >>>> 3. You suggest me to try on kernel v5.12 or the latest v5.13-rc. It looks not >>>> easy in my side to upgrade the kernel version. It would affect those other >>>> device drivers I'm currently using. So, do you think there's any short cut >>>> to fix this problem under my current kernel version - v5.4? >>> >>>In that case, you need to ask for support from whoever forces you to >>>stay with such an old kernel. I believe that would be Xilinx. >> >> I have a thought to back port those changes around the dwc3 and gadget driver >> from the latest kernel version to my kernel (v5.4). Do you think this is >> feasible? > >should be, but it's likely quite a bit of work: > >$ git rev-list --count v5.4..linus/master -- drivers/usb/dwc3/ >257 > Upgraded the kernel version to 5.9, I can set the g_webcam module pararmeters as follow (for max bandwidth): streaming_maxpacket=3072 streaming_maxburst=15 streaming_interval=1 Data transfer with above setting is working now - tested with dummy data generator in the uvc-gadget app. This concludes that kernel 5.4 is too old for DWC3 and UVC gadget driver in high bandwidth usage >>>> 4. I read through the procedures to capture debug info by debugfs. However, >>>> in my test with "streaming_maxburst" set to 10 or above, my system would >>>> crash and I can't pick the log from that point. Any suggestion? >>> >>>have a look at ftrace_dump_on_oops. >> >> I will explore how to enable this >> >>> >> >> Btw, do you know which SoC platform can run the UVC gadget in max throughput. >> Raspberry Pi/TI Beaglebone/i.MX ??? > >Raspberry Pi uses dwc2 >Beaglebone uses musb >i.MX, I think some of them use dwc3 at least. > Watson -----Original Message----- From: Felipe Balbi <balbi@xxxxxxxxxx> Sent: Monday, May 17, 2021 1:32 PM To: Chow, Watson <Watson.Chow@xxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx Subject: RE: [BUG REPORT] usb: dwc3: Bug while setting the USB transfer bandwidth on UVC gadget driver Hi, "Chow, Watson" <Watson.Chow@xxxxxxxxx> writes: > Hi, > >>Hi, >> >>(please don't top-post :-) > I have tried my best to meet the format requirement Thanks >>"Chow, Watson" <Watson.Chow@xxxxxxxxx> writes: >>> Balbi, >>> >>> Thanks for your quick reply. >>> >>> Some questions >>> >>> 1. You mentioned that the max bandwidth in isoc mode (USB3.0) should be >>> around 4Gbps. >>> >>> I have the below calcuation on bandwidth: >>> In USB3.0, 1 micro frame would take 125us and can transfer max 45000 bytes >>> So, in 1 sec, we will have 8000 micro frames >>> >>> Max bandwidth = 8000 x 4500 x 8 = 2.88Gbps >>> >>> Is my understanding correct? >> >>probably, It's been a while since I've dug through the spec, to be frank >> >>> 2. To achieve the max throughput, I need to configure the uvc gadget driver >>> with below parameters. Am I right? >>> >>> # modprobe g_webcam streaming_maxpacket=3072 streaming_maxburst=15 >>> streaming_interval=1 >> >>right, but there's an assumption here that the gadget will be able to >>feed data in a timely manner. > > How does the DWC3 driver or the gadget driver handle the case with intermittent > drop of the input video streaming? > > Any recover mechanism? yeah, the missed ISOC is reported to the gadget driver and that has to queue new requests. >>> 3. You suggest me to try on kernel v5.12 or the latest v5.13-rc. It looks not >>> easy in my side to upgrade the kernel version. It would affect those other >>> device drivers I'm currently using. So, do you think there's any short cut >>> to fix this problem under my current kernel version - v5.4? >> >>In that case, you need to ask for support from whoever forces you to >>stay with such an old kernel. I believe that would be Xilinx. > > I have a thought to back port those changes around the dwc3 and gadget driver > from the latest kernel version to my kernel (v5.4). Do you think this is > feasible? should be, but it's likely quite a bit of work: $ git rev-list --count v5.4..linus/master -- drivers/usb/dwc3/ 257 >>> 4. I read through the procedures to capture debug info by debugfs. However, >>> in my test with "streaming_maxburst" set to 10 or above, my system would >>> crash and I can't pick the log from that point. Any suggestion? >> >>have a look at ftrace_dump_on_oops. > > I will explore how to enable this > >> > > Btw, do you know which SoC platform can run the UVC gadget in max throughput. > Raspberry Pi/TI Beaglebone/i.MX ??? Raspberry Pi uses dwc2 Beaglebone uses musb i.MX, I think some of them use dwc3 at least. -- balbi
