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.

 Tomi