On Sun, Dec 25, 2016 at 2:37 PM, Greg KH [off-list ref] wrote:

On Sat, Dec 24, 2016 at 05:47:19PM +0200, Ran Shalit wrote:

quoted

On Tue, Dec 20, 2016 at 12:26 PM, Greg KH [off-list ref] wrote:

On Tue, Dec 20, 2016 at 12:15:22PM +0200, Ran Shalit wrote:

quoted

On Tue, Dec 20, 2016 at 11:38 AM, Greg KH [off-list ref] wrote:

quoted

On Mon, Dec 19, 2016 at 06:08:47PM +0200, Ran Shalit wrote:

quoted

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.

quoted

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).

quoted

quoted

I already use dma in kernel, and now I want can create a character
device which will be responsible for this.

Why?

quoted

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.

quoted

quoted

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

quoted

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.
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)
Another question, in performance terms which is better: uio driver or
kernel driver?

Thank you,
Ran

thanks,

greg k-h

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161230/40d3c481/attachment.html