dma_alloc_coherent

[Saumendra Dash]

>> Hi Ran,
>              the api which you have mentioned...
>
>> void *
>> dma_alloc_coherent(struct device *dev, size_t size,
>>     dma_addr_t *dma_handle, gfp_t flag)
>>
>> is the kernel api to alloc consistent memory.
>>
>> DMA devices understand the physical addresses not the virtual addresses.
>>
>> which means that we must supply to the dma device, the physical 
>> address, to read
>>
>> from or to write to.
>>
>> The second argument of this api is an input argument which is updated 
>> by the kernel if this api returns a success (and contains the physical 
>> base address of the allocated memory) and the returned value of this 
>> api is the kernel virtual address.
>>
>> if the *CPU* has to operate on this memory (assume that the memory is 
>> dma'ed by the dma device and cpu want to read it for further 
>> processing ) it should use the virtual address, so the returned value 
>> of this api, as the base address.
>> However, if the dma device has to operate on this memory (assume 
>> device want to write to this memory), it should use the *dma_handle* , 
>> which is the physical address (base) of the dma memory.
>>
>> Now the question is how the dma device knows about this *physical* address?
>> The answer is that the "dma controller" register would have a register 
>> to accept this physical address.
>>
>> So the sequence of steps probably would be, in your case:
>> 1: allocate the dma memory
>> 2: programme the dma controller register with the physical address 
>> returned by this api, plus the size of the transaction and may be some 
>> more registers for setting some kind of flags (depends on your dma 
>> device)
>> 3: programme the dma controller's dma *start* bit.
>>
>> after this the dma starts and dma device starts writing to the memory .

Hi Vishwas,

>That's fully clarify the questions about dma_alloc_coherent.

>I also try to figure out what's the difference between dma_alloc_coherent and dma_map_single.

>I could not find and important difference between these two methods.
>1. With both methods I stil need to program the dma controller with the physical address and the start trigger.
>2. I can still do the allocation whenever I want with both methods (for example at the initialization of the driver), 3. Not sure what the actuall dma_map_single does (and if it really necessary to use it), becuase it >seems I could just translate the virtual value from kmalloc into physical address and return it to the dma controller.

DMA transfers are done either in BURST mode or CYCLE STEALING mode.
In Burst mode, the bus is captured for the entire duration of the transfer  from the SRC to DST.  In this case, the bus will  be released when the Xfer is complete, so obviously it is not an efficient way of doing DMA.  DMA_ALLOC_COHERENT() does this way.
In Cycle Stealing mode, the DMA controller grab the bus when free, send a byte  and then free the bus immediately. This process is repeated till the Xfer is complete, it is very efficient sine the bus is not grabbed for the entire transaction to complete.  DMA_MAP_SINGLE() does this way.

 Hope this helps.

Thanks,
Saumendra


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------