SN65DSI83: Issues connecting the

Hi Henrik,

I am not as familiar with the kernel module and specific instructions that are executed under the module from the function, but I do suspect that configuration settings are missing from the SN65DSI83 device. 

• Can you please share more about this kernel module and how it is implemented and called?

From Ikram's forum, there were two resources indicated here:

"Here is an introduction video about this component: https://www.ti.com/video/5829448496001

You can also find more information about programming from this guide: https://www.ti.com/lit/an/slla332b/slla332b.pdf"

I noticed in the programming guide, it is able to produce a flat log that includes the register programming, you can see that here: 

Have you referenced the necessary CSR registers that need to be programmed for this application and referenced this bring up application to determine if they're configured correctly? There is also an example initialization script in our data sheet:

Please let me know if you have any additional details about how the device is interfaced with, is there configuration available through discrete I2C transactions?

Best,

Miguel

Hi Miguel

Thanks for your reply.

When Linux is booting, I see the error "i2c 2-002c: deferred probe pending", and at the same time, I cannot detect any communication on the I2C bus. I can retrieve information about the kernel module using modinfo, which indicates that the module is loaded as expected during boot. However, since there is no activity on the I2C bus and the message "deferred probe pending" appears, something seems to be preventing the kernel module from running. I have verified that I can communicate with the bridge after Linux has fully booted, so the I2C interface itself is functional.

The same person who wrote the kernel module (Marek Vasut) also created a supporting file called "ti,sn65dsi83.yaml", which describes the requirements for getting the kernel module to run. These include properties such as "enable-gpios", "compatible", "reg", and "vcc-supply". I have followed the instructions in this support file, but it still doesn’t work. Do you have any suggestions as to what might be missing?

Secondly, when the kernel module is active and takes control of configuring the bridge, how can I verify that, for example, the PLL in register 0x0D is enabled (by setting bit 0)? The definitions for both the register and the bit are present in the kernel module, but how can I confirm that the module is actually applying that configuration?

Best

Henrik

Hi Henrik,

Thank you for sharing the details about this issue. Please give me 1-2 days to check and get back to you.

Best regards,
Ikram

Hi Ikram

I'm looking forward to hear from you, since I'm still stuck with a display that doesn't show any picture.

I have worked on the device tree source (dts), and it seems that u-boot is parsing the dts, since u-boot is reporting the correct screen resolution. Also the kernel messages indicate that the configuration should be correct:

root@imx7ulpevk:~# dmesg | grep -i -E "mipi|sn65|lcdif|video|drm|panel|2-002c|deferred|i2c"
[    0.086988] platform 40a90000.mipi_dsi: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[    0.100902] platform panel-lvds: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[    0.137775] platform panel-lvds: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[    0.138077] platform 40a90000.mipi_dsi: Fixed dependency cycle(s) with /bus@40000000/lpi2c4@402b0000/sn65dsi83@2c
[    0.138436] i2c 2-002c: Fixed dependency cycle(s) with /panel-lvds
[    0.138657] i2c 2-002c: Fixed dependency cycle(s) with /bus@40800000/mipi_dsi@40a90000
[    0.139426] i2c i2c-2: LPI2C adapter registered
[    0.143261] i2c i2c-3: LPI2C adapter registered
[    0.145179] i2c i2c-1: LPI2C adapter registered
[    0.145869] videodev: Linux video capture interface: v2.00
[    0.149966] MIPI CSI2 driver module loaded
[    0.567590] mipi_dsi_northwest 40a90000.mipi_dsi: i.MX MIPI DSI driver probed
[    0.571637] mxsfb 40aa0000.lcdif: supply lcd not found, using dummy regulator
[    0.704630] mipi_dsi_northwest 40a90000.mipi_dsi: MIPI DSI dispdv inited
[    0.704681] mxsfb 40aa0000.lcdif: registered mxc display driver mipi_dsi_northwest
[    0.746530] sii902x bound to mxs-lcdif from 40aa0000.lcdif
[    0.862295] mxsfb 40aa0000.lcdif: initialized
[    2.091842] i2c_dev: i2c /dev entries driver
[    2.535788] [drm] Initialized vivante 1.0.0 20170808 for 41800000.gpu on minor 0
[    7.297291] systemd[1]: Starting Load Kernel Module drm...
[    8.709721] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    8.747407] systemd[1]: Finished Load Kernel Module drm.
[   13.300238] i2c 2-002c: deferred probe pending

The kernel module programmed by Marek Vasut, is not including kernel messages, but instead uses "dynamic debugging". I have tried to get the dynamic debug messages from the kernel module, but so far I have not seen any messages from the sn65dsi83 module. Maybe because there isn't any? Which could explain why there isn't any I2C communication.

I can get kernel info:

root@imx7ulpevk:~# modinfo ti-sn65dsi83
name:           ti_sn65dsi83
filename:       (builtin)
license:        GPL v2
file:           drivers/gpu/drm/bridge/ti-sn65dsi83
description:    TI SN65DSI83 DSI to LVDS bridge driver
author:         Marek Vasut <marex@denx.de>

Which tells me that it is correctly build into the kernel.

I hope you can help getting a picture shown on the screen :-)

Regards Henrik

Hi Henrik,

Is this the same driver shared here? Question about SN65DSI84
The only sample code for Linux shared is linked in the forum above.

The programming of this device can also be done with via I2C writing to the registers. You can use the DSI Tuner tool to generate the register settings to program the device, and also programming the processor to match the display configurations. Do you think this would be an easier approach? Please check whether the processor display timings match the driver settings programmed for the DSI83.


Also, with the current system, please check whether the datasheet initialization sequence is followed, and read back register 0xE5 to check any errors occurring. 

Best regards,
Ikram

Hi Ikram

The driver you are referring to is written more than 10 years ago, and seems to be written for dsi85 and not dsi83. Though parts of the driver might be able to work, I would prefer to use the much never driver written by Marek Vasut, which is shipped together with the Yocto distribution (see link below). This driver can either be build as a kernel module that can be loaded during or after boot or it can be included in the kernel - this is set in the kernel configuration.

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/ti-sn65dsi83.c

I both cases it seems that the kernel module is deferred, but I don't know why? The kernel driver written by Marek Vasut is using dynamic debugging, which I have had some troubles getting printed in the terminal.

To my understanding the kernel module should read the settings and definition in the device tree source and configure sn65dsi83 accordingly. Since the kernel module is deferred and not running, these settings are never read and the device is not configures. As a work-around I have written a bash script that is configuring the chip to verify that the hardware is working. Though there still are some issues with the picture on the screen, most likely related to some hardware specific settings, the script proves that the hardware is working. 

The problem of using a script as work-around is, that I cannot show information about boot status during boot, which is required to provide the good user experience of the system, when the user can see the system is booting and soon will be ready.

So the question remains: why does the kernel module for sn65dsi83 not load correctly during linux boot?

Best regards

Henrik

Hello,

The team is out due to a public Holiday in the US. Responses will be delayed until Monday.

Thank you for your patience

Hi Henrik,

The only driver example we have to share is the one linked in the previous E2E link.

Would it be possible on your system to set up the DSI83 via I2C? With the DSI Tuner GUI, you can enter the display timings, LVDS timings, and DSI configuration, and there will be an output of the registers that need to be written.

You can use that initialization script as part of the initialization sequence shared in the datasheet. Would this be more suitable instead of using the driver? Is there any reason that you cannot show the boot information? Is this showing on display? The display would only turn on after the DSI83 is initialized. Please check whether this would be suitable in your system. It only involves very few register settings and can be added to your startup sequence to control from the SoC.

Best regards,
Ikram