I wanted to share my experience bringing up an (otherwise) unsupported AMOLED display on the CM4, as it may be helpful to others. I am a software engineer so my hardware understanding is limited, but (spoiler alert) I did manage to get it work. [1]
I'm building an embedded audio product and I wanted a touchscreen that was both brighter and had a higher pixel density than the default, supported displays. It's not impossible to find such displays online, but they cannot be directly interfaced with the 22-pin FPC connector on the I/O board (or, in our case, a custom board). It's not a simple matter of building a breakout board because the supported boards contain a microcontroller for power sequencing which is not present on the display I wanted to use.
So a number of things had to be done:
* building a driver board that provides power rails for both the display and touch panel (these are distinct components, indeed on some displays they will have separate connectors) as well as handling power sequencing. (Because AMOLED displays manage brightness through MIPI (by definition), they do not need a microcontroller to drive the PWM backlight, so a simple I2C expander would suffice. Of course, a RP2040 – which we ended up using – can be cheaper than an expander.)
* writing a kernel ‘regulator’ driver that exposes the display and touch panel’s reset pins as a Linux GPIO device. rpi-panel-v2-regulator.c is a good starting point for this.
* writing a driver for the display: this is the most complicated part, and without the initialisation sequence provided by the vendor, it will be difficult to impossible to get this to work.
* writing a driver for the touch panel (fortunately, the FT3519 on ours worked fine with the edt-ft5x06 driver)
* creating a device tree overlay
Being a software chap, the driver board was outsourced to a colleague. We ended up using a RP2040 instead of an I2C expander as we wanted it to do some other things (rotary encoders, sequencing some other MCUs, etc).
The display itself uses the ICNA3512 controller chip. Getting this working took quite a while, firstly obviously without a MIPI analyser one has no hope of decoding the commands (and even this would be of questionable value given that most of the commands are writes with no response). The initialisation sequence will likely be provided by the vendor as an undocumented blob of hex values, so it can take some work to map them to MIPI commands, if you want to actually understand what they’re doing (this is important, for example, to hook up brightness control to the kernel’s backlight subsystem). Claude is pretty good as doing this though.
Getting the display to initialise reliably took some careful reading of the data sheet and will depend on what state the reset pin is at startup; I won’t dwell on this as this will likely be display-specific. You may want to consider whether to define the pin as active high or low in the device tree; in the latter case, the parameter to the kernel’s GPIO APIs is inverted. Another gotcha is the display timing (the values in drm_display_mode). It’s worth asking the vendor for a range of values that will work, so you can pick one that won’t be modified by vc4_dsi_bridge_mode_fixup(): other posts on this forum describe why this is necessary.
[1] https://github.com/PADL/linux/tree/rpi- ... xebros-rmu
I'm building an embedded audio product and I wanted a touchscreen that was both brighter and had a higher pixel density than the default, supported displays. It's not impossible to find such displays online, but they cannot be directly interfaced with the 22-pin FPC connector on the I/O board (or, in our case, a custom board). It's not a simple matter of building a breakout board because the supported boards contain a microcontroller for power sequencing which is not present on the display I wanted to use.
So a number of things had to be done:
* building a driver board that provides power rails for both the display and touch panel (these are distinct components, indeed on some displays they will have separate connectors) as well as handling power sequencing. (Because AMOLED displays manage brightness through MIPI (by definition), they do not need a microcontroller to drive the PWM backlight, so a simple I2C expander would suffice. Of course, a RP2040 – which we ended up using – can be cheaper than an expander.)
* writing a kernel ‘regulator’ driver that exposes the display and touch panel’s reset pins as a Linux GPIO device. rpi-panel-v2-regulator.c is a good starting point for this.
* writing a driver for the display: this is the most complicated part, and without the initialisation sequence provided by the vendor, it will be difficult to impossible to get this to work.
* writing a driver for the touch panel (fortunately, the FT3519 on ours worked fine with the edt-ft5x06 driver)
* creating a device tree overlay
Being a software chap, the driver board was outsourced to a colleague. We ended up using a RP2040 instead of an I2C expander as we wanted it to do some other things (rotary encoders, sequencing some other MCUs, etc).
The display itself uses the ICNA3512 controller chip. Getting this working took quite a while, firstly obviously without a MIPI analyser one has no hope of decoding the commands (and even this would be of questionable value given that most of the commands are writes with no response). The initialisation sequence will likely be provided by the vendor as an undocumented blob of hex values, so it can take some work to map them to MIPI commands, if you want to actually understand what they’re doing (this is important, for example, to hook up brightness control to the kernel’s backlight subsystem). Claude is pretty good as doing this though.
Getting the display to initialise reliably took some careful reading of the data sheet and will depend on what state the reset pin is at startup; I won’t dwell on this as this will likely be display-specific. You may want to consider whether to define the pin as active high or low in the device tree; in the latter case, the parameter to the kernel’s GPIO APIs is inverted. Another gotcha is the display timing (the values in drm_display_mode). It’s worth asking the vendor for a range of values that will work, so you can pick one that won’t be modified by vc4_dsi_bridge_mode_fixup(): other posts on this forum describe why this is necessary.
[1] https://github.com/PADL/linux/tree/rpi- ... xebros-rmu
Statistics: Posted by lukehatpadl — Sun Dec 21, 2025 10:15 pm