1. 18 Jun, 2008 1 commit
    • Jan Beulich's avatar
      agp: two-stage page destruction issue · da503fa6
      Jan Beulich authored
      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.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  2. 18 Feb, 2008 1 commit
    • Arjan van dev Ven's avatar
      fix historic ioremap() abuse in AGP · fcea424d
      Arjan van dev Ven authored
      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: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
  3. 04 Feb, 2008 1 commit
    • Dave Airlie's avatar
      agp: add chipset flushing support to AGP interface · a13af4b4
      Dave Airlie authored
      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: default avatarDave Airlie <airlied@redhat.com>
  4. 30 Jan, 2008 1 commit
  5. 14 Oct, 2007 1 commit
  6. 26 Jul, 2007 1 commit
  7. 21 May, 2007 1 commit
    • Alexey Dobriyan's avatar
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan authored
      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
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      as well as my two usual configs.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 26 Apr, 2007 1 commit
  9. 22 Feb, 2007 1 commit
  10. 10 Feb, 2007 1 commit
  11. 03 Feb, 2007 1 commit
    • Thomas Hellstrom's avatar
      [AGPGART] Allow drm-populated agp memory types · a030ce44
      Thomas Hellstrom authored
      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: default avatarThomas Hellstrom <thomas@tungstengraphics.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  12. 22 Dec, 2006 1 commit
    • Thomas Hellstrom's avatar
      [AGPGART] Remove unnecessary flushes when inserting and removing pages. · 5aa80c72
      Thomas Hellstrom authored
      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: default avatarThomas Hellstrom <thomas@tungstengraphics.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  13. 22 Nov, 2006 1 commit
    • Linus Torvalds's avatar
      [AGP] Allocate AGP pages with GFP_DMA32 by default · 66c669ba
      Linus Torvalds authored
      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: default avatarAndi Kleen <ak@suse.de>
      Acked-by: default avatarDave Jones <davej@redhat.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  14. 03 Nov, 2006 1 commit
    • Dave Jones's avatar
      [AGPGART] Fix up misprogrammed bridges with incorrect AGPv2 rates. · 28af24bb
      Dave Jones authored
      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
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  15. 28 Sep, 2006 1 commit
  16. 10 Sep, 2006 1 commit
    • Dave Jones's avatar
      [AGPGART] Rework AGPv3 modesetting fallback. · edf03fb0
      Dave Jones authored
      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: default avatarDave Jones <davej@redhat.com>
  17. 30 Jun, 2006 1 commit
  18. 30 May, 2006 1 commit
  19. 27 Feb, 2006 1 commit
  20. 09 Nov, 2005 1 commit
    • Linus Torvalds's avatar
      Fix AGP compile on non-x86 architectures · 6730c3c1
      Linus Torvalds authored
      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: default avatarLinus Torvalds <torvalds@osdl.org>
  21. 08 Nov, 2005 1 commit
    • Alan Hourihane's avatar
      [PATCH] AGP performance fixes · 88d51967
      Alan Hourihane authored
      AGP allocation/deallocation is suffering major performance issues due to
      the nature of global_flush_tlb() being called on every change_page_attr()
      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
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
  22. 04 Nov, 2005 1 commit
  23. 20 Oct, 2005 1 commit
  24. 18 Aug, 2005 1 commit
  25. 11 Aug, 2005 1 commit
  26. 07 Jun, 2005 2 commits
    • David Mosberger's avatar
      [PATCH] Replace check_bridge_mode() with (bridge->mode & AGSTAT_MODE_3_0). · 66bb8bf8
      David Mosberger authored
      [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
      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: default avatarDavid Mosberger-Tang <davidm@hpl.hp.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
    • Keir Fraser's avatar
      [PATCH] AGP fix for Xen VMM · 07eee78e
      Keir Fraser authored
      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: default avatarKeir Fraser <keir@xensource.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  27. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!