1. 06 Jan, 2006 2 commits
  2. 05 Jan, 2006 5 commits
  3. 04 Jan, 2006 2 commits
  4. 03 Jan, 2006 3 commits
  5. 01 Jan, 2006 1 commit
  6. 29 Dec, 2005 2 commits
    • Linus Torvalds's avatar
      Revert radeon AGP aperture offset changes · 392c14be
      Linus Torvalds authored
      This reverts the series of commits
      that changed the GART VM start offset.  It fixed some machines, but
      seems to continually interact badly with some X versions.
      Quoth Ben Herrenschmidt:
        "So I think at this point, the best is that we keep the old bogus code
         that at least is consistent with the bug in the server. I'm working on a
         big patch to X that reworks the memory map stuff completely and fixes
         those issues on the server side, I'll do a DRM patch matching this X fix
         as well so that the memory map is only ever set in one place and with
         what I hope is a correct algorithm..."
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Dave Jones's avatar
      [PATCH] fix ia64 compile failure with gcc4.1 · ee025949
      Dave Jones authored
      __get_unaligned creates a typeof the var its passed, and writes to it,
      which on gcc4.1, spits out the following error:
      drivers/char/vc_screen.c: In function 'vcs_write':
      drivers/char/vc_screen.c:422: error: assignment of read-only variable 'val'
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      [ The "right" fix would be to try to fix <asm-generic/unaligned.h>
        but that's hard to do with the tools gcc gives us. So this
        simpler patch is preferable -- Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  7. 28 Dec, 2005 1 commit
    • Benjamin Herrenschmidt's avatar
      [PATCH] Fix more radeon GART start calculation cases · 67dbb4ea
      Benjamin Herrenschmidt authored
      As reported by Jules Villard <jvillard@ens-lyon.fr> and some others, the
      recent GART aperture start reconfiguration causes problems on some
      What I _think_ might be happening is that the X server is also trying to
      muck around with the card memory map and is forcing it back into a wrong
      setting that also happens to no longer match what the DRM wants to do
      and blows up.  There are bugs all over the place in that code (and still
      some bugs in the DRM as well anyway).
      This patch attempts to avoid that by using the largest of the 2 values,
      which I think will cause it to behave as it used to for you and will
      still fix the problem with machines that have an aperture size smaller
      than the video memory.
      Acked-by: default avatarJules Villard <jvillard@ens-lyon.fr>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  8. 23 Dec, 2005 1 commit
  9. 19 Dec, 2005 2 commits
  10. 16 Dec, 2005 2 commits
  11. 15 Dec, 2005 5 commits
  12. 13 Dec, 2005 1 commit
  13. 12 Dec, 2005 2 commits
  14. 05 Dec, 2005 1 commit
  15. 30 Nov, 2005 1 commit
  16. 28 Nov, 2005 1 commit
    • Linus Torvalds's avatar
      mm: re-architect the VM_UNPAGED logic · 6aab341e
      Linus Torvalds authored
      This replaces the (in my opinion horrible) VM_UNMAPPED logic with very
      explicit support for a "remapped page range" aka VM_PFNMAP.  It allows a
      VM area to contain an arbitrary range of page table entries that the VM
      never touches, and never considers to be normal pages.
      Any user of "remap_pfn_range()" automatically gets this new
      functionality, and doesn't even have to mark the pages reserved or
      indeed mark them any other way.  It just works.  As a side effect, doing
      mmap() on /dev/mem works for arbitrary ranges.
      Sparc update from David in the next commit.
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  17. 24 Nov, 2005 1 commit
    • Dave Airlie's avatar
      drm: fix quiescent locking · cf65f162
      Dave Airlie authored
      A fix for a locking bug which is triggered when a client tries to lock with
      flag DMA_QUIESCENT (typically the X server), but gets interrupted by a signal.
      The locking IOCTL should then return an error, but if DMA_QUIESCENT succeeds
      it returns 0, and the client falsely thinks it has the lock. In addition
      The client waits for DMA_QUISCENT and possibly DMA_READY without having the lock.
      From: Thomas Hellstrom
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
  18. 23 Nov, 2005 3 commits
  19. 22 Nov, 2005 1 commit
  20. 21 Nov, 2005 1 commit
  21. 18 Nov, 2005 2 commits