[Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook

Tomi Valkeinen tomi.valkeinen at ti.com
Wed Jan 13 03:25:17 PST 2016

On 12/01/16 17:12, Daniel Vetter wrote:

> Different approaches to the same problem:
> - omap just unlinks the event from fpriv and still process it normally.
>   But then before sending it out it checks whether the fpriv is still
>   there or not and either sends it, or deletes the event directly. This
>   way the vblank_put is always called from the worker/irq handler as part
>   of the event processing.
>   This is the same approach I implemented in core with this series.
> - tilcdc (and most other drivers) entirely destroy the event in the
>   preclose hook, which means they must also release any other resources
>   acquired as part of that event. Therefore they have the vblank_put here.
>   But the vblank_put is obviously also in the normal event processing
>   paths, so with the new approach of only unlinking it we can handle this
>   without any special cases in the driver.
> I hope this explains what's going on. Since you're about driver maintainer
> no. 3 with the same question: Can you pls review the kerneldoc and make
> sure it explains this well? I tried to improve it already a bit after
> Laurent's/Thomas' questions.

Ok, makes sense. I think the kernel doc is fine.

I wasn't able to test tilcdc, as it seems to crash on drm-next at the
moment... Need to debug that first.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20160113/24f365a9/attachment.sig>

More information about the Intel-gfx mailing list