Hello everyone,
we are using a SN64DSI83 as an interface bridge between the MIPI DSI of the RZ/G2L and a LVDS screen. I have posted the device tree file below. However the screen is instantly turned off after uboot exists and we have no idea why. The configuration for the SN65DSI83 seems to be correct, as we message containing the correct screen resolution and DSI clock speed. Do you have any idea why the backlight might not be working? Best Christian
/ { backlight: pwm-backlight { compatible = "pwm-backlight"; pwms = <&gpt3 0 50000>; brightness-levels = <100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0>; default-brightness-level = <50>; status = "okay"; }; lvds_panel: lvds { compatible = "panel-lvds"; data-mapping = "vesa-24"; ti,width-mm = <197>; ti,height-mm = <144>; backlight = <&backlight>; status = "okay"; ports { port@0 { lvds_in: endpoint { remote-endpoint = <&bridge_out>; }; }; }; }; }; &du { status = "okay"; }; &dsi0 { status = "okay"; #address-cells = <1>; #size-cells = <0>; ports { #address-cells = <1>; #size-cells = <0>; port@1 { dsi0_out: endpoint { remote-endpoint = <&bridge_in>; data-lanes = <4>; attach-bridge; }; }; }; }; &i2c1 { dsi_lvds_bridge: sn65dsi83@2c { compatible = "ti,sn65dsi83"; reg = <0x2c>; ti,dsi-lanes = <4>; ti,lvds-format = <1>; ti,lvds-bpp = <24>; ti,width-mm = <197>; ti,height-mm = <144>; enable-gpios = <&pinctrl RZG2L_GPIO(5, 2) GPIO_ACTIVE_HIGH>; enable-panel-gpios = <&pinctrl RZG2L_GPIO(1, 1) GPIO_ACTIVE_HIGH>; status = "okay"; timings_1024x600_60:display-timings { lvds { clock-frequency = <51200000>; hactive = <1024>; vactive = <600>; hback-porch = <180>; hfront-porch = <140>; vback-porch = <15>; vfront-porch = <20>; hsync-len = <1>; vsync-len = <1>; hsync-active = <0>; vsync-active = <0>; de-active = <0>; pixelclk-active = <0>; }; }; ports{ #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; bridge_in: endpoint { remote-endpoint = <&dsi0_out>; }; }; port@2 { reg = <2>; bridge_out: endpoint { remote-endpoint = <&lvds_in>; }; }; }; }; }; &gpt3 { pinctrl-names = "default"; pinctrl-0 = <&gpt3_pins>; channel = "channel_B"; status = "okay"; }; &pinctrl { gpt3_pins: gpt3-pins { pinmux = <RZG2L_PORT_PINMUX(19, 1, 2)>; /* Channel B */ }; };
Are you sure the bridge is configured correctly over I2C? I don't see any pin mux settings for i2c1.
Once you confirm that, you should check for any mipi dsi message from the driver, or the mipi pins with a scope to see if the RZ is trying to use the MIPI pins at all.
The pin mux settings are in a different dtsi file. But the I2C works, as there is also an RTC on that bus. Also, we get the messages from the SN65DSI83. I have attached the dmesg | grep dsi output below. As for the scope: Unfortunately I won't be able to test that today anymore, I will do it tomorrow and then report back.
dmesg | grep dsi [ 0.455912] sn65dsi83 1-002c: GPIO lookup for consumer enable [ 0.455924] sn65dsi83 1-002c: using device tree for GPIO lookup [ 0.455959] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/soc/i2c@10058400/sn65dsi83@2c[0]' - status (0) [ 0.455993] sn65dsi83 1-002c: GPIO lookup for consumer enable-panel [ 0.455998] sn65dsi83 1-002c: using device tree for GPIO lookup [ 0.456016] of_get_named_gpiod_flags: parsed 'enable-panel-gpios' property of node '/soc/i2c@10058400/sn65dsi83@2c[0]' - status (0) [ 0.719679] sn65dsi83 1-002c: DSI clock [ 153600000 ] Hz [ 0.719691] sn65dsi83 1-002c: Resolution [ 1024 x 600 ] Hz
Don't worry about getting a scope fast enough to make out the data....you just wanted to see 'wiggles' to know something was coming out.
And, you want to see if it keeps sending data or not.
If it keeps sending data out, then
A. The backlight is off so that is why you can't see anything
B. The timing signals are off and the chip is not getting what it needs to display correctly
You can see if that chip has a 'test mode' that will put up a pattern or not. That way you can ignore the MIPI DSI signals a first and just make sure the screen and backlight work.
Yes I can confirm data is permanently sent. I also captured the I2C lines and the configuration also matches the datasheet so that part of the communication seems to be working.
As a test I also disabled the backlight pwm controller and just hooked up 3.3V to the backlight so that I can eliminate this problem, however it is still not displaying any pictures. I will see how to enable the test mode and report back.
For most customers, using the test image is the next step. Mostly that is to test that the MIPI DSI DTC commands are being sent correctly. Of course in your case, you are using I2C to configure the chip, so it's a little different. But, it would still be good to confirm the LCD by using the built-in test pattern
I have used an external microcontroller to enable the test patterns on the lcd. This works well, so the connection between the sn65dsi83 and the lcd is correct. I used the same timing information as set in the dtsi file.Furthermore, I also went ahead and used a different board with a native lvds output. The display also behaved as expected.
Do you have any other idea? I also used a different prototype board to reduce the chance that the board itself is damaged. I controlled the voltages, pinout etc.
Since this is a MIPI DSI to LVDS bridge, are you getting anything out on the LVDS side at all? I think you already confirmed that the MIPI DSI pins are 'moving'.
You can compare the LVDS signals on a working board (assuming you have one and this is not the first time using this panel) with the LVDS signals on the RZ board.
Of course if you get nothing out of the LVDS side, the the problem still lies on what the MIPI DSI signals look like and why the bridge chip does not like them.
For the clock rate, it is current a table of comment values.
rz_linux-cip/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
Here is the table for 4-lane (I'm assuming you are using the latest branch on github)
struct cpg_param resolution_4_lanes_param[TABLE_MAX] = { { 25175, 2, 25, 2936012, 1, 1, 0, 0x16, 1, 2}, /* VGA 25.175MHz */ { 25200, 2, 25, 3355443, 1, 1, 0, 0x16, 1, 2}, /* VGA 25.200MHz */ { 27000, 2, 27, 0, 1, 1, 0, 0x16, 1, 2}, /* 480p/576p 27.000MHz */ { 27027, 2, 27, 452984, 1, 1, 0, 0x16, 1, 2}, /* 480p 27.027MHz */ { 29605, 2, 29, 10150215, 1, 1, 0, 0x16, 1, 2}, /* WVGA 29.605MHz */ { 40000, 2, 40, 0, 1, 1, 0, 0x16, 1, 2}, /* SVGA 40.00MHz */ { 65000, 2, 65, 0, 1, 1, 0, 0x16, 1, 2}, /* XGA 65.00MHz */ { 71000, 2, 71, 0, 1, 1, 0, 0x16, 1, 2}, /* WXGA 1280x800 71.0MHz */ { 74176, 2, 74, 2952790, 1, 1, 0, 0x16, 1, 2}, /* 720p 74.176MHz */ { 74250, 2, 74, 4194304, 1, 1, 0, 0x16, 1, 2}, /* 720p 74.25MHz */ { 85500, 2, 85, 8388608, 1, 1, 0, 0x16, 1, 2}, /* FWXGA 1360x768 85.5MHz */ { 88750, 2, 88, 12582912, 1, 1, 0, 0x16, 1, 2}, /* WXGA+ 1440x900 88.75MHz */ {108000, 2, 108, 0, 1, 1, 0, 0x16, 1, 2}, /* SXGA 108MHz */ {148500, 2, 148, 8388608, 1, 1, 0, 0x16, 1, 2}, /* 1080p 148.5MHz */};
Since your clock tree says:
clock-frequency = <51200000>;
The driver will pick the next lower frequency of output of 40MHz.
Unfortunately, this is the first time we are using both the panel and the board. So it is hard to really eliminate anything right now beyond what I did previously. Thanks for the information about the display driver. I have to look into it. This could indeed be a problem. We configured the SN65DSI83 that it uses the DSI clock as source for generating the LVDS clock. But this I should be able to measure. I will see to do that tomorrow.