1. 17 4月, 2008 1 次提交
    • K
      [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr · 99c62dd7
      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: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      99c62dd7
  2. 09 2月, 2008 1 次提交
    • M
      CONFIG_HIGHPTE vs. sub-page page tables. · 2f569afd
      Martin Schwidefsky 提交于
      Background: I've implemented 1K/2K page tables for s390.  These sub-page
      page tables are required to properly support the s390 virtualization
      instruction with KVM.  The SIE instruction requires that the page tables
      have 256 page table entries (pte) followed by 256 page status table entries
      (pgste).  The pgstes are only required if the process is using the SIE
      instruction.  The pgstes are updated by the hardware and by the hypervisor
      for a number of reasons, one of them is dirty and reference bit tracking.
      To avoid wasting memory the standard pte table allocation should return
      1K/2K (31/64 bit) and 2K/4K if the process is using SIE.
      
      Problem: Page size on s390 is 4K, page table size is 1K or 2K.  That means
      the s390 version for pte_alloc_one cannot return a pointer to a struct
      page.  Trouble is that with the CONFIG_HIGHPTE feature on x86 pte_alloc_one
      cannot return a pointer to a pte either, since that would require more than
      32 bit for the return value of pte_alloc_one (and the pte * would not be
      accessible since its not kmapped).
      
      Solution: The only solution I found to this dilemma is a new typedef: a
      pgtable_t.  For s390 pgtable_t will be a (pte *) - to be introduced with a
      later patch.  For everybody else it will be a (struct page *).  The
      additional problem with the initialization of the ptl lock and the
      NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor and
      a destructor pgtable_page_dtor.  The page table allocation and free
      functions need to call these two whenever a page table page is allocated or
      freed.  pmd_populate will get a pgtable_t instead of a struct page pointer.
       To get the pgtable_t back from a pmd entry that has been installed with
      pmd_populate a new function pmd_pgtable is added.  It replaces the pmd_page
      call in free_pte_range and apply_to_pte_range.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f569afd
  3. 06 2月, 2008 1 次提交
  4. 14 6月, 2007 3 次提交
  5. 23 5月, 2007 1 次提交
    • K
      [POWERPC] Fix modpost warning · f1aed924
      Kumar Gala 提交于
      Mark pte_alloc_one_kernel as __init_refok to fix the following warning:
      
      WARNING: arch/powerpc/mm/built-in.o(.text+0x1068): Section mismatch: reference to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'steal_context')
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      f1aed924
  6. 08 5月, 2007 1 次提交
  7. 24 4月, 2007 1 次提交
    • D
      [POWERPC] Abolish PHYS_FMT macro from arch/powerpc · 37f01d64
      David Gibson 提交于
      32-bit powerpc systems define a macro, PHYS_FMT, giving a printf
      format string fragment for displaying physical addresses, since most
      32-bit powerpc platforms use 32-bit physical addresses but a few use
      64-bit physical addresses.
      
      This macro is used in exactly one place, a rare error message, where
      we can solve the problem more simply by just unconditionally casting
      the address up to 64-bit quantity before formatting it.
      
      This patch does so, meaning that as we bring MMU definitions from
      asm-ppc over to asm-powerpc, cleaning them up in the process, we don't
      need to implement this ugly macro (which additionally has a very bad
      name for something global).
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      37f01d64
  8. 13 4月, 2007 3 次提交
    • B
      [POWERPC] DEBUG_PAGEALLOC for 32-bit · 88df6e90
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      
       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: NPaul Mackerras <paulus@samba.org>
      88df6e90
    • B
      [POWERPC] Fix 32-bit mm operations when not using BATs · ee4f2ea4
      Benjamin Herrenschmidt 提交于
      On hash table based 32 bits powerpc's, the hash management code runs with
      a big spinlock. It's thus important that it never causes itself a hash
      fault. That code is generally safe (it does memory accesses in real mode
      among other things) with the exception of the actual access to the code
      itself. That is, the kernel text needs to be accessible without taking
      a hash miss exceptions.
      
      This is currently guaranteed by having a BAT register mapping part of the
      linear mapping permanently, which includes the kernel text. But this is
      not true if using the "nobats" kernel command line option (which can be
      useful for debugging) and will not be true when using DEBUG_PAGEALLOC
      implemented in a subsequent patch.
      
      This patch fixes this by pre-faulting in the hash table pages that hit
      the kernel text, and making sure we never evict such a page under hash
      pressure.
      Signed-off-by: NBenjamin Herrenchmidt <benh@kernel.crashing.org>
      
       arch/powerpc/mm/hash_low_32.S |   22 ++++++++++++++++++++--
       arch/powerpc/mm/mem.c         |    3 ---
       arch/powerpc/mm/mmu_decl.h    |    4 ++++
       arch/powerpc/mm/pgtable_32.c  |   11 +++++++----
       4 files changed, 31 insertions(+), 9 deletions(-)
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ee4f2ea4
    • B
      [POWERPC] Cleanup 32-bit map_page · 3be4e699
      Benjamin Herrenschmidt 提交于
      The 32 bits map_page() function is used internally by the mm code
      for early mmu mappings and for ioremap. It should never be called
      for an address that already has a valid PTE or hash entry, so we
      add a BUG_ON for that and remove the useless flush_HPTE call.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      
       arch/powerpc/mm/pgtable_32.c |    9 ++++++---
       1 file changed, 6 insertions(+), 3 deletions(-)
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3be4e699
  9. 09 2月, 2007 1 次提交
    • K
      [POWERPC] Fix is_power_of_4(x) compile error · 8dabba5d
      Kumar Gala 提交于
      When building an 85xx kernel we get:
      
        CC      arch/powerpc/mm/pgtable_32.o
      arch/powerpc/mm/pgtable_32.c: In function 'io_block_mapping':
      arch/powerpc/mm/pgtable_32.c:330: error: expected identifier before '(' token
      arch/powerpc/mm/pgtable_32.c:330: error: expected statement before ')' token
      
      The is_power_of_2(x) fixup patch left an extra ')' on the is_power_of_4 macro.
      There is a similiar issue on the arch/ppc side.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      8dabba5d
  10. 07 2月, 2007 1 次提交
  11. 04 12月, 2006 2 次提交
  12. 01 7月, 2006 1 次提交
  13. 29 3月, 2006 1 次提交
  14. 16 3月, 2006 1 次提交
    • O
      [PATCH] powerpc: remove duplicate EXPORT_SYMBOLS · 920573bd
      Olaf Hering 提交于
      remove warnings when building a 64bit kernel.
      smp_call_function triggers also with 32bit kernel.
      
      WARNING: vmlinux: duplicate symbol 'smp_call_function' previous definition was in vmlinux
      arch/powerpc/kernel/ppc_ksyms.c:164:EXPORT_SYMBOL(smp_call_function);
      arch/powerpc/kernel/smp.c:300:EXPORT_SYMBOL(smp_call_function);
      
      WARNING: vmlinux: duplicate symbol 'ioremap' previous definition was in vmlinux
      arch/powerpc/kernel/ppc_ksyms.c:113:EXPORT_SYMBOL(ioremap);
      arch/powerpc/mm/pgtable_64.c:321:EXPORT_SYMBOL(ioremap);
      
      WARNING: vmlinux: duplicate symbol '__ioremap' previous definition was in vmlinux
      arch/powerpc/kernel/ppc_ksyms.c:117:EXPORT_SYMBOL(__ioremap);
      arch/powerpc/mm/pgtable_64.c:322:EXPORT_SYMBOL(__ioremap);
      
      WARNING: vmlinux: duplicate symbol 'iounmap' previous definition was in vmlinux
      arch/powerpc/kernel/ppc_ksyms.c:118:EXPORT_SYMBOL(iounmap);
      arch/powerpc/mm/pgtable_64.c:323:EXPORT_SYMBOL(iounmap);
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      920573bd
  15. 31 10月, 2005 1 次提交
  16. 29 10月, 2005 1 次提交
  17. 10 10月, 2005 1 次提交
  18. 06 10月, 2005 1 次提交
    • P
      powerpc: Merge lmb.c and make MM initialization use it. · 7c8c6b97
      Paul Mackerras 提交于
      This also creates merged versions of do_init_bootmem, paging_init
      and mem_init and moves them to arch/powerpc/mm/mem.c.  It gets rid
      of the mem_pieces stuff.
      
      I made memory_limit a parameter to lmb_enforce_memory_limit rather
      than a global referenced by that function.  This will require some
      small changes to ppc64 if we want to continue building ARCH=ppc64
      using the merged lmb.c.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7c8c6b97
  19. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af
  20. 22 6月, 2005 1 次提交
  21. 17 4月, 2005 2 次提交
    • K
      [PATCH] ppc32: make usage of CONFIG_PTE_64BIT & CONFIG_PHYS_64BIT consistent · a85f6d4a
      Kumar Gala 提交于
      CONFIG_PTE_64BIT & CONFIG_PHYS_64BIT are not currently consistently used in
      the code base.  Fixed up the usage such that CONFIG_PTE_64BIT is used when we
      have a 64-bit PTE regardless of physical address width.  CONFIG_PHYS_64BIT is
      used if the physical address width is larger than 32-bits, regardless of PTE
      size.
      
      These changes required a few sub-arch specific ifdef's to be fixed and the
      introduction of a physical address format string.
      Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a85f6d4a
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4