On Tue, 2011-03-29 at 09:56 +0530, Archit Taneja wrote: > 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 functions, based on Tomi Valkeinen's idea, which ensure > that all the DSI Virtual Channels enabled complete their 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() functions are placed in dsi_vc_config_l4() and > dsi_vc_config_vp() to ensure that the previous tasks of the Virtual Channels are > completed. > > Signed-off-by: Archit Taneja <archit@xxxxxx> > --- > v2: > -Introduce dsi_sync() which syncs all VCs. > -Modify commit message for above change. We don't need to sync all VCs in dsi_vc_config_l4/vp(). There's no problem changing a VC between l4 and vp while other VCs are still transmitting. The problematic case where we need to sync all VCs is sending a BTA. BTA is not a VC-based thing, but a bus wide thing. If another VC was still transmitting data when we send a BTA, we cannot know when the BTA was actually sent, and to which packet the panel responds. But this BTA actually quite a messy thing overall. Consider a case where we use two VCs. We first set VC0 to send a bunch of packets. Then we use VC1 to send, say, READ_ID1, and after that we send a BTA to get the ID1. Now, even if send_bta() would call dsi_sync(), we don't know which packet was actually sent last. Was it the READ_ID1, or something from VC0? Luckily these things are not a problem in any current use case, as we have only one DSI device connected to a single DSI bus, and we can just use one VC. So... I think we could just use the v1 of this patch for now (if the dsi_sync change was the only change). This leaves us with the problem of sending the double BTA (which doesn't manifest currently), which can be fixed in a separate patch. And we need to think more about the solution for using multiple VCs reliably, and see to it later if there's need. How does that sound? 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
