1. 15 6月, 2009 1 次提交
  2. 09 6月, 2009 1 次提交
  3. 27 5月, 2009 2 次提交
    • B
      powerpc: Fix up dma_alloc_coherent() on platforms without cache coherency. · 8b31e49d
      Benjamin Herrenschmidt 提交于
      The implementation we just revived has issues, such as using a
      Kconfig-defined virtual address area in kernel space that nothing
      actually carves out (and thus will overlap whatever is there),
      or having some dependencies on being self contained in a single
      PTE page which adds unnecessary constraints on the kernel virtual
      address space.
      
      This fixes it by using more classic PTE accessors and automatically
      locating the area for consistent memory, carving an appropriate hole
      in the kernel virtual address space, leaving only the size of that
      area as a Kconfig option. It also brings some dma-mask related fixes
      from the ARM implementation which was almost identical initially but
      grew its own fixes.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8b31e49d
    • B
      Revert "powerpc: Rework dma-noncoherent to use generic vmalloc layer" · 84532a0f
      Benjamin Herrenschmidt 提交于
      This reverts commit 33f00dce.
      
          While it was a good idea to try to use the mm/vmalloc.c allocator instead
          of our own (in fact, ours is itself a dup on an old variant of the vmalloc
          one), unfortunately, the approach is terminally busted since
          dma_alloc_coherent() can be called at interrupt time or in atomic contexts
          and there's little chances we'll make the code in mm/vmalloc.c cope with\       that :-(
      
          Until we can get the generic code to forbid that idiocy and fix all
          drivers abusing it, we pretty much have no choice but revert to
          our custom virtual space allocator.
      
          There's also a problem with SMP safety since freeing such mapping
          would require an IPI which cannot be done at interrupt time.
      
          However, right now, I don't think we support any platform that is
          both SMP and has non-coherent DMA (don't laugh, I know such things
          do exist !) so we can sort that out later.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      84532a0f
  4. 21 5月, 2009 1 次提交
  5. 03 5月, 2009 1 次提交
    • D
      Move dtc and libfdt sources from arch/powerpc/boot to scripts/dtc · 9fffb55f
      David Gibson 提交于
      The powerpc kernel always requires an Open Firmware like device tree
      to supply device information.  On systems without OF, this comes from
      a flattened device tree blob.  This blob is usually generated by dtc,
      a tool which compiles a text description of the device tree into the
      flattened format used by the kernel.  Sometimes, the bootwrapper makes
      small changes to the pre-compiled device tree blob (e.g. filling in
      the size of RAM).  To do this it uses the libfdt library.
      
      Because these are only used on powerpc, the code for both these tools
      is included under arch/powerpc/boot (these were imported and are
      periodically updated from the upstream dtc tree).
      
      However, the microblaze architecture, currently being prepared for
      merging to mainline also uses dtc to produce device tree blobs.  A few
      other archs have also mentioned some interest in using dtc.
      Therefore, this patch moves dtc and libfdt from arch/powerpc into
      scripts, where it can be used by any architecture.
      
      The vast bulk of this patch is a literal move, the rest is adjusting
      the various Makefiles to use dtc and libfdt correctly from their new
      locations.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9fffb55f
  6. 15 4月, 2009 1 次提交
  7. 07 4月, 2009 1 次提交
  8. 01 4月, 2009 1 次提交
  9. 31 3月, 2009 1 次提交
  10. 30 3月, 2009 1 次提交
  11. 11 3月, 2009 1 次提交
    • B
      powerpc/kconfig: Kill PPC_MULTIPLATFORM · 28794d34
      Benjamin Herrenschmidt 提交于
      CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
      really meaningful anymore. It was basically equivalent to PPC64 || 6xx.
      
      This removes it along with the following changes:
      
       - 32-bit platforms that relied on PPC32 && PPC_MULTIPLATFORM now rely
         on 6xx which is what they want anyway.
      
       - A new symbol, PPC_BOOK3S, is defined that represent compliance with
         the "Server" variant of the architecture. This is set when either 6xx
         or PPC64 is set and open the door for future BOOK3E 64-bit.
      
       - 64-bit platforms that relied on PPC64 && PPC_MULTIPLATFORM now use
         PPC64 && PPC_BOOK3S
      
       - A separate and selectable CONFIG_PPC_OF_BOOT_TRAMPOLINE option is now
         used to control the use of prom_init.c
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      28794d34
  12. 23 2月, 2009 5 次提交
  13. 15 2月, 2009 1 次提交
    • Y
      powerpc/44x: Support for 256KB PAGE_SIZE · e1240122
      Yuri Tikhonov 提交于
      This patch adds support for 256KB pages on ppc44x-based boards.
      
      For simplification of implementation with 256KB pages we still assume
      2-level paging. As a side effect this leads to wasting extra memory space
      reserved for PTE tables: only 1/4 of pages allocated for PTEs are
      actually used. But this may be an acceptable trade-off to achieve the
      high performance we have with big PAGE_SIZEs in some applications (e.g.
      RAID).
      
      Also with 256KB PAGE_SIZE we increase THREAD_SIZE up to 32KB to minimize
      the risk of stack overflows in the cases of on-stack arrays, which size
      depends on the page size (e.g. multipage BIOs, NTFS, etc.).
      
      With 256KB PAGE_SIZE we need to decrease the PKMAP_ORDER at least down
      to 9, otherwise all high memory (2 ^ 10 * PAGE_SIZE == 256MB) we'll be
      occupied by PKMAP addresses leaving no place for vmalloc. We do not
      separate PKMAP_ORDER for 256K from 16K/64K PAGE_SIZE here; actually that
      value of 10 in support for 16K/64K had been selected rather intuitively.
      Thus now for all cases of PAGE_SIZE on ppc44x (including the default, 4KB,
      one) we have 512 pages for PKMAP.
      
      Because ELF standard supports only page sizes up to 64K, then you should
      use binutils later than 2.17.50.0.3 with '-zmax-page-size' set to 256K
      for building applications, which are to be run with the 256KB-page sized
      kernel. If using the older binutils, then you should patch them like follows:
      
      	--- binutils/bfd/elf32-ppc.c.orig
      	+++ binutils/bfd/elf32-ppc.c
      
      	-#define ELF_MAXPAGESIZE                0x10000
      	+#define ELF_MAXPAGESIZE                0x40000
      
      One more restriction we currently have with 256KB page sizes is inability
      to use shmem safely, so, for now, the 256KB is available only if you turn
      the CONFIG_SHMEM option off (another variant is to use BROKEN).
      Though, if you need shmem with 256KB pages, you can always remove the !SHMEM
      dependency in 'config PPC_256K_PAGES', and use the workaround available here:
       http://lkml.org/lkml/2008/12/19/20Signed-off-by: NYuri Tikhonov <yur@emcraft.com>
      Signed-off-by: NIlya Yanok <yanok@emcraft.com>
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      e1240122
  14. 29 1月, 2009 3 次提交
    • K
      powerpc/fsl: Ensure PCI_QUIRKS are enabled for FSL_PCI · d0839118
      Kumar Gala 提交于
      The FSL PCI code depends on PCI quirks being enabled to function
      properly.  We can ensure this by doing a select in Kconfig of
      PCI_QUIRKS.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      d0839118
    • T
      powerpc/fsl-booke: Make CAM entries used for lowmem configurable · 96051465
      Trent Piepho 提交于
      On booke processors, the code that maps low memory only uses up to three
      CAM entries, even though there are sixteen and nothing else uses them.
      
      Make this number configurable in the advanced options menu along with max
      low memory size.  If one wants 1 GB of lowmem, then it's typically
      necessary to have four CAM entries.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      96051465
    • T
      powerpc/fsl-booke: Allow larger CAM sizes than 256 MB · c8f3570b
      Trent Piepho 提交于
      The code that maps kernel low memory would only use page sizes up to 256
      MB.  On E500v2 pages up to 4 GB are supported.
      
      However, a page must be aligned to a multiple of the page's size.  I.e.
      256 MB pages must aligned to a 256 MB boundary.  This was enforced by a
      requirement that the physical and virtual addresses of the start of lowmem
      be aligned to 256 MB.  Clearly requiring 1GB or 4GB alignment to allow
      pages of that size isn't acceptable.
      
      To solve this, I simply have adjust_total_lowmem() take alignment into
      account when it decides what size pages to use.  Give it PAGE_OFFSET =
      0x7000_0000, PHYSICAL_START = 0x3000_0000, and 2GB of RAM, and it will map
      pages like this:
      PA 0x3000_0000 VA 0x7000_0000 Size 256 MB
      PA 0x4000_0000 VA 0x8000_0000 Size 1 GB
      PA 0x8000_0000 VA 0xC000_0000 Size 256 MB
      PA 0x9000_0000 VA 0xD000_0000 Size 256 MB
      PA 0xA000_0000 VA 0xE000_0000 Size 256 MB
      
      Because the lowmem mapping code now takes alignment into account,
      PHYSICAL_ALIGN can be lowered from 256 MB to 64 MB.  Even lower might be
      possible.  The lowmem code will work down to 4 kB but it's possible some of
      the boot code will fail before then.  Poor alignment will force small pages
      to be used, which combined with the limited number of TLB1 pages available,
      will result in very little memory getting mapped.  So alignments less than
      64 MB probably aren't very useful anyway.
      Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      c8f3570b
  15. 28 1月, 2009 1 次提交
  16. 14 1月, 2009 1 次提交
  17. 08 1月, 2009 2 次提交
  18. 29 12月, 2008 1 次提交
  19. 23 12月, 2008 1 次提交
  20. 03 12月, 2008 1 次提交
    • B
      powerpc: Add sync_*_for_* to dma_ops · 15e09c0e
      Becky Bruce 提交于
      We need to swap these out once we start using swiotlb, so add
      them to dma_ops.  Create CONFIG_PPC_NEED_DMA_SYNC_OPS Kconfig
      option; this is currently enabled automatically if we're
      CONFIG_NOT_COHERENT_CACHE.  In the future, this will also
      be enabled for builds that need swiotlb.  If PPC_NEED_DMA_SYNC_OPS
      is not defined, the dma_sync_*_for_* ops compile to nothing.
      Otherwise, they access the dma_ops pointers for the sync ops.
      
      This patch also changes dma_sync_single_range_* to actually
      sync the range - previously it was using a generous
      dma_sync_single.  dma_sync_single_* is now implemented
      as a dma_sync_single_range with an offset of 0.
      Signed-off-by: NBecky Bruce <becky.bruce@freescale.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      15e09c0e
  21. 11 11月, 2008 1 次提交
  22. 23 10月, 2008 1 次提交
    • S
      ftrace: disable dynamic ftrace for all archs that use daemon · 07c4cc1c
      Steven Rostedt 提交于
      The ftrace daemon is complex and can cause nasty races if something goes
      wrong. Since it affects all of the kernel, this patch disables dynamic
      ftrace from any arch that depends on the daemon. Until the archs are
      ported over to the new MCOUNT_RECORD method, I am disabling dynamic
      ftrace from them.
      
      Note: I am leaving in the arch/<arch>/kernel/ftrace.c code alone since
      that can be used when the arch is ported to MCOUNT_RECORD. To port
      the arch to MCOUNT_RECORD, the scripts/recordmcount.pl needs to be
      updated. I will make that easier to do for 2.6.29. For 28, we will keep
      the archs disabled.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      07c4cc1c
  23. 22 10月, 2008 1 次提交
    • M
      powerpc: Support for relocatable kdump kernel · 54622f10
      Mohan Kumar M 提交于
      This adds relocatable kernel support for kdump. With this one can
      use the same regular kernel to capture the kdump. A signature (0xfeed1234)
      is passed in r6 from panic code to the next kernel through kexec_sequence
      and purgatory code. The signature is used to differentiate between
      kdump kernel and non-kdump kernels.
      
      The purgatory code compares the signature and sets the __kdump_flag in
      head_64.S.  During the boot up, kernel code checks __kdump_flag and if it
      is set, the kernel will behave as relocatable kdump kernel. This kernel
      will boot at the address where it was loaded by kexec-tools ie. at the
      address reserved through crashkernel boot parameter.
      
      CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
      kernel as relocatable. So the same kernel can be used as production and
      kdump kernel.
      
      This patch incorporates the changes suggested by Paul Mackerras to avoid
      GOT use and to avoid two copies of the code.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NMohan Kumar M <mohan@in.ibm.com>
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54622f10
  24. 21 10月, 2008 2 次提交
  25. 20 10月, 2008 1 次提交
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  26. 07 10月, 2008 1 次提交
  27. 16 9月, 2008 1 次提交
    • P
      powerpc: Make the 64-bit kernel as a position-independent executable · 549e8152
      Paul Mackerras 提交于
      This implements CONFIG_RELOCATABLE for 64-bit by making the kernel as
      a position-independent executable (PIE) when it is set.  This involves
      processing the dynamic relocations in the image in the early stages of
      booting, even if the kernel is being run at the address it is linked at,
      since the linker does not necessarily fill in words in the image for
      which there are dynamic relocations.  (In fact the linker does fill in
      such words for 64-bit executables, though not for 32-bit executables,
      so in principle we could avoid calling relocate() entirely when we're
      running a 64-bit kernel at the linked address.)
      
      The dynamic relocations are processed by a new function relocate(addr),
      where the addr parameter is the virtual address where the image will be
      run.  In fact we call it twice; once before calling prom_init, and again
      when starting the main kernel.  This means that reloc_offset() returns
      0 in prom_init (since it has been relocated to the address it is running
      at), which necessitated a few adjustments.
      
      This also changes __va and __pa to use an equivalent definition that is
      simpler.  With the relocatable kernel, PAGE_OFFSET and MEMORY_START are
      constants (for 64-bit) whereas PHYSICAL_START is a variable (and
      KERNELBASE ideally should be too, but isn't yet).
      
      With this, relocatable kernels still copy themselves down to physical
      address 0 and run there.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      549e8152
  28. 14 9月, 2008 1 次提交
  29. 12 8月, 2008 1 次提交
  30. 30 7月, 2008 1 次提交
  31. 28 7月, 2008 1 次提交