1. 18 5月, 2011 2 次提交
  2. 29 3月, 2011 1 次提交
    • C
      x86: A fast way to check capabilities of the current cpu · 349c004e
      Christoph Lameter 提交于
      Add this_cpu_has() which determines if the current cpu has a certain
      ability using a segment prefix and a bit test operation.
      
      For that we need to add bit operations to x86s percpu.h.
      
      Many uses of cpu_has use a pointer passed to a function to determine
      the current flags. That is no longer necessary after this patch.
      
      However, this patch only converts the straightforward cases where
      cpu_has is used with this_cpu_ptr. The rest is work for later.
      
      -tj: Rolled up patch to add x86_ prefix and use percpu_read() instead
           of percpu_read_stable().
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      349c004e
  3. 16 2月, 2011 1 次提交
    • R
      perf, x86: Add support for AMD family 15h core counters · 4979d272
      Robert Richter 提交于
      This patch adds support for AMD family 15h core counters. There are
      major changes compared to family 10h. First, there is a new perfctr
      msr range for up to 6 counters. Northbridge counters are separate
      now. This patch only adds support for core counters. Second, certain
      events may only be scheduled on certain counters. For this we need to
      extend the event scheduling and constraints.
      
      We use cpu feature flags to calculate family 15h msr address offsets.
      This way we later can implement a faster ALTERNATIVE() version for
      this.
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20110215135210.GB5874@erda.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4979d272
  4. 25 9月, 2010 1 次提交
  5. 14 9月, 2010 1 次提交
  6. 09 9月, 2010 3 次提交
  7. 02 8月, 2010 1 次提交
  8. 31 7月, 2010 1 次提交
  9. 20 7月, 2010 2 次提交
  10. 08 7月, 2010 3 次提交
  11. 17 6月, 2010 1 次提交
    • V
      x86: Look for IA32_ENERGY_PERF_BIAS support · 23016bf0
      Venkatesh Pallipadi 提交于
      The new IA32_ENERGY_PERF_BIAS MSR allows system software to give
      hardware a hint whether OS policy favors more power saving,
      or more performance.  This allows the OS to have some influence
      on internal hardware power/performance tradeoffs where the OS
      has previously had no influence.
      
      The support for this feature is indicated by CPUID.06H.ECX.bit3,
      as documented in the Intel Architectures Software Developer's Manual.
      
      This patch discovers support of this feature and displays it
      as "epb" in /proc/cpuinfo.
      Signed-off-by: NVenkatesh Pallipadi <venki@google.com>
      LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      23016bf0
  12. 28 5月, 2010 1 次提交
  13. 12 5月, 2010 1 次提交
    • H
      x86: Add new static_cpu_has() function using alternatives · a3c8acd0
      H. Peter Anvin 提交于
      For CPU-feature-specific code that touches performance-critical paths,
      introduce a static patching version of [boot_]cpu_has().  This is run
      at alternatives time and is therefore not appropriate for most
      initialization code, but on the other hand initialization code is
      generally not performance critical.
      
      On gcc 4.5+ this uses the new "asm goto" feature.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1273135546-29690-2-git-send-email-avi@redhat.com>
      a3c8acd0
  14. 10 4月, 2010 1 次提交
  15. 14 2月, 2010 1 次提交
  16. 17 12月, 2009 1 次提交
  17. 19 10月, 2009 1 次提交
  18. 15 9月, 2009 1 次提交
    • P
      x86: Move APERF/MPERF into a X86_FEATURE · a8303aaf
      Peter Zijlstra 提交于
      Move the APERFMPERF capacility into a X86_FEATURE flag so that it
      can be used outside of the acpi cpufreq driver.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Yanmin <yanmin_zhang@linux.intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: cpufreq@vger.kernel.org
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a8303aaf
  19. 04 9月, 2009 1 次提交
  20. 10 6月, 2009 1 次提交
  21. 09 6月, 2009 1 次提交
    • A
      x86: Detect use of extended APIC ID for AMD CPUs · 42937e81
      Andreas Herrmann 提交于
      Booting a 32-bit kernel on Magny-Cours results in the following panic:
      
        ...
        Using APIC driver default
        ...
        Overriding APIC driver with bigsmp
        ...
        Getting VERSION: 80050010
        Getting VERSION: 80050010
        Getting ID: 10000000
        Getting ID: ef000000
        Getting LVT0: 700
        Getting LVT1: 10000
        Kernel panic - not syncing: Boot APIC ID in local APIC unexpected (16 vs 0)
        Pid: 1, comm: swapper Not tainted 2.6.30-rcX #2
        Call Trace:
         [<c05194da>] ? panic+0x38/0xd3
         [<c0743102>] ? native_smp_prepare_cpus+0x259/0x31f
         [<c073b19d>] ? kernel_init+0x3e/0x141
         [<c073b15f>] ? kernel_init+0x0/0x141
         [<c020325f>] ? kernel_thread_helper+0x7/0x10
      
      The reason is that default_get_apic_id handled extension of local APIC
      ID field just in case of XAPIC.
      
      Thus for this AMD CPU, default_get_apic_id() returns 0 and
      bigsmp_get_apic_id() returns 16 which leads to the respective kernel
      panic.
      
      This patch introduces a Linux specific feature flag to indicate
      support for extended APIC id (8 bits instead of 4 bits width) and sets
      the flag on AMD CPUs if applicable.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090608135509.GA12431@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      42937e81
  22. 11 5月, 2009 1 次提交
    • Y
      x86: clean up and fix setup_clear/force_cpu_cap handling · 3e0c3737
      Yinghai Lu 提交于
      setup_force_cpu_cap() only have one user (Xen guest code),
      but it should not reuse cleared_cpu_cpus, otherwise it
      will have problems on SMP.
      
      Need to have a separate cpu_cpus_set array too, for forced-on
      flags, beyond the forced-off flags.
      
      Also need to setup handling before all cpus caps are combined.
      
      [ Impact: fix the forced-set CPU feature flag logic ]
      
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NYinghai Lu <yinghai.lu@kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3e0c3737
  23. 03 5月, 2009 1 次提交
  24. 08 4月, 2009 1 次提交
  25. 18 2月, 2009 1 次提交
  26. 09 2月, 2009 1 次提交
  27. 17 12月, 2008 1 次提交
  28. 23 11月, 2008 1 次提交
  29. 02 11月, 2008 1 次提交
  30. 01 11月, 2008 1 次提交
  31. 31 10月, 2008 1 次提交
  32. 23 10月, 2008 2 次提交
  33. 23 9月, 2008 1 次提交