Using the Tundra DMA feature allows reading and writing of the VME bus without
CPU
involvement so the chip requires a physical DRAM address for these transfers. In
the
mmap function of my kernel module I acquire 128KB buffer of contiguous physical
memory
with
dmabuf = __get_free_pages( GFP_KERNEL, 5, 1 );
followed by a
remap_page_range( vma->vm_start, dmabuf, vsize, vma->vm_page_prot );
to map the physical buffer address to a virtual memory area that I hope the
application can
access. mmap returns the virtual pointer to the calling program and if I look at
/proc/pid/maps
I can see the vma listed with the proper virtual memory address and length. The
application
then writes and reads using this pointer with no apparent problem. The app is
super user and
has direct access to the Tundra register set so it initiates a DMA write (no
kernel call needed).
A VME DMA transfer actually takes place (VME address is correct and length of
data is
correct) but the data that the app wrote to the vma is not transferred. If I
slip some data into
the physical buffer while executing in the mmap function of the kernel module I
see that data
in the DMA'd data instead! So my questions are...
Does remap_page_range really make the physical buffer accessible to the
application with
the virtual pointer that it generates? Is there some hidden buffering going on
so that the data
that the app generates is not actually going to the physical buffer? Is there
something else
that I am missing?
These are time critical applications so I hope I don't have to do a (redundant)
mem copy just
so the driver is pointing to the correct data. I'm doing this on kernel 2.0.34.
Thanks in advance for any help, and many thanks to Alesandro Rubini for his book.
Best Regards,
Neill.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html