Re: [PATCH] OMAP: DSS2: DSI: Introduce sync_vc functions

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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