Hi,
what is the correct way for a UIO driver to pass a memory allocated
using dma_alloc_coherent to userspace? I have googled for examples
but I was not able to find a definitive answer.
My device needs two 128 kB chunks of DMA-able memory. First I tried
pdev->tx_vaddr = dma_zalloc_coherent(&dev->dev, pdev->dma_len,
&pdev->tx_paddr, GFP_KERNEL | GFP_DMA);
info->mem[2].name = "txdma";
info->mem[2].addr = (phys_addr_t) pdev->tx_vaddr;
info->mem[2].size = pdev->dma_len;
info->mem[2].memtype = UIO_MEM_LOGICAL;
This seemed to work at the first try, but tends to panic in various
ways when unmapping. It probably only maps the first page or something
like that and accessing past some limit overwrites something.
If I change this to
info->mem[2].addr = (phys_addr_t) pdev->tx_paddr;
info->mem[2].memtype = UIO_MEM_PHYS;
it seems to work at least on x86 with < 4GB memory. The uio_pruss.c
(or uio_dmem_genirq.c in newer kernels) do this as well.
I have a bad feeling here - if I am allocating something that
is a virtual memory in the kernel, I don't expect to pretend I am
accessing something else. The UIO howto explicitely states
that UIO_MEM_PHYS is meant for a "physical memory on your card".
Is this really a recommended way of doing this and is it portable
to other architectures?
I am using 3.4 kernel with realtime patches.
Please Cc: me when replying.
Thanks
--
Stano
On Mon, Feb 17, 2014 at 07:06:37PM +0100, Stanislav Meduna wrote:
> Hi,
>
> what is the correct way for a UIO driver to pass a memory allocated
> using dma_alloc_coherent to userspace? I have googled for examples
> but I was not able to find a definitive answer.
>
> My device needs two 128 kB chunks of DMA-able memory. First I tried
>
> pdev->tx_vaddr = dma_zalloc_coherent(&dev->dev, pdev->dma_len,
> &pdev->tx_paddr, GFP_KERNEL | GFP_DMA);
>
> info->mem[2].name = "txdma";
> info->mem[2].addr = (phys_addr_t) pdev->tx_vaddr;
> info->mem[2].size = pdev->dma_len;
> info->mem[2].memtype = UIO_MEM_LOGICAL;
>
> This seemed to work at the first try, but tends to panic in various
> ways when unmapping. It probably only maps the first page or something
> like that and accessing past some limit overwrites something.
Have you tried the uio_dmem_genirq.c driver? Or are you writing a new
one?
> If I change this to
>
> info->mem[2].addr = (phys_addr_t) pdev->tx_paddr;
> info->mem[2].memtype = UIO_MEM_PHYS;
>
> it seems to work at least on x86 with < 4GB memory. The uio_pruss.c
> (or uio_dmem_genirq.c in newer kernels) do this as well.
>
> I have a bad feeling here - if I am allocating something that
> is a virtual memory in the kernel, I don't expect to pretend I am
> accessing something else. The UIO howto explicitely states
> that UIO_MEM_PHYS is meant for a "physical memory on your card".
>
> Is this really a recommended way of doing this and is it portable
> to other architectures?
>
> I am using 3.4 kernel with realtime patches.
The uio_dmem_genirq.c driver showed up in 3.8, so it might be good for
you to update your kernel if you want to do DMA memory with a UIO
driver, as lots of other things in this area was fixed to accomplish
this.
Hope this helps,
greg k-h
On 17.02.2014 19:18, Greg KH wrote:
> The uio_dmem_genirq.c driver showed up in 3.8, so it might be good for
> you to update your kernel if you want to do DMA memory with a UIO
> driver, as lots of other things in this area was fixed to accomplish
> this.
Ah, OK, I will look into this.
I am stuck with 3.4 at the moment because of the real-time patches
and some semantic changes there in the newer kernels necessitating
much more tweak-and-test time than I currently have...
Thanks
--
Stano
On Mon, Feb 17, 2014 at 07:32:10PM +0100, Stanislav Meduna wrote:
> On 17.02.2014 19:18, Greg KH wrote:
>
> > The uio_dmem_genirq.c driver showed up in 3.8, so it might be good for
> > you to update your kernel if you want to do DMA memory with a UIO
> > driver, as lots of other things in this area was fixed to accomplish
> > this.
>
> Ah, OK, I will look into this.
>
> I am stuck with 3.4 at the moment because of the real-time patches
> and some semantic changes there in the newer kernels necessitating
> much more tweak-and-test time than I currently have...
The real-time patches are available for 3.10, so that shouldn't be an
excuse anymore :)