Hi Matthias, Thanks for your help. This seems to fix everything. Am I correct in saying that by using the O_SYNC option, a write access doesn't cause a full page (in the Davinci ARM case, 4Kb) to be written out to the physical device then, but instead only the exact number of bytes I intend to write out?
Thanks. Regards, Andy ----- Original Message ---- From: Matthias Welwarsky <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]> Cc: "davinci-linux-open-source @linux.davincidsp.com" <[email protected]> Sent: Saturday, May 12, 2007 2:32:10 AM Subject: Re: mmap issue Andy, opening /dev/mem O_RDWR|O_SYNC should be enough to map the region uncached and with the write buffer disabled. In that case, every read and write into the memory mapped region directly translates into a CPU access to the respective physical address. No need to call msync before or after. Andy Ngo wrote: Hi, Thanks to everyone for your responses and suggestions. I still have a questions about reads. When I do a read from the mmaped region, how do I know if they values are valid (not stale data)? For example, if the FPGA microblaze processor on the other side writes, let's say 32 bytes, to the shared RAM, then interrupts the Davinci to read them, are those 32 bytes valid when my user application accesses those bytes via the mmaped pointer? Does the /dev/mem driver access the real shared RAM on every read access or do I have to call msync every time I do a read to guarantee the data are valid? Thanks! Regards, Andy ----- Original Message ---- From: Roberto Waltman <[EMAIL PROTECTED]> To: "davinci-linux-open-source @linux.davincidsp.com" <[email protected]> Sent: Friday, May 11, 2007 6:54:39 AM Subject: Re: mmap issue Sorry, I misread the original post. We had a similar, but not identical problem. In our case, CPU writes to control registers in an external FPGA were not being propagated correctly. Still, the same solution may work (dummy writes followed by reads?) Also: Andy Ngo wrote: > 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? You can tell msync() to synchronize only the same area modified in the write. If this is "inefficient" or not, only you can tell. msync() may not be necessary for memory access, as opposed to access to memory mapped files. > 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? I thought about writing a special driver similar to /dev/mem, but with that property as well as only using the right word size (16 bits in our case) Roberto Waltman wrote: > R. Simning wrote: >> Andy Ngo wrote: >>> ..... 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 thought the declaration of a variable as "volatile" would force >> the value to always be read directly from RAM, never cache. I'm not >> clear whether declaring a variable "volatile" forces the write to >> RAM, but that case doesn't seem to be an issue here. >> >> I would believe that just declaring those data structures as >> "volatile" should resolve your cache issues of reading "stale" data. > > No, that only tells the compiler not to optimize-out references to a > variable, always fetching a new value from "memory" when necessary. > The compiler has no knowledge if the value is fetched from actual > memory, from an internal or external cache, or if it is out of sync > with a second CPU's view, etc. > > We went through the same problem recently, one of my colleagues found > the answer: > > (a) Declare all variables in the mapped area as volatile, and > (b) Do a readback immediately after writing to mapped memory, to force > flushing the cache. > > See http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf, chapter 4, in > particular section 4.2, for the rationale behind this. > > > Roberto Waltman > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source 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 [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
