Re: [Gumstix-users] ConsoleLCDvx problems - LDD_16 & LDD_17 gone

[thaGod <th...@gm...>]

Ok... for those interested. I have found a proper color *16 bit* solution
(which is plenty good enough for the girls I date). I'm at home now. I don't
have the fixed code in front of me. I did get all of the colors to display
correctly in 16 actual bits but masquerading in 18 bit mode. The gumstix
hardware, consoleLCD-vx and verdex, is laid out fine (whew). The pxafb.c and
pxa-regs.h files, however, are wrong.

>From the consoleLCD-vx schematic, LDD_16 and LDD_17 are red's most
significant bits. They are not defined in pxa-regs.h. The driver source...
pxafb.c packs the bits in 5-6-5 format and routes the LCD data pins in
numerical order from GPIO pin 58. This defines LCD data pins in order from
lcd data 0 to 15. Since the hardware is wired for RGB18 6-6-6, this shifts
the palette grossly. The most significant blue bit is interpreted as the
least significant green bit, but the driver thinks LDD_5 is the most
significant blue bit, when it is actually wired as the 2nd most significant.
The shift continues.. I just get confused every time I try to explain it... 

Not sure how gumstix staff tested this stuff and decided it was working?
It's not even possible to get the color working right with the pxa-regs.h
provided in the gumstix buildroot. GPIO86_LDD_15 & GPIO87_LDD_16 *must* be
added to pxa-regs.h before you can even make a red pixel brighter than
dried-blood crimson =) .. not to mention the weird offsetting required in
pxafb.c to re-align the bits to work in 16 bit mode.

I'll post my fixes on Monday. They're not pretty, but they work.

Erick


thaGod wrote:
> 
> The patches don't work right. It appears as though they were written to
> patch a different set of source files.
> 
> Erick
> 
> 
> thaGod wrote:
>> 
>> Ok. I got the schematic printed out and in front of me and I think I've
>> figured out why the colors don't come out right with your consoleLCD-vx.
>> Here is the relevant excerpt from pxa-regs.h:
>> 
>> #define GPIO58_LDD_0		58	/* LCD data pin 0 */
>> #define GPIO59_LDD_1		59	/* LCD data pin 1 */
>> #define GPIO60_LDD_2		60	/* LCD data pin 2 */
>> #define GPIO61_LDD_3		61	/* LCD data pin 3 */
>> #define GPIO62_LDD_4		62	/* LCD data pin 4 */
>> #define GPIO63_LDD_5		63	/* LCD data pin 5 */
>> #define GPIO64_LDD_6		64	/* LCD data pin 6 */
>> #define GPIO65_LDD_7		65	/* LCD data pin 7 */
>> #define GPIO66_LDD_8		66	/* LCD data pin 8 */
>> #define GPIO66_MBREQ		66	/* alternate bus master req */
>> #define GPIO67_LDD_9		67	/* LCD data pin 9 */
>> #define GPIO67_MMCCS0		67	/* MMC Chip Select 0 */
>> #define GPIO68_LDD_10		68	/* LCD data pin 10 */
>> #define GPIO68_MMCCS1		68	/* MMC Chip Select 1 */
>> #define GPIO69_LDD_11		69	/* LCD data pin 11 */
>> #define GPIO69_MMCCLK		69	/* MMC_CLK */
>> #define GPIO70_LDD_12		70	/* LCD data pin 12 */
>> #define GPIO70_RTCCLK		70	/* Real Time clock (1 Hz) */
>> #define GPIO71_LDD_13		71	/* LCD data pin 13 */
>> #define GPIO71_3_6MHz		71	/* 3.6 MHz Oscillator clock */
>> #define GPIO72_LDD_14		72	/* LCD data pin 14 */
>> #define GPIO72_32kHz		72	/* 32 kHz clock */
>> #define GPIO73_LDD_15		73	/* LCD data pin 15 */
>> 
>> Notice there is no definition for LDD_16 and LDD_17 (which you *do* have
>> routed from the LCD). If I'm not mistaken, these are also the 2 most
>> significant red bits? In the pxafb.c source in the linux-2.6.21gum, the
>> framebuffer is set up in 5-6-5 format (not 666). This throws the entire
>> palette off as you might imagine. I have found patches for my pxafb.c,
>> pxafb.h, and pxa-regs.h, but I thought you might want to have a look at
>> this.
>> 
>> Let me know what you decide here.. I'm not sure what to do about adding
>> LDD_16 & LDD_17 to pxa-regs.h.
>> 
>> thanks,
>> Erick
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/ConsoleLCDvx-problems---LDD_16---LDD_17-gone-tf4693350.html#a13438800
Sent from the Gumstix mailing list archive at Nabble.com.