raw LCD

Hi folks!

I need to connect embedded LCD display to a Beagleboard. I have 1.8/3.3 translator and it works. Now I need to tune the software for correct display settings (left margin, right margin etc). Is it possible to set those values from the bootargs argument or should I patch the kernel? The latter is not always good because, for example, Angstrom is in fast development and I don’t want constantly support my patch for different customers.

What you suggest?

regards,
Max

I currently work on a similar problem.

U-Boot sources (Khasim's patches) are now good and well structured
enough that you can add your own "lcd init" command to overwrite all
DSS parameters for a different display.

The Linux kernel driver appears more complex and difficult to
understand. In my first prototype board the bootargs approach did
magically work. I just changed the width, heigth in pixels and the
correct refresh rate. And it simply worked.

But on other boards we have built later on, the display just shows
stripes and looses SYNC. Using an oscilloscope has revealed so far
that we should better invert the HSYNC and VSYNC impules compared to
DVI mode (the DSS controller of the OMAP3530 can do that easily by
writing two bits in a configuration register)! So I suspect that we
did have poor signals and glitches which made the first display
luckily work.

Currently we are trying to understand how the DSS initialization works
- and how it is intended to add LCD drivers to a kernel so that we can
easily switch between DVI and LCD. I have so far tracked down (in
2.6.33) the DVI initialization to

drivers/video/omap2

But I have not yet understood how stuff in the subdirectories
"display", "dss" and "omapfb" works together. In the "displays"
directory there is even a file "panel-sharp-ls037v7dw01.c" indicating
that it is intended for adding panel drivers. But I can't answer how
this driver can be configured or enabled through bootargs or from user-
space.

So I also would appreciate if someone could shed light how it is
thought to add new LCD drivers in a way that they have a good chance
to be mainstreamed and at least don't conflict with mainstream
developments.

Nikolaus

I currently work on a similar problem.

U-Boot sources (Khasim's patches) are now good and well structured
enough that you can add your own "lcd init" command to overwrite all
DSS parameters for a different display.

The Linux kernel driver appears more complex and difficult to
understand. In my first prototype board the bootargs approach did
magically work. I just changed the width, heigth in pixels and the
correct refresh rate. And it simply worked.

But on other boards we have built later on, the display just shows
stripes and looses SYNC. Using an oscilloscope has revealed so far
that we should better invert the HSYNC and VSYNC impules compared to
DVI mode (the DSS controller of the OMAP3530 can do that easily by
writing two bits in a configuration register)! So I suspect that we
did have poor signals and glitches which made the first display
luckily work.

Currently we are trying to understand how the DSS initialization works
- and how it is intended to add LCD drivers to a kernel so that we can
easily switch between DVI and LCD. I have so far tracked down (in
2.6.33) the DVI initialization to

drivers/video/omap2

But I have not yet understood how stuff in the subdirectories
"display", "dss" and "omapfb" works together. In the "displays"
directory there is even a file "panel-sharp-ls037v7dw01.c" indicating
that it is intended for adding panel drivers. But I can't answer how
this driver can be configured or enabled through bootargs or from user-
space.

So I also would appreciate if someone could shed light how it is
thought to add new LCD drivers in a way that they have a good chance
to be mainstreamed and at least don't conflict with mainstream
developments.

Nikolaus

Have you asked Tomi Valkeinen <tomi.valkeinen@nokia.com> about this?
He wrote the DSS2 support and is very knowledgeable and usually quick to reply.

Nikolaus,

I did not peer into DSS driver yet to find out details, but I did the same for AT91 processors and it was like piece of cake. There was a structure in atmel-fb driver with actual fields left_margin, right_margin etc. So you just need to set the correct values and recompile a kernel. Sounds easy but if you have a number of display then it becomes painful to supply a number of patches for each display. Moreover sometimes an user wants to drive backlight and requires to use some GPIO which is has to be enabled in: 1) uboot (pinmux), 2) kernel.

The problem is that each LCD has own parameters like pixel frequency, porches horizontal and vertical. And you can’t just press AUTO button on the LCD like you do with your DVI monitor to align a picture. I believe we can invent some bootargs interface for LCD displays. There are not many parameters to transfer to a kernel.

BTW you can play with your embeedded LCD with fbset utility. It is intended to setup LCD parameters on-the-fly. You can set frequency, margins and everything you need for a specific display

regards,
Max

2010/3/31 Gary Thomas <gary@mlbassoc.com>

Nikolaus,

I did not peer into DSS driver yet to find out details, but I did the same
for AT91 processors and it was like piece of cake. There was a structure in
atmel-fb driver with actual fields left_margin, right_margin etc. So you
just need to set the correct values and recompile a kernel. Sounds easy but

Yes, the OMAP DSS system has something similar. But also the display
mode database so that you can specify e.g. setenv dvimode
480x640MR-16@60

if you have a number of display then it becomes painful to supply a number
of patches for each display. Moreover sometimes an user wants to drive
backlight and requires to use some GPIO which is has to be enabled in: 1)
uboot (pinmux), 2) kernel.

Yes, that is a second step which will need a specific driver. And
power management of the display as well. Fortunately I can at least
initialize this in U-Boot.

The problem is that each LCD has own parameters like pixel frequency,
porches horizontal and vertical. And you can't just press AUTO button on the

At least my display is not very critical and specifies only minumum
values for the porches. So the "defaults" (dvimode 480x640MR-16@60)
for a standard monitor are more than sufficient. It is only SYNC
polarity :slight_smile:

LCD like you do with your DVI monitor to align a picture. I believe we can
invent some bootargs interface for LCD displays. There are not many
parameters to transfer to a kernel.

Yes, that would be nice. If you can set a bootarg which defines the
LCD name and somehow the kernel chooses the right driver. Something
like

While writing this I remembered that there is something in the U-Boot
environment: defaultdisplay=dvi

So the real boot arg is

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

Maybe it is sufficient to define a LCD panel driver (in drivers/video/
omap2/display/panel-something.c) and configure it somehow.
Then, e.g.

omapfb.mode=panel:480x640MR-16@60 omapdss.def_disp=panel-something

could do it. But I am just doing educated guesses.

BTW you can play with your embeedded LCD with fbset utility. It is intended
to setup LCD parameters on-the-fly. You can set frequency, margins and
everything you need for a specific display

Thanks for this hint! There is a -hsync low | high which should do the
trick!

Now it would be easy if I could somehow pass this in the bootargs :slight_smile:

Anyway, we should contact Tomi Valkeinen as Gary has suggested.

BR,
Nikolaus

This can be possible using 'omap_dss_register_device' and
'omap_dss_register_driver' DSS internal API. For my 800x480 TFT-LCD panel
I wrote a driver(attached) using these interfaces.

Unfortunately 'omap_dss_register_device' API is not exported in DSS drivers,
although it is public. I'm not sure if this is intentional but given that
'omap_dss_register_driver' is exported, 'omap_dss_register_device' should
be as well. Anyway with the help of patch attached one can add/remove
display panels from modules into a running kernel so that patching kernel
is not needed, only module should be compiled.

Best Regards,
Caglar

--- drivers/video/omap2/dss/core.c.orig 2010-03-22 16:17:10.000000000 +0200
+++ drivers/video/omap2/dss/core.c 2010-03-31 17:02:06.981527823 +0300
@@ -880,6 +880,7 @@

   return 0;
}
+EXPORT_SYMBOL(omap_dss_register_device);

void omap_dss_unregister_device(struct omap_dss_device *dssdev)
{
@@ -890,6 +891,7 @@
     device_unregister(&panel->dev);
   }
}
+EXPORT_SYMBOL(omap_dss_unregister_device);

/* BUS */
static int omap_dss_bus_register(void)

dataimage-panel.c (2.75 KB)

This is cool! Thank you very much!

One more question - how do you select the display from the bootargs,
i.e. what is the correct syntax?

hns@computer.org ha scritto:

I currently work on a similar problem.

U-Boot sources (Khasim's patches) are now good and well structured
enough that you can add your own "lcd init" command to overwrite all
DSS parameters for a different display.

The Linux kernel driver appears more complex and difficult to
understand. In my first prototype board the bootargs approach did
magically work. I just changed the width, heigth in pixels and the
correct refresh rate. And it simply worked.

But on other boards we have built later on, the display just shows
stripes and looses SYNC. Using an oscilloscope has revealed so far
that we should better invert the HSYNC and VSYNC impules compared to
DVI mode (the DSS controller of the OMAP3530 can do that easily by
writing two bits in a configuration register)! So I suspect that we
did have poor signals and glitches which made the first display
luckily work.

Currently we are trying to understand how the DSS initialization works
- and how it is intended to add LCD drivers to a kernel so that we can
easily switch between DVI and LCD. I have so far tracked down (in
2.6.33) the DVI initialization to

drivers/video/omap2

But I have not yet understood how stuff in the subdirectories
"display", "dss" and "omapfb" works together. In the "displays"
directory there is even a file "panel-sharp-ls037v7dw01.c" indicating
that it is intended for adding panel drivers. But I can't answer how
this driver can be configured or enabled through bootargs or from user-
space.

So I also would appreciate if someone could shed light how it is
thought to add new LCD drivers in a way that they have a good chance
to be mainstreamed and at least don't conflict with mainstream
developments.

Nikolaus

Hi folks!

I need to connect embedded LCD display to a Beagleboard. I have 1.8/3.3
translator and it works. Now I need to tune the software for correct display
settings (left margin, right margin etc). Is it possible to set those values
from the bootargs argument or should I patch the kernel? The latter is not
always good because, for example, Angstrom is in fast development and I
don't want constantly support my patch for different customers.

What you suggest?

regards,
Max
    

Dear Nikolaus,
I am also working on this project. My idea is to use the RGB + sync signals that are fed to the TFP410 and use them as they are for the LCD.
I don't know if these infos can help you but
in /sys/devices/platform/omapdss/ you might echo the right timings to /display0/timings.
I didn't test it on the LCD but I took a look at the syncs on the scope and it runs pretty well.

Fabio

Hi Fabio!

I suppose your system has to know all timings and other things before a kernel is started. Otherwise you will usually see a bunch of color lines on a LCD.

Moreover what is wrong with fbset utitity which was createrd specially to set timings to a frame-buffer. You consider echoing more sophisticated method? :slight_smile:

Max

2010/4/1 Fabio Ferrario <ferrario.f@gmail.com>

I think you can't. In this method, lcd panel driver is not built-in to the
kernel so DSS can't select it while booting. Instead, you should switch at
runtime. Something like following works for me:

#!/bin/sh
export dvi=/sys/devices/platform/omapdss/display0
export lcd=/sys/devices/platform/omapdss/display2
export mgr0=/sys/devices/platform/omapdss/manager0
echo "0" > $dvi/enabled
echo "" > $mgr0/display
echo "lcd" > $mgr0/display
echo "1" > $lcd/enabled

More information is avaliable under. ${KERNELDIR}/Documentation/arm/omap2/dss.

On the other hand, if this is not good enough then you should add this driver
to your kernel. You should also patch Beagle board file and add a new display
for lcd. I'm attaching my example to the end of this mail.

Also you should remove 'omap_dss_register_device' from your panel driver since
board file will register it. Then from u-boot you can select it by passing
'omapdss.def_disp=lcd' to the kernel, for instance:

setenv mmcargs 'setenv bootargs setenv bootargs console=ttyS2,115200n8
console=tty0 omapdss.def_disp=lcd root=/dev/mmcblk0p2 rootwait
rootfstype=ext3'

Best Regards,
Caglar

--- arch/arm/mach-omap2/board-omap3beagle.c.orig 2010-04-01 08:42:38.075641481 +0300
+++ arch/arm/mach-omap2/board-omap3beagle.c 2010-04-01 10:44:50.091659734 +0300
@@ -203,6 +203,13 @@
   .platform_disable = beagle_disable_dvi,
};

+static struct omap_dss_device beagle_lcd_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "lcd",
+ .driver_name = "dataimage_7inch_tft_panel",
+ .phy.dpi.data_lines = 18,
+};

Dear Max,

for sure not, I was just trying to forward you hints from the kernel DSS
documentation, trying to answer to the question
how

                this driver can be configured or enabled through
                bootargs or from user-
                space.
                

I think that the FB lies below the DSS overlays that are fed to the
display.

In my board
fbset -fb /dev/fb -xres 720
changes the fb size and the refresh rate but I don't see this on the
scope.
Echoing to the DSS indeed changes the refresh rate easily.

Please correct me if I'm wrong, I'm pretty much a newby.

Well I currently set the current resolution with u-boot, display the
u-boot image before booting the kernel boots, than once the kernel
booted the init script sets the DSS driver...

I just found a nice feature of the DSS driver which may simplify
things a lot (look for skip_init in drivers/video/omap2/core.c)

There is a configuration variable CONFIG_FB_OMAP_BOOTLOADER_INIT. If
that one is set, the linux kernel should test for the LCD already
being initialized by u-boot and then skip any private initialization.
I expect this keeps the DSS completely running and avoids a short
flicker of the LCD until it becomes re-initialized.

Since I already do initialize DSS by a private command in my u-boot
version (to show a boot splash), this may be the simplest solution. I
am currently compiling a kernel with this configuration and if it
works, I can report results.

BR,
Nikolaus