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