Created attachment 235980 [details] logfiles from FreeBSD 11.2 on RS880 and 14-CURRENT on RS780 I'm running FreeBSD 11.2 with radeonkms without problems, but I need to upgrade. So I tried 14-CURRENT. I built the drm modules and firmware from ports. When I load radeonkms my monitor attached to DVI goes blank. I found a similar bug here: https://github.com/freebsd/drm-kmod/issues/117, so I played around a bit. My RS880 board (GA-880GA-UD3H) has one monitor attached to the dual-link DVI output using a 2560x1440 solution. I also have a RS780 board (M3A78-CM) with 3 monitors for VGA, DVI and DisplayPort. I focused on the Asus board since it allows more test cases. When only DVI is connected, the screen goes blank after loading radeonkms. The connected monitor cannot be found. If I start Xorg with xf86-video-ati from ports, Xorg logs about using KMS to the console and the kernel hangs - no output, no ping, nothing (no crash dump). When DVI and DisplayPort is connected the DVI monitor goes blank after loading radeonkms, but the Displayport Monitor works as expected. The DVI connection is not detected, the Displayport is. Xorg only works on the Displayport monitor in the correct resolution. When DVI and VGA is connected, after loading radeonkms the DVI monitor shows exactly what the VGA monitor shows, same resolution. However, no monitor connection is detected. On this board VGA and DVI can't be used separately - DVI and Displayport can. So, the VGA Monitor works as expected, the DVI Monitor is a clone - if you unplug the VGA monitor the DVI monitor goes blank. Same behavior when you start Xorg. A single monitor attached to VGA or Displayport works as expected, monitor and resolutions get detected. I attach logfiles for the different scenarios. A few additional remarks: loading the drm module before the radeonkms never made a difference. It also doesn't matter if the DVI connection is single- or dual-link. In case the radeonkms module found a connected monitor dmesg shows kernel locking problems, so there's something not working correctly, yet. Since using dual-link DVI is the only option to drive my monitor I'd really like you to fix this regression ;-) BTW. earlier attempts with live CDs (GhostBSD) had a similar effect - this bug may already be on previous releases.
(In reply to alomobeto277 from comment #0) This appears to be identical to the issue I reported back in February 2022 (bug #262043, https://github.com/freebsd/drm-kmod/issues/195). This problem exists in drm-510-kmod, while drm-54-kmod used to work (but was broken by the maintainer by API changes to linuxkpi in -CURRENT that were only applied to drm-510-kmod and by declaring drm-54-kmod BROKEN on -CURRENT instead of making it compatible with the changed linuxkpi). lkpi_iic0: <LinuxKPI I2C> on drm3 iicbus0: <Philips I2C bus> on lkpi_iic0 iic0: <I2C generic I/O> on iicbus0 [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_KLDSCP_LVTMA [drm] Connector 2: [drm] DP-1 [drm] HPD2 [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY drmn0: [drm] Cannot find any crtc or sizes This shows that everything worked except the communication with the display in that final step. It is interesting that the DisplayPort connector could be used, I had only tested HDMI, since this observation narrows down the search space! I'm assigning this PR to Emmanuel Vadot, who last worked on these ports and who decided to deprecate drm-54-kmod on -CURRENT instead of keeping it working for users affected by this issue.
I can confirm the problem and add a couple of details. For me the problem happens with an ancient R600 card (HD 2600 XT). It has two DVI outputs and a single TV (S-Video) port which I am not able to test. Video output works fine unless radeonkms is loaded, otherwise it goes blank. It seems that the driver cannot detect a monitor on either of outputs. However, if I use a DVI to VGA converter (passive) and connect to a VGA input, then the monitor gets detected and everything works. I also tried a live linux image (Debian using 5.10.x.y.z kernel) and there there is no such problem. So, I think that this strongly points towards a DVI connector detection problem. https://lists.freedesktop.org/archives/amd-gfx/2022-August/082887.html
Emmanuel, I looked at the latest code and I am confused about it. do_i2c_transfer() calls lkpi_i2cbb_transfer() for bit-bang adapters but lkpi_i2cbb_transfer() is a dummy function that just returns 0. Oh, it's even worse than that, i2c_transfer() returns -EOPNOTSUPP because adapter->algo is NULL for bit-bang adapters... It seems like some piece of the code got lost when the functionality was moved from linuxkpi_gplv2 to linuxkpi.
So, anything using i2c_transfer(), things related to DDC / EDID, seem to be broken (at least on AMD).
(In reply to Andriy Gapon from comment #3) Yeah it seems that I've never finished this code ... Please try this patch : https://people.freebsd.org/~manu/0001-linuxkpi-Try-to-unbreak-linux_i2cbb.patch Only build tested as I don't have affected hardware.
(In reply to Andriy Gapon from comment #4) Not every AMD card, most recent (past 5+ years) have hardware i2c and don't bitbang.
(In reply to Emmanuel Vadot from comment #6) You are correct, only the bit-banging operations got broken. I noticed a couple more issues: - lkpi_iicbb device is added under drmn device (at least in my case), so DRIVER_MODULE should have that and not lkpi_iic as the parent bus - pre_xfer and post_xfer support is missing but it seems to be required by radeon_i2c.c
(In reply to Andriy Gapon from comment #7) Indeed, please try new patch (same url).
(In reply to Emmanuel Vadot from comment #8) Thank you very much for the patch! It did the bulk of work. I needed to do a few corrections and also took a liberty to make some improvements (some of them opinionated). Here my patch as a follow-up to yours: https://people.freebsd.org/~avg/0001-fixup-linuxkpi-Try-to-unbreak-linux_i2cbb.patch
A couple of additional notes. I think that lkpi_i2c_transfer also needs to do the address shifting (but in the opposite direction). I think that we want to consistently use FreeBSD-style slave addresses everywhere. I'd suggest to turn i2c_transfer() and __i2c_transfer() into proper functions instead of having them as inlines. They are parts of the (L)KPI, so I think that their implementation should be in the linuxkpi module instead of getting exposed to every consumer. In other words, I'd prefer that consumers would not have to be recompiled if there is any change in those functions.
I'm good with your patch, I think that originally I added the delays/logic but then I decided to use iicbb and didn't removed this code. For the 7bit/8bit i2c(8) uses 7 bit format, I don't think that this is needed, I mean drm code finds the edid and I can query it from userland too directly using i2c(8) so ... Feel free to commit your patch squashed to mine as you tested that it works correctly. For inline vs not inline I don't really care, feel free to change that if you want.
(In reply to Emmanuel Vadot from comment #11) i2c command indeed takes a 7-bit address, but i2c internally converts it to 8-bit, because it knows that that's how FreeBSD works. I think that's why your example had to use address 0x28 (7-bit) while in reality the DDC/EDID address is 0x50 (7-bit). The drm/kms kernel part works, of course, because it does not use lkpi_i2c_transfer() at all as for it the path is just i2c_transfer -> algo->master_xfer, so FreeBSD I2C code is not involved at all.
(In reply to Andriy Gapon from comment #12) Yes you're right. Initially I though that 0x50 was the 8bit address for the EDID but it's indeed the 7bit address. I'll commit that asap.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=319a4bddb0b991377208293283a87946e4b5d055 commit 319a4bddb0b991377208293283a87946e4b5d055 Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2022-08-19 12:37:05 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2022-08-19 12:39:16 +0000 linuxkpi: i2c: Fix 7bit/8bit addressing Linux is using 7 bit addressing while FreeBSD uses 8 bit addresses internally, but i2c(8) uses 7 bit address. This confused me when originally doing the code and I thought that 0x50 was the 8bit EDID address while it's the 7bit address and since I did all my testing using this I didn't noticed the problem. Reported by: avg PR: 265920 (somewhat) sys/compat/linuxkpi/common/src/linux_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6364180582b769b8fb8fba83511748af3b2c9efd commit 6364180582b769b8fb8fba83511748af3b2c9efd Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2022-08-18 15:34:35 +0000 Commit: Andriy Gapon <avg@FreeBSD.org> CommitDate: 2022-08-24 13:23:37 +0000 linuxkpi: unbreak linux_i2cbb This is a joint work with manu. - fixed conditions in do_i2c_transfer and i2c_transfer as linux_i2cbb does not set adapter->algo->master_xfer but does set adapter->algo_data; - fixed parent bus specification for linux_i2cbb driver module; - actually implemented iicbb_transfer method; - added iicbb_pre_xfer and iicbb_post_xfer methods; - removed unnecessary and harmful delays (and other extra logic) from iicbb methods as iicbb driver already has them; - added setting of iicbb speed based on algo_data->udelay, so that iicbb uses correct delays; PR: 265920 Fixes: 1961a14a4743 linuxkpi: Add i2c support MFC after: 2 weeks Sponsored by: Beckhoff Automation GmbH & Co. KG (manu's work) sys/compat/linuxkpi/common/include/linux/i2c.h | 4 +- sys/compat/linuxkpi/common/src/linux_i2cbb.c | 155 ++++++++++++++++++------- 2 files changed, 118 insertions(+), 41 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b3814a4806dc6117644a7faee157e98c5bc5b2bf commit b3814a4806dc6117644a7faee157e98c5bc5b2bf Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2022-08-18 15:34:35 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2022-09-07 15:09:06 +0000 linuxkpi: unbreak linux_i2cbb This is a joint work with manu. - fixed conditions in do_i2c_transfer and i2c_transfer as linux_i2cbb does not set adapter->algo->master_xfer but does set adapter->algo_data; - fixed parent bus specification for linux_i2cbb driver module; - actually implemented iicbb_transfer method; - added iicbb_pre_xfer and iicbb_post_xfer methods; - removed unnecessary and harmful delays (and other extra logic) from iicbb methods as iicbb driver already has them; - added setting of iicbb speed based on algo_data->udelay, so that iicbb uses correct delays; PR: 265920 Fixes: 1961a14a4743 linuxkpi: Add i2c support MFC after: 2 weeks Sponsored by: Beckhoff Automation GmbH & Co. KG (manu's work) (cherry picked from commit 6364180582b769b8fb8fba83511748af3b2c9efd) sys/compat/linuxkpi/common/include/linux/i2c.h | 4 +- sys/compat/linuxkpi/common/src/linux_i2cbb.c | 155 ++++++++++++++++++------- 2 files changed, 118 insertions(+), 41 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f22498bb4b48ec4b8b8041367aa80099ec0caf26 commit f22498bb4b48ec4b8b8041367aa80099ec0caf26 Author: Emmanuel Vadot <manu@FreeBSD.org> AuthorDate: 2022-08-19 12:37:05 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2022-09-07 15:09:06 +0000 linuxkpi: i2c: Fix 7bit/8bit addressing Linux is using 7 bit addressing while FreeBSD uses 8 bit addresses internally, but i2c(8) uses 7 bit address. This confused me when originally doing the code and I thought that 0x50 was the 8bit EDID address while it's the 7bit address and since I did all my testing using this I didn't noticed the problem. Reported by: avg PR: 265920 (somewhat) (cherry picked from commit 319a4bddb0b991377208293283a87946e4b5d055) sys/compat/linuxkpi/common/src/linux_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Created attachment 237586 [details] logfile from FreeBSD 14-CURRENT on RS880
You guys are fast! At least faster in fixing the bug than me in testing ;-) Two/three weeks ago I downloaded the 14-CURRENT ISO and tested on my RS880 system. DRM worked like a charm! I still see messages when I load the driver but I assume that's debug output. Nevertheless I attach it here. I'm now in progress of migrating from 11.2 to 14-CURRENT. Thanks a lot - I can stay on FreeBSD now.
When will this fix be available on 13.1-RELEASE?
(In reply to Konstantin from comment #20) 13.1 isn't affected, only current was (maybe 13-stable for some time too don't recall).
(In reply to Emmanuel Vadot from comment #21) I am using FreeBSD since 11.0. After upgrade to 13.0, radeonkms got broken. I have two monitors connected via DVI and VGA, and have issues as described in this report: > When DVI and VGA is connected, after loading radeonkms the DVI monitor shows > exactly what the VGA monitor shows, same resolution. However, no monitor > connection is detected. On this board VGA and DVI can't be used separately - DVI > and Displayport can. So, the VGA Monitor works as expected, the DVI Monitor is a > clone - if you unplug the VGA monitor the DVI monitor goes blank. Same behavior > when you start Xorg. Current OS version: 13.1-RELEASE-p3 Kernel: GENERIC amd64 Hardware: Radeon HD 3000 (Radeon R600) Installed packages: drm-510-kmod-5.10.113_7, gpu-firmware-radeon-kmod-rs780, gpu-firmware-radeon-kmod-r600.