From: Tomi Valkeinen Date: Mon, 12 Apr 2010 06:57:19 +0000 (+0300) Subject: OMAP: DSS2: DSI: use a private workqueue X-Git-Tag: v2.6.36-rc1~487^2~48 X-Git-Url: https://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=0f16aa0ae6b84d7ae72fbe8999e6a94cb78edd4e;p=pandora-kernel.git OMAP: DSS2: DSI: use a private workqueue Using the shared workqueue led to to a deadlock in the case where the display was unblanked via keyboard. What happens is something like this: - User presses a key context 1: - drivers/char/keyboard.c calls schedule_console_callback() - fb_unblank takes the console semaphore - dsi bus lock is taken, and frame transfer is started (dsi bus lock is left on) - Unblank code tries to set the panel backlight, which tries to take dsi bus lock, but is blocked while the frame transfer is going on context 2, shared workqueue, console_callback in drivers/char/vt.c: - Tries to take console semaphore - Blocks, as console semaphore is being held by context 1 - No other shared workqueue work can be run context 3, HW irq, caused by FRAMEDONE interrupt: - Interrupt handler schedules framedone-work in shared workqueue - Framedone-work is never ran, as the shared workqueue is blocked. This means that the unblank thread stays blocked, which means that context 2 stays blocked. While I think the real problem is in keyboard/virtual terminal code, using a private workqueue in the DSI driver is perhaps safer and more robust than using the shared one. The DSI works should not be delayed more than a millisecond or so, and even if the private workqueue gives us no hard promise of doing so, it's still safer bet than the shared workqueue. Signed-off-by: Tomi Valkeinen --- Reading git-diff-tree failed