1. 20 Jan, 2013 1 commit
    • Daniel Vetter's avatar
      drm: review locking rules in drm_crtc.c · 8faf6b18
      Daniel Vetter authored
      - 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: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8faf6b18
  2. 18 Jan, 2013 1 commit
  3. 17 Jan, 2013 2 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 72ffaa48
      Linus Torvalds authored
      Pull more s390 patches from Martin Schwidefsky:
       "A couple of bug fixes: one of the transparent huge page primitives is
        broken, the sched_clock function overflows after 417 days, the XFS
        module has grown too large for -fpic and the new pci code has broken
        normal channel subsystem notifications."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390/chsc: fix SEI usage
        s390/time: fix sched_clock() overflow
        s390: use -fPIC for module compile
        s390/mm: fix pmd_pfn() for thp
      72ffaa48
    • Linus Torvalds's avatar
      Merge tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs · dfdebc24
      Linus Torvalds authored
      Pull xfs bugfixes from Ben Myers:
      
       - fix(es) for compound buffers
      
       - fix for dquot soft timer asserts due to overflow of d_blk_softlimit
      
       - fix for regression in dir v2 code introduced in commit 20f7e9f3
         ("xfs: factor dir2 block read operations")
      
      * tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs:
        xfs: recalculate leaf entry pointer after compacting a dir2 block
        xfs: remove int casts from debug dquot soft limit timer asserts
        xfs: fix the multi-segment log buffer format
        xfs: fix segment in xfs_buf_item_format_segment
        xfs: rename bli_format to avoid confusion with bli_formats
        xfs: use b_maps[] for discontiguous buffers
      dfdebc24
  4. 16 Jan, 2013 24 commits
  5. 15 Jan, 2013 11 commits
  6. 14 Jan, 2013 1 commit