1. 27 1月, 2012 1 次提交
  2. 15 9月, 2011 1 次提交
  3. 21 9月, 2010 1 次提交
  4. 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
  5. 11 1月, 2010 1 次提交
  6. 22 9月, 2009 1 次提交
  7. 03 8月, 2009 5 次提交
  8. 19 6月, 2009 1 次提交
  9. 21 10月, 2008 1 次提交
  10. 12 8月, 2008 2 次提交
  11. 19 6月, 2008 1 次提交
    • J
      agp: two-stage page destruction issue · da503fa6
      Jan Beulich 提交于
      besides it apparently being useful only in 2.6.24 (the changes in 2.6.25
      really mean that it could be converted back to a single-stage mechanism),
      I'm seeing an issue in Xen Dom0 kernels, which is caused by the calling
      of gart_to_virt() in the second stage invocations of the destroy function.
      I think that besides this being a real issue with Xen (where
      unmap_page_from_agp() is not just a page table attribute change), this
      also is invalid from a theoretical perspective: One should not assume that
      gart_to_virt() is still valid after unmapping a page. So minimally (keeping
      the 2-stage mechanism) a patch like the one below would be needed.
      
      Jan
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      da503fa6
  12. 05 2月, 2008 1 次提交
    • D
      agp: add chipset flushing support to AGP interface · a13af4b4
      Dave Airlie 提交于
      This bumps the AGP interface to 0.103.
      
      Certain Intel chipsets contains a global write buffer, and this can require
      flushing from the drm or X.org to make sure all data has hit RAM before
      initiating a GPU transfer, due to a lack of coherency with the integrated
      graphics device and this buffer.
      
      This just adds generic support to the AGP interfaces, a follow-on patch
      will add support to the Intel driver to use this interface.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a13af4b4
  13. 30 1月, 2008 1 次提交
  14. 15 10月, 2007 1 次提交
  15. 10 7月, 2007 1 次提交
    • D
      [AGPGART] Hand off AGP maintainence. · 70e8992e
      Dave Jones 提交于
      Most of the AGP changes recently have been done in lock-step with
      DRM updates, so it's probably easier to have airlied pushing
      AGP changes at the same time he does DRM updates.
      
      [Also remove my name from the boot messages.
       Cautionary tale to others: Never do this, when computers
       don't boot, people assume you're responsible even if 15
       other subsystems initialised after yours. :-) ]
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      70e8992e
  16. 04 2月, 2007 1 次提交
    • T
      [AGPGART] Allow drm-populated agp memory types · a030ce44
      Thomas Hellstrom 提交于
      This patch allows drm to populate an agpgart structure with pages of its own.
      It's needed for the new drm memory manager which dynamically flips pages in and out of AGP.
      
      The patch modifies the generic functions as well as the intel agp driver. The intel drm driver is
      currently the only one supporting the new memory manager.
      
      Other agp drivers may need some minor fixing up once they have a corresponding memory manager enabled drm driver.
      
      AGP memory types >= AGP_USER_TYPES are not populated by the agpgart driver, but the drm is expected
      to do that, as well as taking care of cache- and tlb flushing when needed.
      
      It's not possible to request these types from user space using agpgart ioctls.
      
      The Intel driver also gets a new memory type for pages that can be bound cached to the intel GTT.
      Signed-off-by: NThomas Hellstrom <thomas@tungstengraphics.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      a030ce44
  17. 12 8月, 2006 1 次提交
  18. 28 2月, 2006 1 次提交
  19. 17 11月, 2005 1 次提交
  20. 10 11月, 2005 1 次提交
    • L
      Fix AGP compile on non-x86 architectures · 6730c3c1
      Linus Torvalds 提交于
      AGP shouldn't use "global_flush_tlb()" to flush the AGP mappings, that i
      spurely an x86'ism.  The proper AGP mapping flusher that should be used
      is "flush_agp_mappings()", which on x86 obviously happens to do a global
      TLB flush.
      
      This makes AGP (or at least the config _I_ happen to use) compile again
      on ppc64.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6730c3c1
  21. 09 11月, 2005 1 次提交
    • A
      [PATCH] AGP performance fixes · 88d51967
      Alan Hourihane 提交于
      AGP allocation/deallocation is suffering major performance issues due to
      the nature of global_flush_tlb() being called on every change_page_attr()
      call.
      
      For small allocations this isn't really seen, but when you start allocating
      50000 pages of AGP space, for say, texture memory, then things can take
      seconds to complete.
      
      In some cases the situation is doubled or even quadrupled in the time due
      to SMP, or a deallocation, then a new reallocation.  I've had a case of
      upto 20 seconds wait time to deallocate and reallocate AGP space.
      
      This patch fixes the problem by making it the caller's responsibility to
      call global_flush_tlb(), and so removes it from every instance of mapping a
      page into AGP space until the time that all change_page_attr() changes are
      done.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      88d51967
  22. 21 10月, 2005 1 次提交
  23. 11 9月, 2005 1 次提交
  24. 08 6月, 2005 1 次提交
    • K
      [PATCH] AGP fix for Xen VMM · 07eee78e
      Keir Fraser 提交于
      When Linux is running on the Xen virtual machine monitor, physical
      addresses are virtualised and cannot be directly referenced by the AGP
      GART.  This patch fixes the GART driver for Xen by adding a layer of
      abstraction between physical addresses and 'GART addresses'.
      
      Architecture-specific functions are also defined for allocating and freeing
      the GATT.  Xen requires this to ensure that table really is contiguous from
      the point of view of the GART.
      
      These extra interface functions are defined as 'no-ops' for all existing
      architectures that use the GART driver.
      Signed-off-by: NKeir Fraser <keir@xensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      07eee78e
  25. 01 5月, 2005 1 次提交
  26. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4