1. 12 10月, 2011 1 次提交
    • K
      powerpc: respect mem= setting for early memory limit setup · ba14f649
      Kumar Gala 提交于
      For those MMUs that have some form of bolt'd linear mapping (TLB)
      required its rare that one ever sets mem= smaller than the size of that
      mapping.
      
      However, on Book-E 64 parts the initial linear mapping is quite large
      (1G) so its quite reasonable that mem= is set smaller than that.
      
      We need to parse the command line for mem= limit and constrain the
      amount of memory we map initially by it if need be.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      ba14f649
  2. 20 9月, 2011 2 次提交
  3. 29 6月, 2011 1 次提交
  4. 17 6月, 2011 1 次提交
  5. 09 6月, 2011 1 次提交
    • B
      powerpc: Force page alignment for initrd reserved memory · 307cfe71
      Benjamin Herrenschmidt 提交于
      When using 64K pages with a separate cpio rootfs, U-Boot will align
      the rootfs on a 4K page boundary. When the memory is reserved, and
      subsequent early memblock_alloc is called, it will allocate memory
      between the 64K page alignment and reserved memory. When the reserved
      memory is subsequently freed, it is done so by pages, causing the
      early memblock_alloc requests to be re-used, which in my case, caused
      the device-tree to be clobbered.
      
      This patch forces the reserved memory for initrd to be kernel page
      aligned, and will move the device tree if it overlaps with the range
      extension of initrd. This patch will also consolidate the identical
      function free_initrd_mem() from mm/init_32.c, init_64.c to mm/mem.c,
      and adds the same range extension when freeing initrd. free_initrd_mem()
      is also moved to the __init section.
      
      Many thanks to Milton Miller for his input on this patch.
      
      [BenH: Fixed build without CONFIG_BLK_DEV_INITRD]
      Signed-off-by: NDave Carroll <dcarroll@astekcorp.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      307cfe71
  6. 20 5月, 2011 1 次提交
  7. 19 5月, 2011 1 次提交
  8. 11 5月, 2011 1 次提交
  9. 27 4月, 2011 1 次提交
  10. 20 4月, 2011 1 次提交
  11. 31 3月, 2011 1 次提交
  12. 02 3月, 2011 1 次提交
  13. 16 1月, 2011 1 次提交
  14. 22 10月, 2010 1 次提交
  15. 05 8月, 2010 2 次提交
    • B
      memblock: Remove rmo_size, burry it in arch/powerpc where it belongs · cd3db0c4
      Benjamin Herrenschmidt 提交于
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cd3db0c4
    • B
      memblock: Introduce default allocation limit and use it to replace explicit ones · e63075a3
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e63075a3
  16. 23 7月, 2010 1 次提交
  17. 14 7月, 2010 1 次提交
  18. 09 3月, 2010 1 次提交
    • M
      powerpc: Dynamically allocate pacas · 1426d5a3
      Michael Ellerman 提交于
      On 64-bit kernels we currently have a 512 byte struct paca_struct for
      each cpu (usually just called "the paca"). Currently they are statically
      allocated, which means a kernel built for a large number of cpus will
      waste a lot of space if it's booted on a machine with few cpus.
      
      We can avoid that by only allocating the number of pacas we need at
      boot. However this is complicated by the fact that we need to access
      the paca before we know how many cpus there are in the system.
      
      The solution is to dynamically allocate enough space for NR_CPUS pacas,
      but then later in boot when we know how many cpus we have, we free any
      unused pacas.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1426d5a3
  19. 14 2月, 2010 3 次提交
  20. 09 2月, 2010 5 次提交
  21. 29 1月, 2010 3 次提交
  22. 11 12月, 2009 5 次提交
  23. 24 11月, 2009 4 次提交