On Tue, 2011-03-29 at 13:24 +0530, Archit Taneja wrote: > On Tuesday 29 March 2011 12:42 PM, Valkeinen, Tomi wrote: > > 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. > > Yes, makes sense. > > > > > 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. > > We can send a BTA per VC, and we get a BTA Ack corresponding to that VC > (in DSI_VC_IRQSTATUS_i). I don't know what BTA per VC means, I guess > OMAP DSI implementation deviates from the specification here. > > We need to figure out why the bits exist per VC and not in something > like DSI_CTRL and DSI_IRQSTATUS. Hmm, that's true. The HW doesn't really make sense from DSI spec point of view... There's no data associated with BTA, it's just a bus-turn-around for the whole bus. I guess OMAP's DSI HW just keeps track which VC was used to send the BTA, and as only one BTA can be sent at a time it can then associate the reply to the sending VC. But still, why would it do that because it doesn't make any sense... 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
