aboutsummaryrefslogtreecommitdiff
path: root/arch/parisc/Kconfig
diff options
context:
space:
mode:
authorArchit Taneja <archit@ti.com>2011-05-03 12:18:41 +0800
committerRicardo Salveti de Araujo <ricardo.salveti@canonical.com>2011-05-16 22:42:12 -0300
commit17fe32fa959d510576cfc4dceda751e85070bb14 (patch)
treedd2abf68ba65c7c756ec1bf95129de2a81a3bd56 /arch/parisc/Kconfig
parent2353c08e01dfedfeb825fe6b7c378fc0a9a10a8b (diff)
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 'arch/parisc/Kconfig')
0 files changed, 0 insertions, 0 deletions