11:34mareko: can you please review this commit? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20815/diffs?commit_id=ddfc8df2411532ccf31c120419ef89ac3ae0dfa7
18:49jiaozhou_: I am from Google ChromeOS Flex team. I am working on a ticket that the display reset to the default resolution after boot, I saw a lot of timeout error https://paste.debian.net/1269222/. I am wondering if you know why I got this error? Thanks!
18:50agd5f: jiaozhou_, looks like driver driver is having problems communicating with the monitor
18:59jiaozhou_: I am working on a ticket with screen resolution issue. After restarting the device while using Display Port the device resolution changes from 1920x1080 to 1024x864. Not until I unplug and plug the Display port back back in does it return to 1920x1080. Log shows no value for EDID
19:00jiaozhou_: then I saw the above timeout logs I pasted in the link before the screemndefault to 1024 x 8664
19:06agd5f: jiaozhou_, looks like there is some problem communicating with the monitor until you re-plug it
19:26jiaozhou_: https://source.corp.google.com/chromeos_public/src/third_party/kernel/v5.10/drivers/gpu/drm/radeon/atombios_dp.c;l=115?q=%22atom_execute_table_scratch_unlocked(rdev-%3Emode_info.atom_context,%20index,%20(uint32_t%20*)%26args)%22%20v5.10 args.v1.ucReplyStatus;
19:26jiaozhou_: becomes 1 after the above function call
19:44jiaozhou_: there's a general issue. I can reproduce the issue with a different display cable and a different monitor
19:47agd5f: jiaozhou_, is it a regression? that radeon driver hasn't really seen many changes in years
19:54gildekel: agd5f:
19:54jiaozhou_: I do not think it is a regression
19:57gildekel: Hi all, I am with with ChromeOS Graphics - Displays team. Sadly, none of us are radeon driver experts.. so it's hard to say. But it is odd that there are communication issues over DP during DRM init, which are resolved later via re-plug. We also tested a case in which we start the system with no display connected, and plug after the OS settles. Things seem to work fine in that scenario.
19:58gildekel: Another important thing to note is that this particular device runs kernel 5.10 with DRM 5.15, so this could potentially be an old regression that was fixed in later kernels
19:59gildekel: We'll need some guidance regarding whether there are patches that require porting, or help with the issue in general.
20:18agd5f: gildekel, the DP handling in radeon hasn't been touched in probably 5 years so maybe some general drm DP change broke things?
20:38jiaozhou_: what are those general drm DP change?
20:53agd5f: jiaozhou_, I don't know. You'd have to check. Maybe try a vanilla 5.10 or older kernel and see if you can repro the issue
21:51gildekel: Wouldn't a more general DRM DP issue affect other platforms as well? This seems very specific. We don't see issues of on-init link bring-ups on other platforms (e.g. Intel/AMD/MTK/etc..)
21:53agd5f: gildekel, maybe? I haven't seen anything like that on radeon, but I don't test old radeon hardware much anymore
21:53gildekel: As a side note, jiaozhou_ is going to test HDMI as well, JIC.
22:11jiaozhou_: I also installed an Ubuntu image with kernel 5.15 and that it reproduces the issue
22:14jiaozhou_: The dut is using Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4250]
22:14jiaozhou_: pci:1002:9715
22:20gildekel: I guess another possibility is that we're compiling kernel with a missing flag wrt: the radeon driver..?
22:20gildekel: agd5f: (or anyone else), can you think of anyone who might be willing to help us pinpoint this issue? Someone who might be familiar with older chipsets?
22:29Ristovski: Have you completely ruled out a broken HW combo?
22:31gildekel: Yes, jiaozhou_ tested on different displays and with different DP cables. Also, the link comes up fine after re-plug, or if we let the system come up first, and then plug our display
22:32Ristovski: I wonder, what about suspend/resume?
22:33gildekel: hmm.. we did not test that.
22:33gildekel: jiaozhou_: mind putting your device to sleep and waking it up and see if the issue reproduces?
22:49jiaozhou_: the display shows correct resolution after sleep and wakeup
22:51jiaozhou_: I also tested a similar GPU, Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] , no issue on this one
23:14Ristovski: agd5f: How come (radeon_i2c.c) radeon_get_i2c_prescale and radeon_hw_i2c_xfer are "/* todo */" for a lot of the cards? Is there some other mechanism that kicks in (like bitbanging?)
23:14agd5f: gildekel, maybe a vbios bug. E.g., a the vbios has the HPD polarity inverted
23:16agd5f: Ristovski, we never implemented the hw i2c engine support for most cards. bit banging works fine and supports some i2c configurations that didn't have a hw i2c engine
23:18agd5f: Ristovski, the hw i2c engines were only used if you specified a kernel parameter
23:19agd5f: bit banging was the default for everything
23:19Ristovski: Mhm, I see
23:25gildekel: agd5f: >maybe a vbios bug. E.g., a the vbios has the HPD polarity inverted
23:25gildekel: How can we test that?
23:27Ristovski: fwiw r600.c:804 `r600_hpd_sense` is what checks/returns HPD status (with the DCE3 branch taken)