Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 5月, 2013 8 次提交
  3. 01 5月, 2013 5 次提交
    • D
      drm/i915: fix dmabuf vmap support · b11b88ef
      由 Dave Airlie 提交于 
      Sometimes that extra semicolon can really be hard to spot.
Acked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      b11b88ef
    • I
      drm/prime: warn for non-empty handle lookup list during drm file release · 98b76231
      由 Imre Deak 提交于 
      drm_gem_release should release all handles connected to the drm file and
so should also release the prime lookup entries of these handles. So
just WARN if this isn't the case.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      98b76231
    • D
      udl: bind the framebuffer to the correct device. · 33896bf3
      由 Dave Airlie 提交于 
      This just moves the fb sysfs node beside the drm sysfs node which
I fixed before.

just noticed it in passing.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      33896bf3
    • I
      drm: prime: fix refcounting on the dmabuf import error path · 011c2282
      由 Imre Deak 提交于 
      In commit be8a42ae we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.

Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing the
bug this is also more logical.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      011c2282
    • D
      drm/prime: keep a reference from the handle to exported dma-buf (v6) · 219b4733
      由 Dave Airlie 提交于 
      Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object

i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close. The reference gets added at step 2,
but at step 6 we don't have enough info to clean it up.

The solution is to take a reference on the dma-buf when we export it,
and drop the reference when the gem handle goes away.

So when we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.

This patch isn't meant to fix any other problem or bikesheds, and it doesn't
fix any races with other scenarios.

v1.1: move export symbol line back up.

v2: okay I had to do a bit more, as the first patch showed a leak
on one of my tests, that I found using the dma-buf debugfs support,
the problem case is exporting a buffer twice with the same handle,
we'd add another export handle for it unnecessarily, however
we now fail if we try to export the same object with a different gem handle,
however I'm not sure if that is a case I want to support, and I've
gotten the code to WARN_ON if we hit something like that.

v2.1: rebase this patch, write better commit msg.
v3: cleanup error handling, track import vs export in linked list,
these two patches were separate previously, but seem to work better
like this.
v4: danvet is correct, this code is no longer useful, since the buffer
better exist, so remove it.
v5: always take a reference to the dma buf object, import or export.
(Imre Deak contributed this originally)
v6: square the circle, remove import vs export tracking now
that there is no difference
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      219b4733
  5. 30 4月, 2013 9 次提交
  7. 29 4月, 2013 12 次提交
  9. 27 4月, 2013 1 次提交
    • Z
      drm/i915: correct the calculation of first_pd_entry_in_global_pt · 43b27290
      由 Zhang, Xiong Y 提交于 
      When ppgtt is enabled, dev_priv->gtt.total has excluded the gtt space
occupied by ppgtt table in i915_gem_init_global_gtt() function. So the
calculation of first_pd_entry_in_global_pt doesn't need to subtract
I915_PPGTT_PD_ENTRIES again. Or else PPGTT directory table will be
destroyed by global gtt allocation.

This regression has been introduced in

commit a54c0c27
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jan 24 14:45:00 2013 -0800

    drm/i915: remove intel_gtt structure

The breakage is pretty subtile since the old gtt_total_entries
included the pde range, whereas the new on did not.

Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang<xiong.y.zhang@intel.com>
[danvet: Add regression citation and cc: stable. Thanks to Chris for
correcting my wrong guess about which commit broke things.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      43b27290
  11. 26 4月, 2013 5 次提交