Skip to content

L
linux
Switch branch/tag
  1. 01 May, 2013 1 commit
  3. 30 Apr, 2013 7 commits
    • Dave Airlie's avatar
      udl: bind the framebuffer to the correct device. · 33896bf3
      Dave Airlie authored 
      This just moves the fb sysfs node beside the drm sysfs node which
I fixed before.

just noticed it in passing.
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      33896bf3
    • Imre Deak's avatar
      drm: prime: fix refcounting on the dmabuf import error path · 011c2282
      Imre Deak authored 
      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: default avatarImre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      011c2282
    • Dave Airlie's avatar
      drm/prime: keep a reference from the handle to exported dma-buf (v6) · 219b4733
      Dave Airlie authored 
      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: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      219b4733
    • Ville Syrjälä's avatar
      drm: Kill user_modes list and the associated ioctls · c55b6b3d
      Ville Syrjälä authored 
      There is no way to use modes added to the user_modes list. We never
look at the contents of said list in the kernel, and the only operations
userspace can do are attach and detach. So the only "benefit" of this
interface is wasting kernel memory.

Fortunately it seems no real user space application ever used these
ioctls. So just kill them.

Also remove the prototypes for the non-existing drm_mode_addmode_ioctl()
and drm_mode_rmmode_ioctl() functions.

v2: Use drm_noop instead of completely removing the ioctls
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      c55b6b3d
    • Ville Syrjälä's avatar
      drm: Silence some sparse warnings · ea9cbb06
      Ville Syrjälä authored 
      drivers/gpu/drm/drm_pci.c:155:5: warning: symbol 'drm_pci_set_busid' was not declared. Should it be static?
drivers/gpu/drm/drm_pci.c:197:5: warning: symbol 'drm_pci_set_unique' was not declared. Should it be static?
drivers/gpu/drm/drm_pci.c:269:5: warning: symbol 'drm_pci_agp_init' was not declared. Should it be static?

drivers/gpu/drm/drm_crtc.c:181:1: warning: symbol 'drm_get_dirty_info_name' was not declared. Should it be static?
drivers/gpu/drm/drm_crtc.c:1123:5: warning: symbol 'drm_mode_group_init' was not declared. Should it be static?

drivers/gpu/drm/drm_modes.c:918:6: warning: symbol 'drm_mode_validate_clocks' was not declared. Should it be static?
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ea9cbb06
    • Ville Syrjälä's avatar
      drm: Make drm_ioctls const · 7d05336b
      Ville Syrjälä authored 
      We never modify the contents of drm_ioctls, so make it const.
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      7d05336b
    • David Rientjes's avatar
      drivers, drm: fix qxl build error when debugfs is disabled · caaa0352
      David Rientjes authored 
      Fix build error when CONFIG_DEBUG_FS is disabled:

drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_init':
drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function 'drm_debugfs_create_files'
drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_takedown':
drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function 'drm_debugfs_remove_files'
Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      caaa0352
  5. 29 Apr, 2013 17 commits
  7. 27 Apr, 2013 1 commit
    • Zhang, Xiong Y's avatar
      drm/i915: correct the calculation of first_pd_entry_in_global_pt · 43b27290
      Zhang, Xiong Y authored 
      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: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      43b27290
  9. 26 Apr, 2013 14 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7