Bug 46287

I'm having similar symptoms on an ATI FirePro 2460, 4 miniDP connectors, 2 DP monitors and 2 mDP->DVI adapters w/DVI monitors attached.  DisplayPort-0 connected via one of the mDP->DVI adapters fails to resume after suspend, but the other three monitors come back fine.  Sometimes it is DisplayPort-3 connected to the other mDP->DVI adapter that doesn't come back instead.

The difference here is that no amount of LCD power off, remove/reattach DVI cable, remove/reattach mDP->DVI adapter will make the screen wake up.  I have to do a full system reboot.

(In reply to comment #1)
> I'm having similar symptoms on an ATI FirePro 2460, 4 miniDP connectors, 2 DP
> monitors and 2 mDP->DVI adapters w/DVI monitors attached.  DisplayPort-0
> connected via one of the mDP->DVI adapters fails to resume after suspend, but
> the other three monitors come back fine.  Sometimes it is DisplayPort-3
> connected to the other mDP->DVI adapter that doesn't come back instead.
> 
> The difference here is that no amount of LCD power off, remove/reattach DVI
> cable, remove/reattach mDP->DVI adapter will make the screen wake up.  I have
> to do a full system reboot.

What kernel are you running?  Can you try a recent 3.6 snapshot?

I have a very similar issue, which I also described in a post to the dri-users maillist, only that in my case a analogue, i.e. VGA connected monitor is affected, and power cycling the display doesn't help.

I observe the following annoyance in my newly built HTPC (specs, lspci
etc. at the end of the mail) when using the radeon kernel module with
KMS enabled: After the display goes into DPMS Off, returning to DPMS On
mode will not return a signal to the display (without further
action). /sys/class/drm/card0-VGA-1/dmps reports the status as it
should be and the system stays stable and usable. The monitor is
connected via analogue signal on the VGA port (digital transmission is
not an option for this system).

The display signal can be brought back by performing a modeswitch (ATM
I'm working around this problem with a small helper that
polls /sys/class/drm/card0-VGA-1/dpms for a Off->On transition and
quickly changes the vertical clock to a helper frequency and back).
Hence I suspect that the CRTC is not properly brought back into
operation; I assume the modeswitch does bring it back into a sane
state.

I suggest a workaround/fix in which the CRTC is fully reinitialized
when doing a DPMS transition to On state.

Summary problem description:
AMD A-6 APU, with integrated Radeon core, Linux 3.5 radeon DRM/DRI2
kernel module – Video signal does not come back after DPMS state
transistion into On state. Happens with X11 and the framebuffer console
alike. Switching the video mode brings back the signal.

System information:
GPU: AMD A-6 3500 APU integrated Radeon HD 6530D

Arch Linux
# uname -a  
Linux beyla 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 09:14:51 CEST 2012 x86_64 GNU/Linux

# pacman -Q | grep ati  
ati-dri 8.0.4-3
xf86-video-ati 1:6.14.6-1

# lspci  
00:00.0 Host bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Complex
00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI BeaverCreek [Radeon HD 6530D]
00:02.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port
00:10.0 USB controller: Advanced Micro Devices [AMD] Hudson USB XHCI Controller (rev 03)
00:10.1 USB controller: Advanced Micro Devices [AMD] Hudson USB XHCI Controller (rev 03)
00:11.0 SATA controller: Advanced Micro Devices [AMD] Hudson SATA Controller [AHCI mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11)
00:12.2 USB controller: Advanced Micro Devices [AMD] Hudson USB EHCI Controller (rev 11)
00:13.0 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11)
00:13.2 USB controller: Advanced Micro Devices [AMD] Hudson USB EHCI Controller (rev 11)
00:14.0 SMBus: Advanced Micro Devices [AMD] Hudson SMBus Controller (rev 13)
00:14.1 IDE interface: Advanced Micro Devices [AMD] Hudson IDE Controller
00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01)
00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11)
00:14.4 PCI bridge: Advanced Micro Devices [AMD] Hudson PCI Bridge (rev 40)
00:14.5 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11)
00:15.0 PCI bridge: Advanced Micro Devices [AMD] Device 43a0
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 0 (rev 43)
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 6
00:18.6 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 5
00:18.7 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 7
01:00.0 Multimedia video controller: Conexant Systems, Inc. CX23887/8 PCIe Broadcast Audio and Video Decoder with 3D Comb (rev 04)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)


So I did a bit digging myself and although I'm not familiar with the
internal structure of the radeon driver I guess that the culprit is
probably found in those lines (and whatever is called through them)

linux-3.5.x/drivers/gpu/drm/atombios_crtc.c

 250 void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
 251 {
 252         struct drm_device *dev = crtc->dev;
 253         struct radeon_device *rdev = dev->dev_private;
 254         struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
 255 
 256         switch (mode) {
 257         case DRM_MODE_DPMS_ON:
 258                 radeon_crtc->enabled = true;
 259                 /* adjust pm to dpms changes BEFORE enabling crtcs */
 260                 radeon_pm_compute_clocks(rdev);
 261                 /* disable crtc pair power gating before programming */
 262                 if (ASIC_IS_DCE6(rdev) && !radeon_crtc->in_mode_set)
 263                         atombios_powergate_crtc(crtc, ATOM_DISABLE);
 264                 atombios_enable_crtc(crtc, ATOM_ENABLE);
 265                 if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev))
 266                         atombios_enable_crtc_memreq(crtc, ATOM_ENABLE);
 267                 atombios_blank_crtc(crtc, ATOM_DISABLE);
 268                 drm_vblank_post_modeset(dev, radeon_crtc->crtc_id);
 269                 radeon_crtc_load_lut(crtc);
 270                 break;
 271         case DRM_MODE_DPMS_STANDBY:
 272         case DRM_MODE_DPMS_SUSPEND:
 273         case DRM_MODE_DPMS_OFF:
 274                 drm_vblank_pre_modeset(dev, radeon_crtc->crtc_id);
 275                 if (radeon_crtc->enabled)
 276                         atombios_blank_crtc(crtc, ATOM_ENABLE);
 277                 if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev))
 278                         atombios_enable_crtc_memreq(crtc, ATOM_DISABLE);
 279                 atombios_enable_crtc(crtc, ATOM_DISABLE);
 280                 radeon_crtc->enabled = false;
 281                 /* power gating is per-pair */
 282                 if (ASIC_IS_DCE6(rdev) && !radeon_crtc->in_mode_set) {
 283                         struct drm_crtc *other_crtc;
 284                         struct radeon_crtc *other_radeon_crtc;
 285                         list_for_each_entry(other_crtc, &rdev->ddev->mode_config.crtc_list, head) {
 286                                 other_radeon_crtc = to_radeon_crtc(other_crtc);
 287                                 if (((radeon_crtc->crtc_id == 0) && (other_radeon_crtc->crtc_id == 1))      ||
 288                                     ((radeon_crtc->crtc_id == 1) && (other_radeon_crtc->crtc_id == 0))      ||
 289                                     ((radeon_crtc->crtc_id == 2) && (other_radeon_crtc->crtc_id == 3))      ||
 290                                     ((radeon_crtc->crtc_id == 3) && (other_radeon_crtc->crtc_id == 2))      ||
 291                                     ((radeon_crtc->crtc_id == 4) && (other_radeon_crtc->crtc_id == 5))      ||
 292                                     ((radeon_crtc->crtc_id == 5) && (other_radeon_crtc->crtc_id == 4))     ) {
 293                                         /* if both crtcs in the pair are off, enable power gating */
 294                                         if (other_radeon_crtc->enabled == false)
 295                                                 atombios_powergate_crtc(crtc, ATOM_ENABLE);
 296                                         break;
 297                                 }
 298                         }
 299                 }
 300                 /* adjust pm to dpms changes AFTER disabling crtcs */
 301                 radeon_pm_compute_clocks(rdev);
 302                 break;
 303         }
 304 }

What strikes me odd is the discrepancy between the power off and
power on sequences. When entering DPMS On mode (l. 262 et 263),
this happens without the pairing precautions done when powering off
for DPMS Standby, Suspend and Off (l. 282 ... 298)

Is that really correct?

Please try a 3.6 kernel or my 3.7 patch set:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip
There have been a number modesetting fixes since 3.5.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/27.