summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/omapdrm/omap_irq.c
diff options
context:
space:
mode:
authorArchit Taneja <archit@ti.com>2013-04-09 15:26:00 +0300
committerTomi Valkeinen <tomi.valkeinen@ti.com>2013-04-11 13:25:57 +0300
commitb03e14fd4b9f91d0c6be864bf62c75933fa26cac (patch)
treeea5e01fc30a6470eeab374bf310d8ea824813f19 /drivers/gpu/drm/omapdrm/omap_irq.c
parentbddabbe174cfb6f944baaf13ed5b93c6ee89ec3d (diff)
drm/omap: Take a fb reference in omap_plane_update()
When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and passes control to the update_plane op defined by the drm driver. In omapdrm, we have a worker thread which queues framebuffers objects received from update_plane and displays them at the appropriate time. It is possible that the framebuffer is destoryed by userspace between the time of calling the ioctl and apply-worker being scheduled. If this happens, the apply-worker holds a pointer to a framebuffer which is already destroyed. Take an extra refernece/unreference of the fb in omap_plane_update() to prevent this from happening. A reference is taken of the fb passed to update_plane(), the previous framebuffer (held by plane->fb) is unreferenced. This will prevent drm from destroying the framebuffer till the time it's unreferenced by the apply-worker. This is in addition to the exisitng reference/unreference in update_pin(), which is taken for the scanout of the plane's current framebuffer, and an unreference the previous framebuffer. Signed-off-by: Archit Taneja <archit@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Diffstat (limited to 'drivers/gpu/drm/omapdrm/omap_irq.c')
0 files changed, 0 insertions, 0 deletions