On Fri, Dec 30, 2016 at 08:11:56PM +0200, Ran Shalit wrote: > On Sun, Dec 25, 2016 at 2:37 PM, Greg KH <greg@xxxxxxxxx> wrote: > > On Sat, Dec 24, 2016 at 05:47:19PM +0200, Ran Shalit wrote: > >> > >> > >> On Tue, Dec 20, 2016 at 12:26 PM, Greg KH <greg@xxxxxxxxx> wrote: > >> > >> On Tue, Dec 20, 2016 at 12:15:22PM +0200, Ran Shalit wrote: > >> > On Tue, Dec 20, 2016 at 11:38 AM, Greg KH <greg@xxxxxxxxx> wrote: > >> > > On Mon, Dec 19, 2016 at 06:08:47PM +0200, Ran Shalit wrote: > >> > >> Hello, > >> > >> > >> > >> I want to use DMA from userspace. > >> > > > >> > > Why? > >> > > >> > Hi Greg, > >> > > >> > We want that a userspace layer (a library) will do some HW related > >> issues. > >> > We have a memory mapped space (from FPGA), so we think it will be > >> > easier, and I think also more correct way , that we create the driver, > >> > and interact hadrware using the mapped memory space, and also do the > >> > protocols in userspace. The only thing that is less easy in userspace > >> > is using interrupt, and dma. but that is also possible if we just wrap > >> > the dma, and interrupt in a character device (or use uio as you > >> > suggested below). > >> > > > >> > >> I already use dma in kernel, and now I want can create a character > >> > >> device which will be responsible for this. > >> > > > >> > > Why? > >> > > > >> > >> The only problem is that I want to use the same memory which was > >> > >> allocated in kernel with dma_alloc_coherent. > >> > > > >> > > Why? > >> > > >> > in kernel we use dma_alloc_coherent, which returns contiguous memory. > >> > As I understand, we can mmap in userspace the returned physical > >> > address, and use the returned virtual address in userspace. > >> > > >> > > >> > > > >> > >> Is it correct to use mmap in order to use the phsyical memory which > >> > >> was allocated with dma_alloc_coherent ? > >> > >> > >> > >> If it's that simple it can be surely helpful, and the simple driver > >> > >> which wraps dma_alloc_coherent can do the job for dmaing from > >> > >> userspace. > >> > > > >> > > Have you looked at the uio driver interface? > >> > > > >> > > But again, why? What problem are you trying to solve here? > >> > > >> > We need to do some interaction with HW , but since most of the HW is > >> > mapped to physical address (FPGA), it seem simpler to do that in > >> > userspace (HW library), instead of doing this in kernel. What do you > >> > think ? > >> > >> I think you should use the UIO driver api, as that's exactly what it was > >> written for. Have you looked at it yet? It handles your interrupt > >> logic for you. > >> > >> > >> Hello, > >> > >> If I may please ask, I made some reading about uio, but didn't yet > understand > >> what's the benefit of using uio instead of creating a character device ? > > > > It's a lot less work than writing a custom char driver that will not be > > accepted upstream because you are not using the expected UIO api > > interface :) > > > > Writing a UIO driver should be very simple, and very small, all of the > > framework is already done, in a correct way, why would you _not_ want to > > use the UIO interface? > > > Hi, > > UIO drivers seems like a good choice in my case, I am familiar with generic-uio > interface in devicetree. > Just for my understanding, I am trying to understand the difference between > writing a small character device which notifies the interrupt, to using uio > interface. Have you tried it? > Is there any advantage of using uio over the the small chracter device?(I am > sure there is. I just do not know it yet) Try it, doing it "correctly" with a char driver will force you to reimplement everything we did for the UIO layer. It was written for a reason (i.e. we got tired of seeing everyone do it totally wrong and causing bugs). > Another question, in performance terms which is better: uio driver or kernel > driver? Depends on your hardware and your application, and uio _is_ a kernel driver. Again, try it out and see. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
