On 07/11/2013 06:58 PM, Greg KH wrote: >> following scenario: >> you attach an UART-TO-USB adapter to your musb port running ux500-dma >> code. The USB UARt driver queues 1x RX URB with the size of 256 bytes >> (example) and the max packet size is 64. >> >> The other side sends only one byte because it is mean. > > That's actually quite common, why is it "mean"? Hehe. Because it is the unexpected one. common depends on the use case. Mass storage doesn't do this. Not sure if network notices the difference, maybe ncm. >> Now, the way I understand it is, you tell musb that the complete >> transfer of 256 bytes has ended instead one byte that really >> happened. Is my assumption wrong? > > What do you mean by "tell musb"? Of course the transfer has completed, > that's all the device sent to the host controller, so it has to complete > the transfer and send that on up to the driver that requested the urb. > > I don't understand the question/problem you are asking here, care to be > more descriptive? Okay. musb offloads the actual transfer to the DMA engine it is using. Once it does so, it relies on whatever comes back from dma engine regarding transfer complete, transferred size etc. In case of ux500-dma (as far as I can tell) musb forwards the RX request to the DMA engine, which will receive one byte instead of the requested 256bytes. Since the DMA engine did not inform musb about the correct transfer size, musb will complete that URB with 256 bytes. If you take a look on ux500_dma_callback() you will see the line: ux500_channel->channel.actual_len = ux500_channel->cur_len; ->actual_len is what musb thinks got transferred. ->cur_len is what musb asked to transfer. I don't see where the case of a shorter transfer is considered. Again I have no HW I was just browsing. > thanks, > > greg k-h Sebastian -- 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
