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 numb
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
> s
On Fri, Jul 19, 2013 at 2:51 PM, Sebastian Andrzej Siewior
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 wi
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 alw
On Fri, Jul 19, 2013 at 2:23 PM, Sebastian Andrzej Siewior
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_pro
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_ho
On Fri, Jul 19, 2013 at 1:36 PM, Sebastian Andrzej Siewior
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
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
On Thu, Jul 11, 2013 at 10:44 PM, Sebastian Andrzej Siewior
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
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
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 becaus
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.
>
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.
Now, the way I understand it is, y
13 matches
Mail list logo
