Hi Michael. Interesting setup there. Reminds me of a time when I had to do something similar over PCI for IPC between multiple processor domains but that's another story. On Mon, 2007-09-24 at 10:07 -0400, Michael Cashwell wrote: > The Basics: The hardware is an embedded system with an Xscale > processor running at least Linux 2.6.18 and 512MB of private SDRAM. > (There are multiple CPUs but only this one will run Linux.) The > proposed driver is to support an IPC system that uses another 256MB > of shared SDRAM with an FPGA providing the SDRAM's memory controller > and what amounts to a malloc/free interface to it for each CPU. So the Xscale processor's references to the shared SDRAM go via the memory controller in the FPGA right ? I'm guessing that there would be some level of system controller configuration needed on the Xscale side to allow references to the memory area in question be relayed to the FPGA's memory controller. What I'm getting at is that apart from the driver you envision, there probably will be some work needed on the system controller side as well. > Plan: We're considering each IPC connection to be a pair of circular > buffers containing "references" (I'm thinking of offsets from the > memory's base address) to buffers in the shared memory as the > foundation for the IPC system. A major goal is to allow references to > those buffers to be meaningful to all CPUs so we can pass them around > and not need to copy the data. Fair enough. > Each CPU will have this memory at some physical address and those > with MMUs would map that memory into virtual space. This mapping is > where I need to verify my thinking. I've mapped hardware like this > before but never so much. > > -- Question 1 -- > > Will I be able to map a 256MB range of physical address space into a > 256MB range of kernel virtual space such that the whole range remains > contiguous? What I mean is that I want Vbase+offset to refer to Pbase > +offset for all offsets in the 256MB range. > > Is there something special I'd have to do when establishing the > mapping to request this level of physical contiguity? This is a bit of an architecture specific thing but IMHO ioremap() is what you need. It should set up page tables and give you a pointer to a kernel virtual address to play with. Contiguous kernel virtual addresses should translate to corresponding physical addresses thereafter. I am reasonably certain that this will work on a MIPS architecture. > -- Question 2 -- > > Given that this is the basis for a multi-CPU IPC system what steps do > I need to take to have the address range be non-cached? There no way > caching would work since there's no way for the other CPUs to > participate in a cache coherency or snooping protocol. (The CPUs are > not all the same architecture.) You're right about the need for uncached accesses. ioremap variants such as ioremap_nocache() might be what you need. > -- Question 3 -- > > If my thinking above is OK then what would be the best approach to > allow that kernel virtual space (or perhaps only part of it) to also > be mapped into a sufficiently privileged user land process? Is mmap() > of /dev/mem appropriate or would that be a crude hack? I've seen sufficient instances of that method being used in the past to qualify it as a hack, not necessarily rude though!. It should work IMHO. > Further, that process would need to convert the buffer offsets into > usable VAs by adding them to the base VA of its mmap mapping. So I'd > need the 1:1 VA/PA address contiguity in the user land mapping too. > Is that possible? Unless I'm much mistaken, Yes. > -- Question 4 -- > > Can I do all the mapping and setup from my driver module or will I > need to add support directly to the kernel source (in addition to the > code needed in a module)? Obviously it would make version control > easier if it was module-only but if that's not going to work the > sooner I know this the better. Can't see any problems with this being a modular driver save for the system controller set up which you may/may not need depending on your system. > Thanks for any assistance and guidance if I'm off in the weeds. I think you're headed in the right direction. Cheerio! Robin -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
