summaryrefslogtreecommitdiff
path: root/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
AgeCommit message (Collapse)Author
2013-07-24Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk
Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
2011-08-04video: Add SHARP LQ084S3LG01 LCD support on P1022DSTimur Tabi
The SHARP LQ084S3LG01 is a TFT LCD used on the P1022DS (revision "C") board. This device only supports 800x600 resolution, so if that resolution is selected, assume that this is the device. The device is attached to the LVDS port on the P1022DS board. The existing 800x600 entry (for the PDM360NG board) is actually 800x480, so we fix that. To support two different 800x resolutions, the Y-resolution is now passed to fsl_diu_init() and both values are used to pick the proper fb_videomode structure. The data for the 800x600 video mode is originally from Jiang Yutang. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Jiang Yutang <b14898@freescale.com>
2011-04-28powerpc: use 'video-mode' environment variable to configure DIUTimur Tabi
Use the 'video-mode' environment variable (for Freescale chips that have a DIU display controller) to designate the full video configuration. Previously, the DIU driver used the 'monitor' variable, and it was used only to determine the output video port. The old definition of the "monitor" environment variable only determines which video port to use for output. This variable was set to a number (0, 1, or sometimes 2) to specify a DVI, LVDS, or Dual-LVDS port. The resolution was hard-coded into board-specific code. The Linux command-line arguments needed to be hard-coded to the proper video definition string. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2010-09-25fsl_diu_fb: further refactoring of FSL DIU codeAnatolij Gustschin
Move common code to the fsl_diu_fb.c file and remove obsolete code from board files (aria, mpc8610hpcd and pdm360ng). Move fsl_diu_fb.h file to the include directory. Signed-off-by: Anatolij Gustschin <agust@denx.de>
2010-09-21fsl: refactor MPC8610 and MPC5121 DIU code to use existing bitmap and logo ↵Timur Tabi
features The Freescale MPC8610 and MPC5121 DIU code had re-implement two features that already existed in U-Boot: bitmap drawing and top-of-screen logo (CONFIG_VIDEO_LOGO). So delete the 8610-specific code and use the built-in features instead. Signed-off-by: Timur Tabi <timur@freescale.com>
2010-07-24cmd_usage(): simplify return code handlingWolfgang Denk
Lots of code use this construct: cmd_usage(cmdtp); return 1; Change cmd_usage() let it return 1 - then we can replace all these ocurrances by return cmd_usage(cmdtp); This fixes a few places with incorrect return code handling, too. Signed-off-by: Wolfgang Denk <wd@denx.de>
2010-07-04Make sure that argv[] argument pointers are not modified.Wolfgang Denk
The hush shell dynamically allocates (and re-allocates) memory for the argument strings in the "char *argv[]" argument vector passed to commands. Any code that modifies these pointers will cause serious corruption of the malloc data structures and crash U-Boot, so make sure the compiler can check that no such modifications are being done by changing the code into "char * const argv[]". This modification is the result of debugging a strange crash caused after adding a new command, which used the following argument processing code which has been working perfectly fine in all Unix systems since version 6 - but not so in U-Boot: int main (int argc, char **argv) { while (--argc > 0 && **++argv == '-') { /* ====> */ while (*++*argv) { switch (**argv) { case 'd': debug++; break; ... default: usage (); } } } ... } The line marked "====>" will corrupt the malloc data structures and usually cause U-Boot to crash when the next command gets executed by the shell. With the modification, the compiler will prevent this with an error: increment of read-only location '*argv' N.B.: The code above can be trivially rewritten like this: while (--argc > 0 && **++argv == '-') { char *arg = *argv; while (*++arg) { switch (*arg) { ... Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Mike Frysinger <vapier@gentoo.org>
2010-06-14video: cfb_console: add weak default video_set_lut()Anatolij Gustschin
Do not enforce drivers to provide empty video_set_lut() if they do not implement indexed color (8 bpp) frame buffer support. Add default function to the cfb_console driver and remove empty video_set_lut() functions. Signed-off-by: Anatolij Gustschin <agust@denx.de>
2010-04-07fsl: improve the PIXIS code and fix a few bugsTimur Tabi
Refactor and document the Freescale PIXIS code, used on most 85xx and 86xx boards. This makes the code easier to read and more flexible. Delete pixis.h, because none of the exported functions were actually being used by any other file. Make all of the functions in pixis.c 'static'. Remove "#include pixis.h" from every file that has it. Remove some unnecessary #includes. Make 'pixis_base' into a macro, so that we don't need to define it in every function. Add "while(1);" loops at the end of functions that reset the board, so that execution doesn't continue while the reset is in progress. Replace in_8/out_8 calls with clrbits_8, setbits_8, or clrsetbits_8, where appropriate. Replace ulong/uint with their spelled-out equivalents. Remove unnecessary typecasts, changing the types of some variables if necessary. Add CONFIG_SYS_PIXIS_VCFGEN0_ENABLE and CONFIG_SYS_PIXIS_VBOOT_ENABLE to make it easier for specific boards to support variations in the PIXIS registers sets. No current boards appears to need this feature. Fix the definition of CONFIG_SYS_PIXIS_VBOOT_MASK for the MPC8610 HPCD. Apparently, "pixis_reset altbank" has never worked on this board. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2009-07-2285xx/86xx: Replace in8/out8 with in_8/out_8 on FSL boardsKumar Gala
The pixis code used in8/out8 all over the place. Replace it with in_8/out_8 macros. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2009-07-18stdio/device: rework function naming conventionJean-Christophe PLAGNIOL-VILLARD
So far the console API uses the following naming convention: ======Extract====== typedef struct device_t; int device_register (device_t * dev); int devices_init (void); int device_deregister(char *devname); struct list_head* device_get_list(void); device_t* device_get_by_name(char* name); device_t* device_clone(device_t *dev); ======= which is too generic and confusing. Instead of using device_XX and device_t we change this into stdio_XX and stdio_dev This will also allow to add later a generic device mechanism in order to have support for multiple devices and driver instances. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Edited commit message. Signed-off-by: Wolfgang Denk <wd@denx.de>
2009-06-12General help message cleanupWolfgang Denk
Many of the help messages were not really helpful; for example, many commands that take no arguments would not print a correct synopsis line, but "No additional help available." which is not exactly wrong, but not helpful either. Commit ``Make "usage" messages more helpful.'' changed this partially. But it also became clear that lots of "Usage" and "Help" messages (fields "usage" and "help" in struct cmd_tbl_s respective) were actually redundant. This patch cleans this up - for example: Before: => help dtt dtt - Digital Thermometer and Thermostat Usage: dtt - Read temperature from digital thermometer and thermostat. After: => help dtt dtt - Read temperature from Digital Thermometer and Thermostat Usage: dtt Signed-off-by: Wolfgang Denk <wd@denx.de>
2009-01-28Command usage cleanupPeter Tyser
Remove command name from all command "usage" fields and update common/command.c to display "name - usage" instead of just "usage". Also remove newlines from command usage fields. Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
2009-01-28Standardize command usage messages with cmd_usage()Peter Tyser
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
2009-01-28Clean up diufb command definitionsPeter Tyser
The diufb command usage formatting is non-standard. It was made standard in preparation for larger command usage updates. Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
2008-10-18rename CFG_ macros to CONFIG_SYSJean-Christophe PLAGNIOL-VILLARD
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2008-05-21Move pixel clock setting to board fileYork Sun
The clock divider has different format in 5121 and 8610. This patch moves it to board specific code. Signed-off-by: York Sun <yorksun@freescale.com>
2007-11-078610: Add console frame buffer support to FSL 8610 DIU driver.York Sun
Add cfb console support to FSL 8610 DIU driver. Inspect board version from PIXIS to obtain correct pixel format. Use #define CONFIG_VIDEO in config file to enable fb console. To switch monitor, set monitor variable to 0 - DVI, 1 - Single link LVDS, 2 - Double link LVDS followed by "diufb init". Preserve logo bitmap at the top of the fb console. Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Jon Loeliger <jdl@freescale.com>
2007-11-078610: Add 8610 DIU display driverYork Sun
1280x1024 and 1024x768 @ 32 bpp are supported now. DVI, Single-link LVDS, Double-link LVDS are all supported. Environmental variable "monitor" is used to specify monitor port. A new command "diufb" is introduced to reinitialize monitor and display a BMP file in the memory. So far, 1-bit, 4-bit, 8-bit and 24-bit BMP formats are supported. diufb init - initialize the diu driver Enable the port specified in the environmental variable "monitor" diufb addr - display bmp file in memory. The bmp image should be no bigger than the resolution, 1280x1024 for DVI and double-link LVDS, 1024x768 for single-link LVDS. Note, this driver allocate memory but doesn't free it after use It is written on purpose -- to avoid a failure of reallocation due to memory fragement. ECC of DDR is disabled for DIU performance. L2 data cache is also disabled. Signed-off-by: York Sun <yorksun@freescale.com> Signed-off-by: Jon loeliger <jdl@freescale.com>