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:
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:
Display & MIPI configuration:
Current status:
Questions:
"Vsync, Hsync, and VDEN are active high signals. Among the three signals, Vsync andBut in order to get valid data on MIPI lanes these have to be set to active low.
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"
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).
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
I updated in the salesforce, you can follow that, I've already mailed to you
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
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
because the answer includes attachment, I send it to the DFAE, they will reply to you by mail. pls wait.