SN65DSI83: PLL isuce

GARETH OU

Guru 11905 points

Part Number: SN65DSI83

Tool/software:

We customer want to ask why PLL not getting locked, if you want any specific register dump, we can share with you.

4 months ago

0 Ikram Haque 4 months ago

TI__Mastermind 26540 points

Hi Gareth,

Could you please tell us how you are programming the device and the setup/configurations you are using.

You can use the DSI Tuner tool to program the device during initialization. You can download it here: SN65DSI83: DSI TUNER tool needed - Interface forum - Interface - TI E2E support forums

Here's a guide for using this tool: https://www.ti.com/lit/an/slla332b/slla332b.pdf?ts=1746586623218

As a first step, please use the test pattern mode to send a generated test pattern from the device. Please follow the steps in the datasheet initialization sequence.

Best regards,
Ikram

0 GARETH OU 4 months ago in reply to Ikram Haque

Guru 11905 points

Hi Ikram

We have written the dsi2lvds bridge sn65dsi83_display() commands and read back. They are showing correct what is expected.

Can you please confirm?

[ 203.925106][ T1740] Justin line:443 func:sn65dsi83_display read back i2c data address : value;

[ 203.934663][ T1740] 0x9 : 0x0;

[ 203.935344][ T1740] 0xd : 0x1;

[ 203.939747][ T1740] 0xa : 0x3;

[ 203.943894][ T1740] 0xb : 0x10;

[ 203.947836][ T1740] 0x10 : 0x20;

[ 203.952082][ T1740] 0x11 : 0x0;

[ 203.956188][ T1740] 0x12 : 0x1c;

[ 203.960483][ T1740] 0x18 : 0x78;

[ 203.964968][ T1740] 0x19 : 0x4;

[ 203.969709][ T1740] 0x1a : 0x1;

[ 203.973943][ T1740] 0x1b : 0x0;

[ 203.977957][ T1740] 0x28 : 0x20;

[ 203.981975][ T1740] 0x29 : 0x0;

[ 203.986082][ T1740] 0x20 : 0x0;

[ 203.990554][ T1740] 0x21 : 0x4;

[ 203.994580][ T1740] 0x24 : 0x58;

[ 203.998600][ T1740] 0x25 : 0x2;

[ 204.002732][ T1740] 0x2c : 0x78;

[ 204.006749][ T1740] 0x2d : 0x0;

[ 204.011049][ T1740] 0x30 : 0xf;

[ 204.015373][ T1740] 0x31 : 0x0;

[ 204.019381][ T1740] 0x34 : 0x64;

[ 204.023629][ T1740] 0x36 : 0xa;

[ 204.027971][ T1740] 0x38 : 0x64;

[ 204.031985][ T1740] 0x3a : 0xa;

[ 204.036299][ T1740] 0x3c : 0x0;

[ 204.040312][ T1740] 0xd : 0x1;

[ 204.047524][ T1740] 0x9 : 0x0;

[ 204.050770][ T1740]

[ 204.050770][ T1740] Justin sn65dsi83 line:450 func:sn65dsi83_display

[ 204.062756][ T1740] Harish sn65dsi83 link reset done

[ 204.097866][ T1740] Justin line:621 func:sn65dsi83_atomic_pre_enable

[ 204.206313][ T1740] sn65dsi83 3-002d: failed to lock PLL, ret=-110

Still we see that PLL lock is failing.

Can you please let us know what could be the issue.

0 GARETH OU 4 months ago in reply to GARETH OU

Guru 11905 points

Hi Ikram

here’s further information from our engineer~

Please find the register dump of the Colorbar test i2c write then read for reference for TI to be passed on.

[ 41.650535][ T1682] Justin line:408 func:colorbarTest read back i2c data address : value;

[ 41.660226][ T1682] 0x9 : 0x0;

[ 41.661341][ T1682] 0xd : 0x1;

[ 41.665909][ T1682] 0xa : 0x3;

[ 41.670430][ T1682] 0xb : 0x28;

[ 41.674966][ T1682] 0x10 : 0x20;

[ 41.679580][ T1682] 0x11 : 0x0;

[ 41.684283][ T1682] 0x12 : 0x3d;

[ 41.688312][ T1682] 0x18 : 0x78;

[ 41.692415][ T1682] 0x19 : 0x4;

[ 41.696518][ T1682] 0x1a : 0x1;

[ 41.700540][ T1682] 0x1b : 0x0;

[ 41.704552][ T1682] 0x28 : 0x20;

[ 41.708559][ T1682] 0x29 : 0x0;

[ 41.712667][ T1682] 0x20 : 0x0;

[ 41.716685][ T1682] 0x21 : 0x4;

[ 41.720693][ T1682] 0x24 : 0x58;

[ 41.724980][ T1682] 0x25 : 0x2;

[ 41.729092][ T1682] 0x2c : 0x78;

[ 41.733529][ T1682] 0x2d : 0x0;

[ 41.737638][ T1682] 0x30 : 0xf;

[ 41.741664][ T1682] 0x31 : 0x0;

[ 41.745674][ T1682] 0x34 : 0x64;

[ 41.749679][ T1682] 0x36 : 0xa;

[ 41.753775][ T1682] 0x38 : 0x64;

[ 41.757780][ T1682] 0x3a : 0xa;

[ 41.761885][ T1682] 0x3c : 0x10;

[ 41.765893][ T1682] 0xd : 0x1;

[ 41.773423][ T1682] 0x9 : 0x0;

[ 41.777718][ T1682] 0xe5 : 0x1;

Also please find the dsi clk output for reference for TI:

sh-5.2# cat /sys/kernel/debug/clk/clk_summary | grep dsi

gcc_disp_hf_axi_clk 2 2 0 0 0 0 50000 Y ae94000.dsi bus

dsi0vco_clk 1 1 0 604800000 0 0 50000 Y deviceless no_connection_id

dsi0_pll_out_div_clk 1 1 0 302400000 0 0 50000 Y deviceless no_connection_id

dsi0_pll_post_out_div_clk 0 0 0 75600000 0 0 50000 Y deviceless no_connection_id

dsi0_pll_bit_clk 2 2 0 302400000 0 0 50000 Y deviceless no_connection_id

dsi0_pclk_mux 1 1 0 302400000 0 0 50000 Y deviceless no_connection_id

dsi0_phy_pll_out_dsiclk 1 1 0 50400000 0 0 50000 Y deviceless no_connection_id

disp_cc_mdss_pclk0_clk 1 1 0 50400000 0 0 50000 Y ae94000.dsi pixel

dsi0_pll_by_2_bit_clk 0 0 0 151200000 0 0 50000 Y deviceless no_connection_id

dsi0_phy_pll_out_byteclk 1 1 0 37800000 0 0 50000 Y deviceless no_connection_id

disp_cc_mdss_byte0_intf_clk 1 1 0 18900000 0 0 50000 Y ae94000.dsi byte_intf

disp_cc_mdss_byte0_clk 1 1 0 37800000 0 0 50000 Y ae94000.dsi byte

ae94000.dsi byte

disp_cc_mdss_esc0_clk 1 1 0 19200000 0 0 50000 Y ae94000.dsi core

disp_cc_mdss_ahb_clk 4 4 0 19200000 0 0 50000 Y ae94000.dsi iface

ae94000.dsi iface

0 Ikram Haque 4 months ago in reply to GARETH OU

TI__Mastermind 26540 points

Hi Gareth,

With the color bars test pattern did the display output video as expected?

Please clear the 0xE5 register, and then read it back to check for errors during runtime.

Do the programmed resolution and display timings match the DSI source settings? PLL not locking can be caused by timing mismatches. Could you share what the display timings programmed are and the pixel clock rate? Also please share the DSI clock rate used.

Best regards,
Ikram

0 GARETH OU 4 months ago in reply to Ikram Haque

Guru 11905 points

Hi Ikram

We are checking the trial of clearing the 0xE5 register which as per datasheet we need to write 1 to clear it.

The Timings are matching as per resolution as well as read back from the register dumps.

mode = drm_mode_duplicate(connector->dev, &(struct drm_display_mode) {

.clock = 50400, // pixel clock in kHz

.hdisplay = 1024,

.hsync_start = 1024 + 100,

.hsync_end = 1024 + 100 + 120,

.htotal = 1024 + 100 + 120 + 100,

.vdisplay = 600,

.vsync_start = 600 + 10,

.vsync_end = 600 + 10 + 15,

.vtotal = 600 + 10 + 15 + 10,

.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,

});

hdisplay = 1024,

[ 41.712667][ T1682] 0x20 : 0x0;

[ 41.716685][ T1682] 0x21 : 0x4;

vdisplay = 600,

[ 41.720693][ T1682] 0x24 : 0x58;

[ 41.724980][ T1682] 0x25 : 0x2;

Horizontal Front porch : 100

[ 41.753775][ T1682] 0x38 : 0x64;

Horizontal Back porch: 100

[ 41.745674][ T1682] 0x34 : 0x64;

Horizontal pulse width: 120

[ 41.729092][ T1682] 0x2c : 0x78;

[ 41.733529][ T1682] 0x2d : 0x0;

Vertical Front Porch : 10

[ 41.757780][ T1682] 0x3a : 0xa;

Vertical Back Porch : 10

[ 41.749679][ T1682] 0x36 : 0xa;

Vertical Pulse Width : 15

[ 41.737638][ T1682] 0x30 : 0xf;

[ 41.741664][ T1682] 0x31 : 0x0;

Dsi clock matches from the clock summary

Dsi0_phy_pll_out_dsiclk 50,400,000 PHY DSI clock

Could this be related to port used in the connection?

Please check the dtsi node entry for the bridge:

sn65dsi83: ti,sn65dsi83@2d {

compatible = "ti,sn65dsi83";

reg = <0x2d>;

// interrupt-parent = <&tlmm>;

// interrupts = <18 0>;

// interrupt-names = "lt_irq";

//sn65dsi83,irq = <&tlmm 18 0>;

reset-gpios = <&tlmm 17 0>;

power-gpios = <&tlmm 119 0>;

// lcd,reset = <&tlmm 147 0>;

lcdpwr-gpios = <&tlmm 117 0>;

lcd,backlight = <&tlmm 60 0>;

probe-option = <1>;

status = "okay";

ports {

#address-cells = <1>;

#size-cells = <0>;

port@0 {

reg = <0>;

sn65_in: endpoint {

data-lanes = <0 1 2 3>;

remote-endpoint = <&mdss_dsi0_out>;

};

port@2 {

reg = <2>;

sn65_out: endpoint {

remote-endpoint = <&panel_in>;

};

&mdss_dsi0_out {

remote-endpoint = <&sn65_in>;

data-lanes = <0 1 2 3>;

};

panel: panel-lvds {

compatible = "sn65,fx07";

status = "okay";

port {

panel_in: endpoint {

remote-endpoint = <&sn65_out>;

};

0 Ikram Haque 4 months ago in reply to GARETH OU

TI__Mastermind 26540 points

Hi Gareth,

Thank you for sharing the script. I will check and get back to you in 1-2 days.

Best regards,
Ikram

0 Justin Philip 4 months ago in reply to Ikram Haque

Prodigy 30 points

Hi Ikram,

I am working with Gareth to reproduce the issue.

We tried to clear E5 register by writing 1 to it.

But it always reads 1 (PLL lock not aquired) even if try this multiple times with delay as well.

Regards

Justin

0 Ikram Haque 4 months ago in reply to Justin Philip

TI__Mastermind 26540 points

HI Justin, I am checking this issue and I will get back to you soon.

0 Ikram Haque 4 months ago in reply to Ikram Haque

TI__Mastermind 26540 points

Hi Gareth, Justin,

Your current register dump shows that the DSI clock is used as the source clock, and the divider is set to 11. If the pixel clock rate is 50.4, then the DSI clock rate should be 554.4 MHz. Is this what it is currently set to?

In the initialization sequence, it mentions that the DSI clock should be in HS state while data lanes are in LP11 state at the start. Then after programming and soft reset, the data lanes are set to HS mode. Is the system following the full initialization sequence?

Best regards,
Ikram

0 Justin Philip 4 months ago in reply to Ikram Haque

Prodigy 30 points

Hi Ikram,

Updated pixel clock is 51206KHz as

it should be htotal*vtotal*60fps = 51206400

mode = drm_mode_duplicate(connector->dev, &(struct drm_display_mode) {
.clock = 51206, // pixel clock in kHz
.hdisplay = 1024,
.hsync_start = 1024 + 100,
.hsync_end = 1024 + 100 + 120,
.htotal = 1024 + 100 + 120 + 100,
.vdisplay = 600,
.vsync_start = 600 + 10,
.vsync_end = 600 + 10 + 15,
.vtotal = 600 + 10 + 15 + 10,
.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
});

How to check if the DSI clock is required rate?

This is the dsi clock summary:-
sh-5.2# cat /sys/kernel/debug/clk/clk_summary | grep dsi
gcc_disp_hf_axi_clk 2 2 0 0 0 0 50000 Y ae94000.dsi bus
dsi0vco_clk 1 1 0 614471923 0 0 50000 Y deviceless no_connection_id
dsi0_pll_out_div_clk 1 1 0 307235962 0 0 50000 Y deviceless no_connection_id
dsi0_pll_post_out_div_clk 0 0 0 76808990 0 0 50000 Y deviceless no_connection_id
dsi0_pll_bit_clk 2 2 0 307235962 0 0 50000 Y deviceless no_connection_id
dsi0_pclk_mux 1 1 0 307235962 0 0 50000 Y deviceless no_connection_id
dsi0_phy_pll_out_dsiclk 1 1 0 51205994 0 0 50000 Y deviceless no_connection_id
disp_cc_mdss_pclk0_clk 1 1 0 51205994 0 0 50000 Y ae94000.dsi pixel
dsi0_pll_by_2_bit_clk 0 0 0 153617981 0 0 50000 Y deviceless no_connection_id
dsi0_phy_pll_out_byteclk 1 1 0 38404495 0 0 50000 Y deviceless no_connection_id
disp_cc_mdss_byte0_intf_clk 1 1 0 19202248 0 0 50000 Y ae94000.dsi byte_intf
disp_cc_mdss_byte0_clk 1 1 0 38404495 0 0 50000 Y ae94000.dsi byte
ae94000.dsi byte
disp_cc_mdss_esc0_clk 1 1 0 19200000 0 0 50000 Y ae94000.dsi core
disp_cc_mdss_ahb_clk 4 4 0 19200000 0 0 50000 Y ae94000.dsi iface
ae94000.dsi iface

In QCLinux only way we find to disable LP11 mode is remove LPM mode

dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;

as per chatgpt above clock summary is

dsi0_pll_bit_clk → 307 MHz
dsi0_phy_pll_out_byteclk → 38 MHz
disp_cc_mdss_pclk0_clk → 51 MHz
disp_cc_mdss_esc0_clk → 19 MHz

This means your DSI interface is currently in HS (High-Speed) video mode, not LP11 idle.

Can you please confirm.

0 Ikram Haque 4 months ago in reply to Justin Philip

TI__Mastermind 26540 points

Hi Justin,

The DSI clock rate 307 MHz, then the clock divider should be set to 6. Please set 0xB register to 0x28. This is because the 0xA register is set to source clock from DSI clock and the LVDS clock rate is set to the correct rate.

Best regards,
Ikram