Re: mmap on 440gx

[Matt Porter <mporter@kernel.crashing.org>]

On Fri, Jun 17, 2005 at 01:42:07AM -0400, Ed Goforth wrote:
> On 6/17/05, Matt Porter <mporter@kernel.crashing.org> wrote:
> > On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote:
> > > On 6/16/05, Matt Porter <mporter@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.

Heh, I like that. :)

<snip>

> > 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?

It sure does.  That code is 100% wrong.  Just merge in mainline 2.4
stuff and you should be golden. 

-Matt