On Sep 25, 2007, at 7:38 AM, Robin Randhawa wrote:
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?
That's right. The FPGA will handle arbitration to the shared memory.
The details here are being worked out but it's mostly FIFOs and
buffers with collision handled by the FPGA for 32-bit accesses and by
protocol for larger structures.
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.
Yes, I'd expect something to do with the particular chip select
that's controlling that area. I think I can figure that out as I've
done that before.
-- 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.
Actually I'm on Xscale (ARM11).
But I see an ominous warning in the man page for ioremap: "The
returned address is not guaranteed to be usable directly as a virtual
address." The story is that the return is a cookie that one is
supposed to use only via ioread/iowrite. Is that true for ARM?
Since what I ultimately want to be able to do is get a user land
virtual address for this region having to bottleneck access through
ioread() and friends would be a real pain.
I'd like to be able to use the result from ioremap() directly as a VA
in the kernel and map the same virtual address range for user land
via io_remap_page_range().
-Mike
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
