05 Aug, 2010

2 commits

  • The RMA (RMO is a misnomer) is a concept specific to ppc64 (in fact
    server ppc64 though I hijack it on embedded ppc64 for similar purposes)
    and represents the area of memory that can be accessed in real mode
    (aka with MMU off), or on embedded, from the exception vectors (which
    is bolted in the TLB) which pretty much boils down to the same thing.

    We take that out of the generic MEMBLOCK data structure and move it into
    arch/powerpc where it belongs, renaming it to "RMA" while at it.

    Signed-off-by: Benjamin Herrenschmidt

    Benjamin Herrenschmidt
     
  • This introduce memblock.current_limit which is used to limit allocations
    from memblock_alloc() or memblock_alloc_base(..., MEMBLOCK_ALLOC_ACCESSIBLE).

    The old MEMBLOCK_ALLOC_ANYWHERE changes value from 0 to ~(u64)0 and can still
    be used with memblock_alloc_base() to allocate really anywhere.

    It is -no-longer- cropped to MEMBLOCK_REAL_LIMIT which disappears.

    Note to archs: I'm leaving the default limit to MEMBLOCK_ALLOC_ANYWHERE. I
    strongly recommend that you ensure that you set an appropriate limit
    during boot in order to guarantee that an memblock_alloc() at any time
    results in something that is accessible with a simple __va().

    The reason is that a subsequent patch will introduce the ability for
    the array to resize itself by reallocating itself. The MEMBLOCK core will
    honor the current limit when performing those allocations.

    Signed-off-by: Benjamin Herrenschmidt

    Benjamin Herrenschmidt
     

14 Jul, 2010

1 commit

  • via following scripts

    FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')

    sed -i \
    -e 's/lmb/memblock/g' \
    -e 's/LMB/MEMBLOCK/g' \
    $FILES

    for N in $(find . -name lmb.[ch]); do
    M=$(echo $N | sed 's/lmb/memblock/g')
    mv $N $M
    done

    and remove some wrong change like lmbench and dlmb etc.

    also move memblock.c from lib/ to mm/

    Suggested-by: Ingo Molnar
    Acked-by: "H. Peter Anvin"
    Acked-by: Benjamin Herrenschmidt
    Acked-by: Linus Torvalds
    Signed-off-by: Yinghai Lu
    Signed-off-by: Benjamin Herrenschmidt

    Yinghai Lu
     

13 Dec, 2009

1 commit

  • The Nintendo Wii video game console has two discontiguous RAM regions:
    - MEM1: 24MB @ 0x00000000
    - MEM2: 64MB @ 0x10000000

    Unfortunately, the kernel currently does not support discontiguous RAM
    memory regions on 32-bit PowerPC platforms.

    This patch adds a series of workarounds to allow the use of the second
    memory region (MEM2) as RAM by the kernel.
    Basically, a single range of memory from the beginning of MEM1 to the
    end of MEM2 is reported to the kernel, and a memory reservation is
    created for the hole between MEM1 and MEM2.

    With this patch the system is able to use all the available RAM and not
    just ~27% of it.

    This will no longer be needed when proper discontig memory support
    for 32-bit PowerPC is added to the kernel.

    Signed-off-by: Albert Herranz
    Acked-by: Benjamin Herrenschmidt
    Signed-off-by: Grant Likely

    Albert Herranz
     

24 Mar, 2009

1 commit

  • This patch tweaks the way some PTE bit combinations are defined, in such a
    way that the 32 and 64-bit variant become almost identical and that will
    make it easier to bring in a new common pte-* file for the new variant
    of the Book3-E support.

    The combination of bits defining access to kernel pages are now clearly
    separated from the combination used by userspace and the core VM. The
    resulting generated code should remain identical unless I made a mistake.

    Note: While at it, I removed a non-sensical statement related to CONFIG_KGDB
    in ppc_mmu_32.c which could cause kernel mappings to be user accessible when
    that option is enabled. Probably something that bitrot.

    Signed-off-by: Benjamin Herrenschmidt

    Benjamin Herrenschmidt
     

28 Jan, 2009

1 commit

  • _PAGE_COHERENT is now always set in _PAGE_RAM resp. PAGE_KERNEL.
    Thus it has to be masked out, if the BAT mapping should be non
    cacheable or CPU_FTR_NEED_COHERENT is not set.

    This will work on normal SMP setups because we force-set
    CPU_FTR_NEED_COHERENT as part of CPU_FTR_COMMON on SMP.

    Signed-off-by: Gerhard Pircher
    Signed-off-by: Benjamin Herrenschmidt

    Gerhard Pircher
     

23 Dec, 2008

1 commit


21 Dec, 2008

1 commit

  • We're soon running out of CPU features and I need to add some new
    ones for various MMU related bits, so this patch separates the MMU
    features from the CPU features. I moved over the 32-bit MMU related
    ones, added base features for MMU type families, but didn't move
    over any 64-bit only feature yet.

    Signed-off-by: Benjamin Herrenschmidt
    Acked-by: Kumar Gala
    Signed-off-by: Paul Mackerras

    Benjamin Herrenschmidt
     

04 Aug, 2008

1 commit


30 Jun, 2008

2 commits

  • While working on the 36-bit physical support, I noticed that there
    was exactly one line of code that actually referenced the bitfields.
    So I got rid of them and redefined ppc_bat as a struct of 2 u32's:
    batu and batl. I also got rid of the previous union that held the
    bitfield structs and a word representation of the batu/l values.

    This seems like a nicer solution than adding in a bunch of
    new bitfields to support extended bat addressing that would never
    get used, and just leaving the struct as-is would have been
    incomplete in the face of large physical addressing.

    Signed-off-by: Becky Bruce
    Signed-off-by: Paul Mackerras

    Becky Bruce
     
  • Currently, the physical address is an unsigned long, but it should
    be phys_addr_t in set_bat, [v/p]_mapped_by_bat. Also, create a
    macro that can convert a large physical address into the correct
    format for programming the BAT registers.

    Signed-off-by: Becky Bruce
    Signed-off-by: Paul Mackerras

    Becky Bruce
     

17 Apr, 2008

2 commits

  • We always use __initial_memory_limit as an address so rename it
    to be clear.

    Signed-off-by: Kumar Gala
    Signed-off-by: Paul Mackerras

    Kumar Gala
     
  • A number of users of PPC_MEMSTART (40x, ppc_mmu_32) can just always
    use 0 as we don't support booting these kernels at non-zero physical
    addresses since their exception vectors must be at 0 (or 0xfffx_xxxx).

    For the sub-arches that support relocatable interrupt vectors
    (book-e), it's reasonable to have memory start at a non-zero physical
    address. For those cases use the variable memstart_addr instead of
    the #define PPC_MEMSTART since the only uses of PPC_MEMSTART are for
    initialization and in the future we can set memstart_addr at runtime
    to have a relocatable kernel.

    Signed-off-by: Kumar Gala
    Signed-off-by: Paul Mackerras

    Kumar Gala
     

14 Feb, 2008

1 commit


14 Jun, 2007

2 commits

  • Using typedefs to rename structure types if frowned on by CodingStyle.
    However, we do so for the hash PTE structure on both ppc32 (where it's
    called "PTE") and ppc64 (where it's called "hpte_t"). On ppc32 we
    also have such a typedef for the BATs ("BAT").

    This removes this unhelpful use of typedefs, in the process
    bringing ppc32 and ppc64 closer together, by using the name "struct
    hash_pte" in both cases.

    Signed-off-by: David Gibson
    Signed-off-by: Paul Mackerras

    David Gibson
     
  • APUS (the Amiga Power-Up System) is not supported under arch/powerpc
    and it's unlikely it ever will be. Therefore, this patch removes the
    fragments of APUS support code from arch/powerpc which have been
    copied from arch/ppc.

    A few APUS references are left in asm-powerpc in .h files which are
    still used from arch/ppc.

    Signed-off-by: David Gibson
    Signed-off-by: Paul Mackerras

    David Gibson
     

09 May, 2007

1 commit

  • Commit d1953c8888ef034b912ee33bc2ea2cce6a414402 removed the use of
    4level-fixup.h for 32-bit systems under arch/powerpc. However, I
    missed a few things activated on some configurations, resulting in
    some warnings (at least with STRICT_MM_TYPECHECKS enabled) and build
    errors in some circumstances. This fixes it.

    Signed-off-by: David Gibson
    Signed-off-by: Paul Mackerras

    David Gibson
     

13 Apr, 2007

1 commit

  • Here's an implementation of DEBUG_PAGEALLOC for ppc32. It disables BAT
    mapping and is only tested with Hash table based processor though it
    shouldn't be too hard to adapt it to others.

    Signed-off-by: Benjamin Herrenschmidt

    arch/powerpc/Kconfig.debug | 9 ++++++
    arch/powerpc/mm/init_32.c | 4 +++
    arch/powerpc/mm/pgtable_32.c | 52 +++++++++++++++++++++++++++++++++++++++
    arch/powerpc/mm/ppc_mmu_32.c | 4 ++-
    include/asm-powerpc/cacheflush.h | 6 ++++
    5 files changed, 74 insertions(+), 1 deletion(-)
    Signed-off-by: Paul Mackerras

    Benjamin Herrenschmidt
     

01 Jul, 2006

1 commit


21 Jun, 2006

1 commit


15 Jun, 2006

1 commit


11 Jun, 2006

1 commit


07 Nov, 2005

2 commits

  • Oops, some last minute changes caused the 64K pages patch to break ppc32
    build, this fixes it.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     
  • Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
    base page size to 64K. The resulting kernel still boots on any
    hardware. On current machines with 4K pages support only, the kernel
    will maintain 16 "subpages" for each 64K page transparently.

    Note that while real 64K capable HW has been tested, the current patch
    will not enable it yet as such hardware is not released yet, and I'm
    still verifying with the firmware architects the proper to get the
    information from the newer hypervisors.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

10 Oct, 2005

1 commit