On 2020/07/26 10:54, Marcus Glocker wrote: > On Sat, 25 Jul 2020 20:31:44 +0000 > sc.dy...@gmail.com wrote: > >> On 2020/07/25 18:10, Marcus Glocker wrote: >>> On Sun, Jul 19, 2020 at 02:12:21PM +0000, sc.dy...@gmail.com wrote: >>> >>>> On 2020/07/19 11:25, Marcus Glocker wrote: >>>>> On Sun, 19 Jul 2020 02:25:30 +0000 >>>>> sc.dy...@gmail.com wrote: >>>>> >>>>>> hi, >>>>>> >>>>>> It works on AMD Bolton xHCI (78141022), Intel PCH (1e318086), >>>>>> and ASM1042 (10421b21). >>>>>> I simply play with ffplay -f v4l2 /dev/video0 to test. >>>>> >>>>> If your cam supports MJPEG it's good to add '-input_format mjpeg' >>>>> with higher resolutions like 1280x720, because that will >>>>> generated varying image sizes, which hit the 64k memory boundary >>>>> more often, and thus generate potentially more chained TDs. >>>> >>>> Thank you for useful information. >>>> My webcam supprots at most 640x480, but 1024 bytes/frame x (2+1) >>>> maxburst x 40 frames = 122880 bytes/xfer is enough to observe TD >>>> fragmentation. >>>> >>>> >>>>>> At this moment it does not work on VL805, but I have no idea. >>>>>> I'll investigate furthermore... >>> >>> Did you already had a chance to figure out something regarding the >>> issue you faced on your VL805 controller? >>> >>> I'm running the diff here since then on the Intel xHCI controller >>> and couldn't re-produce any errors using different uvideo(4) and >>> uaudio(4) devices. >>> >> >> No, yet -- all I know about this problem is VL805 genegates >> many MISSED_SRV Transfer Event for Isoch-IN pipe. >> >> xhci0: slot 3 missed srv with 123 TRB >> : >> >> Even if I increase UVIDEO_IXFERS in uvideo.h to 6, HC still detects >> MISSED_SRV. When I disable splitting TD, it works well. >> I added printf paddr in the event TRB but each paddr of MISSED_SRV is >> 0, that does not meet 4.10.3.2. >> Parameters in this endpoint context are >> >> xhci0: slot 3 dci 3 ival 0 mps 1024 maxb 2 mep 3072 atl 3072 mult 0 >> >> looks sane. > > Hmm, I see. > > I currently have also no idea what exactly is causing the missed service > events. I was reading a little bit yesterday about the VL805 and could > find some statements where people say it's not fully compliant with the > xHCI specs, and in Linux it took some cooperation with the vendor to > make it work. > > One thing I still wanted to ask you to understand whether the problem > on your VL805 is only related with my last diff; Are the multi-trb > transfers working fine with your last diff on the VL805?
On VL805 ffplay plays the movie sometimes smoothly, sometimes laggy. The multi-TRB transfer itself works on VL805 with your patch. Not all splitted TD fail to transfer. Successful splitted transfer works as intended. I think MISSED_SRV is caused by other reason, maybe isochronous scheduling problem. Thus, IMO your patch can be committed. VL805 also has same problem that AMD Bolton has. It may generate the 1. TRB event w/ cc = SHORT_PKT and remain = requested length (that is, transferred length = 0), but the 2. TRB w/ cc = SUCCESS and remain = 0. remain of 2. TRB should be given length, and CC should be SHORT_PKT. Your patch fixes this problem.
