dma_alloc_coherent

[sanjeev sharma]

Hello Saumendra,

I would suggest you to go through the following link: 1) This will explain
need of DMA with practical scenario 2) ARM DMA Mapping with example

https://sanjeevsharmaengg.wordpress.com/2014/08/26/why-dma-required-in-linux-kernel/

http://linuxkernelhacker.blogspot.in/2014/07/arm-dma-mapping-explained.html

I hope these link will give you more confidence around understanding of DMA.

Regards
Sanjeev Sharma

On Mon, Feb 8, 2016 at 12:29 PM, Saumendra Dash <saumendra.d at hcl.com> wrote:

> >> 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.
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160208/4ef37283/attachment.html