Skip to contentSkip to conversation

Add splash screen for CM-T35

PATCH Superseded Nikita Kiryanov 2 participants 22 messages Jan 29, 2013 – Jan 30, 2013

Subsystems (2)

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

v2 cover Add splash screen for CM-T35

This patchset adds splash screen support for CM-T35.
It includes the ability to initialize the display subsystem either using predefines (selected via env variable "displaytype"), or user supplied configuration options, also stored in an environment variables and pointed to by displaytype. The splash image data is currently read from NAND.

As a preparation for the above functionality this patchset adds:
- new DSS #defines
- an option for board-specific splash screen preparation, which can be invoked in lcd_logo() right before displaying the splash screen (typical use case:
load the image data from non-memory mapped storage in time for it to be displayed).
- struct panel_config is extended to support setting the gfx_format dynamically
- protection from data aborts due to unaligned bmp headers is added to lcd_logo's splashscreen section (I'm also looking into refining this protection later on).

Changes in V2:
- GFXFORMAT_RGB16 now passed to omap3_dss_panel_config() in a new field of panel_cfg. Updated existing panel_config structs to set this field to the value that was originally hardcoded into omap3_dss_panel_config(). [Jeroen Hofstee]
- Used LCD_BPP for vl_bpix. [Jeroen Hofstee]
- Added a comment to explain the choice of GFXFORMAT_RGB16. [Jeroen Hofstee]
- Added an address check (and fix) to the address of splashimage in order to avoid alignment problems with bmp header. A similar check appears in board_splash_screen_prepare() for cm_t35. [Albert ARIBAUD]
- Do not manually set gfx burst size to GFXBURSTSIZE16, as it is apparently not necessary. GFXBURSTSIZE* #defines were kept in patch 1 anyway in the hope they will be useful for someone.

Nikita Kiryanov (7):
omap3: add useful dss defines
omap3: allow dynamic selection of gfx_format
lcd: prevent unaligned memory access when displaying splash screen
lcd: add option for board specific splash screen preparation
cm-t35: add support for dvi displays
cm-t35: add support for user defined lcd parameters
cm-t35: add support for loading splash image from NAND

 README                                |    8 +
 arch/arm/include/asm/arch-omap3/dss.h |   36 +++
 board/cm_t35/Makefile                 |    1 +
 board/cm_t35/cm_t35.c                 |   68 ++++++
 board/cm_t35/display.c                |  426 +++++++++++++++++++++++++++++++++
 board/htkw/mcx/mcx.c                  |    1 +
 board/teejet/mt_ventoux/mt_ventoux.c  |    2 +
 board/ti/beagle/beagle.h              |    6 +-
 common/lcd.c                          |   23 ++
 drivers/video/omap3_dss.c             |    2 +-
 include/configs/cm_t35.h              |   11 +
 include/lcd.h                         |    1 +
 12 files changed, 582 insertions(+), 3 deletions(-)
 create mode 100644 board/cm_t35/display.c
Signature · 1 line
1.7.10.4
#1 lore raw

PATCH 1/7 omap3: add useful dss defines

Add useful omap3 dss defines for: polarity, TFT data lines, lcd display type, gfx burst size, and gfx format

---
 arch/arm/include/asm/arch-omap3/dss.h |   35 +++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
arch/arm/include/asm/arch-omap3/dss.h +35 -0
index ffaffbb..74321ae 100644
@@ -167,6 +167,41 @@ struct venc_regs {
 #define VENC_OUT_SEL				(1 << 6)
 #define DIG_LPP_SHIFT				16
 
+/* LCD display type */
+#define PASSIVE_DISPLAY			0
+#define ACTIVE_DISPLAY			1
+
+/* TFTDATALINES */
+#define LCD_INTERFACE_12_BIT	0
+#define LCD_INTERFACE_16_BIT	1
+#define LCD_INTERFACE_18_BIT	2
+#define LCD_INTERFACE_24_BIT	3
+
+/* Polarity */
+#define DSS_IVS	(1 << 12)
+#define DSS_IHS	(1 << 13)
+#define DSS_IPC	(1 << 14)
+#define DSS_IEO	(1 << 15)
+
+/* GFX format */
+#define GFXFORMAT_BITMAP1		(0x0 << 1)
+#define GFXFORMAT_BITMAP2		(0x1 << 1)
+#define GFXFORMAT_BITMAP4		(0x2 << 1)
+#define GFXFORMAT_BITMAP8		(0x3 << 1)
+#define GFXFORMAT_RGB12			(0x4 << 1)
+#define GFXFORMAT_ARGB16		(0x5 << 1)
+#define GFXFORMAT_RGB16			(0x6 << 1)
+#define GFXFORMAT_RGB24_UNPACKED	(0x8 << 1)
+#define GFXFORMAT_RGB24_PACKED		(0x9 << 1)
+#define GFXFORMAT_ARGB32		(0xC << 1)
+#define GFXFORMAT_RGBA32		(0xD << 1)
+#define GFXFORMAT_RGBx32		(0xE << 1)
+
+/* GFX burst size */
+#define GFXBURSTSIZE4	(0 << 6)
+#define GFXBURSTSIZE8	(1 << 6)
+#define GFXBURSTSIZE16	(2 << 6)
+
 /* Panel Configuration */
 struct panel_config {
 	u32 timing_h;
Signature · 1 line
1.7.10.4
#2 lore raw

PATCH 1/7 omap3: add useful dss defines

Dear Nikita Kiryanov,

Quoted 2 lines · In message <[email protected]> you wrote:

Add useful omap3 dss defines for: polarity, TFT data lines, lcd display type, gfx burst size, and gfx format

Just "useful" (as in generally useful, but mostly dead code here), or actually used somewhere?

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Often it is fatal to live too long.                          - Racine
#3 lore raw

PATCH 1/7 omap3: add useful dss defines

Hi Wolfgang Denk,

Quoted 9 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 2 lines · In message <[email protected]> you wrote:

Add useful omap3 dss defines for: polarity, TFT data lines, lcd display type, gfx burst size, and gfx format

Just "useful" (as in generally useful, but mostly dead code here), or actually used somewhere?

They are used in other patches in this series. The only exception is the #defines for gfx burst size, which were used in V1, but not in this version. I kept the gfx burst size defines in the hope they will be useful to someone, but I can remove them if you think this shouldn't be done.

Quoted 4 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.
#4 lore raw

PATCH v2 2/7 omap3: allow dynamic selection of gfx_format

In reply to Nikita Kiryanov

Currently the value of gfx_format is hardcoded into omap3_dss_panel_config(). Make it a field in struct panel_config, and update existing structs to set this field to the value that was originally hard coded.

---
NOTE: New patch in the series; no V1.

 arch/arm/include/asm/arch-omap3/dss.h |    1 +
 board/htkw/mcx/mcx.c                  |    1 +
 board/teejet/mt_ventoux/mt_ventoux.c  |    2 ++
 board/ti/beagle/beagle.h              |    6 ++++--
 drivers/video/omap3_dss.c             |    2 +-
 5 files changed, 9 insertions(+), 3 deletions(-)
arch/arm/include/asm/arch-omap3/dss.h +1 -0
index 74321ae..ad5a73e 100644
@@ -213,6 +213,7 @@ struct panel_config {
 	u32 data_lines;
 	u32 load_mode;
 	u32 panel_color;
+	u32 gfx_format;
 	void *frame_buffer;
 };
 
board/htkw/mcx/mcx.c +1 -0
index 9fe6408..5eda6c4 100644
@@ -130,6 +130,7 @@ static struct panel_config lcd_cfg = {
 	.load_mode      = 0x02, /* Frame Mode */
 	.panel_color	= 0,
 	.lcd_size	= PANEL_LCD_SIZE(800, 480),
+	.gfx_format	= GFXFORMAT_RGB24_UNPACKED,
 };
 
 int board_video_init(void)
board/teejet/mt_ventoux/mt_ventoux.c +2 -0
index c516c75..78d81d6 100644
@@ -81,6 +81,7 @@ static struct panel_config lcd_cfg[] = {
 	.data_lines     = 0x03, /* 24 Bit RGB */
 	.load_mode      = 0x02, /* Frame Mode */
 	.panel_color	= 0,
+	.gfx_format	= GFXFORMAT_RGB24_UNPACKED,
 	},
 	{
 	.timing_h       = PANEL_TIMING_H(20, 192, 4),
@@ -91,6 +92,7 @@ static struct panel_config lcd_cfg[] = {
 	.data_lines     = 0x03, /* 24 Bit RGB */
 	.load_mode      = 0x02, /* Frame Mode */
 	.panel_color	= 0,
+	.gfx_format	= GFXFORMAT_RGB24_UNPACKED,
 	}
 };
 #endif
board/ti/beagle/beagle.h +4 -2
index c0a94a9..6d71bbc 100644
@@ -544,7 +544,8 @@ static const struct panel_config dvid_cfg = {
 	.panel_type	= 0x01, /* TFT */
 	.data_lines	= 0x03, /* 24 Bit RGB */
 	.load_mode	= 0x02, /* Frame Mode */
-	.panel_color	= DVI_BEAGLE_ORANGE_COL /* ORANGE */
+	.panel_color	= DVI_BEAGLE_ORANGE_COL, /* ORANGE */
+	.gfx_format	= GFXFORMAT_RGB24_UNPACKED,
 };
 
 static const struct panel_config dvid_cfg_xm = {
@@ -556,6 +557,7 @@ static const struct panel_config dvid_cfg_xm = {
 	.panel_type	= 0x01, /* TFT */
 	.data_lines	= 0x03, /* 24 Bit RGB */
 	.load_mode	= 0x02, /* Frame Mode */
-	.panel_color	= DVI_BEAGLE_ORANGE_COL /* ORANGE */
+	.panel_color	= DVI_BEAGLE_ORANGE_COL, /* ORANGE */
+	.gfx_format	= GFXFORMAT_RGB24_UNPACKED,
 };
 #endif
drivers/video/omap3_dss.c +1 -1
index b1424bf..6efba12 100644
@@ -121,7 +121,7 @@ void omap3_dss_panel_config(const struct panel_config *panel_cfg)
 	if (!panel_cfg->frame_buffer)
 		return;
 
-	writel(8 << GFX_FORMAT_SHIFT | GFX_ENABLE, &dispc->gfx_attributes);
+	writel(panel_cfg->gfx_format | GFX_ENABLE, &dispc->gfx_attributes);
 	writel(1, &dispc->gfx_row_inc);
 	writel(1, &dispc->gfx_pixel_inc);
 	writel(panel_cfg->lcd_size, &dispc->gfx_size);
Signature · 1 line
1.7.10.4
#5 lore raw

PATCH v2 2/7 omap3: allow dynamic selection of gfx_format

Dear Nikita Kiryanov,

Quoted 4 lines · In message <[email protected]> you wrote:

Currently the value of gfx_format is hardcoded into omap3_dss_panel_config(). Make it a field in struct panel_config, and update existing structs to set this field to the value that was originally hard coded.

It is not exactly clear to me what exactly this is needed for? Are you just adding dead code? if not, then please explain this in the commit message.

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_
#6 lore raw

PATCH v2 2/7 omap3: allow dynamic selection of gfx_format

Hi Wolfgang Denk,

Quoted 11 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 4 lines · In message <[email protected]> you wrote:

Currently the value of gfx_format is hardcoded into omap3_dss_panel_config(). Make it a field in struct panel_config, and update existing structs to set this field to the value that was originally hard coded.

It is not exactly clear to me what exactly this is needed for? Are you just adding dead code? if not, then please explain this in the commit message.

Currently if you want to use a gfx format other than what omap3_dss_panel_config() sets, you have to change it manually. It was suggested in the review of V1 that it would be better if this value could simply be passed to omap3_dss_panel_config() so that there wouldn't be a need for adjustments.

I'll try to rephrase the commit message to explain the benefits of this.

Quoted 5 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.
#7 lore raw

PATCH v2 3/7 lcd: prevent unaligned memory access when displaying splash screen

In reply to Nikita Kiryanov

When the bmp file is loaded to an address specified by the environment variable "splashimage", its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by mostly 32 bit fields, so when the address in splashimage is not equal to aligned address plus/minus 2, the 32 bit members will be placed in unaligned addresses. This results in a data abort on targets that cannot handle unaligned memory accesses.

Check that the address is safe to use, and fix it if it's not.

---
NOTE: New patch in the series; no V1.

 common/lcd.c |    8 ++++++++
 1 file changed, 8 insertions(+)
common/lcd.c +8 -0
index 66d4f94..104125d 100644
@@ -1046,6 +1046,14 @@ static void *lcd_logo(void)
 		do_splash = 0;
 
 		addr = simple_strtoul (s, NULL, 16);
+		/*
+		 * In order for the fields of bmp header to be properly aligned
+		 * in memory, splash image addr must be aligned to "aligned
+		 * address plus 2". Fix addr if necessary.
+		 */
+		if (addr % 4 != 2)
+			addr += (addr % 4) ?: 2;
+
 #ifdef CONFIG_SPLASH_SCREEN_ALIGN
 		s = getenv("splashpos");
 		if (s != NULL) {
Signature · 1 line
1.7.10.4
#8 lore raw

PATCH v2 3/7 lcd: prevent unaligned memory access when displaying splash screen

Dear Nikita Kiryanov,

Quoted 7 lines · In message <[email protected]> you wrote:

When the bmp file is loaded to an address specified by the environment variable "splashimage", its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by mostly 32 bit fields, so when the address in splashimage is not equal to aligned address plus/minus 2, the 32 bit members will be placed in unaligned addresses. This results in a data abort on targets that cannot handle unaligned memory accesses.

I don;t understand your +/- 2 argument. When there are 32 bit fielkds in the header, these have to be 32 bit aligned, right?

Quoted 1 line

Check that the address is safe to use, and fix it if it's not.

If you perform any such fixes (thus essentially not doing what the user asked for), you should at least print a warning message so the user gets aware of such issues.

Also, you should add the video custodian on Cc: for such patches.

[Done here].

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are some good people in it, but the orchestra as  a  whole  is
equivalent to a gang bent on destruction."      - John Cage, composer
#9 lore raw

PATCH v2 3/7 lcd: prevent unaligned memory access when displaying splash screen

Hi Wolfgang Denk,

Quoted 11 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 7 lines · In message <[email protected]> you wrote:

When the bmp file is loaded to an address specified by the environment variable "splashimage", its header members might be unaligned.
This happens because the bmp header starts with two byte-size fields followd by mostly 32 bit fields, so when the address in splashimage is not equal to aligned address plus/minus 2, the 32 bit members will be placed in unaligned addresses. This results in a data abort on targets that cannot handle unaligned memory accesses.

Quoted 2 lines

I don;t understand your +/- 2 argument. When there are 32 bit fielkds in the header, these have to be 32 bit aligned, right?

Right. The problem stems from the structure of the bmp header, which places the 32 bit fields at an offset of 2 from the load address.

From bmp_layout.h:

typedef struct bmp_header {
	/* Header */
	char signature[2];   <--- This is what's causing the offset
	__u32	file_size;
	__u32	reserved;
	__u32	data_offset;

...
}

This means that in order for these 32 bit fields to be properly aligned when you load the bmp into memory, it has to be placed with a +/- offset relative to an aligned address to cancel the shift that
char signature[2] causes.

Quoted 10 lines
Quoted 2 lines

Check that the address is safe to use, and fix it if it's not.

If you perform any such fixes (thus essentially not doing what the user asked for), you should at least print a warning message so the user gets aware of such issues.

Also, you should add the video custodian on Cc: for such patches.

[Done here].

Thanks, I'll do that in the future.

Quoted 6 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.
#10 lore raw

PATCH 4/7 lcd: add option for board specific splash screen preparation

In reply to Nikita Kiryanov

Currently there is no logical place to put the code that prepares the splash image data. The splash image data should be ready in memory before bmp_display() is called, and after the environment is ready (since lcd.c looks for the splash image in an address specified by the environment variable "splashimage").

Our window of opportunity in board_init_r() is therefore: between env_relocate() and bmp_display(), and from the available options only the lcd related functions in drv_lcd_init() seem appropriate for such lcd oriented code.

Add the option to prepare the splash image data in lcd_logo() right before it is sent to be displayed.

---
 README        |    8 ++++++++
 common/lcd.c  |   15 +++++++++++++++
 include/lcd.h |    1 +
 3 files changed, 24 insertions(+)
README +8 -0
index a336476..89694d7 100644
@@ -1550,6 +1550,14 @@ CBFS (Coreboot Filesystem) support
 			=> vertically centered image
 			   at x = dspWidth - bmpWidth - 9
 
+		CONFIG_SPLASH_SCREEN_PREPARE
+
+		If this option is set then the board_splash_screen_prepare()
+		function, which must be defined in your code, is called as part
+		of the splash screen display sequence. It gives the board an
+		opportunity to prepare the splash image data before it is
+		processed and sent to the frame buffer by U-Boot.
+
 - Gzip compressed BMP image support: CONFIG_VIDEO_BMP_GZIP
 
 		If this option is set, additionally to standard BMP
common/lcd.c +15 -0
index 104125d..bb8a7d2 100644
@@ -1034,6 +1034,18 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
 }
 #endif
 
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+static inline int splash_screen_prepare(void)
+{
+	return board_splash_screen_prepare();
+}
+#else
+static inline int splash_screen_prepare(void)
+{
+	return 0;
+}
+#endif
+
 static void *lcd_logo(void)
 {
 #ifdef CONFIG_SPLASH_SCREEN
@@ -1045,6 +1057,9 @@ static void *lcd_logo(void)
 		int x = 0, y = 0;
 		do_splash = 0;
 
+		if (splash_screen_prepare())
+			return (void *)gd->fb_base;
+
 		addr = simple_strtoul (s, NULL, 16);
 		/*
 		 * In order for the fields of bmp header to be properly aligned
include/lcd.h +1 -0
index c24164a..4ac4ddd 100644
@@ -47,6 +47,7 @@ extern struct vidinfo panel_info;
 
 extern void lcd_ctrl_init (void *lcdbase);
 extern void lcd_enable (void);
+extern int board_splash_screen_prepare(void);
 
 /* setcolreg used in 8bpp/16bpp; initcolregs used in monochrome */
 extern void lcd_setcolreg (ushort regno,
Signature · 1 line
1.7.10.4
#11 lore raw

PATCH 4/7 lcd: add option for board specific splash screen preparation

Dear Nikita Kiryanov,

Quoted 11 lines · In message <[email protected]> you wrote:

Currently there is no logical place to put the code that prepares the splash image data. The splash image data should be ready in memory before bmp_display() is called, and after the environment is ready (since lcd.c looks for the splash image in an address specified by the environment variable "splashimage").

Our window of opportunity in board_init_r() is therefore: between env_relocate() and bmp_display(), and from the available options only the lcd related functions in drv_lcd_init() seem appropriate for such lcd oriented code.

Quoted 5 lines

Add the option to prepare the splash image data in lcd_logo() right before it is sent to be displayed.

You should add the video custodian on Cc: for such patches.

[Done here].

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He only drinks when he gets depressed." "Why does he get depressed?"
"Sometimes it's because he hasn't had a drink."
                                     - Terry Pratchett, _Men at Arms_
#12 lore raw

PATCH 4/7 lcd: add option for board specific splash screen preparation

Hi Wolfgang Denk,

Quoted 17 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 14 lines · In message <[email protected]> you wrote:

Currently there is no logical place to put the code that prepares the splash image data. The splash image data should be ready in memory before bmp_display() is called, and after the environment is ready (since lcd.c looks for the splash image in an address specified by the environment variable "splashimage").

Our window of opportunity in board_init_r() is therefore: between env_relocate() and bmp_display(), and from the available options only the lcd related functions in drv_lcd_init() seem appropriate for such lcd oriented code.

Add the option to prepare the splash image data in lcd_logo() right before it is sent to be displayed.

Quoted 6 lines
Quoted 2 lines

You should add the video custodian on Cc: for such patches.

[Done here].

Will do...
I did Cc Anatolij when running git send-patch though... It's possible that it was dropped by mailman (see this discussion:
http://www.mail-archive.com/u-boot at lists.denx.de/msg103585.html) but he should still get the email.

Anyway, I'll start using the Cc line in the patches as requested..

Quoted 5 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.
#13 lore raw

PATCH v2 5/7 cm-t35: add support for dvi displays

In reply to Nikita Kiryanov

Add support for dvi displays with user selectable dvi presets.

---
Changes in V2:
- Used LCD_BPP for vl_bpix [Jeroen Hofstee]
- GFXFORMAT_RGB16 now passed to omap3_dss_panel_config() as part of panel_cfg predefines. [Jeroen Hofstee]
- Added a comment to explain the choice of GFXFORMAT_RGB16. [Jeroen Hofstee]
- Do not set gfx burst size to GFXBURSTSIZE16, as it is apparently not necessary.

 board/cm_t35/Makefile    |    1 +
 board/cm_t35/cm_t35.c    |    3 +
 board/cm_t35/display.c   |  218 ++++++++++++++++++++++++++++++++++++++++++++++
 include/configs/cm_t35.h |    7 ++
 4 files changed, 229 insertions(+)
 create mode 100644 board/cm_t35/display.c
board/cm_t35/Makefile +1 -0
index 894fa09..bde56e6 100644
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB	= $(obj)lib$(BOARD).o
 
 COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += eeprom.o
+COBJS-$(CONFIG_LCD) += display.o
 
 COBJS	:= cm_t35.o leds.o $(COBJS-y)
 
board/cm_t35/cm_t35.c +3 -0
index edbb941..8f3d735 100644
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
 	/* SB-T35 Ethernet */
 	MUX_VAL(CP(GPMC_NCS4),		(IEN  | PTU | EN  | M0)); /*GPMC_nCS4*/
 
+	/* DVI enable */
+	MUX_VAL(CP(GPMC_NCS3),		(IDIS  | PTU | DIS  | M4));/*GPMC_nCS3*/
+
 	/* CM-T3x Ethernet */
 	MUX_VAL(CP(GPMC_NCS5),		(IDIS | PTU | DIS | M0)); /*GPMC_nCS5*/
 	MUX_VAL(CP(GPMC_CLK),		(IEN  | PTD | DIS | M4)); /*GPIO_59*/
board/cm_t35/display.c new file +218 -0

218 lines not on this page · raw message

include/configs/cm_t35.h +7 -0
index 7d07215..46d35ba 100644
@@ -338,4 +338,11 @@
 #define CONFIG_OMAP3_GPIO_6	/* GPIO186 is in GPIO bank 6  */
 #endif
 
+/* Display Configuration */
+#define CONFIG_OMAP3_GPIO_2
+#define CONFIG_VIDEO_OMAP3
+#define LCD_BPP		LCD_COLOR16
+
+#define CONFIG_LCD
+
 #endif /* __CONFIG_H */
Signature · 1 line
1.7.10.4
#14 lore raw

PATCH v2 5/7 cm-t35: add support for dvi displays

Dear Nikita Kiryanov,

Quoted 1 line · In message <[email protected]> you wrote:

Add support for dvi displays with user selectable dvi presets.

...

board/cm_t35/cm_t35.c static void cm_t3x_set_common_muxconf(void) · line 220

Quoted 8 lines
board/cm_t35/cm_t35.c +2 -0
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
 	/* SB-T35 Ethernet */
 	MUX_VAL(CP(GPMC_NCS4),		(IEN  | PTU | EN  | M0)); /*GPMC_nCS4*/
 
+	/* DVI enable */
+	MUX_VAL(CP(GPMC_NCS3),		(IDIS  | PTU | DIS  | M4));/*GPMC_nCS3*/

Is it intentional and correct to always enable DVI, even when this is not configured by the user?

board/cm_t35/cm_t35.c static void cm_t3x_set_common_muxconf(void) · line 222

Quoted 2 lines
board/cm_t35/cm_t35.c +2 -0
+/*
+ * The frame buffer is allocated before we have the chance to parse user input.

This seems broken to me.

Please explain why you think so?

board/cm_t35/cm_t35.c static void cm_t3x_set_common_muxconf(void)

Quoted 7 lines
board/cm_t35/cm_t35.c +7 -0
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+	.vl_col  = 1400,
+	.vl_row  = 1050,
+	.vl_bpix = LCD_BPP,
+	.cmap = (ushort *)0x80100000,

Can we please avoid such hard coded magic numbers?

Quoted 6 lines

+/*
+ * env_parse_displaytype() - parse display type.
+ *
+ * Parses the environment variable "displaytype", which contains the
+ * name of the display type or preset, in which case it applies its
+ * configurations.

So we have yet another custom implementation for setting the display type? Can we please agree on using common standard methods? thanks.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A father doesn't destroy his children.
	-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
	   stardate 3468.1.
#15 lore raw

PATCH v2 5/7 cm-t35: add support for dvi displays

Hi Wolfgang Denk,

Quoted 11 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 1 line · In message <[email protected]> you wrote:

Add support for dvi displays with user selectable dvi presets.

...

Quoted 6 lines
board/cm_t35/cm_t35.c +0 -0
@@ -216,6 +216,9 @@ static void cm_t3x_set_common_muxconf(void)
  	/* SB-T35 Ethernet */
  	MUX_VAL(CP(GPMC_NCS4),		(IEN  | PTU | EN  | M0)); /*GPMC_nCS4*/
 
Quoted 5 lines

board/cm_t35/cm_t35.c static void cm_t3x_set_common_muxconf(void) · line 220

Quoted 2 lines
board/cm_t35/cm_t35.c +2 -0
+	/* DVI enable */
+	MUX_VAL(CP(GPMC_NCS3),		(IDIS  | PTU | DIS  | M4));/*GPMC_nCS3*/

Is it intentional and correct to always enable DVI, even when this is not configured by the user?

This simply prepares the mux that makes it possible to enable DVI. The actual enabling of DVI is indeed conditional on user setup.

Quoted 6 lines

board/cm_t35/cm_t35.c static void cm_t3x_set_common_muxconf(void) · line 222

Quoted 4 lines
board/cm_t35/cm_t35.c +2 -0
+/*
+ * The frame buffer is allocated before we have the chance to parse user input.

This seems broken to me.

Agreed.

Quoted 2 lines

Please explain why you think so?

This isn't just my impression. A patch was submitted by Stephen Warren to address this issue (http://patchwork.ozlabs.org/patch/212378/), but it isn't in mainline yet.

Quoted 10 lines

board/cm_t35/cm_t35.c static void cm_t3x_set_common_muxconf(void)

Quoted 8 lines
board/cm_t35/cm_t35.c +7 -0
+ * vl_{col | row} to the maximal resolution supported by OMAP3.
+ */
+vidinfo_t panel_info = {
+	.vl_col  = 1400,
+	.vl_row  = 1050,
+	.vl_bpix = LCD_BPP,
+	.cmap = (ushort *)0x80100000,

Can we please avoid such hard coded magic numbers?

OK.

Quoted 11 lines
Quoted 8 lines

+/*
+ * env_parse_displaytype() - parse display type.
+ *
+ * Parses the environment variable "displaytype", which contains the
+ * name of the display type or preset, in which case it applies its
+ * configurations.

So we have yet another custom implementation for setting the display type? Can we please agree on using common standard methods? thanks.

Most of what is custom in this patchset is parsing of environment variables. For actually setting up the DSS I do use common code (specifically omap3_dss_panel_config() and related structs/defines).

Quoted 6 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.
#16 lore raw

PATCH v2 6/7 cm-t35: add support for user defined lcd parameters

In reply to Nikita Kiryanov

Add support for user defined lcd parameters for cm-t35 splash screen.

---
Changes in V2:
- Set gfx_format to GFXFORMAT_RGB16 after parsing custom lcd settings.

 board/cm_t35/display.c |  214 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 211 insertions(+), 3 deletions(-)
board/cm_t35/display.c +211 -3
index da7784a..6d46762 100644
@@ -3,6 +3,8 @@
  *
  * Authors: Nikita Kiryanov <[email protected]>
  *
+ * Parsing code based on linux/drivers/video/pxafb.c
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -33,6 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
 enum display_type {
 	NONE,
 	DVI,
+	DVI_CUSTOM,
 };
 
 /*
@@ -150,6 +153,206 @@ static enum display_type set_dvi_preset(const struct panel_config preset,
 }
 
 /*
+ * parse_mode() - parse the mode parameter of custom lcd settings
+ *
+ * @mode:	<res_x>x<res_y>
+ *
+ * Returns -1 on error, 0 on success.
+ */
+static int parse_mode(const char *mode)
+{
+	unsigned int modelen = strlen(mode);
+	int res_specified = 0;
+	unsigned int xres = 0, yres = 0;
+	int yres_specified = 0;
+	int i;
+
+	for (i = modelen - 1; i >= 0; i--) {
+		switch (mode[i]) {
+		case 'x':
+			if (!yres_specified) {
+				yres = simple_strtoul(&mode[i + 1], NULL, 0);
+				yres_specified = 1;
+			} else {
+				goto done_parsing;
+			}
+
+			break;
+		case '0' ... '9':
+			break;
+		default:
+			goto done_parsing;
+		}
+	}
+
+	if (i < 0 && yres_specified) {
+		xres = simple_strtoul(mode, NULL, 0);
+		res_specified = 1;
+	}
+
+done_parsing:
+	if (res_specified) {
+		set_resolution_params(xres, yres);
+	} else {
+		printf("LCD: invalid mode: %s\n", mode);
+		return -1;
+	}
+
+	return 0;
+}
+
+#define PIXEL_CLK_NUMERATOR (26 * 432 / 39)
+/*
+ * parse_pixclock() - Parse the pixclock parameter of custom lcd settings
+ *
+ * @pixclock:	the desired pixel clock
+ *
+ * Returns -1 on error, 0 on success.
+ *
+ * Handling the pixel_clock:
+ *
+ * Pixel clock is defined in the OMAP35x TRM as follows:
+ * pixel_clock =
+ * (SYS_CLK * 2 * PRCM.CM_CLKSEL2_PLL[18:8]) /
+ * (DSS.DISPC_DIVISOR[23:16] * DSS.DISPC_DIVISOR[6:0] *
+ * PRCM.CM_CLKSEL_DSS[4:0] * (PRCM.CM_CLKSEL2_PLL[6:0] + 1))
+ *
+ * In practice, this means that in order to set the
+ * divisor for the desired pixel clock one needs to
+ * solve the following equation:
+ *
+ * 26 * 432 / (39 * <pixel_clock>) = DSS.DISPC_DIVISOR[6:0]
+ *
+ * NOTE: the explicit equation above is reduced. Do not
+ * try to infer anything from these numbers.
+ */
+static int parse_pixclock(char *pixclock)
+{
+	int divisor, pixclock_val;
+	char *pixclk_start = pixclock;
+
+	pixclock_val = simple_strtoul(pixclock, &pixclock, 10);
+	divisor = DIV_ROUND_UP(PIXEL_CLK_NUMERATOR, pixclock_val);
+	/* 0 and 1 are illegal values for PCD */
+	if (divisor <= 1)
+		divisor = 2;
+
+	panel_cfg.divisor = divisor | (1 << 16);
+	if (pixclock[0] != '\0') {
+		printf("LCD: invalid value for pixclock:%s\n", pixclk_start);
+		return -1;
+	}
+
+	return 0;
+}
+
+/*
+ * parse_setting() - parse a single setting of custom lcd parameters
+ *
+ * @setting:	The custom lcd setting <name>:<value>
+ *
+ * Returns -1 on failure, 0 on success.
+ */
+static int parse_setting(char *setting)
+{
+	int num_val;
+	char *setting_start = setting;
+
+	if (!strncmp(setting, "mode:", 5)) {
+		return parse_mode(setting + 5);
+	} else if (!strncmp(setting, "pixclock:", 9)) {
+		return parse_pixclock(setting + 9);
+	} else if (!strncmp(setting, "left:", 5)) {
+		num_val = simple_strtoul(setting + 5, &setting, 0);
+		panel_cfg.timing_h |= DSS_HBP(num_val);
+	} else if (!strncmp(setting, "right:", 6)) {
+		num_val = simple_strtoul(setting + 6, &setting, 0);
+		panel_cfg.timing_h |= DSS_HFP(num_val);
+	} else if (!strncmp(setting, "upper:", 6)) {
+		num_val = simple_strtoul(setting + 6, &setting, 0);
+		panel_cfg.timing_v |= DSS_VBP(num_val);
+	} else if (!strncmp(setting, "lower:", 6)) {
+		num_val = simple_strtoul(setting + 6, &setting, 0);
+		panel_cfg.timing_v |= DSS_VFP(num_val);
+	} else if (!strncmp(setting, "hsynclen:", 9)) {
+		num_val = simple_strtoul(setting + 9, &setting, 0);
+		panel_cfg.timing_h |= DSS_HSW(num_val);
+	} else if (!strncmp(setting, "vsynclen:", 9)) {
+		num_val = simple_strtoul(setting + 9, &setting, 0);
+		panel_cfg.timing_v |= DSS_VSW(num_val);
+	} else if (!strncmp(setting, "hsync:", 6)) {
+		if (simple_strtoul(setting + 6, &setting, 0) == 0)
+			panel_cfg.pol_freq |= DSS_IHS;
+		else
+			panel_cfg.pol_freq &= ~DSS_IHS;
+	} else if (!strncmp(setting, "vsync:", 6)) {
+		if (simple_strtoul(setting + 6, &setting, 0) == 0)
+			panel_cfg.pol_freq |= DSS_IVS;
+		else
+			panel_cfg.pol_freq &= ~DSS_IVS;
+	} else if (!strncmp(setting, "outputen:", 9)) {
+		if (simple_strtoul(setting + 9, &setting, 0) == 0)
+			panel_cfg.pol_freq |= DSS_IEO;
+		else
+			panel_cfg.pol_freq &= ~DSS_IEO;
+	} else if (!strncmp(setting, "pixclockpol:", 12)) {
+		if (simple_strtoul(setting + 12, &setting, 0) == 0)
+			panel_cfg.pol_freq |= DSS_IPC;
+		else
+			panel_cfg.pol_freq &= ~DSS_IPC;
+	} else if (!strncmp(setting, "active", 6)) {
+		panel_cfg.panel_type = ACTIVE_DISPLAY;
+		return 0; /* Avoid sanity check below */
+	} else if (!strncmp(setting, "passive", 7)) {
+		panel_cfg.panel_type = PASSIVE_DISPLAY;
+		return 0; /* Avoid sanity check below */
+	} else if (!strncmp(setting, "display:", 8)) {
+		if (!strncmp(setting + 8, "dvi", 3)) {
+			lcd_def = DVI_CUSTOM;
+			return 0; /* Avoid sanity check below */
+		}
+	} else {
+		printf("LCD: unknown option %s\n", setting_start);
+		return -1;
+	}
+
+	if (setting[0] != '\0') {
+		printf("LCD: invalid value for %s\n", setting_start);
+		return -1;
+	}
+
+	return 0;
+}
+
+/*
+ * env_parse_customlcd() - parse custom lcd params from an environment variable.
+ *
+ * @custom_lcd_params:	The environment variable containing the lcd params.
+ *
+ * Returns -1 on failure, 0 on success.
+ */
+static int parse_customlcd(char *custom_lcd_params)
+{
+	char params_cpy[160];
+	char *setting;
+
+	strncpy(params_cpy, custom_lcd_params, 160);
+	setting = strtok(params_cpy, ",");
+	while (setting) {
+		if (parse_setting(setting) < 0)
+			return -1;
+
+		setting = strtok(NULL, ",");
+	}
+
+	/* Currently we don't support changing this via custom lcd params */
+	panel_cfg.data_lines = LCD_INTERFACE_24_BIT;
+	panel_cfg.gfx_format = GFXFORMAT_RGB16; /* See dvi predefines note */
+
+	return 0;
+}
+
+/*
  * env_parse_displaytype() - parse display type.
  *
  * Parses the environment variable "displaytype", which contains the
@@ -187,14 +390,19 @@ void *lcd_console_address;
 void lcd_ctrl_init(void *lcdbase)
 {
 	struct prcm *prcm = (struct prcm *)PRCM_BASE;
+	char *custom_lcd;
 	char *displaytype = getenv("displaytype");
 
 	if (displaytype == NULL)
 		return;
 
 	lcd_def = env_parse_displaytype(displaytype);
-	if (lcd_def == NONE)
-		return;
+	/* If we did not recognize the preset, check if it's an env variable */
+	if (lcd_def == NONE) {
+		custom_lcd = getenv(displaytype);
+		if (custom_lcd == NULL || parse_customlcd(custom_lcd) < 0)
+			return;
+	}
 
 	panel_cfg.frame_buffer = lcdbase;
 	omap3_dss_panel_config(&panel_cfg);
@@ -209,7 +417,7 @@ void lcd_ctrl_init(void *lcdbase)
 
 void lcd_enable(void)
 {
-	if (lcd_def == DVI) {
+	if (lcd_def == DVI || lcd_def == DVI_CUSTOM) {
 		gpio_direction_output(54, 0); /* Turn on DVI */
 		omap3_dss_enable();
 	}
Signature · 1 line
1.7.10.4
#17 lore raw

PATCH v2 6/7 cm-t35: add support for user defined lcd parameters

Dear Nikita Kiryanov,

Quoted 1 line · In message <[email protected]> you wrote:

Add support for user defined lcd parameters for cm-t35 splash screen.

Why do you implement another custom method to configure the display? This has been done before, and we should reuse existing methods.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Name one thing windows is better than unix in?
                                          Making money for Microsoft?
         -- Randal L. Schwartz in <[email protected]>
#18 lore raw

PATCH v2 6/7 cm-t35: add support for user defined lcd parameters

Hi Wolfgang Denk,

Quoted 8 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 1 line · In message <[email protected]> you wrote:

Add support for user defined lcd parameters for cm-t35 splash screen.

Why do you implement another custom method to configure the display? This has been done before, and we should reuse existing methods.

This patch implements a user interface, not reimplements methods that configure the DSS. For that, I'm still using omap3_dss_panel_config(), struct panel_config, and omap3_dss.h #defines.

Quoted 4 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.
#19 lore raw

PATCH v2 7/7 cm-t35: add support for loading splash image from NAND

In reply to Nikita Kiryanov

Add support for loading splash image from NAND

---
Changes in V2:
- Added fix to bmp_load_addr to comply with what happens in lcd.c following patch number 3.

 board/cm_t35/cm_t35.c    |   65 ++++++++++++++++++++++++++++++++++++++++++++++
 include/configs/cm_t35.h |    4 +++
 2 files changed, 69 insertions(+)
board/cm_t35/cm_t35.c +65 -0
index 8f3d735..9ad5cbe 100644
@@ -33,7 +33,9 @@
 #include <net.h>
 #include <i2c.h>
 #include <usb.h>
+#include <nand.h>
 #include <twl4030.h>
+#include <bmp_layout.h>
 #include <linux/compiler.h>
 
 #include <asm/io.h>
@@ -75,6 +77,69 @@ static u32 gpmc_nand_config[GPMC_MAX_REG] = {
 	0,
 };
 
+#ifdef CONFIG_LCD
+#ifdef CONFIG_CMD_NAND
+static int splash_load_from_nand(u32 bmp_load_addr)
+{
+	struct bmp_header *bmp_hdr;
+	int res, splash_screen_nand_offset = 0x100000;
+	size_t bmp_size, bmp_header_size = sizeof(struct bmp_header);
+
+	if (bmp_load_addr + bmp_header_size >= gd->start_addr_sp)
+		goto splash_address_too_high;
+
+	res = nand_read_skip_bad(&nand_info[nand_curr_device],
+			splash_screen_nand_offset, &bmp_header_size,
+			(u_char *)bmp_load_addr);
+	if (res < 0)
+		return res;
+
+	bmp_hdr = (struct bmp_header *)bmp_load_addr;
+	bmp_size = le32_to_cpu(bmp_hdr->file_size);
+
+	if (bmp_load_addr + bmp_size >= gd->start_addr_sp)
+		goto splash_address_too_high;
+
+	return nand_read_skip_bad(&nand_info[nand_curr_device],
+			splash_screen_nand_offset, &bmp_size,
+			(u_char *)bmp_load_addr);
+
+splash_address_too_high:
+	printf("Error: splashimage address too high. Data overwrites U-Boot "
+		"and/or placed beyond DRAM boundaries.\n");
+
+	return -1;
+}
+#else
+static inline int splash_load_from_nand(void)
+{
+	return -1;
+}
+#endif /* CONFIG_CMD_NAND */
+
+int board_splash_screen_prepare(void)
+{
+	char *env_splashimage_value;
+	u32 bmp_load_addr;
+
+	env_splashimage_value = getenv("splashimage");
+	if (env_splashimage_value == NULL)
+		return -1;
+
+	bmp_load_addr = simple_strtoul(env_splashimage_value, 0, 16);
+	if (bmp_load_addr == 0) {
+		printf("Error: bad splashimage address specified\n");
+		return -1;
+	}
+
+	/* Fix bmp_load_addr to the alignment that lcd.c expects */
+	if (bmp_load_addr % 4 != 2)
+		bmp_load_addr += (bmp_load_addr % 4) ?: 2;
+
+	return splash_load_from_nand(bmp_load_addr);
+}
+#endif /* CONFIG_LCD */
+
 /*
  * Routine: board_init
  * Description: hardware init.
include/configs/cm_t35.h +4 -0
index 46d35ba..53c4e3c 100644
@@ -344,5 +344,9 @@
 #define LCD_BPP		LCD_COLOR16
 
 #define CONFIG_LCD
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+#define CONFIG_SPLASH_SCREEN_PREPARE
 
 #endif /* __CONFIG_H */
Signature · 1 line
1.7.10.4
#20 lore raw

PATCH v2 7/7 cm-t35: add support for loading splash image from NAND

Dear Nikita Kiryanov,

Quoted 4 lines · In message <[email protected]> you wrote:

Add support for loading splash image from NAND

Quoted 8 lines

---
Changes in V2:
- Added fix to bmp_load_addr to comply with what happens in lcd.c following patch number 3.

 board/cm_t35/cm_t35.c    |   65 ++++++++++++++++++++++++++++++++++++++++++++++
 include/configs/cm_t35.h |    4 +++
 2 files changed, 69 insertions(+)

Why exactly do you need to add code here?

Is it not sufficient to add, for example, a "nand read" command as part of your "preboot" settings?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the strict scientific sense we all feed on death -- even
vegetarians.
	-- Spock, "Wolf in the Fold", stardate 3615.4
#21 lore raw

PATCH v2 7/7 cm-t35: add support for loading splash image from NAND

Hi Wolfgang Denk,

Quoted 12 lines · Wolfgang Denk

Dear Nikita Kiryanov,

Quoted 9 lines · In message <[email protected]> you wrote:

Add support for loading splash image from NAND

---
Changes in V2:
- Added fix to bmp_load_addr to comply with what happens in lcd.c following patch number 3.

Quoted 8 lines
Quoted 3 lines
  board/cm_t35/cm_t35.c    |   65 ++++++++++++++++++++++++++++++++++++++++++++++
  include/configs/cm_t35.h |    4 +++
  2 files changed, 69 insertions(+)

Why exactly do you need to add code here?

Is it not sufficient to add, for example, a "nand read" command as part of your "preboot" settings?

The preboot commands are executed after lcd is turned on; ideally, the splashimage should be in the frame buffer before that. There is also the issue of having to fix the bmp load address to the appropriate alignment (to comply with a similar fix in lcd.c from patch 3), and checking for problems such as overwriting U-Boot data with the bmp. I don't think Hush is the right tool for these actions.

Quoted 5 lines

Best regards,

Wolfgang Denk

Signature · 2 lines
Regards,
Nikita.