diff options
author | Archit Taneja <archit@ti.com> | 2014-01-02 14:49:54 +0530 |
---|---|---|
committer | Tomi Valkeinen <tomi.valkeinen@ti.com> | 2014-01-09 15:17:25 +0200 |
commit | 80e4ed5411dddbafe90083a6c82dd87e88fde0d7 (patch) | |
tree | 90b2e37a5bb34c4742aec8b7b6c3bfbea0bcaa73 /drivers/video | |
parent | ec72a81e27d735eb0b5f9325be3d88aa4cb5510a (diff) | |
download | op-kernel-dev-80e4ed5411dddbafe90083a6c82dd87e88fde0d7.zip op-kernel-dev-80e4ed5411dddbafe90083a6c82dd87e88fde0d7.tar.gz |
drm/omap: fix: change dev_unload order
The current dev_unload order uninits the irqs too early.
In the current sequence, it's possible that a crtc queues work(apply_worker)
to display a buffer, which registers to omap_crtc_apply_irq to notfiy the
completion of the configuration we applied.
Calling drm_vblank_cleanup and omap_drm_irq_uninstall here causes the crtc's
apply handler to never get called, which results in an incorrect state of the
apply_irq.registered parameter.
This condition occurs where there is no mode set via omapdrm, and dev_lastclose
tries to set a default fb mode via drm_fb_helper_restore_fbdev_mode. The apply
work scheduled by restore_fbdev_mode is very close in time to the disabling of
the irq handler, and hence leads to a race condition. We move the irq cleanup
at the end of the unload sequence to prevent this.
Also, the call to flush_workqueue is removed since it's called internally by
destroy_workqueue.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Diffstat (limited to 'drivers/video')
0 files changed, 0 insertions, 0 deletions