Re: [PATCH 00/37] [RFC] revamped modeset locking

[Daniel Vetter <daniel@ffwll.ch>]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch