>Date: Fri, 23 Dec 2005 17:14:37 +0800
>
>
>We can know about status stage response from USB1.1 spec (8.5.2.1
>Reporting Status Results):
>
>/------------------------------------------------------------------------------/
>For control writes, the host sends an IN token to the control pipe to
>initiate the Status stage. The function
>responds with either a handshake or a zero-length data packet to
>indicate its current status. NAK indicates
>that the function is still processing the command and that the host
>should continue the Status stage; return
>of a zero-length packet indicates normal completion of the command; and
>STALL indicates that the
>function cannot complete the command. The function expects the host to
>respond to the data packet in the
>Status stage with ACK. If the function does not receive ACK, it remains
>in the Status stage of the
>command and will continue to return the zero-length data packet for as
>long as the host continues to send
>IN tokens.
>/------------------------------------------------------------------------------/
>
Good start. Keep reading that spec.
>but we can't see how usb device module can responds with either NAK or
>STALL from omap_udc.c or other udc driver.
>
IIRC the spec requires either the NAK, STALL or zero length packet response
with about 5 bit times after the hosts IN packet EOP. A bit time is 1 12mhz
bit. or around 84 nanoseconds. So unless you have some super duper computer,
software will never be able to respond fast enough. So I recommend that you
read the hardware spec for your gadget USB hardware. At a minimum it needs
to automatically handle handshaking.
>In omap_udc.c/ep0_irq:
>
>... ...
>if (irq_src & UDC_EP0_RX) {
> ... ...
> if (stat & UDC_ACK) {
> ... ...
> if (!udc->ep0_in) {
> ... ...
> stat = read_fifo(ep0, req);
> ... ...
> /* activate status stage */
> if (stat == 1) {
> done(ep0, req, 0);
> /* that may have STALLed ep0... */
> UDC_EP_NUM_REG = UDC_EP_SEL|UDC_EP_DIR;
> UDC_CTRL_REG = UDC_CLR_EP;
> UDC_CTRL_REG = UDC_SET_FIFO_EN;
>
> /* causing ACK handshaking by setting the
*/
> * CTRL.SET_FIFO_EN bit with an empty */
> * endpoint 0 FIFO. */
> */
>
> UDC_EP_NUM_REG = UDC_EP_DIR;
> udc->ep0_pending = 0;
> }
> ... ...
> }
> ... ...
> }
> ... ...
>}
>... ...
>
>so, when the function is still busy completing command or the command
>sequence failed to complete, how do gadget driver tell udc to response
>Control writes with NAK/STALL?
>
I know nothing about your hardware, but somewhere you are initiing it to
automatically send NAKs when you have not given it data yet. Similarly if
you want it to STALL the host. Similarly it has to know when you have a data
packet ready so it can respond to some future IN.
In fact in the above code:
> UDC_CTRL_REG = UDC_SET_FIFO_EN;
>
> /* causing ACK handshaking by setting the
*/
> * CTRL.SET_FIFO_EN bit with an empty */
> * endpoint 0 FIFO. */
Says that setting the value in the ctrl reg will send a zero length ep0
packet. It will be sent some time in the not to distant future when the host
sends a IN pid.
Regards, ~Steve
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
