Re: [PATCH] drm/radeon: fix eDP resume from suspend on iMac11, 1 / DCE3.1 systems

[Alex Deucher <alexdeucher@gmail.com>]

On Mon, May 18, 2026 at 10:40 AM Gilles Risch <gilles.risch@gmail.com> wrote:
>
> Am Mo., 18. Mai 2026 um 16:13 Uhr schrieb Alex Deucher <alexdeucher@gmail.com>:
> >
> > On Sat, May 16, 2026 at 2:52 PM Gilles Risch <gilles.risch@gmail.com> wrote:
> > >
> > > After suspend/resume the internal eDP display on iMac11,1 (and
> > > potentially other DCE3.1 systems) stays dark because
> > > atombios_set_edp_panel_power() skips panel power control for
> > > anything older than DCE4.
> > >
> > > Fix this by:
> > > - Extending atombios_set_edp_panel_power() to also handle DCE3.1
> > >   by changing the !ASIC_IS_DCE4() guard to !ASIC_IS_DCE31().
> > >   HPD polling works correctly on DCE3.1 (verified: HPD is asserted
> > >   at iteration 0 on iMac11,1).
> > > - Issuing ATOM_ENCODER_CMD_DP_VIDEO_ON/OFF for DCE3.1 in addition
> > >   to DCE4+.
> > >
> > > Tested on iMac11,1 (Mobility Radeon HD 4850, RV770/DCE3.1).
> > >
> > > Signed-off-by: Gilles Risch <gilles.risch@gmail.com>
> > > ---
> > >  drivers/gpu/drm/radeon/atombios_encoders.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
> > > index 4e984973c043..b62fd713efcf 100644
> > > --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> > > +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> > > @@ -1383,7 +1383,7 @@ atombios_set_edp_panel_power(struct drm_connector *connector, int action)
> > >         if (connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> > >                 goto done;
> > >
> > > -       if (!ASIC_IS_DCE4(rdev))
> > > +       if (!ASIC_IS_DCE31(rdev))
> > >                 goto done;
> > >
> > >         if ((action != ATOM_TRANSMITTER_ACTION_POWER_ON) &&
> > > @@ -1707,7 +1707,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
> > >                 if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector) {
> > >                         /* DP_SET_POWER_D0 is set in radeon_dp_link_train */
> > >                         radeon_dp_link_train(encoder, connector);
> > > -                       if (ASIC_IS_DCE4(rdev))
> > > +                       if (ASIC_IS_DCE4(rdev) || ASIC_IS_DCE31(rdev))
> > >                                 atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
> > >                 }
> > >                 if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
> > > @@ -1724,7 +1724,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode)
> > >         case DRM_MODE_DPMS_SUSPEND:
> > >         case DRM_MODE_DPMS_OFF:
> > >
> > > -               if (ASIC_IS_DCE4(rdev)) {
> > > +               if (ASIC_IS_DCE4(rdev) || ASIC_IS_DCE31(rdev)) {
> > >                         if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector)
> > >                                 atombios_dig_encoder_setup(encoder, ATOM_ENCODER_CMD_DP_VIDEO_OFF, 0);
> > >                 }
> >
> > These changes don't make sense and will break other DCE3.c boards.   I
> > had the attached patch from you in one of my old branches, does it fix
> > the issue?
> >
> > Alex
>
> While the initial attached patch resolved the dark screen issue after
> a fresh boot, this follow-up patch addresses the same problem
> occurring after resuming from suspend. Should I used dmi_match() to
> avoid breaking other DCE3.c boards?

Yes.  Even that is a hack.  You are effectively just skipping some of
the required programming sequences.  Presumably the mac is wired up
strangely or there are issues with its atom tables.  Ideally we'd sort
that out, but this hardware is pretty old so I'm ok with a hack.

Alex