1. 03 May, 2013 1 commit
    • Dave Airlie's avatar
      Merge branch 'drm-next-3.10-2' of git://people.freedesktop.org/~agd5f/linux into drm-next · 61109488
      Dave Airlie authored
      Just some fixes that have accumulated over the last couple of
      weeks and some new PCI ids.
      
      * 'drm-next-3.10-2' of git://people.freedesktop.org/~agd5f/linux:
        drm/radeon: fix handling of v6 power tables
        drm/radeon: clarify family checks in pm table parsing
        drm/radeon: consolidate UVD clock programming
        drm/radeon: fix UPLL_REF_DIV_MASK definition
        radeon: add bo tracking debugfs
        drm/radeon: add new richland pci ids
        drm/radeon: add some new SI PCI ids
        drm/radeon: fix scratch reg handling for UVD fence
        drm/radeon: allocate SA bo in the requested domain
        drm/radeon: fix possible segfault when parsing pm tables
        drm/radeon: fix endian bugs in atom_allocate_fb_scratch()
      61109488
  2. 02 May, 2013 16 commits
  3. 01 May, 2013 2 commits
  4. 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 14 commits