Re: [RFC] ux500 dma short transfers on MUSB
On Thu, Jul 18, 2013 at 01:21:55PM +0200, Sebastian Andrzej Siewior wrote:
On 07/11/2013 07:14 PM, Sebastian Andrzej Siewior wrote:
Dan, Vinod,
do you guys have an idea how the dma driver could inform its user how
much of the requested data got really transferred? This requirement
seems unique to USB where this happens and is not an error. Below an
reply to Greg where I tried to explain the problem. The original thread
started at [0].
I've been browsing by some drivers and did not find anything close to
this. The UART drivers which use DMA seem to know the exact number of
bytes in advance. The dmaengine_tx_status() seems to serve a different
purpose.
Please look into the residue field
/**
* struct dma_tx_state - filled in to report the status of
* a transfer.
* @last: last completed DMA cookie
* @used: last issued DMA cookie (i.e. the one in progress)
* @residue: the remaining number of bytes left to transmit
* on the selected transfer for states DMA_IN_PROGRESS and
* DMA_PAUSED if this is implemented in the driver, else 0
*/
struct dma_tx_state {
dma_cookie_t last;
dma_cookie_t used;
u32 residue;
};
Typically this is set to 0 when DMA_SUCCESS is returned for the
dmaengine_tx_status() API. But in your case I feel its perfectly valid to return
DMA_SUCCESS but with a non zero residue indiactaing how much was not transmitted
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On 07/29/2013 01:44 PM, Vinod Koul wrote:
Please look into the residue field
/**
* struct dma_tx_state - filled in to report the status of
* a transfer.
* @last: last completed DMA cookie
* @used: last issued DMA cookie (i.e. the one in progress)
* @residue: the remaining number of bytes left to transmit
* on the selected transfer for states DMA_IN_PROGRESS and
* DMA_PAUSED if this is implemented in the driver, else 0
*/
struct dma_tx_state {
dma_cookie_t last;
dma_cookie_t used;
u32 residue;
};
Typically this is set to 0 when DMA_SUCCESS is returned for the
dmaengine_tx_status() API. But in your case I feel its perfectly valid to
return
DMA_SUCCESS but with a non zero residue indiactaing how much was not
transmitted
Thank you very much for that feedback. This has been already pointed
out to me and I converted my driver to use this. Once I finish adding
a few pieces I re-post the driver.
~Vinod
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On Thu, Jul 11, 2013 at 10:44 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: 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. AFAIK ux500 musb dma code handles data which is multiple of max packet size in DMA. 1 byte should be in PIO mode. Which version of kernel you are using ? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On 07/19/2013 09:59 AM, Rajaram R wrote: 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. AFAIK ux500 musb dma code handles data which is multiple of max packet size in DMA. 1 byte should be in PIO mode. Which version of kernel you are using ? I am looking at v3.11-rc1 right now and I don't have the HW. As I said: The URB scheduled for receive is 256 bytes in size, max packet size is 64. So DMA should be chosen, right? The UART on other side sends just one byte so the DMA receives just one byte regardless what has been requested. My question is how musb gets notified of this one byte. It might happen someplace but I don't see it. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On Fri, Jul 19, 2013 at 1:36 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/19/2013 09:59 AM, Rajaram R wrote: 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. AFAIK ux500 musb dma code handles data which is multiple of max packet size in DMA. 1 byte should be in PIO mode. Which version of kernel you are using ? I am looking at v3.11-rc1 right now and I don't have the HW. As I said: The URB scheduled for receive is 256 bytes in size, max packet size is 64. So DMA should be chosen, right? The UART on other side sends just one byte so the DMA receives just one byte regardless what has been requested. My question is how musb gets notified of this one byte. It might happen someplace but I don't see it. We program the DMA only when we receive RX interrupt and when the length of data is known. When you submit URB for RX the flow would be something like musb_start_urb==musb_ep_program, Note here we do not program the DMA. DMA is programmed musb_host_rx using channel_program callback. Note here we pass the length of data received. Now in ux500_dma file 'ux500_dma_is_compatible' fails the dma operation and the driver switches to FIFO mode in the same function (musb_host_rx). Cheers Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On 07/19/2013 10:26 AM, Rajaram R wrote: We program the DMA only when we receive RX interrupt and when the length of data is known. When you submit URB for RX the flow would be something like musb_start_urb==musb_ep_program, Note here we do not program the DMA. DMA is programmed musb_host_rx using channel_program callback. Note here we pass the length of data received. Now in ux500_dma file 'ux500_dma_is_compatible' fails the dma operation and the driver switches to FIFO mode in the same function (musb_host_rx). Okay. This is completely different from what I expected. That means while the URB is submitting you only program the musb controller for receive and nothing else. The next interrupt will notify that the musb's endpoint fifo is filled with X bytes and you program the dma engine to transfer X bytes. And then you wait for another interrupt which says DMA transfer completed. So in that case you don't have that problem I though you do. Thank you for clearing that up. ux500_dma_is_compatible() is testing length 512 and length 3. This looks like the fifo can be filled with more than 512 bytes. Do you know on top of your head how much that can be? Cheers Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On Fri, Jul 19, 2013 at 2:23 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/19/2013 10:26 AM, Rajaram R wrote: We program the DMA only when we receive RX interrupt and when the length of data is known. When you submit URB for RX the flow would be something like musb_start_urb==musb_ep_program, Note here we do not program the DMA. DMA is programmed musb_host_rx using channel_program callback. Note here we pass the length of data received. Now in ux500_dma file 'ux500_dma_is_compatible' fails the dma operation and the driver switches to FIFO mode in the same function (musb_host_rx). Okay. This is completely different from what I expected. That means while the URB is submitting you only program the musb controller for receive and nothing else. The next interrupt will notify that the musb's endpoint fifo is filled with X bytes and you program the dma engine to transfer X bytes. And then you wait for another interrupt which says DMA transfer completed. So in that case you don't have that problem I though you do. Thank you for clearing that up. ux500_dma_is_compatible() is testing length 512 and length 3. This looks like the fifo can be filled with more than 512 bytes. Do you know on top of your head how much that can be? That was work in progress. You may wish to look at this patch http://permalink.gmane.org/gmane.linux.usb.general/79858 If a device sends 513 bytes to a musb device. 512 bytes will be received in DMA mode and 1 byte in FIFO mode. FIFO will always handle data 512. Cheers Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On 07/19/2013 11:16 AM, Rajaram R wrote: That was work in progress. You may wish to look at this patch http://permalink.gmane.org/gmane.linux.usb.general/79858 If a device sends 513 bytes to a musb device. 512 bytes will be received in DMA mode and 1 byte in FIFO mode. FIFO will always handle data 512. Okay. Let me rephrase this: Lets say there is a read request for 4096 bytes and your maxpacket is 512 and total of 4096 bytes will be sent by the device. How many interrupts / read requests will there be? 8 like every maxpacket size or is it possible to stuff more data and transfer 4096 in one go? Cheers Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On Fri, Jul 19, 2013 at 2:51 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/19/2013 11:16 AM, Rajaram R wrote: That was work in progress. You may wish to look at this patch http://permalink.gmane.org/gmane.linux.usb.general/79858 If a device sends 513 bytes to a musb device. 512 bytes will be received in DMA mode and 1 byte in FIFO mode. FIFO will always handle data 512. Okay. Let me rephrase this: Lets say there is a read request for 4096 bytes and your maxpacket is 512 and total of 4096 bytes will be sent by the device. How many interrupts / read requests will there be? 8 like every maxpacket size or is it possible to stuff more data and transfer 4096 in one go? Not 100% sure, but as i remember it will be 8 times in the present driver (atleast host mode). But yes we can do 4096 at a time. Cheers Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On 07/11/2013 07:14 PM, Sebastian Andrzej Siewior wrote: Dan, Vinod, do you guys have an idea how the dma driver could inform its user how much of the requested data got really transferred? This requirement seems unique to USB where this happens and is not an error. Below an reply to Greg where I tried to explain the problem. The original thread started at [0]. I've been browsing by some drivers and did not find anything close to this. The UART drivers which use DMA seem to know the exact number of bytes in advance. The dmaengine_tx_status() seems to serve a different purpose. On 07/11/2013 06:58 PM, Greg KH wrote: 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. [0] http://www.mail-archive.com/linux-usb@vger.kernel.org/msg24190.html Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
On Thu, Jul 11, 2013 at 11:08:59AM +0200, Sebastian Andrzej Siewior wrote: Hello, 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? 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? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ux500 dma short transfers on MUSB
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
