1. 22 7月, 2014 1 次提交
  2. 16 3月, 2014 2 次提交
    • D
      drm: init TTM dev_mapping in ttm_bo_device_init() · 44d847b7
      David Herrmann 提交于
      With dev->anon_inode we have a global address_space ready for operation
      right from the beginning. Therefore, there is no need to do a delayed
      setup with TTM. Instead, set dev_mapping during initialization in
      ttm_bo_device_init() and remove any "if (dev_mapping)" conditions.
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      44d847b7
    • D
      drm: use anon-inode instead of relying on cdevs · 6796cb16
      David Herrmann 提交于
      DRM drivers share a common address_space across all character-devices of a
      single DRM device. This allows simple buffer eviction and mapping-control.
      However, DRM core currently waits for the first ->open() on any char-dev
      to mark the underlying inode as backing inode of the device. This delayed
      initialization causes ugly conditions all over the place:
        if (dev->dev_mapping)
          do_sth();
      
      To avoid delayed initialization and to stop reusing the inode of the
      char-dev, we allocate an anonymous inode for each DRM device and reset
      filp->f_mapping to it on ->open().
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      6796cb16
  3. 23 1月, 2014 1 次提交
  4. 18 12月, 2013 1 次提交
  5. 14 11月, 2013 2 次提交
  6. 09 10月, 2013 2 次提交
    • D
      drm: kill ->gem_init_object() and friends · 16eb5f43
      David Herrmann 提交于
      All drivers embed gem-objects into their own buffer objects. There is no
      reason to keep drm_gem_object_alloc(), gem->driver_private and
      ->gem_init_object() anymore.
      
      New drivers are highly encouraged to do the same. There is no benefit in
      allocating gem-objects separately.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Ben Skeggs <skeggsb@gmail.com>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      16eb5f43
    • D
      drm/nouveau: embed gem object in nouveau_bo · 55fb74ad
      David Herrmann 提交于
      There is no reason to keep the gem object separately allocated. nouveau is
      the last user of gem_obj->driver_private, so if we embed it, we can get
      rid of 8bytes per gem-object.
      
      The implementation follows the radeon driver. bo->gem is only valid, iff
      the bo was created via the gem helpers _and_ iff the user holds a valid
      gem reference. That is, as the gem object holds a reference to the
      nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
      guaranteed to also hold a gem reference. The gem object might get
      destroyed after the last user drops the gem-ref via
      drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
      gem-reference.
      
      For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
      valid. However, this shouldn't be used for real functionality to avoid
      gem-internal dependencies.
      
      Note that the implementation follows the previous style. However, we no
      longer can check for bo->gem != NULL to test for a valid gem object. This
      wasn't done before, so we should be safe now.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      55fb74ad
  7. 04 9月, 2013 1 次提交
  8. 25 7月, 2013 1 次提交
    • D
      drm/ttm: convert to unified vma offset manager · 72525b3f
      David Herrmann 提交于
      Use the new vma-manager infrastructure. This doesn't change any
      implementation details as the vma-offset-manager is nearly copied 1-to-1
      from TTM.
      
      The vm_lock is moved into the offset manager so we can drop it from TTM.
      During lookup, we use the vma locking helpers to take a reference to the
      found object.
      In all other scenarios, locking stays the same as before. We always
      guarantee that drm_vma_offset_remove() is called only during destruction.
      Hence, helpers like drm_vma_node_offset_addr() are always safe as long as
      the node has a valid offset.
      
      This also drops the addr_space_offset member as it is a copy of vm_start
      in vma_node objects. Use the accessor functions instead.
      
      v4:
       - remove vm_lock
       - use drm_vma_offset_lock_lookup() to protect lookup (instead of vm_lock)
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Martin Peres <martin.peres@labri.fr>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      72525b3f
  9. 10 7月, 2013 1 次提交
  10. 01 7月, 2013 1 次提交
  11. 28 6月, 2013 3 次提交
  12. 20 2月, 2013 2 次提交
  13. 08 2月, 2013 1 次提交
  14. 15 1月, 2013 2 次提交
  15. 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
  16. 03 10月, 2012 7 次提交
  17. 26 7月, 2012 1 次提交
  18. 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
  19. 24 5月, 2012 2 次提交
  20. 23 5月, 2012 1 次提交
  21. 22 3月, 2012 1 次提交
  22. 01 2月, 2012 1 次提交
    • B
      drm/nouveau/gem: fix fence_sync race / oops · 525895ba
      Ben Skeggs 提交于
      Due to a race it was possible for a fence to be destroyed while another
      thread was trying to synchronise with it.  If this happened in the fallback
      non-semaphore path, it lead to the following oops due to fence->channel
      being NULL.
      
      BUG: unable to handle kernel NULL pointer dereference at   (null)
      IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau]
      *pde = a649c067
      SMP
      Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]
      
      Pid: 2255, comm: gnome-shell Tainted: G           O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
      EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1
      EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
      EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
      ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
      Stack:
       7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
       00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
       00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
      Call Trace:
       [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
       [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau]
       [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
       [<fa964046>] validate_list+0x176/0x300 [nouveau]
       [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm]
       [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
       [<c0406481>] ? die+0x31/0x80
       [<f7c93d98>] drm_ioctl+0x388/0x490 [drm]
       [<c0406481>] ? die+0x31/0x80
       [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
       [<c0635c7b>] ? file_has_perm+0xcb/0xe0
       [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm]
       [<c0564f56>] do_vfs_ioctl+0x86/0x5b0
       [<c0406481>] ? die+0x31/0x80
       [<c0635f22>] ? selinux_file_ioctl+0x62/0x130
       [<c0554f30>] ? fget_light+0x30/0x340
       [<c05654ef>] sys_ioctl+0x6f/0x80
       [<c099e3a4>] syscall_call+0x7/0xb
       [<c0406481>] ? die+0x31/0x80
       [<c0406481>] ? die+0x31/0x80
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Cc: stable@vger.kernel.org
      525895ba
  23. 28 10月, 2011 1 次提交
  24. 01 9月, 2011 1 次提交
    • M
      drm/ttm: add a way to bo_wait for either the last read or last write · dfadbbdb
      Marek Olšák 提交于
      Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
      However, sometimes it would be more useful to be able to query whether
      a buffer is busy and being either read or written, and wait until it's stopped
      being either read or written. The point of this is to be able to avoid
      unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
      reading that buffer, and a CPU wants to map that buffer for read, it needs to
      only wait for the last write. If there were no write, there wouldn't be any
      waiting needed.
      
      This, or course, requires user space drivers to send read/write flags
      with each relocation (like we have read/write domains in radeon, so we can
      actually use those for something useful now).
      
      Now how this patch works:
      
      The read/write flags should passed to ttm_validate_buffer. TTM maintains
      separate sync objects of the last read and write for each buffer, in addition
      to the sync object of the last use of a buffer. ttm_bo_wait then operates
      with one the sync objects.
      Signed-off-by: NMarek Olšák <maraeo@gmail.com>
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dfadbbdb
  25. 27 6月, 2011 1 次提交
  26. 23 6月, 2011 1 次提交