Re: [PATCH v5] drm/radeon: fix internal display on iMac11, 1 (RV770/DCE3.1)
Alex Deucher <[email protected]>
| Newsgroups | org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel |
|---|---|
| Message-ID | <CADnq5_PhfdtFz_hUnGx58YfYvPZYb2ExESuBgQ5UvhbaT-grmA@mail.gmail.com> |
On Thu, Aug 20, 2026 at 2:59 PM Gilles Risch <[email protected]> wrote: > > Good afternoon, > > no problem, please find attached my complete dmesg output after a fresh > reboot. I don't see a bit difference, except that my card is connected > to a different PCI bus. > > I don’t pass any kernel parameters via GRUB and I don’t use a xorg.conf > configuration file either. Have you connected an additional, external > display? > Kind regards, > Gilles > > On 20.08.26 15:24, Alex Deucher wrote: > > On Thu, Aug 20, 2026 at 8:50 AM Erik Gregg <[email protected]> wrote: > >> On Mon, 1 Jun 2026 23:19:32 +0200, Gilles Risch <[email protected]> wrote: > >>> The Apple iMac11,1 (27-inch, Late 2009) uses a Mobility Radeon HD 4850 > >>> (RV770/DCE3.1) with a 2560x1440 internal panel on an internal > >>> DisplayPort path. Without this fix the display stays dark under KMS. > >>> > >>> This machine suffers from the same issue as iMac10,1 and iMac11,2: > >>> Apple routes the internal display through Link B of the DIG encoder > >>> instead of Link A. Add iMac11,1 to the existing DMI quirk and move > >>> the Apple-specific encoder assignment into its own block, independent > >>> of the DCE version check. > >>> > >>> Additionally, the 2560x1440 panel requires RADEON_PLL_USE_FRAC_FB_DIV > >>> and ATOM_ENCODER_CMD_DP_VIDEO_ON, limited to iMac11,1 via dmi_match() > >>> to avoid affecting other boards. > >>> > >>> Signed-off-by: Gilles Risch <[email protected]> > >> I tested this patch on top of 7.1.7-arch1 on a Late 2009 27" iMac11,1 > >> with the Mobility Radeon HD 4850. With nomodeset the machine boots with > >> a working (efifb) console. On vanilla 7.1.7 without nomodeset the panel > >> stays completely black (backlight off) and no radeon init is visible in > >> dmesg over SSH. > >> > >> With the patch and without nomodeset, radeon initializes normally per > >> dmesg, but at the fbcon modeset (~4s) the panel goes blank and then > >> shows flashing horizontal lines that start at the top and sweep down at > >> regular intervals. It never recovers. The logs below are from that case, > >> gathered by logging in blind on the console and running commands blind. > >> > >> I tried radeon.dpm=0, radeon.audio=0, video=eDP-1:2560x1440@60 and > >> radeon.modeset=1, with no change. > > I wonder if different variants of the board are wired up differently. > > @Gilles Risch, can you attach your dmesg output as well? Maybe there > > are different panels on different variants? @Erik Gregg Can you narrow down which hunk(s) if this patch are problematic? If I had to guess, I'd say it's this hunk: + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") || + dmi_match(DMI_PRODUCT_NAME, "iMac11,1") || + dmi_match(DMI_PRODUCT_NAME, "iMac11,2")) { + enc_idx = (dig->linkb) ? 1 : 0; + goto assigned; + } Alex > > > > Alex > > > >> Renderer: AMD RV770 (DRM 2.51.0 / 7.1.7-arch1-1-imac), Mesa 26.1.6 > >> > >> [ 3.028962] radeon 0000:02:00.0: fence driver on ring 3 uses gpu addr 0x0000000020000c0c > >> [ 3.029207] radeon 0000:02:00.0: fence driver on ring 5 uses gpu addr 0x0000000000056230 > >> [ 3.030250] radeon 0000:02:00.0: radeon: using MSI. > >> [ 3.030275] [drm] radeon: irq initialized. > >> [ 3.076796] [drm] ring test on 0 succeeded in 1 usecs > >> [ 3.076803] [drm] ring test on 3 succeeded in 2 usecs > >> [ 3.252855] radeon 0000:02:00.0: [drm] ring test on 5 succeeded in 1 usecs > >> [ 3.252861] radeon 0000:02:00.0: [drm] UVD initialized successfully. > >> [ 3.253264] [drm] ib test on ring 0 succeeded in 0 usecs > >> [ 3.253283] [drm] ib test on ring 3 succeeded in 0 usecs > >> [ 3.906199] radeon 0000:02:00.0: [drm] ib test on ring 5 succeeded > >> [ 3.906669] [drm] radeon atom DIG backlight initialized > >> [ 3.906672] radeon 0000:02:00.0: [drm] Radeon Display Connectors > >> [ 3.906674] radeon 0000:02:00.0: [drm] Connector 0: > >> [ 3.906676] radeon 0000:02:00.0: [drm] DP-1 > >> [ 3.906677] radeon 0000:02:00.0: [drm] HPD2 > >> [ 3.906679] radeon 0000:02:00.0: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c > >> [ 3.906682] radeon 0000:02:00.0: [drm] Encoders: > >> [ 3.906683] radeon 0000:02:00.0: [drm] DFP1: INTERNAL_UNIPHY > >> [ 3.906685] radeon 0000:02:00.0: [drm] Connector 1: > >> [ 3.906687] radeon 0000:02:00.0: [drm] eDP-1 > >> [ 3.906688] radeon 0000:02:00.0: [drm] HPD3 > >> [ 3.906689] radeon 0000:02:00.0: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c > >> [ 3.906692] radeon 0000:02:00.0: [drm] Encoders: > >> [ 3.906693] radeon 0000:02:00.0: [drm] LCD1: INTERNAL_UNIPHY > >> [ 3.906695] radeon 0000:02:00.0: [drm] Connector 2: > >> [ 3.906697] radeon 0000:02:00.0: [drm] VGA-1 > >> [ 3.906698] radeon 0000:02:00.0: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c > >> [ 3.906701] radeon 0000:02:00.0: [drm] Encoders: > >> [ 3.906702] radeon 0000:02:00.0: [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >> [ 3.915213] [drm] Initialized radeon 2.51.0 for 0000:02:00.0 on minor 0 > >> [ 3.988184] [drm] fb mappable at 0xC0347000 > >> [ 3.988187] [drm] vram apper at 0xC0000000 > >> [ 3.988188] [drm] size 14745600 > >> [ 3.988189] [drm] fb depth is 24 > >> [ 3.988190] [drm] pitch is 10240 > >> [ 3.988263] fbcon: radeondrmfb (fb0) is primary device > >> [ 4.026022] radeon 0000:02:00.0: [drm] fb0: radeondrmfb frame buffer device > >> [ 5.366673] systemd[1]: Load Kernel Module drm skipped, unmet condition check ConditionKernelModuleLoaded=!drm > >> [ 8.464118] snd_hda_intel 0000:02:00.1: bound 0000:02:00.0 (ops radeon_audio_component_bind_ops [radeon]) > >> > >> Happy to test further patches or gather more logs. > >> > >> Regards, > >> Erik >