mmap on 440gx

[Ed Goforth]

On 6/17/05, Matt Porter <mporter at kernel.crashing.org> wrote:
> On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:
> > 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).
> > >
> 
> 
> > For what it's worth, __pa(0x5000_0000) returns 0x9000_0000.
> 
> Sure, you just asked it to subtract KERNELBASE from a physical address.
> Don't use __pa() in drivers. That's expected behavior. Why are
> you doing that?

Desperation.

> 
> > > 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.
> 
> Ok, assuming it's all correct then I don't know why it does work
> for you in your vendor tree. Have you asked Timesys for help?

Not yet.  I wanted to get some confidence that I was using the correct
APIs appropriately.

> 
> Put some debug statements throughout fixup_bigphys_addr() to see
> what's going on.

My include/asm/mmu.h has it defined as:
#ifndef CONFIG_440
#include <asm-generic/mmu.h>
#else
typedef unsigned long long phys_addr_t;
#define fixup_bigphys_addr(addr, size)   (addr)
#endif

I see that in later 2.4 kernels and in mainline 2.6 it is implemented
as an actual working routine.  Perhaps that explains it all.  The
ioremap() in my tree implements the fixup code inline, which would
explain why it works, right?

> 
> -Matt
> 

Thanks again.
Ed