1. 03 3月, 2014 1 次提交
  2. 25 12月, 2013 3 次提交
  3. 18 12月, 2013 1 次提交
  4. 27 8月, 2013 1 次提交
    • D
      drm: verify vma access in TTM+GEM drivers · acb46527
      David Herrmann 提交于
      GEM does already a good job in tracking access to gem buffers via handles
      and drm_vma access management. However, TTM drivers currently do not
      verify this during mmap().
      
      TTM provides the verify_access() callback to test this. So fix all drivers
      to actually call into gem+vma to verify access instead of always returning
      0.
      
      All drivers assume that user-space can only get access to TTM buffers via
      GEM handles. So whenever the verify_access() callback is called from
      ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
      true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
      TTM drivers (ie, vmwgfx).
      
      v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
          access was denied.
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      acb46527
  5. 20 5月, 2013 1 次提交
  6. 15 2月, 2013 1 次提交
  7. 05 2月, 2013 1 次提交
  8. 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
  9. 20 11月, 2012 2 次提交
  10. 21 9月, 2012 1 次提交
  11. 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
  12. 21 6月, 2012 3 次提交
  13. 23 5月, 2012 1 次提交
  14. 10 5月, 2012 1 次提交
  15. 03 5月, 2012 1 次提交
  16. 29 2月, 2012 1 次提交
  17. 06 1月, 2012 2 次提交
  18. 21 12月, 2011 3 次提交
  19. 06 12月, 2011 5 次提交
  20. 19 9月, 2011 1 次提交
  21. 22 8月, 2011 1 次提交
  22. 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
  23. 23 2月, 2011 3 次提交
  24. 19 2月, 2011 1 次提交
  25. 14 2月, 2011 1 次提交
  26. 28 1月, 2011 1 次提交