From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alessandro Rubini Date: Sat, 5 Dec 2009 21:01:04 +0100 Subject: [U-Boot] [PATCH V3 6/9] lcd: make 16bpp work In-Reply-To: <3f8ddc66075cce35fbee4e16125c9a9e76b41e14.1260016056.git.rubini@unipv.it> References: <3f8ddc66075cce35fbee4e16125c9a9e76b41e14.1260016056.git.rubini@unipv.it> Message-ID: <20091205200104.GA32562@morgana.gnudd.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Sorry for this late though about lcd issues. > - lcd_color_fg : lcd_color_bg; > + *d++ = (bits & 0x80) ? 0xffff : 0; Here my patch uses hardwired 0 and ~0 for 16-bit pixels. Anatolij suggested to use lcd_color_fg and lcd_color_bg as in the original code, but unfortunately it doesn't work. lcd_color_fg is set by common/lcd.c itself, using this function: static void lcd_setfgcolor (int color) { #ifdef CONFIG_ATMEL_LCD lcd_color_fg = color; #else lcd_color_fg = color & 0x0F; #endif } So, however white I declare my color, it turns out blue. While I'd understand a difference based on LCD_COLOR8 and LCD_COLOR16 (but even in that case I'd request the caller to do the right thing avoiding this late "fix"), I really can't tell why the atmel display is different from other ones. It's true that I can force lcd_color_fg to whatever I want, but only after lcd_clear() is called. Moreover, if there's centralized I wouldn't cowardly change it behind it's back. This is one of the reasons why my original post was an RFC. common/lcd.c is quite a mess and touching it is difficult. At this point I still think forcing 0xffff and 0, ignoring lcd_color_fg, is the right thing to do at least until atmel specifics are removed from common/lcd.c. BTW: I have a 9263ek an a 9261ek, so I might be able to try to propose an atmel-related cleanup in the future, but not on short term, unfortunately. /alessandro