Currently we are having problems related to MIPI-DSI / LVDS and our display, the display is showing signs of instable operation in the form of flickering lines.
A deep dive into our current setup and generation of the clock frequencies has been done. And we found some settings to be not correctly setup. Attached is a full block diagram with detailed register readout and calculations of all PLL's.
Overall setup
phyCORE-i.MX 8MM with 1G RAM and 4G flash soldered onto a custom carrier board. Running a Yocto based Linux image, version 6.6.52. With PHYTEC provided BSP package.
Connected display is a AUO 12.1-inch display.
Display data:
Htotal = 1480
Vtotal = 838
24 bit per pixels
60 FPS
eLCDif
The eLCDIf get its clock from LCDIF_PIXEL_CLK_ROOT (CCM_TARGET_ROOT74), reading all needed registers with memtool resulted in a calculated frequency of 74.25MHz.
The display datasheet states a clock timing of 74.4MHz@60FPS (1480x838x60).
Kernel clk_summary matches with the calculated values.
root@freshbrew:~# cat /sys/kernel/debug/clk/clk_summary| Clock | Enable count | Prepare count | Protect count | Rate | Accuracy | Phase | Duty cycle | Hardware enable | Consumer |
| video_pll1_ref_sel | 1 | 1 | 0 | 24000000 | 0 | 0 | 50000 | y | deviceless |
| video_pll1 | 1 | 1 | 0 | 1039500000 | 0 | 0 | 50000 | y | deviceless |
| video_pll1_bypass | 1 | 1 | 0 | 1039500000 | 0 | 0 | 50000 | y | deviceless |
| video_pll1_out | 1 | 1 | 0 | 1039500000 | 0 | 0 | 50000 | y | deviceless |
| lcdif_pixel | 1 | 1 | 0 | 7425000 | 0 | 0 | 50000 | y | 32e00000.lcdif |
(Setup of video_pll1 is known and matching with the numbers in green, but left out to simply the whole overview)
The current eLCDif setup is slightly under-clocked compared to the display's ideal requirements.
MIPI DSI D-PHY
The MIPI DSI D-PHY get its clock from MIPI_DSI_PHY_REF_CLK_ROOT (CCM_TARGET_ROOT_119)
And is set to 12MHz. So, the D-PHY-PLL Fin is 12MHZ. the MIPI DSI D-PHY output clock is calculated with:
“The DPHY PLL input clock is Fin. The PLL output (Fout) multiplies the input frequency (Fin) by (M / (P * 2^S)).” – 13.7.8.18.4 DPHY PLL – P.4157
The PMS are found in shadow register 13.6.5.1.24 - DSI_PLLCTRL - P.4113, which represent the register of 13.7.10.1 Master PLL MPS Values Setting Register – P. 4161
If interpreted correct, due to both have a first reserved bit [0], the register needs to be shift 2 bits
bits | MIPI_DPHY_M_PLLPMS | DSI_PLLCTRL |
PMS_S | [18:13] | [19:14] |
PMS_M | [12:4] | [13:5] |
PMS_P | [2:1] | [3:2] |
root@freshbrew:~# /root/memtool -32 0x32E10094 1
0x32E10094: 00816E84
1000 0001 0110 1110 1000 0100
Register status:
PMS_P [19:14] - 000101 - divide by 5
PMS_M [13:5] - 101110100 - divide by 372
PMS_S [3:2] - 01 - divide by 2
- Per-Lane Rate: 446.4 Mbps
- Total Bandwidth (4 Lanes): 446.4 X 4 1785.6Mbps
- Required for 74.25 MHz Pixel Clock (RGB888): 74.25 X 24 = 1782Mbps or greater
The MIPI DSI D-PHY has 0.2% overhead compared to the eLCDif.
Looking closer to the PMS settings of the D-PHY PLL reveals some problems with the current settings.
D-PHY parameters and notes for parameters - P.4158
extra notes found in register map - P.4162
The following problems arise:
- Frequency after PMS_P = 2.4MHz – not in specified divider range!
- PMS_M divider = 372 – not in specified divider range to ensure PLL stability!
- VCO_out frequency is 892.8MHZ – out of specified range of 350 MHz to 750 MHz!
- There is a discrepancy in the VCO frequency specifications within the documentation. Table 13-45 (DPHY PLL Parameters) specifies a VCO_out range of 1050–2100 MHz. However, this contradicts the note in the register map on P. 4162, which states the VCO_out range is between 350 MHz and 750 MHz.
NXP AN13573
The application note is used to calculated needed values.
3.8 Bandwidth calculations
Pixel Clock = 1480 x 838 x 60 = 74414400 HZ
Bandwidth = 74414400 HZ x 24 = 1785945600 bit/s
Data rate per lane = 1785945600 / 4 = 446486400 bit/s
MIPI D-PHY clock rate = 446486400 / 2 = 223243200 Hz
4.1.1 Initial system design
Pixel clock = (1280 + 200) x (800 + 38) x 60 fPS = 74.414.400 Hz
Bandwidth = 74.414.400 x 24 = 1.785.945.600 bit/s
DRPL = 1.785.945.600 / 4 = 446.486.400 bit/s
MIPI HS Bit Clock ≥ 446.486.400 Hz
4.1.2.1 Pixel clock setup
Fout = 1039.5MHz / 1 / 14 = 74.25MHz
FPS = 74.25MHz / (1480x838) ≈ 59,87 FPS
D-PHY bit clock = ((74.25MHz x 24 bit) / 4 lanses) x 1.125 = 501.1875MHz
With the help of these values new PMS values were calculated with a Pyhton script with is derived of the method sec_mipi_dsim_calc_pmsk found in the linux-phytec-imx/drivers/gpu/drm/bridge/sec-dsim.c file. Assuming that the VCO_out frequency should be between 350 to 750 MHz.
Reference Clock Fin in Hz: 12000000
H-Total (Active + Blanking): 1480
V-Total (Active + Blanking): 838
Frames Per Second (FPS): 60
Bits Per Pixel (Color Depth): 24
MIPI Lanes: 4
Overhead Multiplier: 1.125
Targeting Pixel Clock: 74,414,400.00 Hz
Targeting D-PHY Bit Clock (Fout): 502,297,200.00 Hz
--- Optimized Register Settings ---
P (Pre-divider): 1
M (Multiplier): 42
S (Post-divider): 0 (Divide by 1)
Fref: 12.000 MHz (Range: 6-12MHz)
VCO: 504.000 MHz (Range: 350-750MHz)
Final Fout: 504.000 MHz
Error: 1702800.00 Hz
MIPI DSI to LVDS bridge SN65DSI83
With the help of this Python script the register of the TI SN65DSI83 were read.
SN65DSI83 register dump | SN65DSI83 Configuration Report |
| reg 0x00 = 0x35 reg 0x01 = 0x38 reg 0x02 = 0x49 reg 0x03 = 0x53 reg 0x04 = 0x44 reg 0x05 = 0x20 reg 0x06 = 0x20 reg 0x07 = 0x20 reg 0x08 = 0x01 reg 0x0a = 0x85 reg 0x0b = 0x10 reg 0x0d = 0x01 reg 0x10 = 0x26 reg 0x11 = 0x00 reg 0x12 = 0x2d reg 0x18 = 0x18 reg 0x19 = 0x0c reg 0x1a = 0x00 reg 0x1b = 0x00 reg 0x20 = 0x00 reg 0x21 = 0x05 reg 0x24 = 0x20 reg 0x25 = 0x03 reg 0x28 = 0x21 reg 0x29 = 0x00 reg 0x2c = 0x64 reg 0x2d = 0x00 reg 0x30 = 0x12 reg 0x31 = 0x00 reg 0x34 = 0x32 reg 0x36 = 0x0a reg 0x38 = 0x32 reg 0x3a = 0x0a reg 0x3c = 0x00 reg 0xe0 = 0x00 reg 0xe1 = 0x00 reg 0xe5 = 0x00 | Clocking DSI Interface LVDS Interface Video Timing |
Two parameters stood out, 1. DSI Clock Divider: Divide by 2 and 2. DSI Clock Range: 225 to 230 MHz. Should the DSI clock divider not be set to 00000 = LVDS clock input, DSI_CLK_DIVIDER 0x0B [7:3] – P. 24?
Conclusion
As we have seen the MIPI D-PHY PLL setting settings are not within specified specs for the I.MX8MM and some settings for the TI SN65DSI83 mighty not match with the MIPI D-PHY.
And we are seeking input / feedback on:
- eLCDif configuration: The current pixel clock is 74.25 MHz , while the display datasheet specifies 74.4 MHz for optimal 60 FPS operation. Is this 0.2% discrepancy acceptable?
- Register interpretation: We have treated 13.6.5.1.24 and 13.7.10.1 as the same functional register. Is the 2-bit shift method we applied correct for extracting the PMS values from the DSI_PLLCTRL shadow register?
- VCO frequency range: There is a conflict in the documentation between Table 13-45 (1050–2100 MHz) and the register map notes on page 4162 (350–750 MHz). Which range is the authoritative specification for the i.MX 8MM D-PHY?
- PLL instability: The current settings yield a VCO_out of 892.8 MHz and a Fin_PLL of 2.4 MHz , both of which violate the stability requirements found in the manual. Using NXP AN13573, we calculated new values: P=1, M=42, S=0, (Fout = 504MHz). Do these values provide the expected stability for our 12.1-inch AUO display?
- Bridge configuration: The SN65DSI83 is currently set to a "Divide by 2" mode for the DSI clock. Should this be changed to 00000 (LVDS clock input) to ensure the bridge and D-PHY are properly synchronized?
- Kernel configuration: How to setup the kernel / device tree in such a way that the new PMS values and SN65DSI83 register value are used correctly?
Hello,
eLCDif configuration: The current pixel clock is 74.25 MHz , while the display datasheet specifies 74.4 MHz for optimal 60 FPS operation. Is this 0.2% discrepancy acceptable?
You need to confirm with DSI-to-LVDS bridge if this deviation is acceptable, in my experience it should be accpetable but I suggest you confirm it with manufacturer.
Register interpretation: We have treated 13.6.5.1.24 and 13.7.10.1 as the same functional register. Is the 2-bit shift method we applied correct for extracting the PMS values from the DSI_PLLCTRL shadow register?
Yes, your understanding is correct.
VCO frequency range: There is a conflict in the documentation between Table 13-45 (1050–2100 MHz) and the register map notes on page 4162 (350–750 MHz). Which range is the authoritative specification for the i.MX 8MM D-PHY?
Below is confirmed setting information:
Parameter Description Frequency Range (MHz)
Fin Input Frequency 6-300
Fin_pll P divider frequency 2-30
VCO_out (M*Fin) / P 1050-2100
Fout (M*Fin)/(P*2^S) 32.8125-2100
P Input Divider 1-63
M Feedback Divider 64-1023
S Output Divider (2^S) 1,2,4,8,16,32
PLL instability: The current settings yield a VCO_out of 892.8 MHz and a Fin_PLL of 2.4 MHz , both of which violate the stability requirements found in the manual. Using NXP AN13573, we calculated new values: P=1, M=42, S=0, (Fout = 504MHz). Do these values provide the expected stability for our 12.1-inch AUO display?
No, since current configuration is out of operating frequency range, you could have stability issues.
Bridge configuration: The SN65DSI83 is currently set to a "Divide by 2" mode for the DSI clock. Should this be changed to 00000 (LVDS clock input) to ensure the bridge and D-PHY are properly synchronized?
It should be ok since is under the SN65DSI83 DSI clock range but first check the PLL stability to be under the recommended ranges.
Kernel configuration: How to setup the kernel / device tree in such a way that the new PMS values and SN65DSI83 register value are used correctly?
This is done here:
https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/drivers/gpu/drm/bridge/sec-dsim.c
Best regards.
Hello,
1.
This unexpected value could be caused by this:
https://lists.freedesktop.org/archives/dri-devel/2022-December/383409.html
2.
This way could be considered since you are working with a display that is not implemented in our BSP.
Best regards.
Hello,
Thank you for your previous response. However, could you provide a more detailed explanation to move forward, as the brief answers provided so far don't fully address the discrepancies we are seeing in the hardware behavior.
1. This unexpected value could be caused by this:
https://lists.freedesktop.org/archives/dri-devel/2022-December/383409.html
This is the driver for the Exynos SoC and this offset is not used in the sec-dsim.c driver in Linux-IMX. Under drivers/gpu/drm/bridge there is also a samsung-dsim.c, here the offset is used. And again under drivers/gpu/drm/imx/ there is sec_mipi_dsim-imx.c.
How do all of these drivers differ from each other and or work together? Could you provide a explanation of the intended driver stack for the i.MX8MM?
I would like to circle back to my question regarding the datasheet notes for the PLL PMS values. Do we still need to take in the notes from the datasheet for the P and M divider?
P - NOTE: The programmable divider range should be within 1 to 33 to ensure PLL stability. The P divider value should also ensure the input frequency (Fin) is divided down between the range of 6 MHz to 12 MHz.
M - NOTE: The programmable divider range should be within 25 to 125 to ensure PLL stability.
Depending on whether those constraints apply, we see two different results for a target D-PHY Bit Clock of 502,297,200 Hz:
- Scenario A (Strict Constraints - NXP AN13573):
P=1, M=88, S=1 -> F_out = 528 MHz (Error: ~25.7 MHz) - Scenario B (Ignoring Constraints):
P=5, M=837, S=2 -> F_out = 502.2 MHz (Error: 97.2 kHz)
2. This way could be considered since you are working with a display that is not implemented in our BSP.
Regarding your suggestion about display implementation: our display is already supported via the panel-simple.c driver , and we have integrated it via a panel node in the Device Tree.
/*
* LCD-TFT
* Backlight - controlled by PWM 1 signal
*/
backlight: backlight {
compatible = "pwm-backlight";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd>;
default-brightness-level = <9>;
pwms = <&pwm1 0 1000000 0>;
power-supply = <®_vdd_3v3_s>;
enable-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
brightness-levels= <0 4 8 16 30 56 82 108 140 192 255>;
};
panel {
compatible = "auo,g121ean01";
backlight = <&backlight>;
power-supply = <®_vcc_3v3>;
port {
panel_in: endpoint {
remote-endpoint = <&bridge_out>;
};
};
};Hello,
1. You are correct, after check again timing parameters like 'p', 'm', 's' are obtained on the table in the following header file:
sec_mipi_dphy_ln14lpp.h\imx\drm\gpu\drivers - linux-imx - i.MX Linux kernel
You can use this post as reference:
2. I was referring for supported displays in our BSP by default, we have not validated your display in our side.
Best regards.