On 6/16/05, Matt Porter <mporter at kernel.crashing.org> wrote: > On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
Thanks for taking the time to reply. > > I've been struggling with implementing mmap on a 440gx-based custom > > board. I have been able to use ioremap(), but we really need a mmap() > > for our software. The kernel is 2.4.18 (TimeSys 4.0). > > There are some special things done for handling [io]_remap_page/pfn_range > on other vendor kernels and the current mainline kernel. I'm not sure > if your vendor kernel addressed them since it would be a vendor-specific > patch in that timeframe. The special things are due to 36-bit > addressing. > > > I'm trying to access one of our FPGA's located at 0x50000000. Offsets > > Let's start at the beginning. How do you have FPGA's at 0x50000000? > that address falls with the fix DDR SDRAM area on the 440GX memory > map. All peripheral and EBC space is mapped by 4GB. You lost me > right here. Oh wait, are you referring to the least significant 32-bits > of the physical mapping. It's not really at 0x50000000. Of course, you're correct. The 36-bit base address is 0x1_0000_0000. It is mapped to the 32-bit address 0x5000_0000. Should I pass the 36-bit address to remap_page_range()? For what it's worth, __pa(0x5000_0000) returns 0x9000_0000. > > You need something like the bigphys_remap patch for 2.4 that can be > found at ftp://source.mvista.com/pub/linuxppc/ I just checked the source, and that patch has indeed been applied. > > It does the same fixup for remap_page_range() that happens for > ioremap(). In 2.6 this stuff is all in the mainline kernel but > you use io_rename_[page|pfn]_range() there. > > -Matt > Thanks, Ed
