On Wed, 1 May 2013, victor yeo wrote: > > Why do you expect there to be any data in the hardware FIFO at this > > point? You said that the hardware will not accept any data if a > > request is not queued. Well, before this point the request wasn't > > queued, so there shouldn't be any data. > > I am sorry for unclear writing. What i mean is: If a request is not > queued, the hardware will still accept data, but interrupt controller > will not read the data from the hardware FIFO. All right. I'm not sure whether that is a good idea or not, but it should work for g-file-storage. > >> list_add_tail(&ka_req->queue, &ka_ep->queue); > >> > >> ka_req->req.actual = len; > >> memcpy(ka_req->req.buf, &val_arr[0], len); > >> > >> ka_req->req.complete(&ka_ep->ep, &ka_req->req); > > > > You should not call req.complete until the request really is complete. > > For example, what happens here if the host hasn't sent any packets yet? > > Or what happens if req is waiting to receive 1024 bytes but the host > > has sent only 512 bytes so far? > > How the UDC driver know when the request is really complete? An OUT request is really complete when either: The total number of bytes copied into req.buffer (i.e., req.actual) is equal to req.length, or The number of bytes received in the last packet is smaller than ep.maxpacket. > >> 2) Repeatedly (many many times), the same SCSI_READ_10 command is > >> received by UDC driver, processed by gadget driver, and UDC driver > >> sends out data and CSW to host. On usbmon trace, only one instance of > >> the SCSI_READ_10 is observed. > > > > This is probably because you are copying the same data from the FIFO to > > req.buffer many times. > > I am curious about it. After data is read from FIFO, the FIFO will > become empty. Still cannot figure out how the same data is read from > the FIFO many times. Maybe the UDC driver needs to do something extra to tell the hardware when the FIFO becomes empty. 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
