Bring-up and Verification of MIPI-to-eDP Chip LT8911EXB on RK3568 Platform

Driver debugging for the MIPI-to-eDP conversion based on the LT8911EXB.

Project Summary: Debugging and Verification of MIPI-DSI to eDP Interface on Rockchip RK3568 Platform

  • Author: Potter White
  • Date: September 2025
  • Project Types: Rockchip, Bring-Up, Linux Kernel Driver, Device Tree, I2C

1. Project Overview

Situation: In a custom project based on the Rockchip RK3568 SoC, it was necessary to convert a MIPI-DSI video signal to an eDP signal using the Lontium LT8911EXB bridge chip to drive an eDP display. After the initial Board Support Package (BSP) integration, the display failed to light up, and the kernel log (dmesg) showed no loading messages for the LT8911EXB driver.

My Role & Contributions: As the project’s BSP engineer, I was responsible for the full-stack debugging, from hardware schematics to the kernel driver, to achieve the functional bring-up of this display path. My core contributions include:

  • Conducted systematic hardware health checks, verifying the fundamental operating conditions of the LT8911EXB chip, including its power, clock, and reset circuits.
  • Performed an in-depth analysis of the Linux device driver model, clarifying the interaction and triggering mechanisms between the Device Tree (DTS), kernel drivers, and hardware.
  • Pinpointed the root cause of the driver loading failure: a mismatch between the I2C address and GPIO attribute configurations in the Device Tree and the specifications of the driver code and hardware.
  • Led and implemented the correction plan for the Device Tree, successfully enabling the kernel driver to match with the hardware device and load correctly.
  • Distilled key knowledge points from the debugging process, creating technical notes on topics such as RC circuits, I2C address notation, and oscilloscope probe usage, thereby contributing to the team’s knowledge base.

2. My Methodology: Embedded Peripheral Bring-up Diagnostic Flow

The debugging process followed a systematic troubleshooting methodology, moving from hardware to software and from surface-level symptoms to underlying causes. This flow is designed to rapidly narrow down the problem scope and avoid wasting time on uncertain paths.

graph TD
    %% === Definitions & Styling ===
    classDef main fill:#2c3e50,color:white,stroke:#8e9eab;
    classDef check fill:#4b3e58,color:white,stroke:#b8a3d3;
    classDef decision fill:#27ae60,color:white,stroke:#88d1a1;
    classDef result_ok fill:#16a085,color:white,stroke:#72d6c1;
    classDef result_fail fill:#c0392b,color:white,stroke:#e69a93;
    classDef note fill:#f39c12,color:white,stroke:#f8c471;

    %% === Flow ===
    S[<b>Start: Display Not Working</b>]:::main
    A["<div style='text-align:left; padding:10px;'><b>1. Hardware Health Check (L1)</b><br>- <b>Power:</b> Measure voltage on all power rails (1.8V)<br>- <b>Clock:</b> Measure crystal oscillator with an oscilloscope (25MHz)<br>- <b>Reset:</b> Analyze RC circuit and confirm reset level</div>"]:::check
    B["<div style='text-align:left; padding:10px;'><b>2. Control Path Verification (L2)</b><br>- <b>Pinctrl:</b> Verify I2C pin muxing in DTS (i2c2m1)<br>- <b>I2C Bus:</b> Scan the bus using `i2cdetect`</div>"]:::check
    C{"<div style='text-align:center'><b>Driver Loaded?</b><br>(dmesg / printk)</div>"}:::decision
    D["<div style='text-align:left; padding:10px;'><b>3. Driver-Device Matching Analysis (L3)</b><br>- Check kernel build config (CONFIG_*)<br>- Check if DTS node exists in /sys<br>- <b>Core:</b> Match `compatible` string<br>- <b>Core:</b> Match `reg` (I2C address)<br>- <b>Core:</b> Match `*-gpios` attributes</div>"]:::check
    E["<div style='text-align:left; padding:10px;'><b>4. Driver Logic Debugging (L4)</b><br>- Analyze `probe` function execution flow<br>- Analyze I2C read/write timing<br>- Verify chip initialization sequence</div>"]:::check
    SUCCESS[<b><i class='fa fa-check-circle'></i> Display On</b>]:::result_ok

    S --> A --> B --> C
    C -- "No" --> D
    C -- "Yes" --> E
    D --> |Correct DTS| C
    E --> SUCCESS

    subgraph "Key Knowledge Distilled"
        direction LR
        K1[Probe Loading Effect]:::note
        K2[7/8-bit I2C Address]:::note
        K3[RC Reset Circuit]:::note
        K4[DTS/Driver Binding]:::note
    end

    A --> K1 & K3
    B --> K2
    D --> K4

3. Debugging Journey and Key Issues Solved

The entire debugging process was challenging but highly rewarding. The following were several key turning points:

Issue 1: I2C Device Scan Was Slow and Found No Slave Devices

Initially, i2cdetect could not find any devices on the i2c2 bus. By cross-referencing the hardware schematic and the RK3568 TRM, I found that the pinctrl configuration in the Device Tree was incorrect. After switching the pin function to the correct i2c2m1_xfer, i2cdetect successfully scanned and found a device at address 0x29.

Issue 2: What is the I2C Device Address of LT8911EXB? 0x52 vs. 0x29

According to the schematic, pulling the S_ADR pin low corresponds to an address of 0x52. However, when I scanned with i2cdetect, there was no slave device at 52, only one at 0x29. By consulting the driver documentation and the I2C protocol specification, I confirmed that the Linux kernel uses 7-bit addresses, whereas hardware datasheets often provide 8-bit addresses (which include the R/W bit). Right-shifting the 8-bit write address 0x52 by one bit yields the 7-bit address 0x29, which perfectly matched the i2cdetect result.

  • Conclusion: The I2C physical path is functional, and the address should be configured as 0x29.

Issue 3: The Driver’s probe Function Was Never Called (Core Issue)

Even with a functional I2C path, there were still no driver loading messages in dmesg. By inspecting /sys/firmware/devicetree/base, I found that although the kernel correctly parsed the lt8911exb@29 node and its compatible property, the crucial information was still missing.

  • Root Cause: When porting the driver code provided by Lontium, I did not modify the line obj-m = in its Makefile. This statement means the driver is compiled as a module (.ko).
  • Solution: By simply changing that line in the Makefile to obj-y = , the driver was built into the kernel by default and loaded automatically at boot.

Issue 4: The Reset Signal Documentation Stated It Required a GPIO, but It Worked Without One. Why?

  • Root Cause: This relates to the concept of an RC circuit. Simply put, the reset pin is situated between a resistor (R) and a capacitor (C). The resistor connects the power supply to the capacitor, while the capacitor is connected between ground, the reset pin, and the resistor. When power is applied, the capacitor cannot instantly reach the high voltage of the supply; it charges up slowly (the charging time is calculated by the equation R * C = Time). Because the capacitor is connected to ground, its initial voltage is low, pulling the reset pin low. The reset pin remains low until the capacitor is sufficiently charged, at which point the pin is pulled high. This is the principle of an RC circuit, which uses the electrical properties of a capacitor to achieve an automatic reset. However, this approach lacks the flexibility of GPIO control.
  • Solution: Do not write reset-gpio in the DTS; simply leave it empty. The hardware will automatically handle the reset operation.

4. Results and Reflections

Through the systematic debugging process described above, the LT8911EXB driver was successfully loaded, the chip was initialized via I2C, and the eDP display was finally lit up.

This bring-up process was more than just establishing a data path; it required an understanding of not just one bus, but also reset circuits, Makefiles, DTS pin multiplexing, and the I2C R/W bit to successfully build the path. This project, through a concrete engineering problem, provided a comprehensive primer on the software-hardware interaction in embedded Linux systems:

  • Hardware is the Foundation: Verifying the physical layer—power, clock, reset—is fundamental. This experience has solidified my hardware debugging routine, giving me a clear starting point when faced with a non-functional board.
  • DTS is the Bridge: The Device Tree is not just a static hardware description but a “living map” for the kernel’s driver model to perform resource matching and dependency resolution. Any minor error can lead to driver loading failure.
  • Tools are Levers: Proficiency with tools like an oscilloscope, dmesg, i2cdetect, and sysfs is key to transforming a “black box” problem into a “white box” one.
  • Documentation and Source Code are the Truth: Schematic notes, driver documentation, and kernel source code are the ultimate sources of truth. A holistic view emerges only when all three are combined.

5. Tech Stack & Tools

  • Hardware Platform: Rockchip RK3568 SoC, Lontium LT8911EXB MIPI-to-eDP Bridge IC
  • Software Environment: Linux Kernel 5.10, Buildroot
  • Core Technologies: Embedded Linux BSP, Device Tree (DTS), I2C Subsystem, Pinctrl, GPIO, Kernel Drivers, Makefile
  • Debugging Tools:
    • Hardware: Siglent SDS2204X Plus Oscilloscope, Multimeter, Serial Console
    • Software: dmesg, printk, i2cdetect, sysfs (/sys/kernel/debug/, /sys/firmware/devicetree/)