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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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

 Tomi

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux