[PATCH 0/2] Add recommended bpp for omap dss2 generic dpi panels

This series adds a mechanism for specifying a recommended bpp for
generic dss2 dpi panels and adds a panel that uses this feature.

The panel added is the 4.3 inch display that is sold with the
Devkit8000.

Daniel Morsing (2):
  omap: dss2: Add recommended bpp option for generic dpi panels
  omap3: devkit8000: Add and use 4.3 inch display

 arch/arm/mach-omap2/board-devkit8000.c           |    2 +-
 drivers/video/omap2/displays/panel-generic-dpi.c |   41 ++++++++++++++++++++++
 2 files changed, 42 insertions(+), 1 deletions(-)

-- 
1.7.4

Currently, there is no way to specify a recommended bpp for a generic
dpi display. This patch adds a mechanism for doing so.

If no recommended bpp is specified by the driver, we fall back to the
default recommended bpp function

Signed-off-by: Daniel Morsing <redacted>
---
 drivers/video/omap2/displays/panel-generic-dpi.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index 07eb30e..b52a28f 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c

@@ -43,6 +43,8 @@ struct panel_config {
 	/* Unit: line clocks */
 	int acb;	/* ac-bias pin frequency */
 
+	int recommended_bpp; /* overrides the default bpp */
+
 	enum omap_panel_config config;
 
 	int power_on_delay;

@@ -331,6 +333,17 @@ static int generic_dpi_panel_check_timings(struct omap_dss_device *dssdev,
 	return dpi_check_timings(dssdev, timings);
 }
 
+static int generic_dpi_panel_get_bpp(struct omap_dss_device *dssdev)
+{
+	struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
+	struct panel_config *panel_config = drv_data->panel_config;
+
+	if (panel_config->recommended_bpp != 0)
+		return panel_config->recommended_bpp;
+
+	return omapdss_default_get_recommended_bpp(dssdev);
+}
+
 static struct omap_dss_driver dpi_driver = {
 	.probe		= generic_dpi_panel_probe,
 	.remove		= generic_dpi_panel_remove,

@@ -344,6 +357,8 @@ static struct omap_dss_driver dpi_driver = {
 	.get_timings	= generic_dpi_panel_get_timings,
 	.check_timings	= generic_dpi_panel_check_timings,
 
+	.get_recommended_bpp = generic_dpi_panel_get_bpp,
+
 	.driver         = {
 		.name   = "generic_dpi_panel",
 		.owner  = THIS_MODULE,

-- 
1.7.4

This patch adds a generic panel entry for the 4.3 inch display that is
sold with the devkit8000 and modifies the board file to use this
display.

Signed-off-by: Daniel Morsing <redacted>
---
Note that this patch depends on the previous one in the series.

 arch/arm/mach-omap2/board-devkit8000.c           |    2 +-
 drivers/video/omap2/displays/panel-generic-dpi.c |   26 ++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 9a2a31e..6dab13e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c

@@ -148,7 +148,7 @@ static struct regulator_consumer_supply devkit8000_vio_supply  	REGULATOR_SUPPLY("vcc", "spi2.0");
 
 static struct panel_generic_dpi_data lcd_panel = {
-	.name			= "generic",
+	.name			= "devkit_43",
 	.platform_enable        = devkit8000_panel_enable_lcd,
 	.platform_disable       = devkit8000_panel_disable_lcd,
 };

diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index b52a28f..ee9e7ea 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c

@@ -83,6 +83,32 @@ static struct panel_config generic_dpi_panels[] = {
 		.name			= "generic",
 	},
 
+	/* Devkit8000 4.3 Inch display */
+	{
+		{
+			.x_res		= 480,
+			.y_res		= 272,
+
+			.pixel_clock	= 10000,
+
+			.hfp		= 2,
+			.hsw		= 41,
+			.hbp		= 2,
+
+			.vfp		= 2,
+			.vsw		= 10,
+			.vbp		= 2,
+		},
+		.acbi			= 0x0,
+		.acb			= 0x0,
+		.recommended_bpp	= 16,
+		.config			= OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+						OMAP_DSS_LCD_IHS,
+		.power_on_delay		= 50,
+		.power_off_delay	= 100,
+		.name			= "devkit_43",
+	},
+
 	/* Sharp LQ043T1DG01 */
 	{
 		{

-- 
1.7.4

Hi,

On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:

This series adds a mechanism for specifying a recommended bpp for
generic dss2 dpi panels and adds a panel that uses this feature.

The panel added is the 4.3 inch display that is sold with the
Devkit8000.

Hmm. Devkit8000's panel is connected with 24 datalines, according to the
board file. Why do you want to use 16 bpp format for that?

 Tomi

Hi Tomi

On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:

Hi,

On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:

quoted

The panel added is the 4.3 inch display that is sold with the
Devkit8000.

Hmm. Devkit8000's panel is connected with 24 datalines, according to the
board file. Why do you want to use 16 bpp format for that?

 Tomi

Running the panel at 24 bpp or specifying 16 datalines causes color
distortion.

The only way I've been able to run the panel without color distortion,
is with 24 datalines and 16 bpp.

I'm not well versed in displays, so I might be making a mistake
somewhere. The BSP for the devkit8000 doesn't include a datasheet for
the panel, so I can't look into what's causing this weirdness.

Regards,
Daniel Morsing

On Wed, 2011-02-16 at 08:06 -0600, Daniel Morsing wrote:

Hi Tomi

On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:

quoted

Hi,

On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:

quoted

The panel added is the 4.3 inch display that is sold with the
Devkit8000.

Hmm. Devkit8000's panel is connected with 24 datalines, according to the
board file. Why do you want to use 16 bpp format for that?

 Tomi

Running the panel at 24 bpp or specifying 16 datalines causes color
distortion.

The only way I've been able to run the panel without color distortion,
is with 24 datalines and 16 bpp.

I'm not well versed in displays, so I might be making a mistake
somewhere. The BSP for the devkit8000 doesn't include a datasheet for
the panel, so I can't look into what's causing this weirdness.

I don't think I'll add a feature which doesn't make sense, to fix a
problem we don't understand =).

A datasheet I found mentions

"One 4.3� TFT LCD (With Touch panel, CHI HSIN LR043JC211 LCD
Model)"

And I found:

http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf

It looks like 24bpp display.

What kind of color distortion do you see? Perhaps the problem is
somewhere else, like wrong horizontal sync, vertical sync or pixel clock
signal setting in .config field. This info should be in the panel
datasheet, but it usually takes some deciphering to understand it =).

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:

can you try these settings.
I have these settings from other users of the 4.3 inch display.
I think only the pixel clock is a little bit slower.


//.name         = "4.3inch_LCD",
.x_res          = 480,
.y_res          = 272,
.hsw            = 41,           /* hsync_len (4) - 1 */
.hfp            = 2,            /* right_margin (4) - 1 */
.hbp            = 2,            /* left_margin (40) - 1 */
.vsw            = 10,           /* vsync_len (2) - 1 */
.vfp            = 2,            /* lower_margin */
.vbp            = 2,            /* upper_margin (8) - 1 */
.pixel_clock    = 9600,

Regards,
Thomas

On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:

On Wed, 2011-02-16 at 08:06 -0600, Daniel Morsing wrote:

quoted

Hi Tomi

On Wed, 2011-02-16 at 15:11 +0200, Tomi Valkeinen wrote:

quoted

Hi,

On Sat, 2011-02-12 at 11:02 -0600, Daniel Morsing wrote:

quoted

The panel added is the 4.3 inch display that is sold with the
Devkit8000.

Hmm. Devkit8000's panel is connected with 24 datalines, according to the
board file. Why do you want to use 16 bpp format for that?

 Tomi

Running the panel at 24 bpp or specifying 16 datalines causes color
distortion.

The only way I've been able to run the panel without color distortion,
is with 24 datalines and 16 bpp.

I'm not well versed in displays, so I might be making a mistake
somewhere. The BSP for the devkit8000 doesn't include a datasheet for
the panel, so I can't look into what's causing this weirdness.

I don't think I'll add a feature which doesn't make sense, to fix a
problem we don't understand =).

A datasheet I found mentions

"One 4.3� TFT LCD (With Touch panel, CHI HSIN LR043JC211 LCD
Model)"

And I found:

http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf

It looks like 24bpp display.

Ok I looked through the datasheet and it looks to me that i got
the .config field right. Only thing that's vague from that sheet is
which pixel clock edge the v-sync and h-sync are driven low and the
color distortion is still there with either option.

What kind of color distortion do you see? Perhaps the problem is
somewhere else, like wrong horizontal sync, vertical sync or pixel clock
signal setting in .config field. This info should be in the panel
datasheet, but it usually takes some deciphering to understand it =).

 Tomi

I'm seeing a light cyan tint to everything when running at 24bpp. Using
16 datalines causes a heavy blue tint.

Regards,
Daniel Morsing




--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 2011-02-16 at 09:42 -0600, Daniel Morsing wrote:

On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:

quoted

And I found:

http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf

It looks like 24bpp display.

Ok I looked through the datasheet and it looks to me that i got
the .config field right. Only thing that's vague from that sheet is
which pixel clock edge the v-sync and h-sync are driven low and the
color distortion is still there with either option.

quoted

What kind of color distortion do you see? Perhaps the problem is
somewhere else, like wrong horizontal sync, vertical sync or pixel clock
signal setting in .config field. This info should be in the panel
datasheet, but it usually takes some deciphering to understand it =).

 Tomi

I'm seeing a light cyan tint to everything when running at 24bpp. Using
16 datalines causes a heavy blue tint.

But with 24 datalines and 16 bpp it works? Sounds strange =). 

One thing to check are the pinmuxings (or pad configuration, as it's
called in omap3 trm).

Are you using 2.6.37 or newer kernel?

Is this also happening with other devkit8000 devices, so it's not just a
broken device?

Have you tried with an image with full red, green and blue areas, to see
if only certain colors are affected? 

And the last option is of course get a scope and see what's going on in
the datalines.

 Tomi

On Wed, 2011-02-16 at 17:58 +0200, Tomi Valkeinen wrote:

On Wed, 2011-02-16 at 09:42 -0600, Daniel Morsing wrote:

quoted

On Wed, 2011-02-16 at 16:36 +0200, Tomi Valkeinen wrote:

quoted

quoted

And I found:

http://www.timll.com/chinese/download/files/CHILIN_TECHNOLOGY.pdf

It looks like 24bpp display.

Ok I looked through the datasheet and it looks to me that i got
the .config field right. Only thing that's vague from that sheet is
which pixel clock edge the v-sync and h-sync are driven low and the
color distortion is still there with either option.

quoted

What kind of color distortion do you see? Perhaps the problem is
somewhere else, like wrong horizontal sync, vertical sync or pixel clock
signal setting in .config field. This info should be in the panel
datasheet, but it usually takes some deciphering to understand it =).

 Tomi

I'm seeing a light cyan tint to everything when running at 24bpp. Using
16 datalines causes a heavy blue tint.

But with 24 datalines and 16 bpp it works? Sounds strange =). 

One thing to check are the pinmuxings (or pad configuration, as it's
called in omap3 trm).

Are you using 2.6.37 or newer kernel?

Is this also happening with other devkit8000 devices, so it's not just a
broken device?

Have you tried with an image with full red, green and blue areas, to see
if only certain colors are affected? 

And the last option is of course get a scope and see what's going on in
the datalines.

 Tomi

Ok I've done some more testing, the result being that I'm a bit of an
idiot.

The cyan tint only appears on console text. Running any sort of program
that actually used the display worked as intended. Setting the bpp as 16
actually made all the colors muted when you actually used the display,
so it is clearly the wrong "solution".

Since no one actually uses a hardware tty on a device like this, the
issue is kinda pointless. So I'm gonna resend the panel adding patch
without the bpp hack and with the correct name.

Regards,
Daniel Morsing

Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:

So only the 4.3 inch display can be used with the devkit8000?
There are also Devkit8000 with 5.6 and 7 inch displays.

Regards,
Thomas

On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:

Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:

quoted

This patch adds a generic panel entry for the 4.3 inch display that is
sold with the devkit8000 and modifies the board file to use this
display.

So only the 4.3 inch display can be used with the devkit8000?
There are also Devkit8000 with 5.6 and 7 inch displays.

Regards,
Thomas

Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
way to specify a board using a class of displays with separate timing
settings.

One way to do it would be to add the settings to modedb, but modedb is
really only for standardized display settings. The other way to do it
would be to add a kernel config for which display you have connected to
the board, but I think that is a bad idea, because it makes everything
more complicated and switching out displays would require recompiling
the kernel.

Maybe Tomi or the fbdev guys have some input on how to best do this?

Regards,
Daniel Morsing

On Fri, 2011-02-18 at 06:55 -0600, Daniel Morsing wrote:

On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:

quoted

Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:

quoted

This patch adds a generic panel entry for the 4.3 inch display that is
sold with the devkit8000 and modifies the board file to use this
display.

So only the 4.3 inch display can be used with the devkit8000?
There are also Devkit8000 with 5.6 and 7 inch displays.

Regards,
Thomas

Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
way to specify a board using a class of displays with separate timing
settings.

One way to do it would be to add the settings to modedb, but modedb is
really only for standardized display settings. The other way to do it
would be to add a kernel config for which display you have connected to
the board, but I think that is a bad idea, because it makes everything
more complicated and switching out displays would require recompiling
the kernel.

Maybe Tomi or the fbdev guys have some input on how to best do this?

There's no proper way for this currently. And I'm not even sure what
would be a good way to do this.

Optimally the board code could read some configuration value from eeprom
or where-ever, which would tell the configuration of the board. And the
board file could then configure the correct display.

Another way would be to add a devkit8000 specific kernel parameter,
given from bootloader, which would tell the configuration. The board
file would use this parameter to configure the correct display.

 Tomi

On Fri, 2011-02-18 at 15:07 +0200, Tomi Valkeinen wrote:

On Fri, 2011-02-18 at 06:55 -0600, Daniel Morsing wrote:

quoted

On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:

quoted

Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:

quoted

This patch adds a generic panel entry for the 4.3 inch display that is
sold with the devkit8000 and modifies the board file to use this
display.

So only the 4.3 inch display can be used with the devkit8000?
There are also Devkit8000 with 5.6 and 7 inch displays.

Regards,
Thomas

Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
way to specify a board using a class of displays with separate timing
settings.

One way to do it would be to add the settings to modedb, but modedb is
really only for standardized display settings. The other way to do it
would be to add a kernel config for which display you have connected to
the board, but I think that is a bad idea, because it makes everything
more complicated and switching out displays would require recompiling
the kernel.

Maybe Tomi or the fbdev guys have some input on how to best do this?

There's no proper way for this currently. And I'm not even sure what
would be a good way to do this.

Optimally the board code could read some configuration value from eeprom
or where-ever, which would tell the configuration of the board. And the
board file could then configure the correct display.

Another way would be to add a devkit8000 specific kernel parameter,
given from bootloader, which would tell the configuration. The board
file would use this parameter to configure the correct display.

 Tomi

How about making it possible to give a generic panel name to the
omapfb.mode boot parameter? This would also solve the problem for any
future boards with different non-standard displays.

Regards,
Daniel Morsing

On Fri, 2011-02-18 at 10:18 -0600, Daniel Morsing wrote:

On Fri, 2011-02-18 at 15:07 +0200, Tomi Valkeinen wrote:

quoted

On Fri, 2011-02-18 at 06:55 -0600, Daniel Morsing wrote:

quoted

On Fri, 2011-02-18 at 13:36 +0100, Thomas Weber wrote:

quoted

Hello Daniel,

Am 12.02.2011 18:02, schrieb Daniel Morsing:

quoted

This patch adds a generic panel entry for the 4.3 inch display that is
sold with the devkit8000 and modifies the board file to use this
display.

So only the 4.3 inch display can be used with the devkit8000?
There are also Devkit8000 with 5.6 and 7 inch displays.

Regards,
Thomas

Yeah, I'll admit that the patch is a bit one-sided. I couldn't find a
way to specify a board using a class of displays with separate timing
settings.

One way to do it would be to add the settings to modedb, but modedb is
really only for standardized display settings. The other way to do it
would be to add a kernel config for which display you have connected to
the board, but I think that is a bad idea, because it makes everything
more complicated and switching out displays would require recompiling
the kernel.

Maybe Tomi or the fbdev guys have some input on how to best do this?

There's no proper way for this currently. And I'm not even sure what
would be a good way to do this.

Optimally the board code could read some configuration value from eeprom
or where-ever, which would tell the configuration of the board. And the
board file could then configure the correct display.

Another way would be to add a devkit8000 specific kernel parameter,
given from bootloader, which would tell the configuration. The board
file would use this parameter to configure the correct display.

 Tomi

How about making it possible to give a generic panel name to the
omapfb.mode boot parameter? This would also solve the problem for any
future boards with different non-standard displays.

No, that wouldn't work. omapfb driver would need to somehow know about
the generic panel driver, to be able to set it up in a special way.

 Tomi