Proper Way To Configure JEIDA 16 bit Display For IMX6SX

[alexkl]

Bunch of problems I'm experiencing here trying to bring up a JDI 16 bits per pixel 640x480 display. Here are all the relevant excerpts from the DTS:

#include "imx6sx.dtsi"

/ {
    mxcfb1: fb@0 {
        compatible = "fsl,mxc_sdc_fb";
        disp_dev = "ldb";
        interface_pix_fmt = "RGB24";
        default_bpp = <24>;
        int_clk = <0>;
        late_init = <0>;
        status = "okay";
    };
    reserved-memory {
        #address-cells = <1>;
        #size-cells = <1
        ranges;
        
        // Memory map for vdev, m4 firmware here, all the way to 0x901000+0x1f000
        
        linux,cma {
            compatible = "shared-dma-pool";
            reusable;
            size = <0x8000000>;
            linux,cma-default;
        };
    };
};

&lcdif2 {
    display = <&display1>;
    disp-dev = "ldb";
    status = "okay";
    display1: display@1 {
        bits-per-pixel = <24>;
        bus-width = <24>;
    };
};

&ldb {
    status = "okay";
    lvds-channel@0 {
        fsl,data-mapping = "jeida";
        fsl,data-width = <24>;
        crtc = "lcdif2";
        status = "okay";
        primary;
        display-timings {
            native-mode = <&timing1>;
            timing1: jdi {
                clock-frequency = <25000000>; // Min/typ/max clk in hz
                hactive = <640>;                        // horizontal resolution
                hback-porch = <130>;                    // Min/typ/max #clock
                hfront-porch = <20>;                    // Min/typ/max #clock
                hsync-len = <10>;                       // Min/typ/max #clock
                vactive = <480>;                        // vertical resolution
                vback-porch = <25>;                     // Min/typ/max #clock
                vfront-porch = <10>;                    // Min/typ/max #clock
                vsync-len = <10>;                       // Min/typ/max #clock
                de-active = <1>;                        // active high display enable in datasheet
                pixelclk-active = <1>;                  // negative edge
            };
        };
    };
};

I have also patched the mxcfb.c driver to reduce the allocation size from 32M to 16M.

It seems that even with 128M of CMA size, the driver still fails to allocate... With kernel cmd argument cma=128M, I get:

[ 1.976945] mxsfb 2220000.lcdif: supply lcd not found, using dummy regulator
[ 1.984239] cma: cma_alloc: reserved: alloc failed, req-size: 4096 pages, ret: -12
[ 1.992149] mxsfb 2220000.lcdif: Unable to allocate framebuffer memory
[ 1.998750] mxsfb 2220000.lcdif: Failed to initialize fbinfo: -12
[ 2.004919] mxsfb: probe of 2220000.lcdif failed with error -12

I don't see issues when I don't enable this driver, so perhaps it's fragmentation, but it's odd that everything seems to work fine with 32M, and a 32M allocation fails with 128M available.

But more importantly - I can't seem to get Linux to honor my framebuffer timings, and I'm not sure how I can support JEIDA 18 bit.

With or without a kernel command line option: "video=mxcfb0:dev=ldb,if=RGB24"

$ fbset

mode "320x240-150"
# D: 15.750 MHz, H: 39.375 kHz, V: 150.286 Hz
geometry 320 240 320 240 32
timings 63492 16 16 16 4 48 2
accel false
rgba 8/16,8/8,8/0,0/0
endmode

The mode is forced to this weird 150Hz 320x240.

I am also not sure how to support my 16 bits per pixel RGB666 panel. Should I keep everything 24 bits, and attempt to pinmux the additional pair off, if that's possible?

[alexkl]

Found why the odd resolution was being set - was a userspace process that set up the display mode.

I've also realized I made an error - RGB666 is 18 bits per pixel - so the title and description are wrong about that.