<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)" href="https://bugs.freedesktop.org/show_bug.cgi?id=56139#c30">Comment # 30</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)" href="https://bugs.freedesktop.org/show_bug.cgi?id=56139">bug 56139</a> from <a class="email" href="mailto:alexandre.f.demers@gmail.com" title="Alexandre Demers <alexandre.f.demers@gmail.com>"> Alexandre Demers</a> <pre>(In reply to <a href="show_bug.cgi?id=56139#c29">comment #29</a>) > (In reply to <a href="show_bug.cgi?id=56139#c28">comment #28</a>) > > 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]: > <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff">http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff</a>; > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>