Re: Fwd: at91_udc driver does not forward data received from h

>>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;
>>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.
>>
>>Regards,
>>
>>Jeff Warren
>>

Hi Jeff,

You have run into the situation that can be solved with a zero length packet 
(ZLP).

The problem is knowing when a transfer is complete. On all sizes not 
divisible by maxpacketlen the hardware knows it is a short packet and the 
transfer is done. If your host/gadget communicate and know the exact length 
of a transfer then that can also end a transfer. The problem is if you want 
random length transfers, how can the hardware know the transfer is done? 
Only if it gets a short packet. But what if the length is divisible by 
maxpacketlen? The solution is to send a ZLP.

I don't write windows minidrivers but I know someone who does. There is some 
kind of endpoint setup bit that says to send/recv ZLP. Using that solution 
will work for packets that are any size divisible by 64 (with your hardware 
having a maximum size of 1024 bytes).

Regards, Steve.

_________________________________________________________________
Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month. 
Intro*Terms  http://www.NexTag.com


-------------------------------------------------------------------------
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