Hello,
I'm trying to analyze instability in display startup, that we observe with some, but not all, displays, both with linux drm drivers and with sdk r5 drivers. Thy symptom is: not all displays turn on and show picture. Some turn on only if uplugged and replugged while system is already running.
The root cause of the issue is that the drivers - both in linux drm and on r5 - always assume that eDP firmware will respond to the outgoing message with a reply with a defined length. However, tracing shows that sometimes the length of the response differs from expectation. This causes the current driver's operation to fail.
Here is an example trace, extracted from linux drm drivers, by adding printk's to cdns_mhdp_mailbox_validate_receive() routine:
...
[ 2.139075] GOOD REPLY opcode=17 module_id=1 size=1
[ 2.147970] BAD REPLY opcode=2 h[0]=2 module_id=1 h[1]=1 req_size=130 mbox_size=2
[ 2.164066] BAD REPLY opcode=2 h[0]=2 module_id=1 h[1]=1 req_size=130 mbox_size=2
[ 2.180162] BAD REPLY opcode=2 h[0]=2 module_id=1 h[1]=1 req_size=130 mbox_size=2
[ 2.196258] BAD REPLY opcode=2 h[0]=2 module_id=1 h[1]=1 req_size=130 mbox_size=2
[ 2.208339] cdns-mhdp a000000.dp-bridge: [drm:cdns_mhdp_get_edid_block] *ERROR* get block[0] edid failed: -22
[ 2.218233] cdns-mhdp a000000.dp-bridge: [drm:cdns_mhdp_get_modes] *ERROR* Failed to read EDID
[ 2.231842] GOOD REPLY opcode=7 module_id=10 size=8
[ 2.232873] BAD REPLY opcode=3 h[0]=3 module_id=1 h[1]=1 req_size=6 mbox_size=21
[ 2.232893] cdns-mhdp a000000.dp-bridge: [drm:mhdp_transfer] *ERROR* Failed to read DPCD
[ 2.234512] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.235532] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.236551] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.239579] BAD REPLY opcode=3 h[0]=3 module_id=1 h[1]=1 req_size=20 mbox_size=5
[ 2.239586] cdns-mhdp a000000.dp-bridge: [drm:mhdp_transfer] *ERROR* Failed to read DPCD
[ 2.241205] GOOD REPLY opcode=3 module_id=1 size=20
[ 2.242234] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.243254] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.244274] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.348270] GOOD REPLY opcode=7 module_id=10 size=8
[ 2.349299] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.350318] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.351337] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.352378] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.353397] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.355473] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.356492] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.357511] GOOD REPLY opcode=3 module_id=1 size=11
[ 2.359556] GOOD REPLY opcode=3 module_id=1 size=11
[ 2.360588] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.361606] GOOD REPLY opcode=3 module_id=1 size=6
[ 2.362625] GOOD REPLY opcode=3 module_id=1 size=11
[ 2.364668] GOOD REPLY opcode=3 module_id=1 size=11
[ 2.365693] GOOD REPLY opcode=4 module_id=1 size=5
[ 2.366711] GOOD REPLY opcode=7 module_id=10 size=8
[ 2.370911] GOOD REPLY opcode=7 module_id=10 size=8
[ 2.382942] Console: switching to colour frame buffer device 128x48
Situation in r5 drivers is similar.
Looks like either (this version of) eDP firmware is broken, or protocol is more complex than just replying with message of known length, or there is some problem in communication with the firmware.
Any hints on this?
Maybe a eDP firmware update, or some protocol documentation, or whatever other related information is available?