1. 01 7月, 2008 2 次提交
  2. 30 6月, 2008 1 次提交
  3. 26 6月, 2008 1 次提交
  4. 19 6月, 2008 1 次提交
    • K
      powerpc/booke: Add support for new e500mc core · 3dfa8773
      Kumar Gala 提交于
      The new e500mc core from Freescale is based on the e500v2 but with the
      following changes:
      
      * Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
      * Floating Point
      * No SPE
      * Supports lwsync
      * Doorbell Exceptions
      * Hypervisor
      * Cache line size is now 64-bytes (e500v1/v2 have a 32-byte cache line)
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      3dfa8773
  5. 11 6月, 2008 1 次提交
  6. 12 5月, 2008 1 次提交
  7. 09 5月, 2008 1 次提交
  8. 25 4月, 2008 1 次提交
  9. 26 3月, 2008 1 次提交
    • S
      [POWERPC] 4xx: Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S · 464076a4
      Stefan Roese 提交于
      This patch adds basic support for the AMCC 460EX/460GT PPC's to arch/powerpc.
      Currently those PPC's are still based on a 440 core and *not* a 460 core.
      
      Here some basic features of those SoC's:
      
      460EX:
      - Up to 1.2GHz, 32kB L1 I-cache and D-cache, 256kB L2-cache, FPU
      - 1 * PCI (max 66MHz), 2 * PCIe (one 4-lane, one 1-lane)
      - 2 * GBit Ethernet with TCP/IP acceleration
      - USB 2.0 Host/Device OTG and Host interface
      - SATA controller
      - Optional security feature
      
      460GT (only changes to 460EX):
      - 4 * GBit Ethernet with TCP/IP acceleration
      - RapidIO
      - No SATA
      - No USB
      Signed-off-by: NStefan Roese <sr@denx.de>
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      464076a4
  10. 06 2月, 2008 2 次提交
  11. 25 1月, 2008 2 次提交
  12. 24 12月, 2007 3 次提交
  13. 12 12月, 2007 1 次提交
  14. 01 11月, 2007 1 次提交
    • V
      [POWERPC] 4xx: Workaround for the 440EP(x)/GR(x) processors identical PVR issue. · d1dfc35d
      Valentine Barshak 提交于
      PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
      they have identical cores. However, FPU is not supported on GR(x) and
      enabling APU instruction broadcast in the CCR0 register (to enable FPU)
      may cause unpredictable results. There's no safe way to detect FPU
      support at runtime. This patch provides a workarund for the issue.
      
      We use a POWER6 "logical PVR approach". First, we identify all EP(x)
      and GR(x) processors as GR(x) ones (which is safe). Then we check
      the device tree cpu path. If we have a EP(x) processor entry,
      we call identify_cpu again with PVR | 0x8. This bit is always 0
      in the real PVR. This way we enable FPU only for 440EP(x).
      Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      d1dfc35d
  15. 12 10月, 2007 1 次提交
  16. 11 10月, 2007 1 次提交
    • P
      [POWERPC] Fix performance monitor on machines with logical PVR · 87a72f9e
      Paul Mackerras 提交于
      Some IBM machines supply a "logical" PVR (processor version register)
      value in the device tree in the cpu nodes rather than the real PVR.
      This is used for instance to indicate that the processors in a POWER6
      partition have been configured by the hypervisor to run in POWER5+
      mode rather than POWER6 mode.  To cope with this, we call identify_cpu
      a second time with the logical PVR value (the first call is with the
      real PVR value in the very early setup code).
      
      However, POWER5+ machines can also supply a logical PVR value, and use
      the same value (the value that indicates a v2.04 architecture
      compliant processor).  This causes problems for code that uses the
      performance monitor (such as oprofile), because the PMU registers are
      different in POWER6 (even in POWER5+ mode) from the real POWER5+.
      
      This change works around this problem by taking out the PMU
      information from the cputable entries for the logical PVR values, and
      changing identify_cpu so that the second call to it won't overwrite
      the PMU information that was established by the first call (the one
      with the real PVR), but does update the other fields.  Specifically,
      if the cputable entry for the logical PVR value has num_pmcs == 0,
      none of the PMU-related fields get used.
      
      So that we can create a mixed cputable entry, we now make cur_cpu_spec
      point to a single static struct cpu_spec, and copy stuff from
      cpu_specs[i] into it.  This has the side-effect that we can now make
      cpu_specs[] be initdata.
      
      Ultimately it would be good to move the PMU-related fields out to a
      separate structure, pointed to by the cputable entries, and change
      identify_cpu so that it saves the PMU info pointer, copies the whole
      structure, and restores the PMU info pointer, rather than identify_cpu
      having to list all the fields that are *not* PMU-related.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      87a72f9e
  17. 03 10月, 2007 3 次提交
  18. 14 9月, 2007 1 次提交
  19. 07 9月, 2007 1 次提交
  20. 11 7月, 2007 1 次提交
  21. 10 7月, 2007 1 次提交
  22. 22 5月, 2007 1 次提交
  23. 17 5月, 2007 1 次提交
  24. 24 4月, 2007 2 次提交
  25. 09 3月, 2007 1 次提交
  26. 08 3月, 2007 1 次提交
  27. 13 2月, 2007 1 次提交
  28. 07 2月, 2007 2 次提交
  29. 08 12月, 2006 2 次提交
    • K
      [POWERPC] Fix 440SPe CPU table entry · a147c585
      Kumar Gala 提交于
      The 440SPe CPU table entry was missing the CPU_FTR_NODSISRALIGN and
      really should have been CPU_FTRS_44X.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      a147c585
    • K
      [POWERPC] Add support for FP emulation for the e300c2 core · aa42c69c
      Kim Phillips 提交于
      The e300c2 has no FPU.  Its MSR[FP] is grounded to zero.  If an attempt
      is made to execute a floating point instruction (including floating-point
      load, store, or move instructions), the e300c2 takes a floating-point
      unavailable interrupt.
      
      This patch adds support for FP emulation on the e300c2 by declaring a
      new CPU_FTR_FP_TAKES_FPUNAVAIL, where FP unavail interrupts are
      intercepted and redirected to the ProgramCheck exception path for
      correct emulation handling.
      
      (If we run out of CPU_FTR bits we could look to reclaim this bit by adding
      support to test the cpu_user_features for PPC_FEATURE_HAS_FPU instead)
      
      It adds a nop to the exception path for 32-bit processors with a FPU.
      Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      aa42c69c
  30. 04 12月, 2006 1 次提交