Hi Felipe,
On 2016/9/23 3:47, Felipe Balbi wrote:
Hi,
yfw <nh26...@gmail.com> 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?
No, I don't have USB tracer. I tried usbmon. But the information from usbmon
is not straight forward enough.
So dumping trb content in device side is what I am using to debug the problem.
On the host side, I am using the libuvc based app to check each iso packet host
get. I also check the throughput of iso transfer to judge whether the iso high
bandwidth is activated or not.
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?
I am not using the latest kernel. Instead the code base is 3.18 + some usb
patches backported because mainline doesn't support the platform I am using.
I will try whether it's possible to apply the latest dwc3 driver from mainline
to the code base I am using. And use the tracepoints with it.
[ 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
This means the PCM1 is correct. Let me manually decode the info (will switch to
trace point then no manually decode needed):
The size of trb has PCM1 field 0x2000400 means PCM1 is 2 (3-1), 0x400 means the
trb has 1024 data.
[ 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
The ctrl of trb has uframe number for iso ep if we read it. So
0x13f64468 has uframe number: 0x13f64468 >> 14 = 20441
0x13f68478 has uframe number: 0x13f68478 >> 14 = 20442
0x13f6cc78 has uframe number: 0x13f6cc78 >> 14 = 20443
which means These three trbs were not transferred in one uframe.
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:
Will switch to trace point.
# 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.
Fair enough. I will reply that thread about the method I am using to reproduce
this issue. It's almost same as Bin's usage case.
Also, I'd like to move all discussion to that thread. :).
Thanks a lot for looking at this.
Regards
Yin, Fengwei
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
