On Tue, Apr 24, 2012 at 10:31:17AM -0400, Alan Stern wrote: > On Tue, 24 Apr 2012, Felipe Balbi wrote: > > > > Why is this a problem? All that should happen is you transfer less > > > data than g_zero expects. Either way, the transfer should succeed. > > > > ok, let's say usbtest is sending at 1024 byte chunks 5 times and g_zero > > uses a 4096 byte buffer, this will mean UDC will start a 4k e.g. DMA > > transfer and that single DMA transfer will receive the first 4 chunks > > sent by usbtest. > > > > Now g_zero blindly starts another 4k transfer, UDC's DMA is kicked, but > > host only sends 1k. That transfer will never finish because 1024 is > > aligned to wMaxPacketSize (so, not a short packet) and is not the end of > > the transfer kicked to DMA (which was 4k). > > Yes, that's right. > > > How do you make this work ? > > It seems to me that what you described _does_ work. usbtest transfers > all the data it wants and gets back the appropriate ACKs. Where's the > problem? > > Sure, the UDC ends up sitting in the middle of an unfinished OUT > transfer. So what? There's nothing wrong with that. of course there is. Try to start another transfer to a DMA which's already busy. Relying on a mechanism to abort a transfer is a broken design. That's why real USB classes have means to negotiate how much data actually needs to be transferred. > > If you look at most UDC's code, you will see there's a DMA abort or some > > sort of transfer abort mechanism whenever actual == length, > > It's not an abort mechanism; it's a completion mechanism. This is true > of _every_ DMA transfer everywhere, not just in UDCs -- there always is > a transfer length, and the transfer stops when that many bytes have > been sent/received. You're misunderstanding. We start a 4k transfer, but host only wants to send 1K. DMA will continue to wait for the missing 3K forever. What happens is, indeed, a transfer abort. > If anything, USB's odd ingredient is the "stop early upon receiving a > short packet" mechanism. When we receive a short packet (or a zlp) there's no issue. We *know* the transfer is over because of that USB detail. But when transfer is aligned on wMaxPacketSize and DMA is started for a bigger size then actually needed, it will hang in there, waiting for the rest of the data block, which doesn't exist. > > this is what > > makes it magically work, but IMHO, that's not how USB is supposed to be > > implemented. Look at all other classes, they have a way to negotiate > > size of transfer (Mass Storage's CBW, Ethernet's MTU, MTP's handling of > > ZLP and so on) so there will always be a way to finish the transfer. But > > g_zero is special, because it relies on the UDC aborting a transfer > > which was bigger than necessary. > > The incomplete transfer doesn't need to be aborted. It can remain in > its incomplete state and still be useful. WHAT ?!? If DMA has no way to complete e.g. the 4K, you will never receive a completion IRQ. How will notify the gadget transfer is complete ? > For example, let's say that the user runs the same test over again, > with the same parameters. This time, when usbtest sends the first > three 1024-byte chunks, g_zero's transfer will complete. g_zero > blindly goes ahead and queues another request. The last two 1024-byte > chunks from usbtest will partially fill the buffer and then the test > will end, again successfully. > > In short, nothing's wrong! How will you know transfer is complete without a completion IRQ ? Do you not understand DMA will only interrupt you after it receives all 4K (or a short/zlp in case of USB) ? If you don't receive an interrupt you either need to poll some status register or use some weird timer mechanism which no one will implement. > Now it's true that under some circumstances the incomplete transfer > will need to be aborted. For example, if the host sends a Set-Config > or Set-Interface request, the existing endpoints will be disabled and > then possibly new endpoints will be enabled. But UDC drivers have to > be able to cope with that sort of thing anyway. I wonder how you see this working without DMA giving you a completion IRQ... -- balbi
Attachment:
signature.asc
Description: Digital signature
