Am 08.05.2017 um 03:56 schrieb Peter Chen:
On Fri, May 05, 2017 at 04:10:14PM +0200, Thomas Entner / EE wrote:
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?
>From the below commit:
84bc70f94d81 ("usb: chipidea: add xilinx zynq platform data"), the tx
fifo is less than 512 Bytes, you may calculate it through [1]
[1] https://www.spinics.net/lists/linux-usb/msg129116.html
Just very brief, should go to bed now...:
We have a interim workaround:
- We use 3072 packet size (3x1024), but always queue only one buffer.
This prevents the lock-up issue. (We want to revisit this later for a
better workaround.)
- However, we still see CRC errors. This could be maybe related to this
very small buffer? As the CRC errors are seldom, we can accept them. But
to understand the root cause of this CRC errors would be very
interesting (I think this CRC error also triggers the bad ATDTW behavior.
- But when there is a CRC error, streaming still stopped. The reason
was, that in case of an -EILSEQ (caused by CRC error) the request
complete callback was not called. I have patched this in the driver.
- I can provide you the patch later if you are interested, but I am not
sure if it is good enough for all situations were the Chipidea IP is used...
--
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
