mmap on 440gx

[Ed Goforth]

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