OLED display support under DSI MIPI

Hello Jetson team and developers!

I’m going to connect OLED Display AUO H546DLB01.2 1920x1080 and Samsung’s OLED display 2560х1440, but I can’t understand: does this displays supported by DTB or I need to write my own drivers/kernel module to manage their settings (saturation/brightness/contrast, etc.)? Or where can I find information about this?

You may direct me to specification or provide some guide for my query, because I’m newbie in microelectronics topic.

Thanks for your attention!

I cannot answer your specific question. However, some information related to this may be of use.

There are often optional uses to various pins in a system, especially when integrated as a System on a Chip (SoC) or System on a Module (SoM). The device tree (and dtb file when compiled from source into binary form) is a way to specify how those pins are to be used. Different carrier boards with different pins used for different purposes result in using a different dtb even if the SoC is the same. On a Jetson you will typically see two numbers in supplied device tree supporting files…one number is for the module itself, the second number is for the carrier board. Module plus carrier results in the sum total of what the device tree will need to configure.

Drivers try to keep some of the vendor-specific settings out of the kernel. Device trees allow generic naming of a given pin or controller as seen from the kernel. The kernel won’t know a given pin number is a controller at a given address because it doesn’t need to know…the dtb has assigned this and the kernel is simplified as not having source code for every single hardware variation in the wild.

Very likely you will need something in the device tree to assign function to wires used by your OLED. Whether or not there is already a driver for that OLED I don’t know.

An example might be that if your OLED talks by serial UART, then several pins might work for this if and only if device tree names those pins to take that function…and then there might already be a driver. If there is no driver, e.g, this is a custom protocol and not something standard like i2c communications, then you would probably have to write the driver.