As a high level overview a display module contains 4 major components. The LCD and row/column drive circuits, a controller which bridges from MIPI-DSI to whatever the LCD requires, and the touchscreen controller, and finally there is also the backlight for the LCD.
Connecting to a MIPI-DSI display is not a “trivial” task like HDMI. The reason HDMI is so easy is the connections are always the same, and the host can query the display on it’s capabilities, get a standardized response, and then set up the HDMI link as needed. MIPI-DSI displays are not plug an play, they are extremely customized and every one is different.
To get this system running you need to do quite a bit of programming, I’ll describe it in the flow of the signals, although you need everything up and running to get a dsiplay working.
The MIPI-DSI signals leaving the host (410 or 820 chip), need to have the right dimensions and timing. You need to program the clock rates, the number of rows and columns, the horizontal and vertical blanking times. There are a few other things, but these are the basics.
the LCD controller chip. This chip is a bridge between the MIPI-DSI signals coming in, and the LCD itself. Since the controller doesn’t know what LCD is attached you need to program the controller to drive the right numbers of rows and columns at the right refresh rates. with the right drive strengths and polarities for the specific LCD you are using.
the Backlight drive. Sometimes the display module just brings out the signals for LED and you need to provide power for them (often 21 Volts), other displays have the backlight drive circuitry built in. How you turn on the backlight really depends on what the LEDs are connected to. Just to add another level of complexity, the backlight intensity needs to be controlled.
the touchscreen. The touchscreen is (usually) a transparent metal layer over top of the LCD, with it’s own controller and communications channel to the host, often I2C or SPI. Usually this controller is pretty autonomous and has almost nothing to do with the rest of display, but not always.
Just to add another level of complexity the display controller can be connected to the host through I2C or SPI, but not always, MIPI-DSI has a control channel mode which could be used rather than the I2C/SPI channel. When you are programming the controller the commands need to clow through the right channel. The MIPI-DSI control channel is bi-directional and runs on Lane-0, it is fast, but not as fast as the display data which is uni-directional.
Further complicating things the Touch controller can be integrated into the Display controller IC, and it can use the MIPI-DSI control channel instead of I2C/SPI for communication with the host.
Did I mention another complexity? The display controller can have a full frame buffer, hence the host only needs to send updates to the display. MIPI-DSI calls this command mode and only rectangular blocks of data are sent to the frame buffer to update some or all of the display. This saves a lot of power since the host can go to sleep and doesn’t need to refresh the display 60 times per second.
You really need to know a lot about your particular display in order to connect it and get it running, and of course the setup in the device tree and the drivers are specific to each display. At a minimum you need the datasheets for the display controller IC (and the touch controller IC if it is not integrated), and the LCD module datasheet.
Using the LCD module datasheet the Hardware guy can figure out how to connect the display module to the host (power, backlight, MIPI-DSI, and possibly 1 or more I2C/SPI connections). Then using the display controller datasheet and knowing how the HW team connected the display module you can create or port the software to drive your specific display.
I hope this overview helps get you started.
no longer a Qualcomm employee
Looking for a new employer