Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 22 Jul, 2008 1 commit
    • Torez Smith's avatar
      powerpc: Indicate which oprofile counters to use while in compat mode · 79e25bac
      Torez Smith authored 
      While running on a system with new hardware and a kernel where the
cpu_specs[] table does not recognize the new hardware, the identify_cpu()
routine will select the default case as it searches through cpu_specs[]
in an attempt to match the real PVR. Once the default case is selected,
non of the oprofile counters and/or fields have been set up or defined.

When identify_cpu() is called once more with the logical PVR, some of
the cpu specific fields are replaced with the exception of the oprofile
related ones. However, in the case where we have actually taken the
default case while searching for the real PVR, we need to tell
oprofile that we are now running in compatibility mode so it can pick up
the correct counters. We do this by setting the oprofile_cpu_type field
to be that taken from the cpu_specs[] for the cpu we are now emulating.

This change will detect that we are now altering the real PVR and determine
if we also need to update the oprofile_cpu_type field.
Signed-off-by: default avatarTorez Smith <lnxtorez@linux.vnet.ibm.com>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      79e25bac
  3. 15 Jul, 2008 1 commit
    • Nathan Lynch's avatar
      powerpc: Add PPC_FEATURE_PSERIES_PERFMON_COMPAT · 0f473314
      Nathan Lynch authored 
      Background from Maynard Johnson:
As of POWER6, a set of 32 common events is defined that must be
supported on all future POWER processors.  The main impetus for this
compat set is the need to support partition migration, especially from
processor P(n) to processor P(n+1), where performance software that's
running in the new partition may not be knowledgeable about processor
P(n+1).  If a performance tool determines it does not support the
physical processor, but is told (via the
PPC_FEATURE_PSERIES_PERFMON_COMPAT bit) that the processor supports
the notion of the PMU compat set, then the performance tool can
surface just those events to the user of the tool.

PPC_FEATURE_PSERIES_PERFMON_COMPAT indicates that the PMU supports at
least this basic subset of events which is compatible across POWER
processor lines.
Signed-off-by: default avatarNathan Lynch <ntl@pobox.com>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0f473314
  5. 04 Jul, 2008 1 commit
  7. 01 Jul, 2008 3 commits
  9. 30 Jun, 2008 1 commit
  11. 26 Jun, 2008 1 commit
  13. 18 Jun, 2008 1 commit
    • Kumar Gala's avatar
      powerpc/booke: Add support for new e500mc core · 3dfa8773
      Kumar Gala authored 
      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: default avatarKumar Gala <galak@kernel.crashing.org>
      3dfa8773
  15. 11 Jun, 2008 1 commit
  17. 12 May, 2008 1 commit
  19. 09 May, 2008 1 commit
  21. 24 Apr, 2008 1 commit
  23. 26 Mar, 2008 1 commit
    • Stefan Roese's avatar
      [POWERPC] 4xx: Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S · 464076a4
      Stefan Roese authored 
      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: default avatarStefan Roese <sr@denx.de>
Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
      464076a4
  25. 06 Feb, 2008 2 commits
  27. 25 Jan, 2008 2 commits
  29. 24 Dec, 2007 1 commit
  31. 23 Dec, 2007 2 commits
  33. 11 Dec, 2007 1 commit
  35. 01 Nov, 2007 1 commit
    • Valentine Barshak's avatar
      [POWERPC] 4xx: Workaround for the 440EP(x)/GR(x) processors identical PVR issue. · d1dfc35d
      Valentine Barshak authored 
      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: default avatarValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
      d1dfc35d
  37. 11 Oct, 2007 2 commits
    • Stefan Roese's avatar
      [POWERPC] 4xx: Add AMCC 405EX support to cputable.c · 5d8476c8
      Stefan Roese authored 
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
      5d8476c8
    • Paul Mackerras's avatar
      [POWERPC] Fix performance monitor on machines with logical PVR · 87a72f9e
      Paul Mackerras authored 
      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: default avatarPaul Mackerras <paulus@samba.org>
Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      87a72f9e
  39. 03 Oct, 2007 3 commits
  41. 14 Sep, 2007 1 commit
  43. 07 Sep, 2007 1 commit
  45. 11 Jul, 2007 1 commit
  47. 10 Jul, 2007 1 commit
  49. 22 May, 2007 1 commit
  51. 17 May, 2007 1 commit
  53. 24 Apr, 2007 2 commits
  55. 09 Mar, 2007 1 commit
  57. 07 Mar, 2007 1 commit
  59. 13 Feb, 2007 1 commit
  61. 07 Feb, 2007 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7