I just checked drivers/char/mem.c:
static int mmap_mem(struct file * file, struct vm_area_struct * vma)
{
#ifdef pgprot_noncached
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
int uncached;
uncached = uncached_access(file, offset);
if (uncached)
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
#endif
/* Remap-pfn-range will mark the range VM_IO and VM_RESERVED */
if (remap_pfn_range(vma,
vma->vm_start,
vma->vm_pgoff,
vma->vm_end-vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
return 0;
}
have a look at the function "uncached_access" in the same file. You'll
see that it returns 1 for O_SYNC, so it should work as is suggested.
regards,
matthias
Matthias Welwarsky wrote:
> Andy Ngo wrote:
>> Thanks, but how do I set the range uncacheable? I don't see such an
>> option for mmap. Please advise. Thanks!
> does it help to open /dev/mem with O_SYNC?
>>
>> Regards,
>> Andy
>>
>> ----- Original Message ----
>> From: YunChuan Qin <[EMAIL PROTECTED]>
>> To: Andy Ngo <[EMAIL PROTECTED]>
>> Sent: Thursday, May 10, 2007 9:38:46 PM
>> Subject: Re: mmap issue
>>
>> set this memory range uncacheable may solve your problem.
>>
>> 2007/5/11, Andy Ngo <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>>:
>>
>> Hi,
>>
>> This is more of a Linux question than anything. Hopefully
>> someone can help me. Our custom board has the Davinci exchanging
>> data with a Xilinx Virtex 5 Pro FPGA Microblaze processor via a
>> shared (Dual-Port) RAM interface. The shared RAM is 128Kb and is
>> hooked us to CS4 on the AEMIF. In order to access this shared
>> RAM memory space (physical address is 0x06000000), our
>> application is using mmap to map it to a virtual address space.
>> Here's a snippet of the mmap initialization:
>>
>> int fd;
>> unsigned char *shareRamPtr;
>>
>> fd = open("/dev/mem", O_RDWR);
>> sharedRamPtr = (unsigned char *)mmap(0, 0x20000 /* 128 Kb */,
>> PROT_READ | PROT_WRITE,
>> MAP_SHARED, fd, 0x06000000);
>>
>> It seems to work but not quite. We have a interrupt processing
>> handler that needs access (writes as well as reads) this space in
>> real-time every 2ms. Sometimes, when the FPGA Microblaze write
>> values to the shared RAM, and when our ARM processor on the
>> Davinci reads them during the interrupt processing, the data
>> looks staled (as though from previous reads). I googled and
>> found that writes require a call to msync to flush writes to the
>> actual shared RAM interface. So here are my questions:
>>
>> 1) If I need the writes to be real-time (immediately flushed out
>> to the shared RAM), do I have to call msync every single time I
>> do a write? If this is the case, isn't this very inefficient?
>> Does msync have to check the whole 0x20000 range to check what
>> bytes need to be flushed?
>> 2) How about for reads? As mentioned above, I seem to get stale
>> data sometimes during reads. Since the Microblaze is constantly
>> writing to shared RAM, what needs to be done so that when the ARM
>> reads the data at those locations, they are what the Microblaze
>> wrote?
>> 3) I tried using MAP_PRIVATE and it doesn't seem to map to the
>> shared RAM space at all (mmap doesn't return an error but I can't
>> write or read from it). Is there anyway to force the mechanism
>> behind mmap (driver for /dev/mem ?) to force a flush everytime
>> the ARM writes to shared RAM without having to call msync?
>>
>> Please advise. Thanks.
>>
>> Regards,
>> Andy
>>
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@linux.davincidsp.com
>> <mailto:Davinci-linux-open-source@linux.davincidsp.com>
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>> <http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source>
>>
>>
>>
>>
>> --
>> blog site:blog.csdn.net/freasy <http://blog.csdn.net/freasy>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source@linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
>
> --
> * Matthias Welwarsky
> Project Manager Software
> Germany
>
> *
--
* Matthias Welwarsky
Project Manager Software
Germany
*
____________________________________________________________________________
This email and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to which they are
addressed. Access to this e-mail by anyone else is unauthorised. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited. E-mail
messages are not necessarily secure. Archos does not accept responsibility
for any changes made to this message after it was sent.
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
