Driver to allow DMA from user space

[greg@kroah.com (Greg KH)]

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@kroah.com> 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@kroah.com> 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@kroah.com> 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