[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 #30 from Alexandre Demers <alexandre.f.demers at gmail.com> ---
(In reply to comment #29)
> (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

Your explanations are appreciated, but that kills another idea. By the way,
pictures and videos are coming, my camera had no power yesterday and I had to
charge it during last night.

-- 
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/7565bff4/attachment.html>