application needs fast access to physical memory

[steven.lin at teradyne.com]

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                                                    
             <scottwood at freesc                                             
             ale.com>                                                   To 
                                       <steven.lin at teradyne.com>           
             11/18/2010 01:35                                           cc 
             PM                        David Gibson                        
                                       <david at gibson.dropbear.id.au>,      
                                       Michael Ellerman                    
                                       <michael at ellerman.id.au>,           
                                       <linuxppc-dev at lists.ozlabs.org>     
                                                                   Subject 
                                       Re: application needs fast access   
                                       to physical memory                  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On Thu, 18 Nov 2010 10:55:21 -0600
<steven.lin at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20101118/ad964724/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20101118/ad964724/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic02222.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20101118/ad964724/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20101118/ad964724/attachment-0002.gif>