On Mon, 21 Jun 2010, ext Zygo Blaxell wrote:
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
<vger-linux-omap-esightcorp@xxxxxxxxxxxxxxxxxxxxxx> 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?
I would suggest to use the new driver, and fix any possible bugs on that
one. The older driver is not really maintained anymore.
Of course if there's a critical bug in the old driver that appears on a
board supported in the mainline kernel, the bug should be fixed.
Tomi
