1. 03 8月, 2009 2 次提交
  2. 19 6月, 2009 1 次提交
  3. 20 4月, 2009 1 次提交
  4. 21 8月, 2008 3 次提交
  5. 15 8月, 2008 1 次提交
  6. 12 8月, 2008 2 次提交
  7. 26 6月, 2008 1 次提交
  8. 19 6月, 2008 3 次提交
  9. 19 2月, 2008 1 次提交
    • A
      fix historic ioremap() abuse in AGP · fcea424d
      Arjan van dev Ven 提交于
      Several AGP drivers right now use ioremap_nocache() on kernel ram in order
      to turn a page of regular memory uncached.
      
      There are two problems with this:
      
          1) This is a total nightmare for the ioremap() implementation to keep
             various mappings of the same page coherent.
      
          2) It's a total nightmare for the AGP code since it adds a ton of
             complexity in terms of keeping track of 2 different pointers to
             the same thing, in terms of error handling etc etc.
      
      This patch fixes this by making the AGP drivers use the new
      set_memory_XX APIs instead.
      
      Note: amd-k7-agp.c is built on Alpha too, and generic.c is built
      on ia64 as well, which do not yet have the set_memory_*() APIs,
      so for them some we have a few ugly #ifdefs - hopefully they'll
      be fixed soon.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      fcea424d
  10. 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
  11. 30 1月, 2008 1 次提交
  12. 15 10月, 2007 1 次提交
  13. 27 7月, 2007 1 次提交
  14. 22 5月, 2007 1 次提交
    • A
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan 提交于
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      
      Cross-compile tested on
      
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	arm
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	m68k
      	mips
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	um-x86_64
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      
      as well as my two usual configs.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8edc6e0
  15. 27 4月, 2007 1 次提交
  16. 23 2月, 2007 1 次提交
  17. 11 2月, 2007 1 次提交
  18. 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
  19. 23 12月, 2006 1 次提交
    • T
      [AGPGART] Remove unnecessary flushes when inserting and removing pages. · 5aa80c72
      Thomas Hellstrom 提交于
      This patch is to speed up flipping of pages in and out of the AGP aperture as
      needed by the new drm memory manager.
      
      A number of global cache flushes are removed as well as some PCI posting flushes.
      The following guidelines have been used:
      
      1) Memory that is only mapped uncached and that has been subject to a global
      cache flush after the mapping was changed to uncached does not need any more
      cache flushes. Neither before binding to the aperture nor after unbinding.
      
      2) Only do one PCI posting flush after a sequence of writes modifying page
      entries in the GATT.
      Signed-off-by: NThomas Hellstrom <thomas@tungstengraphics.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      5aa80c72
  20. 23 11月, 2006 1 次提交
    • L
      [AGP] Allocate AGP pages with GFP_DMA32 by default · 66c669ba
      Linus Torvalds 提交于
      Not all graphic page remappers support physical addresses over the 4GB
      mark for remapping, so while some do (the AMD64 GART always did, and I
      just fixed the i965 to do so properly), we're safest off just forcing
      GFP_DMA32 allocations to make sure graphics pages get allocated in the
      low 32-bit address space by default.
      
      AGP sub-drivers that really care, and can do better, could just choose
      to implement their own allocator (or we could add another "64-bit safe"
      default allocator for their use), but quite frankly, you're not likely
      to care in practice.
      
      So for now, this trivial change means that we won't be allocating pages
      that we can't map correctly by mistake on x86-64.
      
      [ On traditional 32-bit x86, this could never happen, because GFP_KERNEL
        would never allocate any highmem memory anyway ]
      Acked-by: NAndi Kleen <ak@suse.de>
      Acked-by: NDave Jones <davej@redhat.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      66c669ba
  21. 04 11月, 2006 1 次提交
    • D
      [AGPGART] Fix up misprogrammed bridges with incorrect AGPv2 rates. · 28af24bb
      Dave Jones 提交于
      Some dumb bridges are programmed to disobey the AGP2 spec.
      This is likely a BIOS misprogramming rather than poweron default, or
      it would be a lot more common.
      
      AGPv2 spec 6.1.9 states:
      
       "The RATE field indicates the data transfer rates supported by this
        device. A.G.P. devices must report all that apply."
      
      Fix them up as best we can.
      
      This will prevent errors like..
      
      agpgart: Found an AGP 3.5 compliant device at 0000:00:00.0.
      agpgart: req mode 1f000201 bridge_agpstat 1f000a14 vga_agpstat 2f000217.
      agpgart: Device is in legacy mode, falling back to 2.x
      agpgart: Putting AGP V2 device at 0000:00:00.0 into 0x mode
      agpgart: Putting AGP V2 device at 0000:01:00.0 into 0x mode
      agpgart: Putting AGP V2 device at 0000:01:00.1 into 0x mode
      
      https://bugs.freedesktop.org/show_bug.cgi?id=8816Signed-off-by: NDave Jones <davej@redhat.com>
      28af24bb
  22. 29 9月, 2006 1 次提交
  23. 11 9月, 2006 1 次提交
    • D
      [AGPGART] Rework AGPv3 modesetting fallback. · edf03fb0
      Dave Jones 提交于
      Sometimes the logic to handle AGPx8->AGPx4 fallback failed, as can
      be seen in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197346
      
      The failures occured if the bridge was in AGPx8 mode, but the
      user hadn't specified a mode in their X config.  We weren't
      setting the mode to the highest mode capable by the video card+bridge
      (as we do in the AGPv2 case), which was leading to all kinds of
      mayhem including us believing that after falling back from AGPx8, that
      we couldn't do x4 mode (which is disastrous in AGPv3, as those are
      the only two modes possible).
      Signed-off-by: NDave Jones <davej@redhat.com>
      edf03fb0
  24. 01 7月, 2006 1 次提交
  25. 31 5月, 2006 1 次提交
  26. 28 2月, 2006 1 次提交
  27. 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
  28. 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
  29. 05 11月, 2005 1 次提交
  30. 21 10月, 2005 1 次提交
  31. 18 8月, 2005 1 次提交
  32. 12 8月, 2005 1 次提交
  33. 08 6月, 2005 2 次提交
    • D
      [PATCH] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0). · 66bb8bf8
      David Mosberger 提交于
      [AGPGART] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0).
      
      As mentioned earlier, the current check_bridge_mode() code assumes
      that AGP bridges are PCI devices.  This isn't always true.  Definitely
      not for HP zx1 chipset and the same seems to be the case for SGI's AGP
      bridge.
      
      The patch below fixes the problem by picking up the AGP_MODE_3_0 bit
      from bridge->mode.  I feel like I may be missing something, since I
      can't see any reason why check_bridge_mode() wasn't doing that in the
      first place.  According to the AGP 3.0 specs, the AGP_MODE_3_0 bit is
      determined during the hardware reset and cannot be changed, so it
      seems to me it should be safe to pick it up from bridge->mode.
      
      With the patch applied, I can definitely use AGP acceleration both
      with AGP 2.0 and AGP 3.0 (one with an Nvidia card, the other with an
      ATI FireGL card).
      
      Unless someone spots a problem, please apply this patch so 3d
      acceleration can work on zx1 boxes again.
      
      This makes AGP work again on machines with an AGP bridge that isn't a
      PCI device.
      Signed-off-by: NDavid Mosberger-Tang <davidm@hpl.hp.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      66bb8bf8
    • 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