Hello Scott, Do you know whether this patch is necessary if I were to use alloc_bootmem () (to set aside a region of contiguous physical memory) instead of the kernel parameter "mem=256"?
-Steve Lin Scott Wood <scottw...@freesc ale.com> To <steven....@teradyne.com> 11/18/2010 01:35 cc PM David Gibson <da...@gibson.dropbear.id.au>, Michael Ellerman <mich...@ellerman.id.au>, <linuxppc-dev@lists.ozlabs.org> Subject Re: application needs fast access to physical memory On Thu, 18 Nov 2010 10:55:21 -0600 <steven....@teradyne.com> wrote: > Thanks for the replies. > > In the Linux Device Drivers book regarding mmap(), it states: > > Mapping a device means associating a range of user-space addresses to > device memory. > Whenever the program reads or writes in the assigned address range, it > is actually > accessing the device. In the X server example, using mmap allows quick > and easy > access to the video card’s memory. For a performance-critical > application like this, > direct access makes a large difference. > > For whatever reason, mmap() is definitely not quick and does not appear to > be a direct access to device memory. After the application completes a > large write into physical memory (via the pointer returned from mmap()), > the application performs an ioctl() to query whether the data actually > arrived into the memory region. It seems to take some time before the > associated kernel module actually "sees" the data in the physical memory > region. > > There's a few things I should say about this memory region. There's a total > of 512 MB of physical memory. U-Boot passes "mem=256M" as a kernel > parameter to tell Linux to only directly manage the lower 256 MB. The > special region of physical memory that the application is trying to access > is the upper 256 MB of memory not directly managed by Linux. The mmap() > call from the application is: > *memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, > _fdTerAlloc, (off_t) 0x10000000); Try this patch: http://patchwork.ozlabs.org/patch/68246/ -Scott
<<inline: graycol.gif>>
<<inline: pic02222.gif>>
<<inline: ecblank.gif>>
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev