summaryrefslogtreecommitdiff
path: root/include/video
diff options
context:
space:
mode:
authorArchit Taneja <archit@ti.com>2011-03-23 12:59:34 +0300
committerTomi Valkeinen <tomi.valkeinen@ti.com>2011-05-11 15:10:55 +0400
commitcf398fb3e6aed8e7a9b3bcf77f6de2d34ccd2078 (patch)
tree7e5fe4d850f3021a6117cdcde6b5f583dedc0d0a /include/video
parent9613c02b5feba3ea03ab34f1422dd122c6e54f57 (diff)
downloadlinux-cf398fb3e6aed8e7a9b3bcf77f6de2d34ccd2078.tar.xz
OMAP: DSS2: DSI: Introduce sync_vc functions
The DSI protocol engine has no interrupt for signalling the end of a Frame transfer. The present approach is to send a BTA after DISPC generates a FRAMEDONE interrupt, and unlock the dsi bus only when the BTA Ack is received. The assumption made with this approach was that OMAP will send a BTA only after the long packet corresponding to the last line is sent. However, it is possible that on the DISPC FRAMEDONE interrupt there are 2 (or more) lines of pixel data in the DSI line buffer. Hence, the BTA Ack could be received for the long packet corresponding to the second last line (or the third last and so on..). Therefore, the current method doesn't ensure that the complete frame data is sent before we start a new transfer. A similar explanation holds valid if we send a BTA in between multiple short/long command packets from the slave port. Introduce dsi_sync_vc functions, based on Tomi Valkeinen's idea, which ensure that the DSI Virtual Channel in use(update_channel) completes its previous work before proceeding to the next Frame/Command. For a frame update, the DSI driver now sends a callback to the Panel Driver on the FRAMEDONE interrupt itself. The callback in the panel driver then unlocks the bus. dsi_sync_vc() functions are placed in dsi_vc_config_l4() and dsi_vc_config_vp() to ensure that the previous task of the Virtual Channel is completed. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Diffstat (limited to 'include/video')
0 files changed, 0 insertions, 0 deletions