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
--
Best Regards,
Peter Chen
--
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
