1. 07 4月, 2011 1 次提交
    • H
      x86, hibernate: Initialize mmu_cr4_features during boot · 4da9484b
      H. Peter Anvin 提交于
      Restore the initialization of mmu_cr4_features during boot, which was
      removed without comment in checkin e5f15b45
      
      x86: Cleanup highmap after brk is concluded
      
      thereby breaking resume from hibernate.  This restores previous
      functionality in approximately the same place, and corrects the
      reading of %cr4 on pre-CPUID hardware (%cr4 exists if and only if
      CPUID is supported.)
      
      However, part of the problem is that the hibernate suspend/resume
      sequence should manage the save/restore of %cr4 explicitly.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <201104020154.57136.rjw@sisk.pl>
      4da9484b
  2. 04 4月, 2011 2 次提交
  3. 01 4月, 2011 1 次提交
  4. 31 3月, 2011 2 次提交
    • B
      x86, amd-nb: Rename CPU PCI id define for F4 · cb6c8520
      Borislav Petkov 提交于
      With increasing number of PCI function ids, add the PCI function
      id in the define name instead of its symbolic name in the BKDG
      for more clarity. This renames function 4 define.
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      LKML-Reference: <20110330183447.GA3668@aftab>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cb6c8520
    • I
      sound: Add delay.h to sound/soc/codecs/sn95031.c · 438008af
      Ingo Molnar 提交于
      This is further fallout from delay.h removal from asm/apic.h and asm/dma.h:
      
        ca444564: x86: Stop including <linux/delay.h> in two asm header files
      
      Which caused this build failure:
      
        sound/soc/codecs/sn95031.c: In function ‘sn95031_get_mic_bias’:
        sound/soc/codecs/sn95031.c:153:2: error: implicit declaration of function ‘msleep’ [-Werror=implicit-function-declaration]
      
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: James E.J. Bottomley <James.Bottomley@suse.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20110325152014.297890ec@endymion.delvare>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      438008af
  5. 30 3月, 2011 1 次提交
    • S
      x86, mtrr, pat: Fix one cpu getting out of sync during resume · 84ac7cdb
      Suresh Siddha 提交于
      On laptops with core i5/i7, there were reports that after resume
      graphics workloads were performing poorly on a specific AP, while
      the other cpu's were ok. This was observed on a 32bit kernel
      specifically.
      
      Debug showed that the PAT init was not happening on that AP
      during resume and hence it contributing to the poor workload
      performance on that cpu.
      
      On this system, resume flow looked like this:
      
      1. BP starts the resume sequence and we reinit BP's MTRR's/PAT
         early on using mtrr_bp_restore()
      
      2. Resume sequence brings all AP's online
      
      3. Resume sequence now kicks off the MTRR reinit on all the AP's.
      
      4. For some reason, between point 2 and 3, we moved from BP
         to one of the AP's. My guess is that printk() during resume
         sequence is contributing to this. We don't see similar
         behavior with the 64bit kernel but there is no guarantee that
         at this point the remaining resume sequence (after AP's bringup)
         has to happen on BP.
      
      5. set_mtrr() was assuming that we are still on BP and skipped the
         MTRR/PAT init on that cpu (because of 1 above)
      
      6. But we were on an AP and this led to not reprogramming PAT
         on this cpu leading to bad performance.
      
      Fix this by doing unconditional mtrr_if->set_all() in set_mtrr()
      during MTRR/PAT init. This might be unnecessary if we are still
      running on BP. But it is of no harm and will guarantee that after
      resume, all the cpu's will be in sync with respect to the
      MTRR/PAT registers.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <1301438292-28370-1-git-send-email-eric@anholt.net>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Tested-by: NKeith Packard <keithp@keithp.com>
      Cc: stable@kernel.org	[v2.6.32+]
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      84ac7cdb
  6. 29 3月, 2011 27 次提交
  7. 28 3月, 2011 6 次提交