On Mon, 30 Jan 2012, Nikolai Zhubr wrote: > 30.01.2012 12:41, Chen Peter-B29397: > > command stage, it will not prepare usb request. The gadget driver decides when > > to send the data, the udc driver only supply callback function ->queue to help > > prepare the request to hardware. > > Hmmm. My understanding is that usb transfers are determined by host side > entirely (and this being a key point of the whole design). If USB transfers were determined by the host side entirely, there would be no need for USB devices! After all, the host would already have determined what the device was going to send. :-) > That is, > (-1-) transfer only (and always) starts as the host decides so, and > device just has to obey competely (or maybe NAK in the worst case). That's right. > On the other hand, I see that (-2-) the gadget attempts to behave much > like you say. That is, only send data if it has some. That's also right. > I'm still failing to understand how can (-1-) and (-2-) be put together. What's the difficulty? The host starts a transfer when it wants to. If the device is ready to send or receive data at that time, it does so; otherwise it replies with NAK and the host tries again later. Alan Stern -- 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
