Hi, On Mon, Jan 09, 2012 at 05:13:26PM +0800, Yu Xu wrote: > >> I'm now trying to write the usb3 controller driver. As you said, the > >> usb set config request has two stage, one is setup stage which is > >> handled in composite.c, and the other is status stage. > > > > The way it works is like this: > > > > UDC is required to receive the SETUP packet (from the SETUP Stage), > > handle what it can (which is USB_REQ_SET_ADDRES, USB_REQ_SET_FEATURE and > > USB_REQ_CLEAR_FEATURE) and bounce the rest to gadget driver/composite.c, > > by calling driver->setup(). > > > > driver->setup() has to handle the Setup Packet and either queue a > > request or return an error, in which case, UDC will reply with a Stall. > > > > When everything goes fine and gadget driver queues a request, that > > request could be your Data phase (for any request which has a data > > phase) or the zero-length Status Stage. > > > > Clearly, when there's Data stage usb_ep_queue(), UDC driver will have to > > be responsible of finishing by sending Status Stage to host. > > > >> For usb2, the status stage is handled by usb_ep_queue to send ZLP. But > >> for usb3, it's different. > > > > Why is it different ? It follows the same code path ;-) > > OK. I see. I mean the difference is the status stage between usb3 and usb2. > usb2 is IN->data->ACK transaction. And usb3 is STATUS TP->ACK TP. > So I need to implement it in usb_ep_queue(), and code path of request handling > is the same, right? Ok hehe, now I get it. That part is handled by the HW. All you should need to do is start a transfer on the physical ep0in. The difference between a ACK and a ACK TP should be handled by the HW ;-) So yes, usb_ep_queue() will queue a request to USB ep0 and you need to start that transfer on the correct physical endpoint. -- balbi
Attachment:
signature.asc
Description: Digital signature