linux-mips
[Top] [All Lists]

[RFC] FLATMEM: allow memory to start at pfn != 0

To: ralf@linux-mips.org
Subject: [RFC] FLATMEM: allow memory to start at pfn != 0
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Date: Wed, 6 Dec 2006 16:48:27 +0100
Cc: linux-mips@linux-mips.org
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:cc:subject:date:message-id:x-mailer:from; b=lA7ebdCXY8iZQIaryLRr8Nbkc7lE8Lo2beY2O48JPrPP1EUQRzjvYWQRNr6BcHq8bUkRTy+ygo7Ks4JgzQO7OUI9Wbo8sdy24wkzWd5iqtBjrPfJv8vyTmeCb+CqiRfjaMv2/DLQCz8gqnMitIaezluGtBu1IH/hYz/ppFhsAbM=
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
This patchset relaxes this constraint. Basically you just need to
define in your platform code (include/asm-mips/mach-foo/spaces.h
probably) PHYS_OFFSET that corresponds to the start of your
physical memory and you're done.

The first patch is just a fix for HIGHMEM, I just found it while
writing this patchset. I haven't done any tests though, I have
no hardwares to play with.

The second and third patchs are the real meat. There are 2 points
that I'm not really sure:

        - PHYS_OFFSET is defined in page.h, I'm not sure if it's
        the right place though.

        - ARCH_PFN_OFFSET is always defined whatever the memory
        model. I don't think it will hurt since physical memory
        always has a starting point in all cases.



Please consider.

                Franck
---

 arch/mips/kernel/setup.c |   30 ++++++++++++++++++++++--------
 arch/mips/mm/init.c      |   30 +++++++++++++-----------------
 include/asm-mips/dma.h   |    1 +
 include/asm-mips/io.h    |    4 ++--
 include/asm-mips/page.h  |   25 +++++++++++++++++++++----
 5 files changed, 59 insertions(+), 31 deletions(-)



<Prev in Thread] Current Thread [Next in Thread>