[Intel-gfx] [PATCH 20/22] drm/tilcdc: Nuke preclose hook
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...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Intel-gfx