kernel news – 21.01.2013

Posted: January 21, 2013 in kernel

-Daniel Vetter has a pull request regarding drm-kms-locking:

Changes since the patchbomb on dri-devel:
– Added a patch to adjust the new omapdrm code in 3.8-rc4, reviewed by Rob
Clark on irc (hence also why the baseline of this pull is 3.8-rc4).
– Slightly fixed/clarified some commit messages and fixed one spelling
fail in a comment.
– Sprinkled Rob’s r-b tags over the patches (for drm core changes +

Imo the individual patches contain really detailed commit messages, so for
the merge commit just a quick overview:

The aim of this locking rework is that ioctls which a compositor should be
might call for every frame (set_cursor, page_flip, addfb, rmfb and
getfb/create_handle) should not be able to block on kms background
activities like output detection. And since each EDID read takes about
25ms (in the best case), that always means we’ll drop at least one frame.

The solution is to add per-crtc locking for these ioctls, and restrict
background activities to only use the global lock. Change-the-world type
of events (modeset, dpms, …) need to grab all locks.

Two tricky parts arose in the conversion:
– A lot of current code assumes that a kms fb object can’t disappear while
holding the global lock, since the current code serializes fb
destruction with it. Hence proper lifetime management using the already
created refcounting for fbs need to be instantiated for all ioctls and

– The rmfb ioctl removes the to-be-deleted fb from all active users. But
unconditionally taking the global kms lock to do so introduces an
unacceptable potential stall point. And obviously changing the userspace
abi isn’t on the table, either. Hence this conversion opportunistically
checks whether the rmfb ioctl holds the very last reference, which
guarantees that the fb isn’t in active use on any crtc or plane (thanks
to the conversion to the new lifetime rules using proper refcounting).
Only if this is not the case will the code go through the slowpath and
grab all modeset locks. Sane compositors will never hit this path and so
avoid the stall, but userspace relying on these semantics will also not

All these cases are exercised by the newly added subtests for the i-g-t
kms_flip, tested on a machine where a full detect cycle takes around 100
ms. It works, and no frames are dropped any more with these patches
applied. kms_flip also contains a special case to exercise the
above-describe rmfb slowpath.

-Rusty Rusell has a few minor module fixes and a virtio block fix as well,
Dave Airlie has DRM fixes, and that’s about it for now.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s