1. 20 1月, 2013 1 次提交
    • D
      drm: review locking rules in drm_crtc.c · 8faf6b18
      Daniel Vetter 提交于
      - config_cleanup was confused: It claimed that callers need to hold
        the modeset lock, but the connector|encoder_cleanup helpers grabbed
        that themselves (note that crtc_cleanup did _not_ grab the modeset
        lock). Which resulted in all drivers _not_ hodling the lock. Since
        this is for single-threaded cleanup code, drop the requirement from
        docs and also drop the lock_grabbing from all _cleanup functions.
      
      - Kill the LOCKING section in the doctype, since clearly we're not
        good enough to keep them up-to-date. And misleading locking
        documentation is worse than useless (see e.g. the comment in the
        vmgfx driver about the cleanup mess). And since for most functions
        the very first line either grabs the lock or has a WARN_ON(!locked)
        the documentation doesn't really add anything.
      
      - Instead put in some effort into explaining the only two special
        cases a bit better: config_init and config_cleanup are both called
        from single-threaded setup/teardown code, so don't do any locking.
        It's the driver's job though to enforce this.
      
      - Where lacking, add a WARN_ON(!is_locked). Not many places though,
        since locking around fbdev setup/teardown is through-roughly screwed
        up, and so will break almost every single WARN annotation I've tried
        to add.
      
      - Add a drm_modeset_is_locked helper - the Grate Modset Locking Rework
        will use the compiler to assist in the big reorg by renaming the
        mode lock, so start encapsulating things. Unfortunately this ended
        up in the "wrong" header file since it needs the definition of
        struct drm_device.
      
      v2: Drop most WARNS again - we hit them all over the place, mostly in
      the setup and teardown sequences. And trying to fix it up leads to
      nice deadlocks, since the locking in the setup code is really
      inconsistent.
      Reviewed-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8faf6b18
  2. 17 1月, 2013 3 次提交
  3. 16 1月, 2013 1 次提交
  4. 15 1月, 2013 1 次提交
  5. 14 1月, 2013 5 次提交
  6. 13 1月, 2013 12 次提交
  7. 12 1月, 2013 17 次提交