BACKGROUND
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:
drivers/video/mxc/mxc_lcdif.c
{
/* 1280x120 @ 60 Hz , pixel clk @ 32MHz */
"TRULY-1U",
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:
video=mxcfb0:dev=lcd,TRULY-1U,if=RGB24,bpp=32
RESULT
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.
THEORY
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.
ATTEMPTED FIXES
I've tried various combinations of the display bootarg and 'named' display definition to see if it had any effect.
if=
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?
bpp=
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.
fbmem=
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?
