1. 02 May, 2013 3 commits
    • Dave Airlie's avatar
      drm/cirrus: deal with bo reserve fail in dirty update path · f3b2bbdc
      Dave Airlie authored
      Port over the mgag200 fix to cirrus as it suffers the same issue.
      
          On F19 testing, it was noticed we get a lot of errors in dmesg
          about being unable to reserve the buffer when plymouth starts,
          this is due to the buffer being in the process of migrating,
          so it makes sense we can't reserve it.
      
          In order to deal with it, this adds delayed updates for the dirty
          updates, when the bo is unreservable, in the normal console case
          this shouldn't ever happen, its just when plymouth or X is
          pushing the console bo to system memory.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      f3b2bbdc
    • Dave Airlie's avatar
      drm/ast: deal with bo reserve fail in dirty update path · 306373b6
      Dave Airlie authored
      Port over the mgag200 fix to ast as it suffers the same issue.
      
          On F19 testing, it was noticed we get a lot of errors in dmesg
          about being unable to reserve the buffer when plymouth starts,
          this is due to the buffer being in the process of migrating,
          so it makes sense we can't reserve it.
      
          In order to deal with it, this adds delayed updates for the dirty
          updates, when the bo is unreservable, in the normal console case
          this shouldn't ever happen, its just when plymouth or X is
          pushing the console bo to system memory.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      306373b6
    • Dave Airlie's avatar
      drm/mgag200: deal with bo reserve fail in dirty update path · 64171959
      Dave Airlie authored
      On F19 testing, it was noticed we get a lot of errors in dmesg
      about being unable to reserve the buffer when plymouth starts,
      this is due to the buffer being in the process of migrating,
      so it makes sense we can't reserve it.
      
      In order to deal with it, this adds delayed updates for the dirty
      updates, when the bo is unreservable, in the normal console case
      this shouldn't ever happen, its just when plymouth or X is
      pushing the console bo to system memory.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      64171959
  2. 01 May, 2013 2 commits
  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
  4. 29 Apr, 2013 17 commits
  5. 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
  6. 26 Apr, 2013 10 commits