Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
“be523baad2f4f494d08fec3a40737578d47e25e1”上不存在“paddle/fluid/inference/anakin/convert/relu.h”
切换分支/标签
  1. 10 6月, 2013 1 次提交
  3. 15 5月, 2013 1 次提交
  5. 03 5月, 2013 2 次提交
  7. 02 5月, 2013 16 次提交
  9. 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
  11. 30 4月, 2013 7 次提交
  13. 29 4月, 2013 8 次提交