[Bug 46287] [R600] DVI monitor fails to resume after DPMS off
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Sun Sep 16 07:07:14 PDT 2012
https://bugs.freedesktop.org/show_bug.cgi?id=46287
--- Comment #3 from Wolfgang Draxinger <bugzilla+bugs.freedesktop.org at datenwolf.net> 2012-09-16 14:07:14 UTC ---
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?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the xorg-driver-ati
mailing list