[RFC 0/3] solving omapdrm/omapdss layering issues

[Rob Clark]

On Wed, Aug 1, 2012 at 12:38 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On Wed, 2012-08-01 at 11:53 -0500, Rob Clark wrote:
>
>> Ok.. this would help.  I'll take a look.  I do request that
>> interfaces/panels don't set any mgr/timing related registers.  I had
>> to comment all this stuff out in my prototype.  Really we want to set
>> the timings separately on the crtc (mgr) / encoder (interface) /
>> connector (panel.. not sure if it is needed, though?).  KMS will take
>> care of propagating the timings through the pipeline.
>
> If we only had auto-update displays, and only the video timings were
> shadow register, it'd work. Unfortunately we have other registers as
> shadow registers also, like DISPC_CONTROL1, DISPC_CONFIG1 and
> DISPC_DIVISOR1.

well, I was kinda thinking we just do all the register access from the
corresponding crtc (mgr)'s GO/apply sequencing..  so if, for example,
you change resolution, then the plane, crtc, encoder, panel all queue
up via omap_crtc_apply() on their associated crtc, and then at the
right time from pre_apply() fxns call the appropriate omapdss/dispc
function(s) for register updates.

I think that would work well for everything but mgr enable/disable
(which is infrequent, so ok to block for a few vblanks), and
fifomerge, which I'm a bit on the fence about.

> But we should think if this could be somehow be changed, so that all the
> shadow register info would come from one place. I do find it a bit
> unlikely with a quick thought, though.
>
> Well, hmm. Perhaps... Omapdrm (or omapfb etc) doesn't really need to
> know about the values of those registers, it just needs to control the
> GO bit. So perhaps if we had some method to inform omapdrm that these
> things have changed, and omapdrm would then set the GO bit as soon as
> possible.

Well, what I'm doing now is basically, if I update anything in any of
the omap_*_info structs, I schedule an apply, and from pre_apply
callback push the changes down to dispc.. I was thinking to follow the
same for encoder and probably connector.  (Not sure if doing things
like setting timings at hdmi need to be GO bit sync'd?  Maybe this
could be bypassed for the connector, but if not it is easy enough just
to use the same mechanism that the plane/crtc/encoder are already
using.)

> But there are some tricky stuff, like the divisors... Well, we need to
> think about this.

I think, if I understand properly, the most tricky thing is the shared
clocks.. although I'm not really sure if we can actually change things
like the core clock when you plug in a 2nd display w/out loosing sync
on the first?  That's seems like a tricky thing either way.  Anything
else, that is only effecting a single crtc->encoder->connector chain
can have register programming sync'd to that mgr's GO bit.

BR,
-R

>  Tomi
>