Re: [PATCH 00/22] drm_event cleanup, round 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 11, 2016 at 10:40:54PM +0100, Daniel Vetter wrote:
> Hi all,
> 
> Mostly just small changes from review feedback (plus a few misplaced hunks,
> silly me). Plus an attempt at better kerneldoc to explain how this works. Since
> that caused questions both from Thomas and Laurent let me explain things also
> here:
> 
> Currently anyone using drm_events (vblank code, atomic/legacy flips, drivers
> like exynos) need to handle event setup, sending to the drm file and handling
> when the drm file disappears themselves. This patch series provides functions to
> encapsulate all these steps. Furthermore the file closing is handled
> differently: Events are no longer completely destroyed in preclose hooks like
> all current users do, but instead they're just unlinked from the file. The new
> drm_send_event can still be called, but instead of transmitting the event to the
> file it'll destroy it right away.
> 
> This means that when the drm file disappears it's entirely transparent to
> drivers, and we can remove all the special tracking and cleanup code around
> preclose functions.
> 
> The other consequence is that it's opt-in - drivers are still free to remove
> events explicitly when the file disappears, it's just needless code. Which means
> the patch series can be split up really nicely into core parts + driver patches.
> The only patch I didn't split up in this fashion is the one that creates
> drm_send_event - it's imo easier to review this way, and the driver changes are
> really simple.

-rc1 is out, so I pulled this all into drm-misc. Thanks a lot for all the
reviews&comments.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux