Verdin AM62 MIPI DSI 24-bit color depth?

vilchanskyio · February 18, 2026, 12:40pm

Hi,

according the the Toradex Verdin AM62 SoM datasheet, it seems like only 18-bit MIPI DSI is routed:

And later the datasheet says:

Some Verdin AM62 variants support DSI video output via the Toshiba TC9594XBG Parallel Port (RGB) to MIPI DSI bridge, attached to the Display Parallel Interface of the SoC.

The DSI interface supports 16, 18, and 24-bit color modes. The 24-bit mode has an image color depth of 18 bits (same depth of the 18-bit mode), as the 2 LSBs of each color channel copy the 2 MSBs.

At the same time, AM62x technical reference manual has specifies that MIPI DPI 24-bit is supported:

And the Toshiba RGB to DSI converter also supports 24-bit:

So, is the 24-bit support simply not physically routed from SoC to SoM? If it isn’t, is there a technical limitation that forced this decision, or is it a business-related decision from Toradex?

Or I am I missing something? I found in arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi that data-lines is set to 18:

	dsi_bridge: dsi@e {
		compatible = "toshiba,tc358778";
		reg = <0xe>;
		assigned-clocks = <&k3_clks 157 20>;
		assigned-clock-parents = <&k3_clks 157 22>;
		assigned-clock-rates = <25000000>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_bridge_reset>;
		clocks = <&k3_clks 157 20>;
		clock-names = "refclk";
		reset-gpios = <&main_gpio0 20 GPIO_ACTIVE_LOW>;
		vddc-supply = <&reg_1v2_dsi>;
		vddmipi-supply = <&reg_1v2_dsi>;
		vddio-supply = <&reg_1v8_dsi>;
		status = "disabled";

		dsi_bridge_ports: ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;

				rgb_in: endpoint {
					data-lines = <18>;
					remote-endpoint = <&dpi_out>;
				};
			};

			port@1 {
				reg = <1>;
			};
		};
	};

But given the Toradex datasheet, I doubt that I can do anything about this?

ToradexAI · February 18, 2026, 12:40pm

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I’d be glad to help! Could you let me know which OS and version you are using, and which specific Verdin AM62 variant you’re working with? You can use the tdx-info command to get detailed information about your setup: tdx-info

This information will help me provide more specific guidance about your MIPI DSI configuration and the data-lines setting you’re seeing in the device tree.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

vilchanskyio · February 18, 2026, 12:41pm

Torizon OS 7.5.0, Verdin AM62 1.2A.

ToradexAI · February 18, 2026, 12:42pm

Based on the information in the sources, I can see that you’re working with MIPI DSI configuration on the Verdin AM62, and your observation about the 18-bit limitation is correct based on the device tree configuration.

Device Tree Configuration

The sources show that for MIPI DSI displays on Verdin AM62, you need to enable the dss node in your device tree overlay (1). Here’s the required configuration:

&dss {
	status = "okay";
};

(1)

Display Panel Configuration

For custom MIPI DSI displays, you’ll need to create a device tree overlay that defines your panel specifications (2). Device Tree Overlays allow you to modify the device tree without recompiling the entire kernel, which is ideal for customizing hardware configurations like display interfaces (2).

MIPI DSI Implementation Considerations

Based on community discussions, when working with MIPI DSI on Toradex modules, the system needs to recognize the display through proper device tree configuration (3). The sources indicate that for custom displays, you may need to:

Create a custom device tree overlay that defines your specific panel timing parameters (2)
Ensure proper driver support for your display controller (1)
Configure the display subsystem correctly in the device tree (1)

Next Steps

To work with your specific display requirements, you’ll need to create a custom device tree overlay following the principles outlined in the Device Tree Overlays Technical Overview (2). This involves defining the display timing parameters that match your hardware specifications.

The 18-bit limitation you’re seeing in the device tree appears to be the current configuration for the Verdin AM62 platform based on the hardware routing decisions.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

vilchanskyio · February 23, 2026, 12:17pm

Hey, any update on this?

To reiterate my main questions:

So, is the 24-bit support simply not physically routed from SoC to SoM?

If it isn’t, is there a technical limitation that forced this decision, or is it a business-related decision from Toradex?

diegom.tx · February 23, 2026, 3:42pm

Hi Oleksii,

thanks for the detailed analysis and for pointing out the different references (SoM datasheet, AM62x TRM and the Toshiba bridge datasheet).

You understood it correctly:

On Verdin AM62, only 18 bits of the parallel RGB interface are routed from the SoC to the on‑module DSI bridge.
The Toshiba bridge and the AM62x SoC are in fact capable of 24‑bit RGB, but on our Verdin AM62 design we intentionally use an 18‑bit RGB bus, and that is what is reflected in the device tree (data-lines = <18>;) and in the Verdin AM62 datasheet.
The 24‑bit DSI mode mentioned in the datasheet is the bridge’s mode where the extra LSBs are just replicated (the image color depth remains effectively 18 bits, as the text states).

So yes, in practice there is no way on Verdin AM62 to get a true 24‑bit RGB path into the bridge; this is a hardware design decision of the module, not something that can be overridden in software.

Do you actually require a true 24‑bit color path end‑to‑end (24 bits into the bridge and panel), or is 18‑bit effective color depth acceptable for your application?
If this is a blocking limitation for your design, could you share a bit more about your display and image quality requirements so we can see whether there is a suitable workaround or an alternative interface/module that better matches your needs?

Best regards,

vilchanskyio · February 23, 2026, 4:03pm

Thanks for the reply, Diego.

The main issue with software rendering in 24-bit and hardware being able to push through only 18-bit colors is in noticable color banding. This may be replicated with the default Torizon OS 7.5.0 and gradients demo (from qt6-am62 container) running inside a Weston session (from weston-am62 container).

Here is how it looks with default settings (phone photo):

Versus how it “should look” in a perfect scenario (this is a screenshot):

For now, we achieved a “good enough” image by setting RGB565 surface format in Weston, which instructs GPU to render in 16-bit mode and this seems to apply GPU-level dithering, which results in much smoother gradients (quite close to the “perfect” scenario on the screenshot).

I don’t have a photo of the final result, because the camera was too eager to focus on the pixel cells instead of the image, so it wouldn’t do it proper justice. Owners of Verdin AM62 reading this thread can try it on their own

We were just a bit surprised to find out about this limitation (I think, even 10-years old i.MX6 SoMs do 24-bit colors) and wanted to confirm our findings, but we completely understand the decision.

In case we get a hard requirement on 24-bit color depth, we will consider an upgrade to a “higher-class” SoM in the Verdin family, or contact Toradex about any potential custom design changes.

diegom.tx · February 23, 2026, 4:27pm

Thanks a lot for the detailed feedback Oleksii! And also, for sharing your test results with the gradients demo.

Please count on us for anything you need regarding this topic or future evaluations (testing, setup changes, or checking alternatives in the Verdin family).

On the technical side, your observations are spot on:

Rendering in 24‑bit while the hardware path is effectively 18‑bit makes banding more visible, especially in smooth gradients.
Forcing RGB565 in Weston is a solid workaround: it aligns the pipeline to a lower color depth and the GPU dithering helps hide quantization artifacts, which explains the much smoother result you’re seeing.

If you eventually get a strict requirement for true 24‑bit color end‑to‑end, we can support you in evaluating higher‑class Verdin SoMs or discussing possible custom design options.

Best regards,
Diego