Skip to content

L
linux
Switch branch/tag
  1. 20 Jan, 2013 5 commits
    • Daniel Vetter's avatar
      drm/gma500: move fbcon restore to lastclose · 7147573a
      Daniel Vetter authored 
      Doing this within the fb->destroy callback leads to a locking
nightmare. And all other drm drivers that restore the fbcon do
it in lastclose, too.

With this adjustments all fb->destroy callbacks optionally drop
references to any gem objects used as backing storage, call
drm_framebuffer_cleanup and then kfree the struct. Which nicely
simplifies the locking for framebuffer unreferencing and freeing,
since this doesn't require that we hold the mode_config lock. A
slight exception is the vmwgfx surface backed framebuffer, it also
calls drm_master_put and removes the object from a device-private
framebuffer list. Both seem to have solid locking in place already.

Conclusion is that now it is no longer required to hold the
mode_config lock while freeing a framebuffer.

v2: Drop the corresponding mutex_lock WARN check from
drm_framebuffer_unreference.

v3: Use just the mode_config lock not modeset_lock_all, due to patch
reordering.
Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7147573a
    • Daniel Vetter's avatar
      drm/vmwgfx: reorder framebuffer init sequence · 80f0b5af
      Daniel Vetter authored 
      vmwgfx has an oddity, when failing to reference the surface it'll
return 0, since that's what the successfull drm_framebuffer_init will
leave behind in ret. Fix this up by returning -EINVAL.

Split out from all the other driver updates due to the above tiny
semantic change. Shouldn't matter though since the reference grabbing
seemingly can't fail.
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      80f0b5af
    • Daniel Vetter's avatar
      drm/<drivers>: reorder framebuffer init sequence · c7d73f6a
      Daniel Vetter authored 
      With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by the time drivers
call drm_framebuffer_init.

This patch here is the drivers part of that reorg. Nothing really fancy
going on safe for three special cases.

- exynos needs to be careful to properly unref all handles.
- nouveau gets a resource leak fixed for free: one of the error
  cases didn't cleanup the framebuffer, which is now moot since
  the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
  break anything (but it's refcount management only, so should be safe).

v2: Split out exynos, since it's a bit more hairy than expected.

v3: Drop bogus cirrus hunk noticed by Richard Wilbur.

v4: Split out vmwgfx since there's a small change in return values.

Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c7d73f6a
    • Daniel Vetter's avatar
      drm/doc: integrate drm_crtc.c kerneldoc · 065a50ed
      Daniel Vetter authored 
      And do a quick pass to adjust them to the last few (years?) of changes
...

This time actually compile-tested ;-)
Reviewed-by: default avatarRob Clark <rob@ti.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      065a50ed
    • 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
  3. 18 Jan, 2013 1 commit
  5. 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
  7. 16 Jan, 2013 24 commits
  9. 15 Jan, 2013 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7