summaryrefslogtreecommitdiff
path: root/drivers/mailbox
diff options
context:
space:
mode:
authorTina Zhang <tina.zhang@intel.com>2018-01-15 09:41:42 +0300
committerRodrigo Vivi <rodrigo.vivi@intel.com>2018-02-01 18:31:58 +0300
commit412718a10926f77052d8107cb3c5d9dbc96cf8c9 (patch)
treef5c0b1dccd0d1a977e8d74e90c7d9793a0daa5b9 /drivers/mailbox
parentcc4f8fc72eb949889caa1d574d3db65fa9d71a12 (diff)
downloadlinux-412718a10926f77052d8107cb3c5d9dbc96cf8c9.tar.xz
drm/i915/gvt: Keep obj->dma_buf link NULL during exporting
According to commit (319c933c71f3dbdb2b3274d1634d3494c70efa06) Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 15 00:02:46 2013 +0200 drm/prime: proper locking+refcounting for obj->dma_buf link obj->dma_buf link should be reinstated at import time. Gvt-g dma-buf buffer exposeing might be simpler, as there won't be much racing during Gvt-g dma-buf exposing. In other words, Gvt-g dma-buf exposing can guarantee exposing happens before gem close ioctl, and Gvt-g is the only exporter of the guest framebuffer. But following the drm prime scheme can give Gvt-g a chance to increase a dma-buf reference count during importing. Otherwise, we have to increase the reference during exposing, which will break the case that the only reference userspace has held was through the dma-buf fd and the reference count is one. Signed-off-by: Tina Zhang <tina.zhang@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Hang Yuan <hang.yuan@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Diffstat (limited to 'drivers/mailbox')
0 files changed, 0 insertions, 0 deletions