MIPI DSI display on Jetson TX2

Currently we are trying to setup a LCD display that is connected over MIPI DSI to the Jetson.

The display is a 800x1280 RGB display. The controller on the display is a JD9365 LCD driver.
We have setup the timing of the display according to the manufacturer settings (see snippets below).

Currently the display only shows rubbish. When we look with a scope to the MIPI signals, it does seem more or less correct.

Still there are a few questions.

  1. Using the dts settings below, we expect to see a RGB888 signal for the data, but we don’t find the 0xE3 MIPI command on MIPI lane0, with the settings below, is it correct that data is sent as RGB888

  2. What does the nvidia,h-ref-to-sync and nvidia,v-ref-to-sync mean, I can’t find this value in the documentation.

display-timings {      
  800x1280-32 {
    clock-frequency = <70794000>;
    hactive = <800>;
    vactive = <1280>;
    hfront-porch = <40>;
    hback-porch = <40>;
    hsync-len = <20>;
    vfront-porch = <16>;
    vback-porch = <6>;
    vsync-len = <9>;
    nvidia,h-ref-to-sync = <9>;
    nvidia,v-ref-to-sync = <1>;
  };
};

Also the init sequence for the display is configured in:

nvidia,dsi-init-cmd =
<TEGRA_DSI_PACKET_CMD DSI_DCS_WRITE_1_PARAM 0xE0 0x00 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0xE1 0x93 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0xE2 0x65 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0xE3 0xF8 0x00>,
...;
nvidia,dsi-n-init-cmd = <223>;
nvidia,dsi-pkt-seq =
  <CMD_VS LEN_SHORT CMD_BLNK LEN_HSYNC CMD_HE LEN_SHORT PKT_LP LINE_STOP>,
  <CMD_VE LEN_SHORT CMD_BLNK LEN_HSYNC CMD_HE LEN_SHORT PKT_LP LINE_STOP>,
  <CMD_HS LEN_SHORT CMD_BLNK LEN_HSYNC CMD_HE LEN_SHORT PKT_LP LINE_STOP>,
  <CMD_HS LEN_SHORT CMD_BLNK LEN_HSYNC CMD_HE LEN_SHORT CMD_BLNK LEN_HBP CMD_RGB_24BPP LEN_HACTIVE3 CMD_BLNK LEN_HFP PKT_LP LINE_STOP>,
  <CMD_HS LEN_SHORT CMD_BLNK LEN_HSYNC CMD_HE LEN_SHORT PKT_LP LINE_STOP>,
  <CMD_HS LEN_SHORT CMD_BLNK LEN_HSYNC CMD_HE LEN_SHORT CMD_BLNK LEN_HBP CMD_RGB_24BPP LEN_HACTIVE3 CMD_BLNK LEN_HFP PKT_LP LINE_STOP>;
dsi {
   panel-s-wuxga-8-0 {
     status = "disabled";
     compatible = "s,wuxga-8-0";
     nvidia,dsi-instance = <DSI_INSTANCE_0>;
     nvidia,dsi-n-data-lanes = <4>;
     nvidia,dsi-pixel-format = <TEGRA_DSI_PIXEL_FORMAT_24BIT_P>;
     nvidia,dsi-refresh-rate = <60>;
     nvidia,dsi-video-data-type = <TEGRA_DSI_VIDEO_TYPE_VIDEO_MODE>;
     nvidia,dsi-video-clock-mode = <TEGRA_DSI_VIDEO_CLOCK_CONTINUOUS>; //TEGRA_DSI_VIDEO_CLOCK_TX_ONLY
     nvidia,dsi-lp00-pre-panel-wakeup = <TEGRA_DSI_DISABLE>;
     /*nvidia,enable-hs-clk-in-lp-mode;*/
     nvidia,dsi-video-burst-mode = <TEGRA_DSI_VIDEO_NONE_BURST_MODE>;
     nvidia,dsi-controller-vs = <DSI_VS_1>;
     nvidia,dsi-virtual-channel = <TEGRA_DSI_VIRTUAL_CHANNEL_0>;
     nvidia,dsi-panel-reset = <TEGRA_DSI_ENABLE>;
     nvidia,dsi-ulpm-not-support = <TEGRA_DSI_ENABLE>;
     nvidia,dsi-suspend-stop-stream-late = <TEGRA_DSI_ENABLE>;
     nvidia,dsi-power-saving-suspend = <TEGRA_DSI_DISABLE>;
     nvidia,default_color_space = <1>;       /*default color profile:adobeRGB*/
  };
};

(i am on the same project)
We have a bunch of questions, one topic is the “nvidia,dsi-pkt-seq”
Is there some more detailed documentation on the “nvidia,dsi-pkt-seq”. in relation to the TRM page 2528?

e.g.
is one <…> entry equal to 1 line type?
should LEN_VBP be included in the CMD_RGB_24BPP ?

does CMD_VS mean vertical sync is asserted, until CMD_VE is used?
or does CMD_VS LEN_SHORT mean vertical sync is only asserted for LEN_SHORT

what is the definition of LEN_HACTIVE3 and LEN_HACTIVE5 (when should it be used?)

we have a somewhat lacking description of the display as to what it expects, and lacking understanding of how the dsi-pkt-seq can be used.

Is there an expert out there that could help us out and give more hints or refer to detailed dsi-pkt-seq spec?

kind regards,

h_ref_to_sync and v_ref_to_sync is used by nv driver only. You have to put proper value to meet the constraint in our driver.

Please refer to mode.c → check_ref_to_sync() for the constraint.

60  - nvidia,dsi-init-cmd: panel required init command sequence.
61  - nvidia,dsi-n-init-cmd: command counts of init command sequence, including delay set.
62  - nvidia,dsi-suspend-cmd: panel required suspend command sequence.
63  - nvidia,dsi-n-suspend-cmd: command counts of suspend command sequence, including delay set.
64  - nvidia,dsi-early-suspend-cmd: panel required early suspend command sequence.
65  - nvidia,dsi-n-early-suspend-cmd: command counts of early suspend command sequence, including delay set.
66  - nvidia,dsi-suspend-stop-stream-late: keep DC stream enabled while issuing suspend sequence; DC stream
67    will be stopped at the end of the suspend sequence.
68  - nvidia,dsi-late-resume-cmd: panel required late resume command sequence.
69  - nvidia,dsi-n-late-resume-cmd: command counts of late resume command sequence, including delay set.
70  - nvidia,dsi-pkt-seq: custom packet sequence since some panels need non standard packet sequence.
71  - nvidia,dsi-te-gpio: specifies a GPIO used for dsi panel TE signal.

For the other definition, please refer to

kernel/kernel-4.4/arch/powerpc/boot/dts/include/dt-bindings/display/tegra-panel.h

We finally figured out the problem: The display settings (nvidia,dsi-init-cmd) did not reach the display properly. Certain settings were modified by the hardware.

What we did see:
A display that was not properly configured.

To check where the problem lay, we checked the init sequence that was transferred over the MIPI DSI to the LCD. When we compared this to the data that should have been sent, we noticed some differences with the data in the packet sequence.

Our packet sequence consisted of:

...
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0x3C 0x72 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0x3D 0xFF 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0x3E 0xFF 0x00>
...
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0x2C 0x09 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0x2D 0x1A 0x00>,
<TEGRA_DSI_PACKET_CMD  DSI_DCS_WRITE_1_PARAM 0x2E 0x0B 0x00>,
...

For sequence commands that contain address 0x2D, 0x2E, 0x3D and 0x3E, the address and the value were replaced by 0x00. Resulting in that on address 0x00 value 0x00 was written in the LCD controller.

We traced this all the way to the tegra_dsi_controller_writel(…) function. In that function, when writel() is called, the value that is written to DSI_WR_DATA register is still valid. When we measure/trace in on the DSI line, the data is changed to 0x00.

We were able to work around this issue by changing the parts in the sequence where these addresses are written to long writes by making use of the auto increment in the LCD controller:

...
<TEGRA_DSI_PACKET_CMD DSI_DCS_LONG_WRITE 0x4 0x0 0x0 0x3C 0x38 0x1D 0x1F 0x0 0x0>,
...
<TEGRA_DSI_PACKET_CMD DSI_DCS_LONG_WRITE 0x4 0x0 0x0 0x2C 0x09 0x1A 0x0B 0x0 0x0>
...

We have it working now, but we still have some open questions:

  1. Is this a known bug in the silicon?
  2. Are only the 0x2D, 0x2E, 0x3D and 0x3E addresses affected by this bug?

We hope this post also helps other people with the same issue.

Regards,
Gerard Bos,
Benchmark Electronics

I am working on making a MIPI DSI display for Jetson Nano. The MIPI DSI display is a TFT-LCD module which is 8 inches display and contains 800x1280 pixels, use JD9365 as driver IC.

The initialization code of driver IC contains:

LCD_nReset=1;
Delayms(5);
LCD_nReset=0;
Delayms(10);
LCD_nReset=1;
Delayms(120);

How to set these configurations in DTS?

The comments can for DTS fields can not be found in latest Linux_for_Tegra. Where to find these information?

Please download the kernel source from our download center.
Linux_for_Tegra does not have this document.

Hi WayneWWW,

I downloaded L4T Sources 32.3.1 "L4T Jetson Nano, 32.3.1 Sources"1. There is no file in extracted kernel_src.tbz2 contains such information.

Are they contained in an old version of L4T Sources?