What is causing my custom 18-bit display to have sections of wrong colors?

Showing results for 
Search instead for 
Did you mean: 

What is causing my custom 18-bit display to have sections of wrong colors?

Contributor I


I have a custom 1280x120 18-bit PRGB LCD display connected to a Boundary Devices Nitrogen6X iMX6 SBC.

I've compiled a custom kernel with a 'named' display using the following code:



/* 1280x120 @ 60 Hz , pixel clk @ 32MHz */


60, // refresh rate in Hz

1280, // xres in pixels

120, // yres in pixels

45000, // pixel clock in picoseconds (dot clock or just clock)

54, // left_margin (Horizontal Back Porch) in pixel clock units

54, // right_margin (Horizontal Front Porch) in pixel clock units

3, // upper_margin (Vertical Back Porch) in pixel clock units

3, // lower_margin (Vertical Front Porch) in pixel clock units

3, // hsync_len (Hsync pulse width)

3, // vsync_len (Vsync pulse width)

0, // sync (Polarity on the Data Enable)

FB_VMODE_NONINTERLACED, // vmode (Video Mode)

0, // flags


I'm using the following bootarg:



The above code is producing the following result:


Here is the reference image:


As you can see, there are 3 "sections" where the colors are not correct. And the white to black greyscale bar is appearing 4 times.


I feel like this is a result of a few RGB data bits (blue perhaps?) not being sent to the display, but I don't have an oscilloscope to verify. Or perhaps framebuffer issue? I've verified connectivity of all the RGB pins from the SBC to the display, so I don't think this is a "Layer 1" issue in my interconnect board.


I've tried various combinations of the display bootarg and 'named' display definition to see if it had any effect.


I've tried RGB24, RGB888, RGB666 (plus the BGR equivalents). My interconnect board is setup assuming that DAT_0-7 = R, DAT_8-15 = G, & DAT_16-23 = B. According to pg3617 of the i.MX 6Quad reference manual (IMX6DQRM.pdf) that pinout should be correct for both 24-bit and 18-bit (Config1) pin muxing. As far as I can tell, Config1 is supposed to use the same pinout as 24-bit, but drop the two least significant bits for each color. Config2 is supposed to "pack" the pins all together to be DAT_0-17 and free up DAT_18-23 for other uses via remuxing. I'm setting to RGB24 currently since I can't verify which 18-bit pinout is being muxed. How can I set/verify if the pin muxing is set as 18-bit Config1 (i.e. loosely) vs 18-bit Config2 (packed)?

Do I have a pin muxing issue?


I've tried 16, 18, 24 & 32. As expected bpp=32 appears to give the best 'resolution', but there are still these 3 rogue color shifts.


According to here, fbmem is calculated as xres*yres*bpp*3 in megabytes, so 1280*120*32*3 bytes = 14.7456 megabytes. Rounding up to fbmem=15M. Changing this value has no perceivable effect on colors.

UPDATE (8/2/14):

This does not appear to be a framebuffer issue. The output of fbgrab produces the following result:


As you can see, there are no color issues here.

UPDATE (8/8/14):

Changing the gradient test image as shown above to be smaller (i.e. only taking up a portion of the display), still creates the same result. It doesn't matter if its full size, half-size, quarter-size, etc. Portions of the gradient still get duplicated.

There is a comment in the app notes that accompanies the LCD datasheet that says: "Don't support the DE MODE, Only support the SYNC MODE timing. So the DE signal doesn't use it, please connect it to GND or VDD or OPEN."

Would this have anything to do with it? Is there a setting within the iMX6 registers that needs to be set to tell it not to use the Data Enable pin for timing? Or is this simply stating that the timing for the display will be used solely from the HSYNC and VSYNC pins?

I used devregs to check the pin muxing of the RGB pin registers, IOMUXC_SW_MUX_CTL_PAD_DISP0_DAT0-23. All are currently set to 0x00000000, which according to pg.2024 if the IMX6Q datasheet, means that the RGB pins are set to ALT0 (IPU1_DISP0_DATA_XX). So those appear to be correct.

I also used devregs to check the DPI interface configuration, register MIPI_DSI_DPI_CFG. This register is for setting the parallel RGB modes correct? The register was set to 0x01e00000. And according to pg.3628-3629 of the manual, this indicates the DPI mode is set to "16-bit config1" which is wrong! However setting to other DPI modes using devregs had no effect. In addition, changing the bootargs to use RGB666 did have an effect, but did not change the value of this register. Is this the wrong register for the PRGB interface? If so, what is the correct register to check?

Labels (2)
0 Kudos
2 Replies

Contributor IV


Any luck?  It sounds like you might have a similar issue to mine.  My understanding if you are using the IPU1_DISP0_DATA pins is that you are using a PRGB LCD driven by the IPU direct, not through the DSI/MIPI interface.  That could be adding some confusion as it did for me.  I also found the 16bit/18bit config option in the DSI registers, but that whole block was all zeroed out.

What's confusing, is where is that option for the IPU/LCD interface?  Can't find anything about that in the IPU regs.

When I run fbset, depending on my kernel bootarg from Uboot, I can get:

rgba 5/11,6/5,5/0,0/0


rgba 8/16,8/8,8/0,8/24

but neither of these seems correct, since I am using RGB666.  As far as I can tell, it should read

rgba 6/12,6/6,6/0,0/0

why doesn't it?  can I use fbset to fix it?

0 Kudos

Contributor IV


Looks like rgba 8/16,8/8,8/0,8/24 is the best setting.

Turns out there was a late boundary devices uboot update that fixed part of the problem, changing drive strength for two of the pins to 120ohm.  No success with all LCD control and data at same drive strength.  We had to forty and data to 120 for max sharpness.

0 Kudos