]> git.karo-electronics.de Git - linux-beck.git/commit
OMAP: DSS2: DSI: use a private workqueue
authorTomi Valkeinen <tomi.valkeinen@nokia.com>
Mon, 12 Apr 2010 06:57:19 +0000 (09:57 +0300)
committerTomi Valkeinen <tomi.valkeinen@nokia.com>
Tue, 3 Aug 2010 12:18:46 +0000 (15:18 +0300)
commit0f16aa0ae6b84d7ae72fbe8999e6a94cb78edd4e
treeff277d1cfa93a6ea5b6602d93462a704b79be5ca
parent86a7867ebff675f5f5816222c5a2c64b35f8bea6
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 <tomi.valkeinen@nokia.com>
drivers/video/omap2/dss/dsi.c