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 <saumendr...@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@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies