On Tue, 7 May 2013, victor yeo wrote: > Hi, > > >> 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. > > I made some changes regarding req.actual. Now the UDC driver still > cannot process SCSI_WRITE_10 command. Please see the attached UDC > driver log when i try to write to a text file. There should be three > SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and > SCSI_WRITE_10. SCSI_WRITE_10 is not received properly. No, it isn't. Here's what the log says: > EP1 OUT IRQ 0x28 > ep1_out: RX DMA done : NULL REQ on OUT EP-1 > [start_transfer] 53425355 10d > ept1 out queue len 0x200, buffer 0xc1304000 > g_file_storage gadget: bulk-out, length 31: This is from bulk_out_complete, when the WRITE(10) was received. > EP1 OUT IRQ 0x28 > epnum 1 in 0 len 0 512 0 > g_file_storage gadget: bulk-out, length 0: This line indicates a bug. It means the UDC driver called bulk_out_complete again, even though the previous request was no longer queued and no new requests had been submitted yet. It is likely that this bug occurs because you don't use a spinlock in kagen2_ep_queue. Does the interrupt handler routine use a spinlock? Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT READY commands weren't received correctly either. The last three bytes in each command should be 0, but they aren't. They are: c3 63 4a. Where did those values come from? 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
