i.MX7Dual MIPI issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX7Dual MIPI issue

2,867 Views
l_madej
Contributor II

Dear Community,

I'm struggling with making AMOLED display up and running for three weeks now. Detailed description of the problem and bunch of questions are given below. Could you please try to answer them and advise me where should I dig to solve the issue?

All additional files mentioned in the description attached.

Thank you and kind regards,
Lukasz


General problem description:
MIPI display does not show any valid picture. Improper image (some rapidly changing glitches or shrunken image + flickers [depends on vertical front porch settings]) can be seen on the display only.


HW configuration:

  1. G1549HD122GF 720x1280 AMOLED display connected to MIPI-DSI of i.MX 7Dual.
  2. Two MIPI lanes used.

Verified display DT (taken from other project with different HW):

clock-frequency = <60000000>;

hactive = <720>;

vactive = <1280>;

hfront-porch = <20>;

hsync-len = <8>;

hback-porch = <20>;

vfront-porch = <20>;

vsync-len = <10>;

vback-porch = <20>;

SW configuration:

  1. Latest kernel from FLS BSP integrated with the project (https://source.codeaurora.org/external/imx/linux-imx/tree/?h=imx_4.9.88_2.0.0_ga),
  2. Display related kernel configuration as described in kernel_conf.txt (attached),
  3. Display related device tree configuration as described in device_tree.txt (attached),
  4. drivers/video/fbdev/mxsfb.c used as a driver for eLCD interface,
  5. drivers/video/fbdev/mxc/mipi_dsi_samsung.c used as a driver for MIPI-DSI interface. Quick fix for fifo read, debug messages added and small changes to MIPI configuration applied (attached),
  6. drivers/video/fbdev/mxc/mxcfb_govision_wxga.c used for low level AMOLED display initialization. The file is a draft at the moment and it has been created based on mxcfb_hx8369_wvga.c (attached).


Display & MIPI configuration:

  1. Frame buffer configuration as described by fb_videomode structure in drivers/video/fbdev/mxc/mxcfb_govision_wxga.c,
  2. MIPI in video mode, non-burst mode with sync events used (changes to drivers/video/fbdev/mxc/mipi_dsi_samsung.c applied),
  3. Pixel format: 24-bit RGB (888),
  4. Pixel clock (PCLK): 60 MHz,
  5. MIPI CLK speed: 744 MHz. Clock speed has been calculated as >= 12 * PCLK (changes to drivers/video/fbdev/mxc/mipi_dsi_samsung.c applied),


Current status:

  1. Display interface is initialized ("mxsfb 30730000.lcdif: initialized" visible in dmesg output). Complete dmesg output attached,
  2. Basically display does not show any valid picture. Improper images (some glitches or shrunken image with glitches) can be sometimes seen on the display (photo attached),
  3. Communication with the display in LP mode works fine. Display's registers can be written and read correctly (debug logs can be found in dmesg output). Oscillogram for one LS frame attached,
  4. After switching to HS mode communication with the display works ok (read/write from/to display's regs),
  5. Changes in frame buffer are reflected on MIPI lanes (oscillograms attached).


Questions:

  1. How shall I configure MIPI_DSI_PHYTIMING, MIPI_DSI_PHYTIMING1/2 registers? Description of the registers is not present in the Reference Manual so I'm not sure if values given by me are correct (in terms of values and mapping to MIPI D-PHY timings). Current values have been taken from display used in another project, verified against MIPI D-PHY specification and entered as number of nibble clocks (MIPI CLK / 4). [The same display has been used before with SSD2828 RGB->MIPI converter (datasheet attached) so I'm in possession of verified timings. SSD2828 D-PHY related registers values attached]. These D-PHY timings have been verified using scope and they seems to be correct but they have to be examined with MIPI_DSI_PHYTIMING, MIPI_DSI_PHYTIMING1/2 specification in hands.

  2. Might it be necessary to configure MIPI_DSI_PHYCTRL_B1/B2 and MIPI_DSI_PHYCTRL_M1/M2 registers? In FSL's samsung driver these are not configured. If yes how shall I proceed with the configuration (description of the registers is not present in the Reference Manual)?

  3. What is your general recomendation i.e. what should I check/correct to make the display up and running?

  4. According to Reference Manual chapter 13.4.3.8.2 eLCD sync signals shall be set to active high:
    "Vsync, Hsync, and VDEN are active high signals. Among the three signals, Vsync and
    Hsync are pulse types that spend several video clocks. RGB_VD[23:0] is {R[7:0],
    G[7:0], B[7:0]}. All sync signals are synchronized to the rising edge of RGB_VCLK"
    But in order to get valid data on MIPI lanes these have to be set to active low.
    Is my understanding correct? Could you please explain this?

  5. I'm able to get response of the display for content in the frame buffer but only for really high values of lower_margin (vertical front porch around 1000) which significantly reduces vertical refresh rate
    What is the proper way to configure MIPI_DSI_MVPORCH register?
    What is the proper way to configure vertical porch related fb_videomode struct members?
    After studying of Reference Manual chapter 13.4.3.8.2.5 my understanding is following:
    - MAINVBP field of MIPI_DSI_MVPORCH shall be equal to vertical back porch of the display (20),
    - fb_videomode struct member named upper_margin shall be equal to MAINVBP field,
    - STABLEVFP shall be equal to vertical front porch of the display (20),
    - CMDALLOW field of MIPI_DSI_MVPORCH can change from 0x0 to 0xF but I have no idea how to configure it. Could you advise me how to do it in my case?
    - fb_videomode struct member named lower_margin shall be equal to sum of CMDALLOW, STABLEVFP and CMD_MASK_AREA which has to be properly calculated.

    In my case CMD_MASK_AREA would be:

    esc_clock = 8.454545 MHz,
    LPDT transferring time = 1030 * 8 / esc_clock = 974.6 us
    One line time = (HFP + HBP + HACTIVE) * 1 / pxl_clk = (20 + 20 + 720) * 1 / 60000000 = 12.667 us
    Timing violation occurs in 77 lines
    CMD_MASK_AREA shall be > (77 + alpha).

    Could you please confirm that my general understanding and calculations are correct?
    How shall I calculate alpha?

Potential bug in the driver found:
According to reference manual frequency of escape clock equals PLL_out_clock divided by 8 and divided by escape clock divider value entered to MIPI_DSI_CLKCTRL register.
In mipi_dsi_samsung.c in func mipi_dsi_master_init() frequency of byte clock is calculated as 1500000000/8.
The calculation does not include changes of PLL_out_clock frequency (PLL_out_clock freq is set by MIPI_DI_PLLCTRL register) thus frequency of escape clock will be always incorrect.
I've verified above using oscilloscope, fixed code and calculations given below:

Fin = 24 MHz
PMS_S = 3; PMS_M = 93; PMS_P = 0
PLL_out_clock = Fin * 31 = 744 MHz
byte_clock = PLL_out_clock / 8 = 93 MHz
ESCPRESCALER = 11
esc_clock = 93 MHz / 11 = 8.454545 MHz
Time of each bit in LP mode shall equal ~118 ns - confirmed using scope (correct).

Labels (2)
Tags (1)
0 Kudos
Reply
5 Replies

2,220 Views
l_madej
Contributor II

Thank you for the answer.
Unfortunately setting proper D-PHY timings is not enough - the image is still not correct.
Are you able to find anything suspicious in my configuration?

Looking forward to hearing from you, 
Łukasz

0 Kudos
Reply

2,220 Views
joanxie
NXP TechSupport
NXP TechSupport

I updated in the salesforce, you can follow that, I've already mailed to you

2,220 Views
l_madej
Contributor II

Thank you very much for your support.
With given hints I've successfully run the display.

Basically I had to lower PLL frequency from 744 MHz to 360 MHz and apply proper D-PHY configuration.
Additionally I had to lower ESC_CLOCK frequency to make communication with the display in low power mode working (as described in my initial question in "Potential bug in the driver found" section).

Thank you once again and best regards,
Łukasz

0 Kudos
Reply

2,220 Views
koilarulraj
Contributor III

Hi Lukasz,

We are also working with iMX7D MIPI DSI interface. In our case we are converting the DSI signals to Parallel data using TC358762 bridge. We are configuring the DSI clock to 360Mhz using the values, (P=4, M=60 and S=0 ; Fout=Fin x (M / P x 2^S))

We are expecting 800x480 60Hz RGB24 output. But we are not getting any data from the DSI to parallel chip.

As of now we are calculating the ESC_CLOCK related values as follows,
byte_clk = 360000000 / 8;    /*Fout is configured as 360Mhz*/
esc_div  = DIV_ROUND_UP(byte_clk, 20 * 1000000);
reg |= (esc_div & 0xffff);
 /* enable escape clock for clock lane and data lane0 and lane1 */
 reg |= MIPI_DSI_LANE_ESC_CLK_EN(0x7);
 reg |= MIPI_DSI_ESC_CLK_EN(1);
 writel(reg, mipi_dsi->mmio_base + MIPI_DSI_CLKCTRL);

Are we configuring it correctly? Is there any modification needed? What is the purpose of escape clock in MIPI DSI data transmission?

Thanks,

Koil Arul Raj.S

0 Kudos
Reply

2,220 Views
joanxie
NXP TechSupport
NXP TechSupport

because the answer includes attachment, I send it to the DFAE, they will reply to you by  mail. pls wait.