1. 01 7月, 2016 2 次提交
  2. 29 3月, 2016 1 次提交
  3. 06 5月, 2015 1 次提交
    • A
      x86/gart: Check for GART support before accessing GART registers · 1b457429
      Aravind Gopalakrishnan 提交于
      GART registers are not present in newer AMD processors (Fam15h, Model
      10h and later). So, avoid accessing those in PCI config space by
      returning early in early_gart_iommu_check() and gart_iommu_hole_init()
      if GART is not available.
      
      Current code doesn't break on existing processors but there are some
      side effects:
      
      We get bogus AGP aperture messages which are simply noise on
      GART-less processors:
      
        AGP: Node 0: aperture [bus addr 0x00000000-0x01ffffff] (32MB)
        AGP: Your BIOS doesn't leave aperture memory hole
        AGP: Please enable the IOMMU option in the BIOS setup
        AGP: This costs you 64MB of RAM
        AGP: Mapping aperture over RAM [mem 0xd4000000-0xd7ffffff]
      
      We can avoid calling allocate_aperture() and would not have to
      wastefully reserve 64MB of RAM with memblock_reserve(). Also, we can
      avoid having to loop through all PCI buses and devices twice, searching
      for a non-existent AGP bridge if we bail out early.
      
      Refactor the family check used in amd_nb.c into an inline function so we
      can use it here as well as in amd_nb.c
      
      Fix some typos while at it.
      
      Tested the patch on Fam10h and Fam15h Model 00h-fh and this code runs
      fine. On Fam15h Model 60h-6fh and on Fam16h, we bail early as they don't
      have GART.
      Signed-off-by: NAravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Joerg Rodel <joro@8bytes.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1428443197-3834-1-git-send-email-Aravind.Gopalakrishnan@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1b457429
  4. 20 10月, 2014 1 次提交
  5. 28 2月, 2014 1 次提交
  6. 25 1月, 2014 1 次提交
  7. 12 8月, 2013 1 次提交
  8. 19 4月, 2013 1 次提交
  9. 11 3月, 2013 1 次提交
  10. 07 6月, 2012 1 次提交
  11. 06 6月, 2012 1 次提交
  12. 07 1月, 2012 1 次提交
  13. 21 12月, 2011 1 次提交
  14. 31 3月, 2011 1 次提交
  15. 17 3月, 2011 1 次提交
  16. 03 3月, 2011 1 次提交
  17. 10 2月, 2011 1 次提交
  18. 08 2月, 2011 1 次提交
    • H
      x86, amd: Support L3 Cache Partitioning on AMD family 0x15 CPUs · cabb5bd7
      Hans Rosenfeld 提交于
      L3 Cache Partitioning allows selecting which of the 4 L3 subcaches can be used
      for evictions by the L2 cache of each compute unit. By writing a 4-bit
      hexadecimal mask into the the sysfs file
      /sys/devices/system/cpu/cpuX/cache/index3/subcaches, the user can set the
      enabled subcaches for a CPU.
      
      The settings are directly read from and written to the hardware, so there is no
      way to have contradicting settings for two CPUs belonging to the same compute
      unit. Writing will always overwrite any previous setting for a compute unit.
      Signed-off-by: NHans Rosenfeld <hans.rosenfeld@amd.com>
      Cc: <Andreas.Herrmann3@amd.com>
      LKML-Reference: <1297098639-431383-1-git-send-email-hans.rosenfeld@amd.com>
      [ -v3: minor style fixes ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cabb5bd7
  19. 26 1月, 2011 2 次提交
  20. 11 1月, 2011 1 次提交
    • J
      x86: Use PCI method for enabling AMD extended config space before MSR method · 24d9b70b
      Jan Beulich 提交于
      While both methods should work equivalently well for the native
      case, the Xen Dom0 case can't reliably work with the MSR one,
      since there's no guarantee that the virtual CPUs it has
      available fully cover all necessary physical ones.
      
      As per the suggestion of Robert Richter the patch only adds the
      PCI method, but leaves the MSR one as a fallback to cover new
      systems the PCI IDs of which may not have got added to the code
      base yet.
      
      The only change in v2 is the breaking out of the new CPI
      initialization method into a separate function, as requested by
      Ingo.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Acked-by: NRobert Richter <robert.richter@amd.com>
      Cc: Andreas Herrmann3 <Andreas.Herrmann3@amd.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      LKML-Reference: <4D2B3FD7020000780002B67D@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      24d9b70b
  21. 18 11月, 2010 3 次提交
  22. 02 10月, 2010 1 次提交
  23. 21 9月, 2010 1 次提交
  24. 18 9月, 2010 1 次提交
  25. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  26. 13 3月, 2010 1 次提交
    • B
      x86, k8 nb: Fix boot crash: enable k8_northbridges unconditionally on AMD systems · 0e152cd7
      Borislav Petkov 提交于
      de957628 changed setting of the
      x86_init.iommu.iommu_init function ptr only when GART IOMMU is
      found.
      
      One side effect of it is that num_k8_northbridges
      is not initialized anymore if not explicitly
      called. This resulted in uninitialized pointers in
      <arch/x86/kernel/cpu/intel_cacheinfo.c:amd_calc_l3_indices()>,
      for example, which uses the num_k8_northbridges thing through
      node_to_k8_nb_misc().
      
      Fix that through an initcall that runs right after the PCI
      subsystem and does all the scanning. Then, remove initialization
      in gart_iommu_init() which is a rootfs_initcall and we're
      running before that.
      
      What is more, since num_k8_northbridges is being used in other
      places beside GART IOMMU, include it whenever we add AMD CPU
      support. The previous dependency chain in kconfig contained
      
      K8_NB depends on AGP_AMD64|GART_IOMMU
      
      which was clearly incorrect. The more natural way in terms of
      hardware dependency should be
      
      AGP_AMD64|GART_IOMMU depends on K8_NB depends on CPU_SUP_AMD &&
      PCI. Make it so Number One!
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      LKML-Reference: <20100312144303.GA29262@aftab>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NJoerg Roedel <joerg.roedel@amd.com>
      0e152cd7
  27. 29 10月, 2008 1 次提交
    • J
      x86, gart: fix gart detection for Fam11h CPUs · 87c6f401
      Joerg Roedel 提交于
      Impact: fix AMD Family 11h boot hangs / USB device problems
      
      The AMD Fam11h CPUs have a K8 northbridge. This northbridge is different
      from other family's because it lacks GART support (as I just learned).
      
      But the kernel implicitly expects a GART if it finds an AMD northbridge.
      
      Fix this by removing the Fam11h northbridge id from the scan list of K8
      northbridges. This patch also changes the message in the GART driver
      about missing K8 northbridges to tell that the GART is missing which is
      the correct information in this case.
      Reported-by: NJouni Malinen <jkmalinen@gmail.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      87c6f401
  28. 06 9月, 2008 1 次提交
  29. 11 10月, 2007 1 次提交
  30. 24 5月, 2007 1 次提交
  31. 17 4月, 2007 1 次提交
  32. 27 6月, 2006 1 次提交
    • A
      [PATCH] x86_64: Clean and enhance up K8 northbridge access code · a32073bf
      Andi Kleen 提交于
       - Factor out the duplicated access/cache code into a single file
         * Shared between i386/x86-64.
       - Share flush code between AGP and IOMMU
         * Fix a bug: AGP didn't wait for end of flush before
       - Drop 8 northbridges limit and allocate dynamically
       - Add lock to serialize AGP and IOMMU GART flushes
       - Add PCI ID for next AMD northbridge
       - Random related cleanups
      
      The old K8 NUMA discovery code is unchanged. New systems
      should all use SRAT for this.
      
      Cc: "Navin Boppuri" <navin.boppuri@newisys.com>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a32073bf