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" <davinci-linux-open-source@linux.davincidsp.com> 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 > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
