Are you using our WinCE BSP or Linux?
For our WinCE BSP, we set the interface to only be 16 bit and use a frame buffer of 5:6:5 (R:G:B), which allows for 16bpp. I'm not sure how the standard Linux offering is set up, but I assume it's the same since Logic's display kits are connected this way (16 bits).
If using 16 bit (yes, not 18), you would connect to a 24 bit display like so:
LCD SOM Signal iMX31 LCD data bit
R7 R5 LD17
R6 R4 LD16
R5 R3 LD15
R4 R2 LD14
R3 R1 LD13
R2 R5 LD17 (note repeat)
R1 R4 LD16 (note repeat)
R0 R3 LD15 (note repeat)
G7 G5 LD11
G6 G4 LD10
G5 G3 LD9
G4 G2 LD8
G3 G1 LD7
G2 G0 LD6
G1 G5 LD11 (note repeat)
G0 G4 LD10 (note repeat)
B7 B5 LD5
B6 B4 LD4
B5 B3 LD3
B4 B2 LD2
B3 B1 LD1
B2 B5 LD5 (note repeat)
B1 B4 LD4 (note repeat)
B0 B3 LD3 (note repeat)
Why? -> You don't have enough bits, so this pattern will give you the most color contrast, or varied color spectrum I guess you could say. Otherwise, you could tie the lower sig bits high or low, but then you'd never be able to get all off or all on. Does this make sense?
The IMX31 does actually have 8 bits of each color and LogicPD makes these extra bits available on connector J9 on the development baseboard. So, if you wanted to write your display driver (set up the correct interface and frame buffer), you could actually use 24 bits, 1:1 with this LCD. I recommend against it unless you truly need this and want to spend the time. Note, when you go over 16bits, you go over 16bpp for a frame buffer. Anything over this and your frame buffer's pixels have to take up 24 bits or 32 bits of each 32bit word in RAM. So, the overhead becomes quite a bit more.
If you truly wanted 18 bits to 24 bits, you can see from my example above how this would be done by looking at the green bits which have 6 bits available in the 5:6:5 configuration.
This can be confusing.