First of all, thanks for your fast reply.
I can read and write registers on the bridge that way (and enable test pattern).
i2c-23 is relevant however. As far as I understand, it's a virtual i2c bus on top of i2c-10. It's created for the display port aux communication by the DSI86 kernel driver. That's why it's named "ti-sn65dsi86-aux" when running "i2cdetect -l". The aux-channel exists physically between the bridge and the eDP display. When the kernel want's to access it, it has to tunnel the aux messages via the i2c connection to the bridge.
Do you need schematics of the board? There is no issue with the schematics. The board works perfectly fine with the old 5.10 kernel.
Regarding I2C schematics: SCL/SDA of the DSI86 bridge-chip are connected to a level-shifter, and from there connected to SCL0/SDA0 on the CM4 (on physical pins 80 and 82, translating to GPIO 44&45 as far as i know).
"raspi-gpio get" gives:
GPIO 44: level=1 fsel=5 alt=1 func=SDA0 pull=NONE
GPIO 45: level=1 fsel=5 alt=1 func=SCL0 pull=NONE
- Input port is connected to the DSI out port of the CM4.
- Output port is connected to the input port of the eDP panel.
The configuration works like that on the old 5.10 kernel. I do not see why it should be wrong on the 6.6. kernel. Can you explain in more detail what I am overlooking here?
And the two lines in the config.txt where only for testing, but they should not harm. Removed them just now to be sure, but does not change anything.
Regarding the backlight, that's a bit special on my board. It's controlled via a sperate micro-controller for super-smooth on/off-dimming. Works like a charm. The micro-controller listens on the power controller for the bridge for on-synchronization, off is controlled via a separate display controller software. That works without any issues (backlight is switching on/off properly even on the 6.6 kernel)
I still think it boils down to the question why the kernel cannot communicate via the "DP-aux over i2c" channel. Due to that, communication with the panel fails. This breaks link training for the eDP bus.
I already checked the "ti_sn_aux_transfer" function in the ti-sn65dsi86.c file that sends the data over i2c. But I have not seen anything unusual in there. And if that function would be the issue, the other boards with sn65dsi86 would also not work (sdm850-lenovo-yoga-c630.dts and sc7180-acer-aspire1.dts).
Correct, the bridge is configured to run on address 0x2c. And it's found on 0x2c on I2C-10 (the "UU"). And as I wrote, I can also communicate to it via a python script via 0x2c on bus 10. The following way of setting up the I2C communication in python works:Your overlay looks for the device on I2C-10 (target = <&i2c_csi_dsi>;) and expects to have the bridge responding to address 0x2c.
Code:
bus_num = 10i2cbus = SMBus(bus_num, True) # Create a new I2C busi2caddress = 0x2C # Address of Bridge chipval = i2cbus.read_byte_data(i2caddress, reg_t)You are right, checking on I2C bus 0 was pointless regarding the bridge functionality. I was just checking if the two devices connected to bus 0 (touch panel and a micro-controller) are also found. And they are. Sorry for the confusion.Checking other I2C interfaces makes no sense. What do you expect to see from therr (schematics please)?
i2c-23 is relevant however. As far as I understand, it's a virtual i2c bus on top of i2c-10. It's created for the display port aux communication by the DSI86 kernel driver. That's why it's named "ti-sn65dsi86-aux" when running "i2cdetect -l". The aux-channel exists physically between the bridge and the eDP display. When the kernel want's to access it, it has to tunnel the aux messages via the i2c connection to the bridge.
Do you need schematics of the board? There is no issue with the schematics. The board works perfectly fine with the old 5.10 kernel.
Regarding I2C schematics: SCL/SDA of the DSI86 bridge-chip are connected to a level-shifter, and from there connected to SCL0/SDA0 on the CM4 (on physical pins 80 and 82, translating to GPIO 44&45 as far as i know).
"raspi-gpio get" gives:
GPIO 44: level=1 fsel=5 alt=1 func=SDA0 pull=NONE
GPIO 45: level=1 fsel=5 alt=1 func=SCL0 pull=NONE
I don't understand what you mean with that. The section of the overlay that you are citing configures the input and output ports of the DSI86 chip:will not work as you can't combine the PI's DSI interfaces.
- Input port is connected to the DSI out port of the CM4.
- Output port is connected to the input port of the eDP panel.
The configuration works like that on the old 5.10 kernel. I do not see why it should be wrong on the 6.6. kernel. Can you explain in more detail what I am overlooking here?
Panel timings are defined by an extension of the panel-edp.c file. They are loaded due to the 'compatible = "auo,b156hak022_edp_30fps";' line in the overlay in the panel section. That works, my log line in that file get's triggered:Where do you define your panel timings?
Code:
[ 7.594094] panel-simple-dp-aux aux-ti_sn65dsi86.aux.0: panel_edp_probe: num modes: 1, clock: 79750, h: 1920, v: 1080You are right. I omitted the touch driver section from the overlay in the posting.Your panel and touch enable, as well as your backlight, should be configured via DT overlay - and not from your config.txt
And the two lines in the config.txt where only for testing, but they should not harm. Removed them just now to be sure, but does not change anything.
Regarding the backlight, that's a bit special on my board. It's controlled via a sperate micro-controller for super-smooth on/off-dimming. Works like a charm. The micro-controller listens on the power controller for the bridge for on-synchronization, off is controlled via a separate display controller software. That works without any issues (backlight is switching on/off properly even on the 6.6 kernel)
I still think it boils down to the question why the kernel cannot communicate via the "DP-aux over i2c" channel. Due to that, communication with the panel fails. This breaks link training for the eDP bus.
I already checked the "ti_sn_aux_transfer" function in the ti-sn65dsi86.c file that sends the data over i2c. But I have not seen anything unusual in there. And if that function would be the issue, the other boards with sn65dsi86 would also not work (sdm850-lenovo-yoga-c630.dts and sc7180-acer-aspire1.dts).
Statistics: Posted by thmang82 — Tue May 28, 2024 7:53 pm