On 5/23/2014 5:04 PM, Daniel Mack wrote:
Hi George,
Thanks for having a look!
On 05/23/2014 01:24 PM, George Cherian wrote:
On 5/23/2014 3:01 PM, Daniel Mack wrote:
The musb/cppi41 glue layer is capable of handling transactions that span
over more than one USB packet by reloading the DMA descriptors
partially. An urb is considered completed when either its transfer
buffer has been filled entirely (actual_length ==
transfer_buffer_length) or if a packet in the stream has less bytes than
the endpoint's wMaxPacketSize.
Can you explain a bit more.
Sure.
Doesn't it checks for
actual_length + xfer_len >= transfer_buffer_length ?
This check is also failing?
Yes. For the driver I'm testing with, transfer_buffer_length is 16k.
Assume wMaxPacketSize == 512 and the following sequence of incoming
packet sizes: 512, 512, 384. The URB should be given back after the 384
packet has been received, with an effective total length of 1408 bytes.
The code in musb_cppi41.c does the right thing by not reloading a new
DMA descriptor but calling musb_dma_completion() from
cppi41_trans_done(). However, both checks for 'done' that the core
currently looks at a false in that case (musb_host.c, ~ line 1740):
In rx we always use the transparent mode of CPPI dma.
In transparent mode we always program the min( packet_sz,len)
[musb_cppi41.c cppi41_configure_channel()]
In your example len is 16K and packet_sz is wMaxPacketSize.
Basically it always does a wMaxPacketSize of dma and updates the
urb->actual_length in return.
In RX we cant use the Generic RNDIS mode of CPPI, due to some of the
bugs in the silicon.
done = (urb->actual_length + xfer_len >= urb->transfer_buffer_length
|| dma->actual_len < qh->maxpacket);
... because dma->actual_len is already 1408, and hence the maxpacket
size check doesn't make sense in such cases.
This is why I added a new flag to overrule that decision from the cppi41
glue layer.
HTH,
Daniel
--
-George
--
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
