On Thu, 2011-03-24 at 03:36 -0500, Taneja, Archit wrote: > Hi, > > On Thursday 24 March 2011 01:18 PM, Valkeinen, Tomi wrote: > > 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. > > Okay. I agree the second one is a better option. I have a couple of > queries though: > -The second BTA should be sent only after we get the Ack for the first > one, i.e, we need to use bta_sync() for the first BTA, right? True. > -We shouldn't send null packets and the 2 BTAs at all if we aren't using > Automatic TE mode, is this correct? If by automatic TE mode you mean the DSI TEE trigger, then yes. There's currently check for the dsi.te_enabled in dsi_update_screen_dispc() for that. > -Whose job should it be to send the null packet and the 2 BTAs, the dsi > driver or the panel driver? I'd say the dsi driver. It currently sends the one BTA in dsi_update_screen_dispc(). Adding one null packet and a BTA there should be quite simple. 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
