On Tue, 24 Apr 2012, Felipe Balbi wrote: > 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. Why would you start another transfer before the existing one completes? If you try to do that, you'll run into trouble regardless. > 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. What abort mechanism are you talking about? Where does g_zero abort any transfers? As for broken designs, what do you think should happen if a transfer is in progress when the USB cable gets unplugged? Doesn't every UDC need to handle this correctly? Doesn't this require the ability to safely abort the transfer? What's broken about it? > > > 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. What makes you think the transfer gets aborted? If you "continue to wait for the missing 3K forever" then when does this abort take place? After "forever"? :-) > > 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 ? If the transfer never will be complete then there's no need to notify the gadget. But that's not what I said. I didn't say a completion IRQ would arrive or that the gadget would be notified of transfer completion; I said that the incomplete transfer can still be useful. > > 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. I don't understand what you're missing. The idea is simple: The UDC expects to receive 4 KB of data. The host sends only 1 KB of data. The UDC continues to wait. Some time later, the user restarts the testusb program. The host sends 3 KB of data. The completion IRQ fires and the gadget is notified. Why do you say there won't be a completion IRQ? Let's continue the scenario: The gadget queues another 4-KB request. The UDC waits for data to arrive. testusb sends another 2 KB of data. The UDC continues to wait. The host doesn't send any more data. The UDC continues to wait. The USB cable eventually gets unplugged. The endpoint is disabled and the UDC aborts the transfer. The gadget gets notified that the transfer completed with an error. Then it gets notified about the disconnection. Again, what's wrong with this? > > 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... See above. 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
