1. 31 5月, 2013 1 次提交
    • A
      Add arch_phys_wc_{add, del} to manipulate WC MTRRs if needed · d0d98eed
      Andy Lutomirski 提交于
      Several drivers currently use mtrr_add through various #ifdef guards
      and/or drm wrappers.  The vast majority of them want to add WC MTRRs
      on x86 systems and don't actually need the MTRR if PAT (i.e.
      ioremap_wc, etc) are working.
      
      arch_phys_wc_add and arch_phys_wc_del are new functions, available
      on all architectures and configurations, that add WC MTRRs on x86 if
      needed (and handle errors) and do nothing at all otherwise.  They're
      also easier to use than mtrr_add and mtrr_del, so the call sites can
      be simplified.
      
      As an added benefit, this will avoid wasting MTRRs and possibly
      warning pointlessly on PAT-supporting systems.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d0d98eed
  2. 15 12月, 2012 1 次提交
  3. 02 3月, 2012 1 次提交
  4. 22 8月, 2009 2 次提交
    • H
      x86, mtrr: make mtrr_aps_delayed_init static bool · 5400743d
      H. Peter Anvin 提交于
      mtr_aps_delayed_init was declared u32 and made global, but it only
      ever takes boolean values and is only ever used in
      arch/x86/kernel/cpu/mtrr/main.c.  Declare it "static bool" and remove
      external references.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      5400743d
    • S
      x86, pat/mtrr: Rendezvous all the cpus for MTRR/PAT init · d0af9eed
      Suresh Siddha 提交于
      SDM Vol 3a section titled "MTRR considerations in MP systems" specifies
      the need for synchronizing the logical cpu's while initializing/updating
      MTRR.
      
      Currently Linux kernel does the synchronization of all cpu's only when
      a single MTRR register is programmed/updated. During an AP online
      (during boot/cpu-online/resume)  where we initialize all the MTRR/PAT registers,
      we don't follow this synchronization algorithm.
      
      This can lead to scenarios where during a dynamic cpu online, that logical cpu
      is initializing MTRR/PAT with cache disabled (cr0.cd=1) etc while other logical
      HT sibling continue to run (also with cache disabled because of cr0.cd=1
      on its sibling).
      
      Starting from Westmere, VMX transitions with cr0.cd=1 don't work properly
      (because of some VMX performance optimizations) and the above scenario
      (with one logical cpu doing VMX activity and another logical cpu coming online)
      can result in system crash.
      
      Fix the MTRR initialization by doing rendezvous of all the cpus. During
      boot and resume, we delay the MTRR/PAT init for APs till all the
      logical cpu's come online and the rendezvous process at the end of AP's bringup,
      will initialize the MTRR/PAT for all AP's.
      
      For dynamic single cpu online, we synchronize all the logical cpus and
      do the MTRR/PAT init on the AP that is coming online.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      d0af9eed
  5. 31 1月, 2009 1 次提交
  6. 08 1月, 2009 1 次提交
  7. 31 12月, 2008 1 次提交
  8. 23 10月, 2008 2 次提交
  9. 23 7月, 2008 1 次提交
    • V
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum 提交于
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  10. 17 4月, 2008 4 次提交
  11. 30 1月, 2008 2 次提交
    • J
      x86, 32-bit: trim memory not covered by wb mtrrs · 99fc8d42
      Jesse Barnes 提交于
      On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all
      available RAM, meaning the last few megs (or even gigs) of memory will be
      marked uncached.  Since Linux tends to allocate from high memory addresses
      first, this causes the machine to be unusably slow as soon as the kernel
      starts really using memory (i.e.  right around init time).
      
      This patch works around the problem by scanning the MTRRs at boot and
      figuring out whether the current end_pfn value (setup by early e820 code)
      goes beyond the highest WB MTRR range, and if so, trimming it to match.  A
      fairly obnoxious KERN_WARNING is printed too, letting the user know that
      not all of their memory is available due to a likely BIOS bug.
      
      Something similar could be done on i386 if needed, but the boot ordering
      would be slightly different, since the MTRR code on i386 depends on the
      boot_cpu_data structure being setup.
      
      This patch fixes a bug in the last patch that caused the code to run on
      non-Intel machines (AMD machines apparently don't need it and it's untested
      on other non-Intel machines, so best keep it off).
      
      Further enhancements and fixes from:
      
        Yinghai Lu <Yinghai.Lu@Sun.COM>
        Andi Kleen <ak@suse.de>
      Signed-off-by: NJesse Barnes <jesse.barnes@intel.com>
      Tested-by: NJustin Piszcz <jpiszcz@lucidpixels.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      99fc8d42
    • P
      x86: mtrr use type bool [RESEND AGAIN] · 2d2ee8de
      Paul Jimenez 提交于
      This is a janitorish patch to 1) remove private TRUE/FALSE #def's in
      favor of using the standard enum from linux/stddef.h and 2) switch the
      variables holding those values to type 'bool' (from linux/types.h)
      since it both seems more appropriate and allows for potentially better
      optimization.
      
      As a truly minor aside, I removed a couple of comments documenting
      a 'do_safe' parameter that seems to no longer exist.
      Signed-off-by: NPaul Jimenez <pj@place.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2d2ee8de
  12. 24 10月, 2007 1 次提交
  13. 11 10月, 2007 1 次提交