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