Hi,
I have a 1 meg chunk of shared memory reserved via the append
"mem=xx" command line, and I'm curious as to the consistency and
behavior of it. Though I don't believe this is specifically an
RT-Linux question, I suspect that others are doing similar things to
provide "zero-copy" buffers...
I access the shared memory via 3 different "interfaces":
1. DMA - a DMA controller feeds data to/from the memory. This
requires a non-cached interface, contiguous addresses and a real
(physical) memory address.
2. RT-Linux - data is examined here, also this is where DMA's are
started. Again, a non-cached (for consistency with DMA HW)
interface, and both virtual (for my accesses) and physical (for
handing to DMA controller) addresses. I use
virt_addr = ioremap_nocache(phys_addr, phys_len);
to get my uncached virtual address.
3. User Space - I mmap() the physical memory in. Again I need
consistency, so (I presume) no caching is occurring (though I can't
find any flags to mmap to guarantee this), and I'll be working only
with virtual memory addresses (after the mmap).
My question(s):
1. Are my assumptions reasonable regarding keeping memory consistent
between all three spaces? Note that there are no problems with
"ownership", I don't need to specifically mutex access to the
buffers, but is there anything (for example) I need to do to
guarantee memory consistency between RT-Linux and User Space (e.g. a
"cache flush").
2. I tried using virt_to_phys(virt_addr) to get me a physical
address (for the DMA controller), but it didn't give me back the
same address that I fed to ioremap_nocache(phy_addr). Specifically:
phy_addr = 0x7f00000 (127MB) len=0x100000 (1MB)
ioremap_nocache(phy_addr, len) returns virtual 0xc8867000
and I can use the virtual address pointer to access the buffer.
Now, when I call:
virt_to_phys(0xc886700) it returns "physical" addr 0x8867000
Huh?! Any explanations as to why I don't get back my original
physical address (0x7f00000)?
Thanks in advance,
Eric
--
Woolsey-Swanson Rule:
People would rather live with a problem they cannot
solve rather than accept a solution they cannot understand.
Eric Peterson WB6PYK (805)370-3046 mailto:[EMAIL PROTECTED]
http://www.troikanetworks.com
----- End of forwarded message from [EMAIL PROTECTED] -----
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
