renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 21:54:06 +08:00
Code

OMAP: DSS2: remove non-working msleep(40) workaround

Browse Source 
The sleep workaround for the problem described in the comment doesn't
really work. This patch removes the workaround, and improves the comment
about the bug, and proposes an userspace workaround.

omap_dss_set_manager() is called 6 times when loading omapdss and
omapfb, which means that 40ms * 6 = 240ms was spent sleeping when
booting up.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This commit is contained in:
Tomi Valkeinen 2010-05-20 15:13:12 +03:00
parent c6940a3dc5
commit d792eecd9a
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
drivers/video/omap2/dss/overlay.c
View File

@ -491,13 +491,18 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
ovl->manager = mgr;
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
/* XXX: on manual update display, in auto update mode, a bug happens
* here. When an overlay is first enabled on LCD, then it's disabled,
* and the manager is changed to TV, we sometimes get SYNC_LOST_DIGIT
* errors. Waiting before changing the channel_out fixes it. I'm
* guessing that the overlay is still somehow being used for the LCD,
* but I don't understand how or why. */
msleep(40);
/* XXX: When there is an overlay on a DSI manual update display, and
* the overlay is first disabled, then moved to tv, and enabled, we
* seem to get SYNC_LOST_DIGIT error.
*
* Waiting doesn't seem to help, but updating the manual update display
* after disabling the overlay seems to fix this. This hints that the
* overlay is perhaps somehow tied to the LCD output until the output
* is updated.
*
* Userspace workaround for this is to update the LCD after disabling
* the overlay, but before moving the overlay to TV.
*/
dispc_set_channel_out(ovl->id, mgr->id);
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);