On Tue, May 09, 2017 at 11:47:07AM +0200, Thomas Entner / EE wrote:
>
> Am 08.05.2017 um 03:56 schrieb Peter Chen:
> >On Fri, May 05, 2017 at 04:10:14PM +0200, Thomas Entner / EE wrote:
> >>>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
> OK, I think I understand this now. However, the link indicates a buffer size
> of 341.33 bytes, which I think is wrong (would be a strange buffer size,
> wouldn't it?):
>
> > tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) *
> (DWORD_PER_BYTES) (DWORD_PER_BYTES is 4)
>
> While the number of address bits (HWTXBUF.VUSB_HS_TX_ADD) is 10, i.e. 2 ^ 10
> is 1024, it looks like actually only 768 words are implemented (as indicated
> by Xilinx UG585, description of TX_ADD on page 1815). When using 768 instead
> of 1024 for ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) we get tx_buffer_size of 256,
> which matches my latest observations: Things behave well with max packet
> size of 256, but I see issues (i.e. CRC errors) with 300, 360, 512, 1024.
> BTW, I am also seeing CRC errors with your "3*256" trick.
>
Have you tried non-stream mode? [1]
After enabling it, dump register $BASE + 0x1a8
> How the hell could Xilinx make this buffer so small?
[1] http://www.spinics.net/lists/linux-usb/msg156666.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
