Hi
I'm having some troubles getting my display to work (TX18D211VM0BAA) with the i.MX7ULP. The display is using LVDS for communication, thus I have place a MIPI_DSI-LVDS bridge (SN65DSI83TPAPRQ1) to convert the signals for the display.
When booting Linux, it all seems fine:
root@imx7ulpevk:/# dmesg | grep -i -E "mipi|sn65|lcdif|video|drm|panel"
[ 0.085332] platform 40a90000.mipi_dsi: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[ 0.134710] platform 40a90000.mipi_dsi: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[ 0.135162] i2c 2-002c: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c/panel@0/ports/port@0
[ 0.135253] i2c 2-002c: Fixed dependency cycle(s) with /bus@40800000/mipi_dsi@40a90000
[ 0.142246] videodev: Linux video capture interface: v2.00
[ 0.146419] MIPI CSI2 driver module loaded
[ 0.564469] mipi_dsi_northwest 40a90000.mipi_dsi: i.MX MIPI DSI driver probed
[ 2.187945] [drm] Initialized vivante 1.0.0 20170808 for 41800000.gpu on minor 0
[ 7.157978] systemd[1]: Starting Load Kernel Module drm...
[ 14.327604] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 14.514570] systemd[1]: Finished Load Kernel Module drm.
though at the very end of the boot process I do get a notice the the Psplash failed to start:
[FAILED] Failed to start Terminate Psplash Boot Screen.
See 'systemctl status psplash-quit.service' for details.
Below is the snippets from the dts, that shows the configuration of the bridge and panel.
Do anyone have some ideas why nothing is shown on the display? Is there something that I'm failing or missing to do?
&lpi2c4 {
#address-cells = <1>;
#size-cells = <0>;
clock-frequency = <100000>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_lpi2c4>;
pinctrl-1 = <&pinctrl_lpi2c4>;
status = "okay";
dsi_lvds_bridge: sn65dsi83@2c {
compatible = "ti,sn65dsi83";
reg = <0x2c>; /* 7-bit I2C address */
pinctrl-names = "default";
pinctrl-0 = <&sn65dsi83_enable_pins &sn65dsi83_irq_pins>;
status = "okay";
interrupt-gpios = <&gpio_ptc 2 GPIO_ACTIVE_LOW>;/* PTC2 */
enable-gpios = <&gpio_ptc 3 GPIO_ACTIVE_HIGH>; /* PTC3 */
ti,dsi-lanes = <2>; /* Use two DSI lanes, DA0 and DA1 */
ti,lvds-format = <1>;
ti,lvds-bpp = <18>; /* 6-bit per color -> 18 bpp */
ti,lvds-channels = <1>;
ti,width-mm = <152>;
ti,height-mm = <91>;
video-mode = <1>;
/* dsi traffic mode (0=non-burst,1=sync-event,2=burst) */
dsi-traffic-mode = <0>;
panel: panel@0 {
compatible = "panel-simple";
reg = <0>;
label = "lvds-panel";
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <33300000>; /* Clock freq. 33.3 MHz */
hactive = <800>;
vactive = <480>;
hsync-len = <128>; /* thp (HS pulse) ≈ 128 */
hback-porch = <10>; /* thb */
hfront-porch = <118>; /* thf */
vsync-len = <1>; /* tvp~1 */
vback-porch = <9>; /* tvb (tvp+tvb = 10 -> tvb=9) */
vfront-porch = <35>; /* tvf */
de-active = <1>;
hsync-active = <0>;
vsync-active = <0>;
pixelclk-active = <0>;
};
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
endpoint {
panel_ep: endpoint {
/* left empty: this is the panel end-point */
};
};
};
};
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_bridge_in: endpoint {
remote-endpoint = <&dsi_out>; /* DSI host endpoint on &lcdif */
data-lanes = <0 1>;
};
};
port@1 {
reg = <1>;
lvds_bridge_out: endpoint {
remote-endpoint = <&panel_ep>; /* link to panel node */
};
};
};
};
};
&mipi_dsi {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_mipi_dsi_reset>;
pinctrl-1 = <&pinctrl_mipi_dsi_reset>;
lcd_panel = "TX18D211VM0BAA";
resets = <&mipi_dsi_reset>;
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dsi_out: endpoint {
remote-endpoint = <&lvds_bridge_in>;
data-lanes = <0 1>;
attach-bridge;
};
};
};
};
Hello,
The sn65dsi83 probe function pries to lock PLL from MIPI-DSI before imx_sec_dsim_encoder_atomic_enable() function ensbles it.
Moved piece of code that sets PLL to sn65dsi83_atomic_enable() function.
This problem was fixed after I adding
loglevel=8 drm.debug=0x1ff
to kernel commandline.
It was incorrect LVDS timing configuration so the mode was rejected.
Regards
Hi
Thanks for the answer.
I tried to apply the patch but it seems that the version (scarthgap 6.6.52) already have the modification in place. When applying patch, i tried to make a dry run and get the message:
"error: drivers/gpu/drm/imx/sec_mipi_dsim-imx.c: patch does not apply"
Looking into the file that are going to be patched, the lines that are added is found a little further down in the file.
This means that the patch unfortunately does not solve the problem.
Other suggestions to solve the problem are very welcome:-)
Regards
Hi
Maybe one more thing to consider in order to solve the problem... When I look at the clock for the mipi-dsi, it seems not to be enabled. I'm not sure if it supposed to be like that or if it should be enabled. Below is a screenshot of the clock register, and besides "hardware enable" which is no, then also the clock rate does not look right?
Any ideas?
/Regards
The device tree source (dts) for linux kernel defines some of the settings for the MIPI_DSI output and input for the LVDS-bridge, e.g. number of dsi lanes and lvds-bpp, but the bridge has more register settings that seems necessary to define to get the bridge working together with the MIPI_DSI output. The clock source for the LVDS-bridge is defined in register 0x0A, where bit zero is defining of the clock source is either derived from the REFCLK pin (default) or from the MIPI D-PHY channel – in my case I use the latter, which meant that bit 0 needs to be set. This is not the case when I am reading the registers from the linux command line.
All the channel posts that I can find regarding this topic seem only to mention the dts configuration and leave out the configuration of the registers of the bridge. Is there something I have missed?
Also the Kernel configuration provides an option of either compiling the sn65dsi83 kernel module or include the kernel module. To my understanding the kernel module provides the link between the dts and the hardware, thus the settings dts should be read by the kernel module and reflected in the settings of the bridge? Or how are the settings of the bridge defined if not by the kernel module?
I guess that the kernel module is compiled from the file ti-sn65dsi83.c which is included in the yocto/bitbake repository. This file seems to get the settings from somewhere else, could it be from the dts as suggested above?
Hope someone can shed some light on this
/Regards