SN65DSI83ZXHR: unable to reset the LVDS bridge through software and no output on display

Raghavendra

Looking at the schematic, it looks like the EN is driven externally. Have you made sure that you are following the power-up timing requirement?

Are you also trying to set the SOFT_RESET bit of DSI83 register 0x09? It looks like the DSI83 I2C pins are connected to test points, do you have them connected to a I2C controller?

Thanks

David 

Hi David,

thanks for the quick response.

I understand that, SN65DSI83 driver used is based on the I2C, but in current design our HW team has made the I2C SCL and SDA lines as float and RESET pin in controlled by IMX8MM.

Now how to proceed further. could you please help to answer below queries.

1. How to pass the display data from IMX8MM through MIPI-DSI ==> LVDS(bridge) ==> LVDS 10.1 inch Display panel without I2C

2. one observation, if I hardcode the I2C reset return value to 0, it completes the probe function execution and going forth all I2C read and writes failed.

3. Does TI have driver to achieve our design(without attaching Bridge to I2C)? what would be the impact on display data?

Thanks,

Raghavendra

Hi David,

we had resolved the reset issue and further there is no proper display output on panel. not able to see the images/activities clearly.

The parameters of display are as below.

Below are the dtsi changes made in the source code.

&i2c2 {

        clock-frequency = <400000>;

        pinctrl-names = "default";

        pinctrl-0 = <&pinctrl_i2c2>;

        status = "okay";

        lvds_bridge: sn65dsi83@2c {

                compatible = "ti,sn65dsi83";

                reg = <0x2c>;

                ti,dsi-lanes = <4>;

                ti,lvds-format = <2>;

                ti,lvds-bpp = <24>;

                ti,lvds-channels = <1>;

                ti,width-mm = <260>;

                ti,height-mm = <183>;

                enable-gpios = <&gpio2 9  GPIO_ACTIVE_HIGH>;

                interrupt-parent = <&gpio2>;

                interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;

                pinctrl-names = "default";

                pinctrl-0 = <&pinctrl_dsi_lvds_bridge>;

                status = "okay";

                display-timings {

                        lvds {

                                clock-frequency = <72400000>;

                                hactive = <1280>;

                                vactive = <800>;

                                hback-porch = <88>;

                                hfront-porch = <72>;

                                vback-porch = <23>;

                                vfront-porch = <15>;

                                hsync-len = <80>;

                                vsync-len = <10>;

                        };

                };

                port {

                        sn65dsi83_in: endpoint {

                                remote-endpoint = <&dsim_to_sn65dsi8>;

                        };

                };

        };

Image displayed on panel:

Expected images to be displayed:

are we missing changes, Could you please help us to review the same.

Thanks,

Raghavendra

Raghavendra

Do you have the DSI83 I2C bus now connected to a I2C controller? 

Many of the SN65DSI83 device functions are controlled by the control and status registers (CSR). All CSR registers are accessible through the local I2C interface. So you have to program the DSI83 properly through the I2C first. 

Attached is the DSI Tuner SW, you can use it to generate the DSI83 registers programming value from the LVDS panel spec.

DSI Tuner 2.1.zip

Thanks

David

Hi David,

attaching current display video for your reference. kindly let me know your thoughts on this.

Thanks,

Raghavendra

Raghavendra

Are you now able to program the DSI83? If you look at the DSI83 initialization sequence requirement, you need to initialize all CSR registers to their appropriate values based on the implementation (The SN65DSI8x is not functional until the CSR registers are initialized)

Thanks

David

Hi David,

Yes, am able to program DSI83, but from driver I could see all the parameters(CSR registers) are getting written through register shifting operations.

rest other register values are same as expected from CSR.txt. generated from DSI tuner.

please find the attached logcat and dmesg logs.

logcat.txtkernel_dmesg.txt

//=====================================================================
// Filename   : CSR-bridge.txt
//
//   (C) Copyright 2013 by Texas Instruments Incorporated.
//   All rights reserved.
//
//=====================================================================
0x09              0x00
0x0A              0x05
0x0B              0x10
0x0D              0x00
0x10              0x26
0x11              0x00
0x12              0x00
0x13              0x00
0x18              0x7a
0x19              0x00
0x1A              0x03
0x1B              0x00
0x20              0x00
0x21              0x05
0x22              0x00
0x23              0x00
0x24              0x00
0x25              0x00
0x26              0x00
0x27              0x00
0x28              0x21
0x29              0x00
0x2A              0x00
0x2B              0x00
0x2C              0x00
0x2D              0x00
0x2E              0x00
0x2F              0x00
0x30              0x00
0x31              0x00
0x32              0x00
0x33              0x00
0x34              0x58
0x35              0x00
0x36              0x00
0x37              0x00
0x38              0x00
0x39              0x00
0x3A              0x00
0x3B              0x00
0x3C              0x00
0x3D              0x00
0x3E              0x00


The PLL_EN bit and SOFT_RESET bit are not set as they need to be set per the recommended sequence defined in the datasheet

kindly let me know if any other changes to be done.

Thanks,

Raghavendra

Raghavendra

The DSI83 device supports a pattern generation feature on LVDS channels. This feature can be used to test the LVDS output path and LVDS panels in a system platform. The pattern generation feature can be enabled by setting the CHA_TEST_PATTERN bit at address 0x3C.

Are you able to see the test pattern if you enabled it?

Thanks

David

Hi David,

I have tested LVDS test pattern by writing 0X16 to 0x3C. Am able to see below output on LVDS panel.

we have probed VCC and EN pin of DSI83 and below are the waveforms. 

Thanks,

Raghavendra

Raghavendra

The test pattern should look like this,

In this case, the LVDS output is not been configured correctly for the display panel. Can you please check that you’re using the correct format (Format 1 vs. Format 2) for the display panel, and that the LVDS timing is within spec?

Thanks

David

Hi David,

I have changes the format value to <1> and able to observe the below image on display.

from the above images its is clear that communication between LVDS Bridge ==> panel is proper and no issue is observed.

Looks like there is some SW or HW configurations we might missing. Am attaching dtsi, driver and error logs for your reference. kindly review and share your review comments.

display_bringup.zip

Thanks,

Raghavendra

Raghavendra

I agree that the LVDS output interface now looks correct.

Can you please check the line time on the DSI side? The line time (time from HSYNC to HSYNC) on the DSI input matches the line time on the LVDS output. The line time on the LVDS output is the total amount of horizontal pixels divided by the LVDS clock frequency. You can measure the line time on the DSI input with an oscilloscope by zooming in on the data stream on of the data lanes like below:

Thanks

David

Hi David,

I have fixed this issue, and below are the latest images of Display panel. there is no flickering observed, but still I would expect some more clarity since its 1280 x 800 display panel. Below are the parameters I had changed in the dtsi, which slightly differs from Vendor provided hsync and vsync timing parameters.

lvds_bridge: sn65dsi83@2c {
compatible = "ti,sn65dsi83";
reg = <0x2c>;
ti,dsi-lanes = <4>;
ti,lvds-format = <2>;
ti,lvds-bpp = <16>;
ti,lvds-channels = <1>;
ti,width-mm = <216>;
ti,height-mm = <135>;
ti,burst-mode = <1>;
enable-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&gpio2>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dsi_lvds_bridge>;
status = "okay";

display-timings {
lvds {
clock-frequency = <72400000>;
hactive = <1280>;
vactive = <800>;
hback-porch = <88>;
hfront-porch = <72>;
vback-porch = <23>;
vfront-porch = <15>;
hsync-len = <660>;
vsync-len = <20>;
};
};

images displayed:

I have one query: what would be the further changes needed to achieve more clarity image?

Thanks,

Raghavendra

Raghavendra

1. Do you have a way to increase the output LVDS clock frequency? 

2. You can also try to increase the LVDS output swing and see if that helps, register 0x19, bit [3:2].

Thanks

David

Hi David,

In continuation to the above debugging, we could complete display Bringup, but with current configurations display flickers.

could you please help to answer the below queries

1. I did debug from LVDS bridge side, are we still missing any configurations??

2. Can LVDS bridge cause flickering seen on panel.

3. currently as per vendor configurations, hsync-len is 40(provides refresh rate 60Hz) but not able to see anything on panel. if we change hsync-len to 660(leads to refresh rate 40Hz), we could able to see output on panel. with this flickering is observed often, but after 2-3 power cycles seems like stable.

Thanks

Raghavendra

Raghavendra

Can you please share the latest resolution spec you are trying to implement? 

With hsync-len (Hactive) being 660, and if you enable the test pattern, are you seeing any flicking issue?

If you change the Hactive to 660, did you also change the DSI input as well? The line time of the DSI input must match with the line time of the LVDS output.

Thanks

David

Hi David,

please find the below responses.

1. Can you please share the latest resolution spec you are trying to implement? 

parameters used in source code:

lvds_bridge: sn65dsi83@2c {
compatible = "ti,sn65dsi83";
reg = <0x2c>;
ti,dsi-lanes = <4>;
ti,lvds-format = <2>;
ti,lvds-bpp = <24>;
ti,lvds-channels = <1>;
ti,width-mm = <216>;
ti,height-mm = <135>;
ti,burst-mode = <1>;
enable-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&gpio2>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dsi_lvds_bridge>;
status = "okay";

display-timings {
lvds {
clock-frequency = <72400000>;
hactive = <1280>;
vactive = <800>;
hback-porch = <88>;
hfront-porch = <72>;
vback-porch = <23>;
vfront-porch = <15>;
hsync-len = <40>;
vsync-len = <20>;
};
};

NOTE: with above configurations are not working, if hsync-len = 660 able to observe output on display.

2. With hsync-len (Hactive) being 660, and if you enable the test pattern, are you seeing any flicking issue?

we could generate test patterns hsync-len 660, but no flickering is seen at this stage.

3.If you change the Hactive to 660, did you also change the DSI input as well? The line time of the DSI input must match with the line time of the LVDS output.

NO, can you please share more inputs on this.

if hsync-len = 660, can you please let us know where we can change the DSI input as well.

Thanks,

Raghavendra

Raghavendra

Please see this e2e FAQ, https://e2e.ti.com/support/interface-group/interface/f/interface-forum/990480/faq-sn65dsi84-how-to-debug-flickering-video-with-sn65dsi83-sn65dsi84-and-sn65dsi85. You have to make sure the line time (time from HSYNC to HSYNC) from the DSI source matches the line time on the LVDS output. The line time on the LVDS output is the total amount of horizontal pixels divided by the LVDS clock frequency. You can measure the line time on the DSI input with an oscilloscope.

Thanks

David

Hi David,

1. If there is flickering or incorrect color with the test pattern (e.g. the white strip appears gray) then the LVDS output has likely not been configured correctly for the display panel. Check that you’re using the correct format (Format 1 vs. Format 2) for the display panel, and that the LVDS timing is within spec.

Response:  WE have kept format 2. If changed to format 1, distorted output on display and still flickering behavior observed.

2. the burst/line time on the DSI input. Make sure the line time (time from HSYNC to HSYNC) on the DSI input matches the line time on the LVDS output. The line time on the LVDS output is the total amount of horizontal pixels divided by the LVDS clock frequency

Response: the DSI 0 line response while probing is different from the TI reference image provided by you

DSI 0 lane probed image: attached

clocks:

DSI_0_N:

DSI_0_P:

3. You can also try using a clean external REFCLK as the clock source for the PLL instead of using the DSI CLK as the PLL source, as an excessively noisy DSI CLK may lead to an unstable LVDS clock output.

Response : As of now DSI clock is used as reference clock, can you please provide any TI reference design for this.

Thanks,

Raghavendra

Raghavendra

The line time (from HYSNC to HSYNC) on the DSI side must match with the line time on the LVDS side. The line time on the LVDS side = Htotal / LVDS CLK = 1480/74.2 = 20.44us. But the measured line time on the DSI side is 28us. So you have to update the DSI source to make sure the line time is matching and then see if flicking issue goes away. 

For the clock, what is channel 1 and 2? The two waveforms are completely different from each other. DSI_CLK = LVDS CLK * bpp / (2 * DSI lane) = 74.2 * 24 / (2 * 4) = 222.6MHz. But the DSI CLK does not match this frequency.

Thanks

David

Hi David,

1. The line time on the LVDS side = Htotal / LVDS CLK = 1480/74.2 = 20.44us. ==> agreed on this and would be a case with hsync-len=40 so that Htotal will be 1480 (1280+88+72+40).
But the measured line time on the DSI side is 28us ==>  because we have used hsync-len=660 leads to Htotal 2100 so that 2100/72.4 = ~29us.

2. So you have to update the DSI source to make sure the line time is matching and then see if flicking issue goes away.
you mean updating DSI clock or DSI data input signals?? if DSI data signals can you please guide us with any reference here.

3. from waveforms,
    >> the channel-1 is the probe result of LVDS clock and from waveform could see 72.5MHz
    >> channel-2 is the DSI_CLK_P/N clock signal and DSI_CLK = (LVDS CLK * bpp)/(2*DSI lane) = (74.2M*24)/(2*4) = 217.2MHz (from waveforms this is  ~211.81MHz)

Thanks,

Raghavendra

Raghavendra

The Htotal of 2100 is exceeding what the panel is able to support. If you reduce the hsync-len to 40, does the flicker go away?

Thanks

David

Hi David,

With hsync-len=40, nothing will be shown on panel. So with trial and error, with 660, we could able to observe on display panel.

The observations on flickering behaviour:

1. Flicker behaviour is observed while we power up the device after first flash.

2. After 2-3 power cycles, the chances of flickering is very less.

Thanks,

Raghavendra 

Raghavendra 

Looking at the panel spec, the Hsync back porch value of 88 being defined by the panel spec is with the pulse width. So can we check and see what happens with pulse width of 40, and Hsync back porch of 48?

We also want to make the same change to the Vsync back porch as well.

Thanks

David

Hi David,

I have tried, hsync back proch value to 48 and similar to this made change to vsync back porch as well to 13 and 3. 

but couldn't observe anything on display panel.

Thanks,

Raghavendra

Raghavendra

Can you please share your latest source code for me to check? If you enable test pattern, is the test pattern still work correctly?

Thanks

David

Hi David,

1. Please find the attached source code. Kindly review and let us know if any changes required.

source_code.zip

2. if we enable test patterns we could able to see working correctly.

Thanks,

Raghavendra

Raghavendra

Did you change the DSI83 register HBP and VBP programmed value? This is what I see from the code.

#ifndef __SN65DSI83_TIMING_H__
#define __SN65DSI83_TIMING_H__

/* Default Video Parameters */
#define PIXCLK_INIT 72400000

#define HACTIVE_INIT 1280
#define HPW_INIT 0
#define HBP_INIT 88
#define HFP_INIT 72

#define VACTIVE_INIT 800
#define VPW_INIT 0
#define VBP_INIT 23
#define VFP_INIT 15

static const struct display_timing panel_default_timing = {
.pixelclock = { PIXCLK_INIT, PIXCLK_INIT, PIXCLK_INIT },
.hactive = { HACTIVE_INIT, HACTIVE_INIT, HACTIVE_INIT },
.hfront_porch = { HFP_INIT, HFP_INIT, HFP_INIT },
.hsync_len = { HPW_INIT, HPW_INIT, HPW_INIT },
.hback_porch = { HBP_INIT, HBP_INIT, HBP_INIT },
.vactive = { VACTIVE_INIT, VACTIVE_INIT, VACTIVE_INIT },
.vfront_porch = { VFP_INIT, VFP_INIT, VFP_INIT },
.vsync_len = { VPW_INIT, VPW_INIT, VPW_INIT },
.vback_porch = { VBP_INIT, VBP_INIT, VBP_INIT },
.flags = DISPLAY_FLAGS_HSYNC_LOW |
DISPLAY_FLAGS_VSYNC_LOW |
DISPLAY_FLAGS_DE_LOW |
DISPLAY_FLAGS_PIXDATA_NEGEDGE,
};

#endif /* __SN65DSI83_TIMING_H__ */

Thanks

David

Hi David,

1. what we have been observed been so far is, the timing parameters are parsed from dtsi files and could see impact when changed. In our case imx8mm-evk.dtsi.

2. the values you have shared are from sn65dsi83_timing.h file and these values will Read default timing if there is no device tree node.

from sn65dsi83_drv.c please refer below snippet.

/* Read default timing if there is not device tree node for */
if ((of_get_videomode(np, &sn65dsi83->brg->vm, 0)) < 0)
videomode_from_timing(&panel_default_timing, &sn65dsi83->brg->vm);

Thanks,

Raghavendra 

Raghavendra

With the current configuration, does the Hsync to Hsync (line time) on the DSI side matches with the line time of the LVDS side which will be 1440/72.4 = 19.89us?

Thanks

David

Hi David,

please find the below dtsi node with timing parameters used.

display-timings {
lvds {
clock-frequency = <72400000>;
hactive = <1280>;
vactive = <800>;
hback-porch = <88>;
hfront-porch = <72>;
vback-porch = <3>;
vfront-porch = <15>;
hsync-len = <40>;
vsync-len = <20>;
};
};

with the above changes no output on display but and with the change hysnc-len=660. able to observe the display with flickering.

The line time measured for working condition waveform is already attached in earlier chat. 

kindly let us know how can we proceed further.

Thanks,

Raghavendra

Raghavendra

What happens if you change the Hback-port = 48?

display-timings {
lvds {
clock-frequency = <72400000>;
hactive = <1280>;
vactive = <800>;
hback-porch = <48>;
hfront-porch = <72>;
vback-porch = <3>;
vfront-porch = <15>;
hsync-len = <40>;
vsync-len = <20>;
};
};

What is now the line time on the DSI side with hsync-len = <40>?

Thanks

David

Hi David,

with hback-porch = <48> ; change we are not able observe any output on panel. please find the below image for your reference.

thanks,

Raghavendra

Raghavendra

Can you please measure the DSI input? Are you seeing the correct line time on the DSI input?

Thanks

David

HI David,

sure will check and update.

Thanks,

Raghavendra

HI David,

we have another question w.r.t flickering behavior.

We have two reset signals provided, one is for SN65DSI83, i.e. EN and another for LCD Panel.

1. can flickering cause due to power-up/reset sequence of EN and panel reset?

we have probed bridge VDD, EN, LCD and backlight. Below waveform shows the current reset sequence followed.

2. our LCD panel vendor had suggested to remove the panel reset and test. we had tested and still able to observe flicker on display.

3. our hardware team has asked us to follow the attached reset sequence? would like to know from you that, does this really impacts flicker behavior? kindly review both waveforms and revert if any changes to be made.

LCD & LVDS Bridge Initialization Sequence.pdf

Thanks,

Raghavendra

Hi David,

please find the below response for your queries.

1. With hsync-len=660 this leads to Htotal 2100 which is outside the LCD panel spec, can the panel support this resolution?

NO, checked with vendor too on this.

2. Can you please verify the test pattern works with the below configurations

with the configurations provided, we could able to generate test pattern.

3. Can you measure the line time on the DSI input with the below configuration?

yes, we have measured the line time and found to be value 7.52ns with the configurations provided and please refer below image for waveform probed at MIPI_DSI0_N/P lines.

Thanks,

Raghavendra

Raghavendra

The measurement does not look correct as I do not see a clear LP and HS data from the waveform as you did before.

Thanks
David