Hi, yfw <nh26223@xxxxxxxxx> writes: > Hi Felipe, Bin, > > >> Hi Felipe, >> I am very sorry for the multiple sending. The previous were rejected because of >> HTML format because I used gmail web interface. >> >> Hi list, >> I tried to enable the high speed, high bandwidth transfer in device mode for iso >> type on dwc3 based soc. The platform only supports usb device 2.0. >> >> I set the MaxPacketSize to 0x1400 so the host could allocate 3072 bytes for >> uframe. But when I chain three trbs together, the dwc3 behavior is quite weird: >> >> If I set the individual trb as following: >> [ 32.495556] trb: ffffff800080f1b0, trb dump: bpl: 0xec803000,bph: 0x0, size: >> 0x400, ctrl: 0x469 >> [ 32.495560] trb: ffffff800080f1c0, trb dump: bpl: 0xec803400,bph: 0x0, size: >> 0x400, ctrl: 0x469 >> [ 32.495564] trb: ffffff800080f1d0, trb dump: bpl: 0xec803800,bph: 0x0, size: >> 0x400, ctrl: 0xc69 >> >> It's actually not high bandwidth. Just normal ISO transfer. Everything is fine. >> I got following msg: >> [ 32.495909] dwc3_cleanup_done_reqs: trb: ffffff800080f1b0,trb->size: 0x0, >> trb->ctrl: 0x393dc468, trb_num: 3 >> [ 32.495915] dwc3_cleanup_done_reqs: trb: ffffff800080f1c0,trb->size: 0x0, >> trb->ctrl: 0x393e0478, trb_num: 3 >> [ 32.495920] dwc3_cleanup_done_reqs: trb: ffffff800080f1d0,trb->size: 0x0, >> trb->ctrl: 0x393e4c78, trb_num: 3 >> >> We could see every trb has size to 0 finally. >> >> But if I set the trb chain as: >> [ 42.137322] trb: ffffff800080f000, trb dump: bpl: 0xe2a8c000,bph: 0x0, size: >> 0x2000400, ctrl: 0x46d >> [ 42.137326] trb: ffffff800080f010, trb dump: bpl: 0xe2a8c400,bph: 0x0, size: >> 0x400, ctrl: 0x47d >> [ 42.137330] trb: ffffff800080f020, trb dump: bpl: 0xe2a8c800,bph: 0x0, size: >> 0x400, ctrl: 0xc79 >> >> There are three trbs. The first and second has CHN bit set. The first one has >> First-ISO type. >> And the PCM1 filed is set to 2 for the first one. The last one has IOC bit set. >> I tried to let dwc3 >> send the first one at DATA2 stage, the second one at DATA1 stage and the third >> one at DATA0 >> stage. >> >> But there result is: >> [ 42.137872] dwc3_cleanup_done_reqs: trb: ffffff800080f000,trb->size: 0x0, >> trb->ctrl: 0x2cd7c46c, trb_num: 3 >> [ 42.137877] dwc3_cleanup_done_reqs: trb: ffffff800080f010,trb->size: 0x400, >> trb->ctrl: 0x47d, trb_num: 3 >> [ 42.137891] dwc3_cleanup_done_reqs: trb: ffffff800080f020,trb->size: >> 0x10000800, trb->ctrl: 0x2cd7cc78, trb_num: 3 >> >> Only the first one is transferred correctly. >> >> I saw the kernel code is using CHN bit. SO I believe it works fine. But it >> doesn't work in my environment. Did I miss some obvious registers? Any >> comments/hints are appreciated. >> > > Just saw this thread: > http://marc.info/?t=147439118000001&r=1&w=2 > > I am fighting with the similar issue now. The patch from Felipe can't work. I okay, and what was the outcome of your test? Do you have any sniffer capture you could share? Did you make sure that PCM1 is set correctly? What is the problem you notice? which gadget driver are you using? > tried that. Here is the my debugging output: are you using mainline? If you are, capture dwc3 tracepoints. If you're not, which kernel are you using? > [ 33.780999] trb: ffffff800080f080, trb dump: bpl: 0xdfb23000, bph: 0x0, size: > 0x2000400, ctrl: 0x469 > [ 33.781004] trb: ffffff800080f090, trb dump: bpl: 0xdfb23400, bph: 0x0, size: > 0x400, ctrl: 0x479 > [ 33.781007] trb: ffffff800080f0a0, trb dump: bpl: 0xdfb23800, bph: 0x0, size: > 0x400, ctrl: 0xc79 > > [ 33.782478] dwc3_cleanup_done_reqs: trb: ffffff800080f080, trb->size: 0x0, > trb->ctrl: 0x13f64468, trb_num: 3, dep->iso_xfer_num: 3993 > [ 33.782483] dwc3_cleanup_done_reqs: trb: ffffff800080f090, trb->size: 0x0, > trb->ctrl: 0x13f68478, trb_num: 3, dep->iso_xfer_num: 3994 > [ 33.782488] dwc3_cleanup_done_reqs: trb: ffffff800080f0a0, trb->size: 0x0, > trb->ctrl: 0x13f6cc78, trb_num: 3, dep->iso_xfer_num: 3995 sorry but I have no inclination in decoding this when the driver has very good tracepoint support. Please remove your debugging and capture trace output: # mkdir -p /t # mount -t tracefs none /t # echo 20480 > /t/buffer_size_kb # echo 1 > /t/events/dwc3/enable Now reproduce the issue, then: # cp /t/trace /path/to/non-volatile/media/ Send me the trace file. You'll probably have to compress it. gzip or xz should compress it enough. > We could see the trb present was transferred correctly. But they are not at > the same uframe stage. The field in trb->ctrl are not same. That means the data > was transferred at different uframe stage. And the video throughput was not > increased as well. I don't have any information on how to reproduce this problem, how can I be of any help? :-) Either Bin has some notes on how to use g_webcam so I can reproduce, or you can tell me more details about your setup. > I have no new databook (Only have one for v2.50a). So I tested almost all the > combines I could imagine. > > Per my test, the CHN bit matters a lot. If the CHN bit is set, I could get: you should only use CHN if you're dealing with sg-lists. If you have linear buffers you don't need CHN. > [ 42.137872] dwc3_cleanup_done_reqs: trb: ffffff800080f000,trb->size: 0x0, > trb->ctrl: 0x2cd7c46c, trb_num: 3 > [ 42.137877] dwc3_cleanup_done_reqs: trb: ffffff800080f010,trb->size: 0x400, > trb->ctrl: 0x47d, trb_num: 3 > [ 42.137891] dwc3_cleanup_done_reqs: trb: ffffff800080f020,trb->size: > 0x10000800, trb->ctrl: 0x2cd7cc78, trb_num: 3 I really need trace output, this is hardly enough to figure out what's going on. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
