On Wed, Dec 12, 2012 at 02:06:40PM +0100, Daniel Vetter wrote:
Hi all,
First thing first: It works, I now no longer have a few dropped frames every 10s on my testbox here with the pageflip i-g-t tests.
Random notes:
New design has per-crtc locks to protect the crtc input-side (pageflip, cursor) for r/w and the output state of the crtc (mode, dpms) as read-only. It also required completely revamped fb lifecycle management, those are now refcounted for real (which is a nice cleanup). Imo the proposed rwsem hack from Dave/Ajax is too ugly to life in comparison.
Smoke tested on i915, compile tested for x86 drivers, probably all arm drivers trivially broken. I plan add tons of i-g-t testscases to exercise all the cornercases with i915 (so that lockdep has full coverage among other things) and at least run radeon/nouveau a bit. I also need to set up an arm crosscompiler. Generally testing feedback on !i915 highly welcome.
Driver audit: I've tried to not break anything more than it already is, and for the big three desktop drivers fixup any related breakage I've noticed. Big unknown is vmwgfx since that driver is over my head. Generally review from driver devs is required to check all corner-cases.
Merging, presuming people like this idea here: I think it'd be good to slurp in the driver changes as early as possible. The big rework probably has to go in with a separate pull directly to drm-next for all drivers - there are simply too many sync-points in this rework where all drivers need to follow the new rules before core drm changes can be applied.
Having a global lock which synchronizing object destruction is a royal pain, since it reliably results in that locking getting in the way almost everywhere when trying to implement refcounting. It's fixed now for fb & the mode_config mutex, but I'm already eagerly looking forward to simplifying dev->struct_mutex gem_bo cleanup rules.
drm teardown/setup synchronization and locking is terminally broken. Insane volunteers welcome, I don't want to do this.
I've mentioned that reading too much driver code causes nightmares, right? vmwgfx ...
Please bring on the flames.
I've forgotten to add: Patch series pushed out to the drm-kms-locking branch in my personal fdo repo:
http://cgit.freedesktop.org/~danvet/drm/log/?h=drm-kms-locking
-Daniel