Re: at91_udc driver does not forward data received from host if size is less than ep buffer and size %64 == 0

On 22 Feb 2007, Jeff Warren wrote:

> Hello everyone,
> 
> 	I currently have a driver that has 1024 byte endpoint buffers (bulk
> transfer) and it is running on the AT91RM9200. I am running 2.6.12, but
> I looked at the kernel git tree head(2.6.20) at91_udc.c code and it has
> the same issue. My gadget can accept data from the host and the data
> will be any amount.
> 	If data is transmitted from the host and its length is 960 bytes lets
> say, the read_fifo() does not call done() because the length of the last
> transfer is 64 bytes and the 1024 byte buffer is not yet full so is_done
> is set to zero (below).
> code snippet, at91_udc.c::read_fifo():
> 
> 	req->req.actual += count;
> 	is_done = (count < ep->ep.maxpacket);
> 	if (count == bufferspace)
> 		is_done = 1;
> 
> 	PACKET("%s %p out/%d%s\n", ep->ep.name, &req->req, count, is_done ? "
> (done)" : "");
> 
> 	/*
> 	 * avoid extra trips through IRQ logic for packets already in
> 	 * the fifo ... maybe preventing an extra (expensive) OUT-NAK
> 	 */
> 	if (is_done)
> 		done(ep, req, 0);
> end snippet;

Although not familiar with the at91 driver, I find your description a
little puzzling.  Why should you expect the routine to call done() in this
situation?  A bulk transfer doesn't finish until either a short packet is
received (count < ep->ep.maxpacket) or the expected number of bytes has
been received (count == bufferspace).  In either case is_done gets set to
1.

> If I run "cat /proc/driver/udc", I see a request sitting with 960/1024
> bytes used.  Upon the completion of the next transfer, the first
> transfer will then be sent as done() will be called.
> 	So I have changed my host program to check and see if the data size
> being sent to the gadget is divisible by 64 (size % 64 == 0).  If it is,
> then I add a small chunk so that the driver will handle it correctly and
> the data will be processed upon transfer completion.
> 	I hate this fix, but it is the only one I can think of, anybody have a
> better way of fixing this issue?  I looked at the driver and could not
> come up with an elegant solution to this.

It sounds like you have a protocol problem, not a driver problem.  If you 
submitted a request for 1024 bytes on a bulk endpoint and 960 bytes have 
been received so far, what makes you think the transfer is finished?

Alan Stern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel