1. 27 Jun, 2013 5 commits
  2. 26 Jun, 2013 1 commit
  3. 25 Jun, 2013 5 commits
    • Daniel Vetter's avatar
      drm: fix fb leak in setcrtc · 5cef29aa
      Daniel Vetter authored
      Drivers are allowed (actually have to) disable unrelated crtcs in
      their ->set_config callback (when we steal all the connectors from
      that crtc). If they do that they'll clear crtc->fb to NULL.
      
      Which results in a refcount leak, since the drm core is keeping track
      of that reference.
      
      To fix this track the old fb of all crtcs and adjust references for
      all of them. Of course, since we only hold an additional reference for
      the fb for the current crtc we need to increase refcounts before we
      drop the old one.
      
      This approach has the benefit that it inches us a bit closer to an
      atomic modeset world, where we want to update the config of all crtcs
      in one step.
      
      This regression has been introduce in the framebuffer refcount
      conversion, specifically in
      
      commit b0d12325
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Dec 11 01:07:12 2012 +0100
      
          drm: refcounting for crtc framebuffers
      Reported-by: default avatarRussell King <linux@arm.linux.org.uk>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      5cef29aa
    • Daniel Vetter's avatar
      drm: check that ->set_config properly updates the fb · cc85e121
      Daniel Vetter authored
      Historically drm lacked fb refcounting, so the updating of crtc->fb
      was done by the lower levels at a point convenient to get their own
      refcounting (e.g. refcounts for the underlying gem bo, pinning
      refcounts) right. With the introduction of refcounted fbs the drm core
      handled the fb refcounts, but still relied on drivers to update the
      crtc->fb pointer (this approach required the least invasive changes in
      drivers).
      
      Enforce this contract with a WARN_ON.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      cc85e121
    • Daniel Vetter's avatar
      drm/crtc-helper: explicit DPMS on after modeset · 372835a8
      Daniel Vetter authored
      Atm the crtc helper implementation of set_config has really
      inconsisten semantics: If just an fb update is good enough, dpms state
      will be left as-is, but if we do a full modeset we force everything to
      dpms on.
      
      This change has already been applied to the i915 modeset code in
      
      commit e3de42b6
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Fri May 3 19:44:07 2013 +0200
      
          drm/i915: force full modeset if the connector is in DPMS OFF mode
      
      which according to Greg KH seems to aim for a new record in most
      Bugzilla: links in a commit message.
      
      The history of this dpms forcing is pretty interesting. This patch
      here is an almost-revert of
      
      commit 811aaa55
      Author: Keith Packard <keithp@keithp.com>
      Date:   Thu Feb 3 16:57:28 2011 -0800
      
          drm: Only set DPMS ON when actually configuring a mode
      
      which fixed the bug of trying to dpms on disabled outputs, but
      introduced the new discrepancy between an fb update only and full
      modesets. The actual introduction of this goes back to
      
      commit bf9dc102
      Author: Keith Packard <keithp@keithp.com>
      Date:   Fri Nov 26 10:45:58 2010 -0800
      
          drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
      
      And if you'd dig around in the i915 driver code there's even more fun
      around forcing dpms on and losing our heads and temper of the
      resulting inconsistencies. Especially the DP re-training code had tons
      of funny stuff in it.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      372835a8
    • Daniel Vetter's avatar
      drm/crtc-helper: no need to check for fb->depth/bpp · cbdfebc9
      Daniel Vetter authored
      ... since we already check for fb->pixel_format, which encodes all
      this. The other two fields are only for backwards compat of older
      drivers (and we might want to look into eventually just killing them).
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      cbdfebc9
    • Daniel Vetter's avatar
      drm/crtc-helpers: Enforce sane set_config api · e58de880
      Daniel Vetter authored
      There's no point in trying to clean up after driver-bugs, so just blow
      up. Furthermore it's an interface abuse to set no mode but have an fb
      and aslo to try to set an fb without enough connectors. These two
      spefici cases of interface abuse have been committed by the fb helper,
      but that's been fixed meanwhile in
      
      commit 7e53f3a4
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Mon Jan 21 10:52:17 2013 +0100
      
          drm/fb-helper: fixup set_config semantics
      
      The i915 driver has been shipping since a while with these BUGs with
      no reports, so should be save.
      
      Note that this drops an ugly case where we clear crtc->fb behind the
      upper levels back and so cause a refcounting mayhem, which Russell
      Kins spotted while trying to hunt down a drm framebuffer leak.
      Reported-by: default avatarRussell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e58de880
  4. 23 Jun, 2013 1 commit
  5. 22 Jun, 2013 9 commits
  6. 21 Jun, 2013 8 commits
  7. 20 Jun, 2013 11 commits