Add splash screen for CM-T35
Subsystems (2)
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
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
@@ -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
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
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.
PATCH v2 2/7 omap3: allow dynamic selection of gfx_format
In reply to Nikita KiryanovCurrently 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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_formatis hardcoded intoomap3_dss_panel_config(). Make it a field in structpanel_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_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_formatis hardcoded intoomap3_dss_panel_config(). Make it a field in structpanel_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.
PATCH v2 3/7 lcd: prevent unaligned memory access when displaying splash screen
In reply to Nikita KiryanovWhen 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
@@ -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
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
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.
PATCH 4/7 lcd: add option for board specific splash screen preparation
In reply to Nikita KiryanovCurrently 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
@@ -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
@@ -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
@@ -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
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 (sincelcd.clooks for the splash image in an address specified by the environment variable "splashimage").Our window of opportunity in
board_init_r()is therefore: betweenenv_relocate()andbmp_display(), and from the available options only the lcd related functions indrv_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.Signed-off-by Nikita Kiryanov <[email protected]>Signed-off-by Igor Grinberg <[email protected]>
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_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 (sincelcd.clooks for the splash image in an address specified by the environment variable "splashimage").Our window of opportunity in
board_init_r()is therefore: betweenenv_relocate()andbmp_display(), and from the available options only the lcd related functions indrv_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
Signed-off-by Nikita Kiryanov <[email protected]>Signed-off-by Igor Grinberg <[email protected]>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.
PATCH v2 5/7 cm-t35: add support for dvi displays
In reply to Nikita KiryanovAdd 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
@@ -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
@@ -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
@@ -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
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.
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.
PATCH v2 6/7 cm-t35: add support for user defined lcd parameters
In reply to Nikita KiryanovAdd 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
@@ -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
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]>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.
PATCH v2 7/7 cm-t35: add support for loading splash image from NAND
In reply to Nikita KiryanovAdd 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
@@ -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
@@ -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
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
Signed-off-by Nikita Kiryanov <[email protected]>Signed-off-by Igor Grinberg <[email protected]>
Quoted 8 lines
---
Changes in V2:
- Added fix tobmp_load_addrto comply with what happens inlcd.cfollowing 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
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
Signed-off-by Nikita Kiryanov <[email protected]>Signed-off-by Igor Grinberg <[email protected]>---
Changes in V2:
- Added fix tobmp_load_addrto comply with what happens inlcd.cfollowing 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.