On Wed, 2011-03-23 at 04:59 -0500, Taneja, Archit wrote: > From: Archit Taneja <archit@xxxxxx> > > 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@xxxxxx> > --- > Note: > Applies over the master branch of the tree: > http://gitorious.org/linux-omap-dss2/linux/commits/master > > drivers/video/omap2/dss/dsi.c | 180 ++++++++++++++++++++++++++-------------- > 1 files changed, 117 insertions(+), 63 deletions(-) Looks good, but this patch introduces one problem: handling the double BTA for DSI TE. Currently we aim DSI to be always in a state where one BTA has been sent. So when the next frame transfer starts, we can just send one BTA and we know we'll get two consecutive BTAs. This patch removes the BTA which is sent after the frame transfer, thus breaking the above system. This doesn't cause problems currently because panel-taal.c always sends columns and rows addresses before starting the frame update, and a BTA is sent after those configurations. But a simple optimization would be to only send column/row config if they have changed. And in that case we would not get a double BTA, and thus we'd never get the DSI TE. So how to solve that... Two ways come to my mind: - Track sent BTAs in dsi.c. Every time we send a packet, reset the counter. Every time we send a BTA, increase the counter. Thus at frame update we would know if we need to send an extra BTA. - Always reset the BTA "status" from the panel at the beginning of frame transfer. This could be done by sending a null packet. The second one is probably simpler and more failsafe as there's no state stored. The first one (as well as the current system) would go wrong if something strange happens, like the panel resets. However, the second one introduces some overhead, as we need to send a null packet and two BTAs (versus one BTA) for every frame. It's probably negligible, though. I think we should go with the second option for now. It's simpler and works (should, at least). We can study the first option later if we need to optimize this. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
