Issue 22: Better initialize DSS for our LCM

Reported by Nikolaus Schaller, Feb 19, 2010

when booting the kernel it appears as if quite at the beginning some 
parts of the OMAP are reset. This stops HSYNC/VSYNC until it is 
programmed again by the DSS driver.

This has two effects:
a) the boot splash disappears until the X-Server starts
b) this is running the LCM outside of the Specs where such changes 
should be announced to the LCM controller through the SPI interface. 
The bad effect is that the display "blurs out". This may 
reduce the lifetime of the liquid chrystal

Comment 1 by Nikolaus Schaller, Feb 26, 2010

There is a driver

drivers/video/omap/lcd_omap3beagle.c

but it is not clear what the role of this file is. It is compiled 
into the kernel, but it does a 768x1024 init of the omap 
framebuffer. So it appears as if it has nothing to do with the DVI 
driver and theinitialization by command line.

Comment 2 by Nikolaus Schaller, Feb 27, 2010

Here I found the documentation file for DSS2

  Documentation/arm/OMAP/DSS

and it refers to the "mode DB":

  drivers/video/modedb.c

Owner: hns

Comment 3 by Nikolaus Schaller, Feb 27, 2010

Hmmmm.

After digging into modedb.c the question is why the LCM did work at 
all for the FOSDEM demo.

We do 'omapfb.mode=dvi:480x640MR-16@60' and there is NO matching 
entry in the database!

Comment 4 by Nikolaus Schaller, Feb 28, 2010

Ok, next piece of information

http://www.linusakesson.net/hardware/beagleboard/vga.php

First, make sure to select your desired resolution at boot, e.g. 
omapfb.mode=dvi:1024x768-16@60. Avoid the R flag (reduced blanking).

When the system is up, cat the following file: 
/sys/devices/platform/omapdss/display0/timings

The output is in the format 
pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw

Field	Unit	Description
pixclock	picoseconds	The duration of one pixel
xres	pixels	Width of visible area (typically width of framebuffer)
hfp	pixels	Horizontal front porch
hbp	pixels	Horizontal back porch
hsw	pixels	Horizontal sync width
yres	rows	Height of visible area (typically height of framebuffer)
vfp	rows	Vertical front porch
vbp	rows	Vertical back porch
vsw	rows	Vertical sync "width" (in rows)
Details are available in the kernel sources, in 
Documentation/arm/OMAP/DSS.

Comment 5 by Nikolaus Schaller, Feb 28, 2010

According to the Data Sheet we should have this (minimum) timing:

22000,480/24/8/8,640/4/2/2

Comment 6 by Nikolaus Schaller, Feb 28, 2010

What we get from the initialization string

omapfb.mode=dvi:480x640MR-16@60

is

25250,480/80/48/32,640/3/6/10

All values appear to be on the safe side.

Probing with the Scope shows that the polarity of the impulses looks 
to be wrong! So it may be that the one LCM where we had good results 
may auto-detect the polarity...

Comment 7 by Nikolaus Schaller, Feb 28, 2010

At least for a Sharp Panel there is a specific/individual driver 
file:

drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c

Probably we should define a similar one for the TPO display and 
include the SPI based driver.

But - how do we enable/switch to such a driver/panel during Linux 
boot?

Comment 8 by Nikolaus Schaller, Apr 1, 2010

More information became available through:

http://groups.google.de/group/beagleboard/browse_thread/thread/998e5a
f7d6208c7b/9b1f7ab61ea1aac3#9b1f7ab61ea1aac3

Comment 9 by Nikolaus Schaller, Apr 22, 2010

The original GTA02 jbt6k driver has been added to the kernel tree 
(drivers/video/display).

Comment 10 by Nikolaus Schaller, May 19, 2010

Done. Suspend/Powerdown appears to work as well (shutdown -h now).

Status: Fixed

Letux Kernel