TF55001A-V0 Display for DragonBoard 410C


#1

Hello,

We have a DragonBoard 410C, and would like to combine it with a TF55001A-V0 display (with a Raydium RM69071 driver ic) and we are wondering if this is possible.

Our electrical engineers have developed a pcb to convert the 60-pin mipi-dsi to the correct 40-pin mipi-dsi, but we can’t find corresponding files as mentioned in the display porting guide.

Any help would be much appreciated!


#2

Hi @DLeijen

The first question is “Which Operating system are you using?” Android, Linux. or Win10?

Full disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.


#3

Hey @ljking,

Sorry for the late reply, busy weekend.

Preference would be android, so our app developer can handle software side of the DragonBoard, but linux would also be fine for us.

End goal is to have our own pcb, which can be powered by supercaps to play locally cached video for at least 3 minutes before needing to be charged again, meaning we have a 5V 0.7mA power budget. If OS has major impact on the power usage, we would like to know that too.


#4

Is there anybody else with a suggestion how to use either this display or another display that works with the DragonBoard 410C, is fullHD, amoled, and connected through mipi-DSI?


#5

Attaching any display to any of the 96Boards is a two part problem:

  1. The first part of the problem is the electrical connections. The MIPI-DSI standard describes the electrical signals that flow between the host SOC (the APQ8016 in this case) and the display controller chip (The RM69071 chip in the display module in this case). The MIPI-DSI standard does not specify a ‘standard’ physical connector for MIPI-DSI displays, in fact you will find that every model of display has a different physical connector, and a different pin-out order. The 96Boards standard does specify a standard connector for the MIPI-DSI signals and all of the compliant 96Boards products will match this connector and pin-out (the High-Speed connector on the board). In order to use a specific display module you will need to create a custom mezzanine PCB that has the correct mating connectors and electrical connections.

  2. The second part of the problem is the software drivers for the panel. Even this part of the problem has two sub-problems, the first is the driver for the display, and the second is the driver for the touch screen controller.
    2a) The display driver must set up the MIPI-DSI display controller in the SOC with the correct timing and data formats. For the 410c there is an app note that will help you get started. You also need to initialize the display controller on the display module to accept the timing signals and to drive OLED array. We do publish some guidelines on how to set-up the display controller for Android in the Application Note: https://developer.qualcomm.com/download/db410c/dsi-display-porting-guide-linux-android.pdf Some display controllers are initialized over I2C, ad some are initialized over the MIPI-DSI virtual command channel.Setting up the controller on the display module is different for each controller and OLED matrix, you will need to get documentation form the display module manufacturer, and the display controller manufacturer to determine how the program the controller.
    2b) The Touchscreen controller usually communicates with the host SOC over I2C, however I have seen some that communicate over SPI. Again you will need datasheets and programming guides for the touch screen controller manufacturer in order to set this up.

Without a PCB or the programming guides for the display, display controller, and the touch screen controller we will not be able to give you much more help than this. Hopefully this post will give you some guidance on what information you need and what you need to do to interface the display module with the 410c.

Full disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.


#6

Hello @ljking

as i saw an expert entry about the thema in forum , I have decided to take my chance and shoot my question.
I would appreciate any sort of hinweis .

I work on Snapdragon 820 Apq8096 board .
I work thougt the display porting guide (which is for Snapdragon 410 , still guiding and useful).
There are some points that make me confuse :

There are steps to introduce /import display panel settings (via device tree and header for bootloader) but there are nothing about display controller and touch controller porting .

From the point of hardware view :
Display = panel + display controller + backlight unit(optinal) + touch controller (optional)
Right ? It is not the same also from the software side ?

I digged the existing device tree and kernel and found entries , driver ,header files for display controller and touch controller.
That means they should be also ported, right ?or am I missing something ?

Thanks in advance ,
Elif


#7

Hi @Elif

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

-Lawrence-
no longer a Qualcomm employee
Looking for a new employer


#8

Hello Lawrance @ljking ,
Thank you very much for the precious ,detailed information.
I am going to work through on each line

Glad to see that i am on the right path. All datasheets and drivers i have .The adapter board design is on process.

Excuse me if i ask further and a little bit detailed ones :

About the second step : LCD controller chip programming is normally the display vendors duty, right ?So what you have mentioned here is a rare case.or not?

About the fourth : Even if the touch controller chip is integrated in the display module , is it not necessary to import the driver file in kernel and also in device tree ?

Thanks and I hope that you find your dream job soon.
Best regards,
Elif


#9

Hi @Elif

Yes you are correct about step 2, normally the display vendor will give you a list registers and values and the list is embedded into the driver for that specific panel assembly. However not all vendors give you the list, they just give you specifications and you have to figure it out based on the controller IC datasheet.

As to step 4, Yes, you do need a driver and a device tree entry for the touch screen.

-Lawrence-
no longer a Qualcomm employee
Looking for a new employer


#10

Thanks again @ljking for the guidance .

Best regards,
Elif