SN65DSI83: Issues connecting the

Part Number: SN65DSI83


Tool/software:

Hi

I have some troubles getting the kernel module correctly initializing the MIPI_DSI_LVDS_BRIDGE. I have defined the timings of the display in the Device Tree Source (DTS) file and ensured that when building the kernel, the ti_ns65dsi83 kernel module is compiled and can be loaded afterwards. However nothing is shown on the screen, neither during boot nor when the kernel module is loaded afterwards. My suspicion is, that the problem is related to the initialization of the SN65DSI83 chip. Besides the timings related to the display and the number of DSI lanes, is seems that most of the configuration is handled by the kernel module, e.g. enabling PLL.

When looking into the kernel module there is a function called "sn65dsi83_atomic_pre_enable", that is taking care of enabling the PLL. But when and how is this function called? How can I confirm that the function is called?

The embedded processor I'm using is an NXP iMX7ULP, the linux version is Scarthgap 6.6.52. The only clue that can point me in some direction of, why nothing is shown on the display is the kernel message during boot. Below is a copy of the kernel messages related to the mipi-dsi.

Any ideas why nothing is shown on the screen?

/Henrik

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.

  • 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