1. 23 Mar, 2014 38 commits
  2. 21 Mar, 2014 2 commits
    • Dave Airlie's avatar
      drm/helper: lock all around force mode restore · 3ea87855
      Dave Airlie authored
      Since Daniel documented things with a sledge hammer, we got lots of
      nice backtraces in suspend/resume operations, I've check the callers
      of this and they all seems safe to me,
      
      This fixes one set of warns I reported.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      3ea87855
    • Daniel Vetter's avatar
      drm/fb-helper: improve drm_fb_helper_initial_config locking · 53f1904b
      Daniel Vetter authored
      The locking in drm_fb_helper_initial_config is a bit troublesome for a
      few reasons:
      
      - We can't just wrap the entire function up into modeset locks since
        the fbdev registration might call down into fbcon code, which then
        through our ->set_par implementation needs to be able to grab all
        modeset locks. So we'd have a neat deadlock.
      
      - This implies though that all current callers don't hold any modeset
        locks by necessity, so we have free reign to grab any modeset locks
        we need to grab.
      
      - The private state of the fbdev helper doesn't need any protection
        through locks, since once we have the fbdev registered it is mostly
        invariant or protected through the modeset locking in ->set_par and
        other callbacks. We can fully rely on driver having non-racy setup
        sequences here. For the initial config computation we actually may
        not grab locks since drivers which provide their own magic sauce
        (like i915) might need to grab locks themselves.
      
      - We should grab locks though when we probe outputs. Currently there's
        not much risk, but already now userspace could start poking at sysfs
        files and so probe concurrently. I expect that in the future driver
        init will be much more async, and since probing is really
        time-consuming this is a prime candidate.
      
      - We must not hold any crtc->mutex locks while calling probe functions
        since those might need to lock a crtc for e.g. load detection. i915
        is such a driver.
      
      Also it's the probing calls which hit upon piles of new locking
      asserts I've recently added in
      
      commit 62ff94a5
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 23 22:18:47 2014 +0100
      
          drm/crtc-helper: remove LOCKING from kerneldoc
      
      and
      
      commit 63951385
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 23 15:14:15 2014 +0100
      
          drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
      
      Hence the right fix is to grab the mode_config mutex, but only that
      and only right around the probe calls.
      
      It seems to be sufficient to shut up all the locking WARNINGs I see on
      i915 and nouveau in drm_fb_helper_initial_config.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      53f1904b