RE: dma_alloc_coherent
>> 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
RE: pci device driver
-Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of Greg KH Sent: Monday, January 18, 2016 10:42 AM To: Rabinarayan Panigrahi Cc: kernelnewbies@kernelnewbies.org Subject: Re: pci device driver On Mon, Jan 18, 2016 at 07:23:42AM +0530, Rabinarayan Panigrahi wrote: > Hi, > >> For understanding more about pci device driver i went though below > links > >> http://www.tldp.org/LDP/tlk/dd/pci.html > > and > >> http://www.makelinux.net/ldd3/ chapter 12 > >> but i am trying to understand a bit code side. can some one help me or >> any resources which will help me to understand more about it. >What exactly do you have questions about? Specific questions are best please. Please go through some simple PCI driver code to know more about PCI programming. 8250/16550 family of Serial Driver is a good one to start with. Thanks, Saumendra ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ::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
RE: signing kernel modules on RHEL 7
>I have compiled kernel module on RHEL7 but when I insert the module, I got >following warning >"module verification failed: signature and/or required key missing - tainting >kernel". >I tried signing the module on custom kernel and find it working. >How can we sign the module for a target system with standard RHEL distribution? >where can we find keys for signing the module on standard kernel? The kernel module signature verification has been enabled for your system, which is giving warnings while loading modules that has not signed by the vendor. Not a big problem though... Try to compile with the following flags off during menuconfig: - CONFIG_MODULE_SIG - CONFIG_MODULE_SIG_ALL Hope it 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
RE: getting interrupt number
-Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies-boun...@kernelnewbies.org] On Behalf Of valdis.kletni...@vt.edu Sent: Monday, March 09, 2015 8:14 AM To: Ronit Halder Cc: kernelnewbies@kernelnewbies.org Subject: Re: getting interrupt number On Mon, 09 Mar 2015 07:55:10 +0530, Ronit Halder said: >> How to get the interrupt number of a device.I know it's device id and >> the bus number. >> The device is a usb mouse. >In that case, you won't find an interrupt number for the mouse, you'll find >one for the USB controller the mouse is attached to. Make note that the same >USB controller will catch interrupts for *all* devices on that USB bus. Since USB devices uses PCI window, you can find the interrupt number of the USB controller, by reading the IRQ Line (PCI_INTERRUPT_LINE) form the PCI config. Space, using pci_read_config_byte(). - 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
RE: executing insmod hangs the entire os
On Tue, 17 Feb 2015 21:46:00 +0530, noyb noybee said: >> am on a VM running CentOS 6.6 with kernel version 2.6.32-504. >Which probably has kernel relocation and ASLR enabled. >> unsigned long *syscall_table = (unsigned long *)0x81600560; >So that isn't pointing at the syscall table in the running kernel. >> syscall_table[__NR_chroot] = new_chroot; Leave apart the security holes / undocumented ways etc. raised by Valdis, the way you are getting the address of the syscall table( from System.map), and then changing that will only hang the system. The syscall table is read only. You need to make it writable by changing the write protection bit in the Control Regs. Hope it 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
Re: DMA, CMA, coherence and performance
For streaming DMA, you can use the function dma_map_single(). Alternatively, you can create your own DMA pool using dma_pool_create(), and allocate memory from that using dma_pool_alloc((). The later case will be more suitable for you, since you want a 8MB DMA buffer for your DMA. Hope that helps/ Thanks, Saumendra On Mon, Jan 6, 2014 at 11:48 AM, Steven Bell wrote: > > On Sun, Jan 5, 2014 at 8:02 AM, Peter Teoh wrote: > >> I think this discussion should help you: >> >> http://e2e.ti.com/support/embedded/linux/f/354/t/89419.aspx >> >> other failures: >> >> http://stackoverflow.com/questions/14625919/allocating-a-large-dma-buffer >> >> and some guideline here: >> >> https://www.kernel.org/doc/Documentation/DMA-API.txt >> >> https://lkml.org/lkml/2011/3/25/19 >> >> As I don't have any specific crashdump or error information, nothing I >> can comment further about your problem. It is quite difficult to make >> general comment. >> >> >> >> On Fri, Jan 3, 2014 at 7:20 AM, Steven Bell wrote: >> >>> Hi, >>> >>> I'm working on a device driver for a video device which continuously >>> reads and writes image frames using DMA. The frames are fairly large, in >>> the range of 2-8MB, and I would like the buffers for them to be contiguous >>> because of my hardware. My understanding is that using the contiguous >>> memory allocator is the current "right way" to get the buffers, and that >>> CMA operates entirely behind the scenes when calls are made to >>> dma_alloc_coherent(). >>> >>> However, it seems that for this system, a streaming DMA setup would be >>> more appropriate. The buffer gets filled with data once, handed to the >>> device, and then isn't touched again until it gets reused with new data. >>> The resources I've read have hinted that streaming DMA has some performance >>> benefits over coherent DMA, so this seems like the way to go. But I >>> haven't seen any discussion of how to use CMA with streaming DMA (or >>> whether such a thing is even necessary). >>> >>> Does the CMA also work behind get_free_pages, or other kernel memory >>> allocation methods? Does it matter? The kernel newbies page on memory >>> allocation (http://kernelnewbies.org/KernelMemoryAllocation) says that >>> get_free_pages up to about 8MB are ok. Is that a generalization based on >>> typical memory fragmentation, or a guarantee? >>> >>> Thanks, >>> Steven >>> >>> ___ >>> Kernelnewbies mailing list >>> Kernelnewbies@kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> >> >> >> -- >> Regards, >> Peter Teoh >> > > Thanks for the reply and the links. Unfortunately, they don't really > answer my basic question - which is a general conceptual question, not a > specific error or problem that I'm running into. > > I want to allocate a contiguous 8MB buffer and use it for streaming DMA. > I don't need or want a coherent buffer, since I'm using streaming DMA, and > so dma_alloc_coherent() seems like the wrong method to use. Is that true, > or should I use it anyway? If not, what method do I use? > > The DMA-API and DMA-API-HOWTO documents don't seem to say anything about > allocating memory for streaming DMA operations. Have I missed something? > > Thanks, > Steven > > > > > ___ > 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
