1. 07 1月, 2006 4 次提交
  2. 06 1月, 2006 4 次提交
  3. 05 1月, 2006 3 次提交
  4. 04 1月, 2006 2 次提交
  5. 03 1月, 2006 1 次提交
  6. 02 1月, 2006 1 次提交
  7. 30 12月, 2005 2 次提交
    • L
      Revert radeon AGP aperture offset changes · 392c14be
      Linus Torvalds 提交于
      This reverts the series of commits
      
      	67dbb4ea
      	281ab031
      	47807ce3
      
      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: NLinus Torvalds <torvalds@osdl.org>
      392c14be
    • D
      [PATCH] fix ia64 compile failure with gcc4.1 · ee025949
      Dave Jones 提交于
      __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: NDave 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: NLinus Torvalds <torvalds@osdl.org>
      ee025949
  8. 28 12月, 2005 1 次提交
    • B
      [PATCH] Fix more radeon GART start calculation cases · 67dbb4ea
      Benjamin Herrenschmidt 提交于
      As reported by Jules Villard <jvillard@ens-lyon.fr> and some others, the
      recent GART aperture start reconfiguration causes problems on some
      setups.
      
      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: NJules Villard <jvillard@ens-lyon.fr>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      67dbb4ea
  9. 23 12月, 2005 1 次提交
  10. 20 12月, 2005 1 次提交
  11. 19 12月, 2005 1 次提交
  12. 17 12月, 2005 1 次提交
  13. 16 12月, 2005 6 次提交
  14. 13 12月, 2005 3 次提交
  15. 05 12月, 2005 1 次提交
  16. 01 12月, 2005 1 次提交
  17. 29 11月, 2005 1 次提交
    • L
      mm: re-architect the VM_UNPAGED logic · 6aab341e
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@osdl.org>
      6aab341e
  18. 24 11月, 2005 1 次提交
    • D
      drm: fix quiescent locking · cf65f162
      Dave Airlie 提交于
      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: NDave Airlie <airlied@linux.ie>
      cf65f162
  19. 23 11月, 2005 4 次提交
  20. 21 11月, 2005 1 次提交