1. 14 10月, 2008 2 次提交
  2. 13 10月, 2008 12 次提交
  3. 10 10月, 2008 4 次提交
  4. 07 10月, 2008 1 次提交
  5. 03 10月, 2008 1 次提交
    • V
      powerpc/44x: Add AMCC Arches eval board support · e00de30a
      Victor Gallardo 提交于
      The Arches Evaluation board is based on the AMCC 460GT SoC chip.
      This board is a dual processor board with each processor providing
      independent resources for Rapid IO, Gigabit Ethernet, and serial
      communications.  Each 460GT has it's own 512MB DDR2 memory, 32MB NOR FLASH,
      UART, EEPROM and temperature sensor, along with a shared debug port.
      The two 460GT's will communicate with each other via shared memory,
      Gigabit Ethernet and x1 PCI-Express.
      Signed-off-by: NVictor Gallardo <vgallardo@amcc.com>
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      e00de30a
  6. 29 9月, 2008 2 次提交
  7. 25 9月, 2008 2 次提交
  8. 24 9月, 2008 1 次提交
  9. 16 9月, 2008 9 次提交
    • M
      powerpc: Board support for GE Fanuc SBC610 · 54508214
      Martyn Welch 提交于
      Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
      MPC8641D).
      
      This is the basic board support for GE Fanuc's SBC610, a 6U single board
      computer, based on Freescale's MPC8641D.
      Signed-off-by: NMartyn Welch <martyn.welch@gefanuc.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      54508214
    • P
      powerpc/sbc8560: fix compile warning on CPM pin array · 66576a87
      Paul Gortmaker 提交于
      This is just a parallel of a5dc66e2
      applied to the sbc8560 board.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      66576a87
    • H
    • H
      powerpc: Add support for the MPC852 based mgsuvd board from keymile. · e14d4af0
      Heiko Schocher 提交于
      Supported SMC1 (serial console), SCC3 Ethernet (10Mbps hdx).
      Signed-off-by: NHeiko Schocher <hs@denx.de>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      e14d4af0
    • S
      powerpc: Separate the irq radix tree insertion and lookup · 967e012e
      Sebastien Dugue 提交于
      irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
      and insertion which happen in interrupt and process context respectively.
      
      Separate the function into its 2 components, one for lookup only and one
      for insertion only.
      
      Fix the only user of the revmap tree (XICS) to use the new functions.
      
      Also, move the insertion into the radix tree of those irqs that were
      requested before it was initialized at said tree initialization.
      
      Mutual exclusion between the tree initialization and readers/writers is
      handled via a state variable (revmap_trees_allocated) set to 1 when the tree
      has been initialized and set to 2 after the already requested irqs have been
      inserted in the tree by the init path. This state is checked before any reader
      or writer access just like we used to check for tree.gfp_mask != 0 before.
      
      Finally, now that we're not any longer inserting nodes into the radix-tree
      in interrupt context, turn the GFP_ATOMIC allocations into GFP_KERNEL ones.
      Signed-off-by: NSebastien Dugue <sebastien.dugue@bull.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      967e012e
    • 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
    • P
      powerpc: Use LOAD_REG_IMMEDIATE only for constants on 64-bit · e31aa453
      Paul Mackerras 提交于
      Using LOAD_REG_IMMEDIATE to get the address of kernel symbols
      generates 5 instructions where LOAD_REG_ADDR can do it in one,
      and will generate R_PPC64_ADDR16_* relocations in the output when
      we get to making the kernel as a position-independent executable,
      which we'd rather not have to handle.  This changes various bits
      of assembly code to use LOAD_REG_ADDR when we need to get the
      address of a symbol, or to use suitable position-independent code
      for cases where we can't access the TOC for various reasons, or
      if we're not running at the address we were linked at.
      
      It also cleans up a few minor things; there's no reason to save and
      restore SRR0/1 around RTAS calls, __mmu_off can get the return
      address from LR more conveniently than the caller can supply it in
      R4 (and we already assume elsewhere that EA == RA if the MMU is on
      in early boot), and enable_64b_mode was using 5 instructions where
      2 would do.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e31aa453
    • N
      powerpc: Check rc of notifier chain for memory remove · 525c411d
      Nathan Fontenot 提交于
      The return code from invocation of the notifier for
      pSeries_reconfig_chain during update of the device tree is not
      checked.  This causes writes to /proc/ppc64/ofdt to update memory
      properties (i.e. ibm,dyamic-reconfiguration-memory) to always
      return success, instead of the result of the notifier chain.
      
      This happens specifically when we remove/add memory from the
      device tree on machines using memory specified in the
      ibm,dynamic-reconfiguration-memory property of the device tree.
      Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      525c411d
    • R
      powerpc: Fix duplicate test of MACIO_FLAG_SCCB_ON · 1b3c83e6
      roel kluin 提交于
      Evidently MACIO_FLAG_SCCA_ON was meant.
      Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1b3c83e6
  10. 08 9月, 2008 1 次提交
  11. 05 9月, 2008 2 次提交
    • J
      powerpc/spufs: Fix race for a free SPU · b65fe035
      Jeremy Kerr 提交于
      We currently have a race for a free SPE. With one thread doing a
      spu_yield(), and another doing a spu_activate():
      
      thread 1				thread 2
      spu_yield(oldctx)			spu_activate(ctx)
        __spu_deactivate(oldctx)
        spu_unschedule(oldctx, spu)
        spu->alloc_state = SPU_FREE
      					spu = spu_get_idle(ctx)
      					    - searches for a SPE in
      					      state SPU_FREE, gets
      					      the context just
      					      freed by thread 1
      					spu_schedule(ctx, spu)
      					  spu->alloc_state = SPU_USED
      spu_schedule(newctx, spu)
        - assumes spu is still free
        - tries to schedule context on
          already-used spu
      
      This change introduces a 'free_spu' flag to spu_unschedule, to indicate
      whether or not the function should free the spu after descheduling the
      context. We only set this flag if we're not going to re-schedule
      another context on this SPU.
      
      Add a comment to document this behaviour.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      b65fe035
    • J
      powerpc/spufs: Fix multiple get_spu_context() · 9f43e391
      Jeremy Kerr 提交于
      Commit 8d5636fb introduced a reference
      count on SPU contexts during find_victim, but this may cause a leak in
      the reference count if we later find a better contender for a context to
      unschedule.
      
      Change the reference to after we've found our victim context, so we
      don't do the extra get_spu_context().
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      9f43e391
  12. 03 9月, 2008 1 次提交
    • T
      powerpc: Work around gcc's -fno-omit-frame-pointer bug · 7563dc64
      Tony Breeds 提交于
      This bug is causing random crashes
      (http://bugzilla.kernel.org/show_bug.cgi?id=11414).
      
      -fno-omit-frame-pointer is only needed on powerpc when -pg is also
      supplied, and there is a gcc bug that causes incorrect code generation
      on 32-bit powerpc when -fno-omit-frame-pointer is used---it uses stack
      locations below the stack pointer, which is not allowed by the ABI
      because those locations can and sometimes do get corrupted by an
      interrupt.
      
      This ensures that CONFIG_FRAME_POINTER is only selected by ftrace.
      When CONFIG_FTRACE is enabled we also pass -mno-sched-epilog to work
      around the gcc codegen bug.
      
      Patch based on work by:
      	Andreas Schwab <schwab@suse.de>
      	Segher Boessenkool <segher@kernel.crashing.org>
      Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7563dc64
  13. 28 8月, 2008 2 次提交