1. 20 5月, 2013 1 次提交
  2. 15 2月, 2013 1 次提交
  3. 05 2月, 2013 1 次提交
  4. 10 12月, 2012 1 次提交
    • M
      drm/ttm: remove no_wait_reserve, v3 · 97a875cb
      Maarten Lankhorst 提交于
      All items on the lru list are always reservable, so this is a stupid
      thing to keep. Not only that, it is used in a way which would
      guarantee deadlocks if it were ever to be set to block on reserve.
      
      This is a lot of churn, but mostly because of the removal of the
      argument which can be nested arbitrarily deeply in many places.
      
      No change of code in this patch except removal of the no_wait_reserve
      argument, the previous patch removed the use of no_wait_reserve.
      
      v2:
       - Warn if -EBUSY is returned on reservation, all objects on the list
         should be reservable. Adjusted patch slightly due to conflicts.
      v3:
       - Focus on no_wait_reserve removal only.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      97a875cb
  5. 20 11月, 2012 2 次提交
  6. 21 9月, 2012 1 次提交
  7. 25 7月, 2012 1 次提交
    • I
      drm: track dev_mapping in more robust and flexible way · 949c4a34
      Ilija Hadzic 提交于
      Setting dev_mapping (pointer to the address_space structure
      used for memory mappings) to the address_space of the first
      opener's inode and then failing if other openers come in
      through a different inode has a few restrictions that are
      eliminated by this patch.
      
      If we already have valid dev_mapping and we spot an opener
      with different i_node, we force its i_mapping pointer to the
      already established address_space structure (first opener's
      inode). This will make all mappings from drm device hang off
      the same address_space object.
      
      Some benefits (things that now work and didn't work
      before) of this patch are:
      
       * user space can mknod and use any number of device
         nodes and they will all work fine as long as the major
         device number is that of the drm module.
       * user space can even remove the first opener's device
         nodes and mknod the new one and the applications and
         windowing system will still work.
       * GPU drivers can safely assume that dev->dev_mapping is
         correct address_space and just blindly copy it
         into their (private) bdev.dev_mapping
      
      For reference, some discussion that lead to this patch can
      be found here:
      
      http://lists.freedesktop.org/archives/dri-devel/2012-April/022283.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      949c4a34
  8. 21 6月, 2012 3 次提交
  9. 23 5月, 2012 1 次提交
  10. 10 5月, 2012 1 次提交
  11. 03 5月, 2012 1 次提交
  12. 29 2月, 2012 1 次提交
  13. 06 1月, 2012 2 次提交
  14. 21 12月, 2011 3 次提交
  15. 06 12月, 2011 5 次提交
  16. 19 9月, 2011 1 次提交
  17. 22 8月, 2011 1 次提交
  18. 14 3月, 2011 1 次提交
    • D
      drm/radeon: fix problem with changing active VRAM size. (v2) · 53595338
      Dave Airlie 提交于
      So we used to use lpfn directly to restrict VRAM when we couldn't
      access the unmappable area, however this was removed in
      93225b0d as it also restricted
      the gtt placements. However it was only later noticed that this
      broke on some hw.
      
      This removes the active_vram_size, and just explicitly sets it
      when it changes, TTM/drm_mm will always use the real_vram_size,
      and the active vram size will change the TTM size used for lpfn
      setting.
      
      We should re-work the fpfn/lpfn to per-placement at some point
      I suspect, but that is too late for this kernel.
      
      Hopefully this addresses:
      https://bugs.freedesktop.org/show_bug.cgi?id=35254
      
      v2: fix reported useful VRAM size to userspace to be correct.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      53595338
  19. 23 2月, 2011 3 次提交
  20. 19 2月, 2011 1 次提交
  21. 14 2月, 2011 1 次提交
  22. 28 1月, 2011 1 次提交
  23. 18 11月, 2010 1 次提交
  24. 09 11月, 2010 1 次提交
  25. 05 10月, 2010 2 次提交
  26. 23 9月, 2010 1 次提交
  27. 04 8月, 2010 1 次提交