On Mon, Jun 21, 2010 at 04:34:33PM +0300, Grazvydas Ignotas wrote:
> (CC Tomi)
>
> On Thu, Jun 17, 2010 at 12:43 AM, Zygo Blaxell
> <[email protected]> wrote:
> > The TRM and the OMAP FB driver have different ideas about the widths
> > of various bit fields in the DISPC_TIMING_{H,V} registers. This patch
> > is based on what the TRM (TI document SPRUF98G) says.
> >
> > Note: this patch changes the meanings of the vertical timing values
> > by one scan line. It still works with my display, but it might break
> > things for other people.
>
> Why? The TRM doesn't say VFP, VBP have to be programmed with value -1.
Hmmm...that's correct. Only VSW in DISPC_TIMING_V needs -1. Sorry,
my bad.
On the other hand, I've since found the equivalent code in the DSS driver,
and it looks like this:
if (cpu_is_omap24xx() || omap_rev() < OMAP3430_REV_ES3_0) {
timing_h = FLD_VAL(hsw-1, 5, 0) | FLD_VAL(hfp-1, 15, 8) |
FLD_VAL(hbp-1, 27, 20);
timing_v = FLD_VAL(vsw-1, 5, 0) | FLD_VAL(vfp, 15, 8) |
FLD_VAL(vbp, 27, 20);
} else {
timing_h = FLD_VAL(hsw-1, 7, 0) | FLD_VAL(hfp-1, 19, 8) |
FLD_VAL(hbp-1, 31, 20);
timing_v = FLD_VAL(vsw-1, 7, 0) | FLD_VAL(vfp, 19, 8) |
FLD_VAL(vbp, 31, 20);
}
so it would seem that the wider field widths are only available on
newer hardware than the old omapfb code was intended to support?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
