[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #29 from Alex Deucher <agd5f at yahoo.com> ---
(In reply to comment #28)
> Alex, a simple question: you said bit 0 in EVERGREEN_CRTC_CONTROL stops the
> CRTC sync. With the culprit commit, when is it set? I mean, I had a quick
> look in the driver's code and I couldn't find it. When going in suspend
> state, shouldn't it be set to 0? Then, on resume, shouldn't it be set to 1?
> I may just have missed it, but could this be something missing? Same
> questions goes for GPU soft reset.

It's set by the vbios at boot before the OS loads.  Once the driver loads, it's
then handled by the modesetting code.  crtcs are enabled or disabled based on
what's connected and what displays the user has chosen to enable.

These functions have nothing to do with system suspend/hibernate and resume
directly.  evergreen_mc_stop() and evergreen_mc_resume() are for disabling MC
clients when we make changes to the GPU memory controller.  System
suspend/hibernate are handled by radeon_suspend_kms() and radeon_resume_kms(). 
radeon_suspend_kms() explicitly disables all of the display hardware:

list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
       drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
}

And then the displays are enabled again in radeon_resume_kms():

/* blat the mode back in */
drm_helper_resume_force_mode(dev);
/* turn on display hw */
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
    drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
}

> 
> Before the culprit commit, we were setting bit 0 to 0 on stop and setting it
> back to 1 on resume, which was working great. Why aren't we doing it anymore
> when suspending and resuming?

The previous code[1] didn't do that.  It set bit 0 to 0 in evergreen_mc_stop()
and then left it disabled in evergreen_mc_resume().  The crtc was not
subsequently re-enabled until the displays were set up later by the modesetting
code.  Prior to that patch[1], we just saved and restored the value of the
register which is basically what you are proposing, but that didn't work
otherwise we wouldn't have needed the subsequent patches.

We'd like to avoid disabling the crtc during driver load or GPU reset to avoid
the visible flicker it causes.

[1]:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=81ee8fb6b52ec69eeed37fe7943446af1dccecc5

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121113/6933e94e/attachment.html>