Hello,
i have a custom PCB for the Compute Module 4 with the SN65DSI86 DSI to eDP bridge successfully running on a modified 5.10.74 64bit kernel since almost 2 years (with 44 Hz only, but that's another story).
I tried to make it run on the latest 6.6.30 kernel from the PI foundation, but no luck so far.
There where quite a lot of changes to the sn65dsi86 driver between the two kernels. But I am absolutely not sure if that's the problem.
Most changes where regarding the initialization order. I checked most of the logic, and it seems that register programming wise, most stuff still matches my patched 5.10 kernel. I had to make some adaptions for handling the new organization of eDP panels though. Also added 2 lines for handling 3 line DSI properly.
I also added most of the debugging log lines that I had in the old kernel to the new 6.6 code-base.
From comparing old kernel and new kernel logs, it seems that the problem boils down to the DP AUX channel (tunneled via I2C) is not working.
What's strange though, is that the kernel can read registers from the eDP chip via i2c as it seems:-> the read value was 0 at start, but after resolving some overlay issues, reads the same 240 as on the old kernel in latest test.
The errors start when the driver starts to communicate with the eDP panel:afterwards, also the link-training fails:What's interesting though, is that I can easily program the chip to drive the display with a test-pattern via a small python script (via normal i2c).
Therefore, the communication with the bridge seems to work in principle.
It's also not Bookworm related. I can run my old kernel on Bookworm without issues.
My custom board overlay looks like this (it's in principle the same as on the old 5.10 kernel).
I also tried to attach the display directly via an aux channel. This is given as a second example in the documentation of the new driver.
The display in the dts file above is removed, and the overlay section for the display looks as this:
The result is an error in the eDP display driver:---
Of course, i also checked the general i2c connectivity:
-> same output as on old kernel
-> same output as on old kernel, detects the 2c port
-> nothing on the AUX i2c though. At least not when the kernel controls it!
Here is the output on the old kernel, when the display is active:When I activate the test-pattern while running the new kernel, the i2c channel-23 becomes active though:
Has anybody an idea why the 6.6 kernel is not able to use the AUX channel ?
I tried for a few days, but did not find any way to make it work![:-(]( "Sad")
I even checked the raspberry pi board definitions in the old and new kernel. There have been quite some changes on the new kernel. So I am even wondering if it's a general issue with the new CM4 definitions. But otherwise, in that case the programming via a python script should also fail.
For completeness, that's my config.txt
i have a custom PCB for the Compute Module 4 with the SN65DSI86 DSI to eDP bridge successfully running on a modified 5.10.74 64bit kernel since almost 2 years (with 44 Hz only, but that's another story).
I tried to make it run on the latest 6.6.30 kernel from the PI foundation, but no luck so far.
There where quite a lot of changes to the sn65dsi86 driver between the two kernels. But I am absolutely not sure if that's the problem.
Most changes where regarding the initialization order. I checked most of the logic, and it seems that register programming wise, most stuff still matches my patched 5.10 kernel. I had to make some adaptions for handling the new organization of eDP panels though. Also added 2 lines for handling 3 line DSI properly.
I also added most of the debugging log lines that I had in the old kernel to the new 6.6 code-base.
From comparing old kernel and new kernel logs, it seems that the problem boils down to the DP AUX channel (tunneled via I2C) is not working.
What's strange though, is that the kernel can read registers from the eDP chip via i2c as it seems:
Code:
[175443.706165] ti_sn65dsi86 10-002c: ti_sn_bridge_enable: status of reg 94 (current gpio values): 240The errors start when the driver starts to communicate with the eDP panel:
Code:
[ 8.746798] ti_sn65dsi86 10-002c: [drm:ti_sn_bridge_atomic_enable [ti_sn65dsi86]] *ERROR* Can't read lane count (-5); assuming 4[ 9.016793] ti_sn65dsi86 10-002c: [drm:ti_sn_bridge_atomic_enable [ti_sn65dsi86]] *ERROR* Can't read eDP rev (-5), assuming 1.1[ 9.191069] ti_sn65dsi86 10-002c: [drm:ti_sn_bridge_atomic_enable [ti_sn65dsi86]] *ERROR* Can't read max rate (-110); assuming 5.4 GHzCode:
[ 9.730374] ti_sn65dsi86 10-002c: [drm:ti_sn_bridge_atomic_enable [ti_sn65dsi86]] *ERROR* Link training failed, link is off (-5)Therefore, the communication with the bridge seems to work in principle.
It's also not Bookworm related. I can run my old kernel on Bookworm without issues.
My custom board overlay looks like this (it's in principle the same as on the old 5.10 kernel).
Code:
/ { compatible = "raspberrypi,4-compute-module", "brcm,bcm2711"; fragment@0 { target-path = "/"; __overlay__ { panel_disp: panel_disp@0 { reg = <0>; compatible = "auo,b156hak022_edp_30fps"; // custom panel with same numbers as on old kernel, just with 30 Hz only, as 44 is not accepted on new driver enable-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; // Display Power enable GPIO no-hpd; // No Hot-Plug-Detect port { panel_in_edp: endpoint { remote-endpoint = <&edp_bridge_out>; }; }; }; // Some dummy regulartors here ... }; }; fragment@1 { target = <&i2c_csi_dsi>; __overlay__ { status = "okay"; clk_refclk: clk_refclk { compatible = "fixed-clock"; clock-frequency = <27000000>; clock-output-names = "refclk"; }; edp-bridge@2c { compatible = "ti,sn65dsi86"; reg = <0x2c>; // determines I2c address of bridge chip: 0x2d => ADDR High, 0x2c => ADDR Low | Board has ADDR Low!!! enable-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; // required, gpio for chip enable (Converter enable) clocks = <&clk_refclk>; clock-names = "refclk"; // use the external reference clock vccio-supply = <&dummy_reg_1V8>; vcca-supply = <&dummy_reg_1V2>; vpll-supply = <&dummy_reg_1V8>; vcc-supply = <&dummy_reg_1V2>; ports { port@0 { reg = <0>; edp_bridge_in: endpoint { remote-endpoint = <&dsi_out_port>; data-lanes = <0 1 2>; }; }; port@1 { reg = <1>; edp_bridge_out: endpoint { data-lanes = <0 1>; remote-endpoint = <&panel_in_edp>; }; }; }; }; }; }; fragment@2 { target = <&dsi1>; __overlay__ { status = "okay"; port { dsi_out_port: endpoint { remote-endpoint = <&edp_bridge_in>; data-lanes = <0 1 2>; // data-lanes = <0 1 2 3>; }; }; }; }; fragment@3 { target = <&i2c0if>; __overlay__ { status = "okay"; }; }; fragment@4 { target = <&i2c0mux>; __overlay__ { status = "okay"; }; };}The display in the dts file above is removed, and the overlay section for the display looks as this:
Code:
edp-bridge@2c { compatible = "ti,sn65dsi86"; reg = <0x2c>; enable-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; clocks = <&clk_refclk>; clock-names = "refclk"; // use the external reference clock vccio-supply = <&dummy_reg_1V8>; vcca-supply = <&dummy_reg_1V2>; vpll-supply = <&dummy_reg_1V8>; vcc-supply = <&dummy_reg_1V2>; ports { port@0 { reg = <0>; edp_bridge_in: endpoint { remote-endpoint = <&dsi_out_port>; data-lanes = <0 1 2>; }; }; port@1 { reg = <1>; edp_bridge_out: endpoint { data-lanes = <0 1>; remote-endpoint = <&panel_in_edp>; }; }; }; aux-bus { panel: panel@0 { reg = <0>; compatible = "auo,b156hak022_edp_30fps"; enable-gpios = <&gpio 25 GPIO_ACTIVE_LOW>; no-hpd; // No Hot-Plug-Detect port { panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_out>; }; }; }; };};Code:
[ 7.908028] panel-simple-dp-aux: probe of aux-ti_sn65dsi86.aux.0 failed with error -5Of course, i also checked the general i2c connectivity:
Code:
$ i2cdetect -li2c-0i2c i2c-22-mux (chan_id 0) I2C adapteri2c-10i2c i2c-22-mux (chan_id 1) I2C adapteri2c-20i2c fef04500.i2c I2C adapteri2c-21i2c fef09500.i2c I2C adapteri2c-22i2c bcm2835 (i2c@7e205000) I2C adapteri2c-23i2c ti-sn65dsi86-aux I2C adapteri2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Code:
i2cdetect -y 10 0 1 2 3 4 5 6 7 8 9 a b c d e f00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --Code:
i2cdetect -y 23 0 1 2 3 4 5 6 7 8 9 a b c d e f00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Here is the output on the old kernel, when the display is active:
Code:
i2cdetect -y 23 0 1 2 3 4 5 6 7 8 9 a b c d e f00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77 Code:
sudo i2cdetect -y 23 0 1 2 3 4 5 6 7 8 9 a b c d e f00: 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77 Has anybody an idea why the 6.6 kernel is not able to use the AUX channel ?
I tried for a few days, but did not find any way to make it work
I even checked the raspberry pi board definitions in the old and new kernel. There have been quite some changes on the new kernel. So I am even wondering if it's a general issue with the new CM4 definitions. But otherwise, in that case the programming via a python script should also fail.
For completeness, that's my config.txt
Code:
kernel=my_kernel.imgforce_eeprom_read=0# Touch enable: set gpio 22 to high at bootgpio=22=op,dh# Panel enable (drive low)gpio=25=op,dldtdebug=1enable_uart=1dtoverlay=uart4# Relocate Bluetooth UART (wee neeed the one from bluetooth)dtoverlay=pi3-miniuart-bt# Enable USB2 (DesignWare Core) - needed for network over USBdtoverlay=dwc2,dr_mode=host# Disable HDMI (needed for DSI)ignore_lcd=1# Disable HDMI on screen offhdmi_blanking=1# Automatically load initramfs files, if foundauto_initramfs=1# Don't have the firmware create an initial video= setting in cmdline.txt.disable_fw_kms_setup=1# Enable DRM VC4 V3D driverdtoverlay=vc4-kms-v3dmax_framebuffers=2# Enable the custom overlaydtoverlay=my_overlay# Enable 64bit, should be down herearm_64bit=1dtoverlay=dwc2gpu_mem=128Statistics: Posted by thmang82 — Mon May 27, 2024 8:40 pm