Am 05.05.2017 um 14:56 schrieb Thomas Entner / EE:
Hi, I am Thomas who contacted Laurent regarding this issue. We have
some further observations:
Am 04.05.2017 um 08:45 schrieb Peter Chen:
On Wed, May 03, 2017 at 01:32:28PM +0300, Laurent Pinchart wrote:
There was no one reported this problem before, but from the
description,
it seems an IC issue which is triggered at high loading memory bus,
controller may not get time to visit memory at limited time.
That's my guess too. I was expecting the USB controller's bus master
interface
to get stalled but eventually perform the access (or retry it, I'm
not sure
what kind of bus it sits on), but there might be a hardware bug that
messes up
the controller's state machine. I won't rule out the possibility of
a software
issue yet, it might be possible to detect this condition and retry the
transfer.
I am not sure if it can be recovered, you can call ->fifo_flush, and
->ep_disable and ->ep_enable if it returns -ETIME, and re-submit this
request.
At Xilinx Zynq, its tx buffer is small, and less than 512 bytes
(84bc70f94d81, "usb: chipidea: add xilinx zynq platform data"), and
your
throughput may be > (512 * 3) bytes/SoF, you can't use non-stream
mode by
reducing max packet size.
My throughput is actually 1*1024 bytes / SOF.
>From previous discussion, the tx fifo size is 341.33 bytes for xilinx
zynq, you can set max packet size as 341 and mult as 3, then you can
transfer 1023 bytes / SoF for non-stream mode, assumed the non-stream
mode can fix your problem.
I am not sure if this is totally correct: Xilinx UG585, page 1815,
register HWTXBUF (TXADD), the TxBuffer size of the Xilinx controller
is only 768 Bytes. However, I think you are correct that the issue is
related to this topic:
When we reduce the max packet size to 512, we no longer get the full
lock-ups, but UVC streaming still stops after some time (under have
memory traffic).
When we reduce the max packet size to 256, things appear to work
stable (but very slow).
When we use a max packet size of 720 we still see lock-ups (which is a
bit of surprise to me, I would have expected something close to 768 to
be the magical limit).
We have further debugged the issue now with a USB bus analyzer and made
a (for us) surprising observation:
Both the lock-ups (packet size = 1024) and the stop of streaming without
lock-up (packet size = 512) always happen at the end of a UVC frame
(i.e. end of image). We can see the payload header (e.g. 02 83) with the
EOF bit set, but that packet has a CRC error (end the end of the packet
is not FF D9, as it should be for our MJPEG payload), I assume because
the Tx-buffer did underrun.
My present understanding was that the DMA of the Chipidea IP was not
able to fast enough refill the Tx buffer, but then I would expect this
to happen also e.g. in the middle of the image and not only at the last
transfer?
--
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
