Hi, On Tue, Apr 15, 2014 at 01:55:38PM -0400, Alan Stern wrote: > On Tue, 15 Apr 2014, Felipe Balbi wrote: > > > > 2. Does device need to know OUT transactions before hand so that OUT > > > requests are queued for endpoint before packets are received > > > from host? > > > > well, no. Gadget driver shouldn't depend on that. That's UDC driver's > > responsability to manage that. I mean, if host sends OUT token and > > there's nothing in the out queue, then UDC need to start transfer as > > soon as gadget driver queues the request. If, on the other hand, gadget > > driver queues packet before host has sent OUT token then you have two > > choices: > > > > 1) start the transfer - most HW will wait for OUT token > > 2) wait for out token > > I'm not familiar with the variations in all the different UDC hardware. > Nevertheless, I wouldn't describe the situation in those terms. OK, I've oversimplified... what I meant was that even if you start a transfer at the UDC level, nothing will happen on the bus until HW sees an OUT token. The buffer pointed to by req->buf won't get any writes, DMA won't do anything. On (2) I meant that some HW (e.g. dwc3) will assert the IRQ line once they see a token for which they have to transfer descriptors in the internal controller's cache. > If an OUT transaction occurs and the gadget driver hasn't queued a > request, the UDC hardware could store the incoming data in an internal > buffer or it could NAK the transaction. There aren't any other > choices. If there isn't enough space available in an internal buffer, > the only possible action is NAK. in HS there's also NYET > Regardless, gadget drivers do not need to queue requests for OUT > endpoints before the host starts sending data. When the request does they're not required, but they can. It's UDC driver's responsability to start consuming the queue at the proper time. > get queued, the UDC driver will make sure that the transfer takes > place. correct. -- balbi
Attachment:
signature.asc
Description: Digital signature
