From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN) Date: Tue, 13 Nov 2012 15:45:32 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0659680584==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id B26B49F0EA for ; Tue, 13 Nov 2012 07:45:32 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0659680584== Content-Type: multipart/alternative; boundary="1352821532.a1Fd0.22685"; charset="us-ascii" --1352821532.a1Fd0.22685 Date: Tue, 13 Nov 2012 15:45:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D56139 --- Comment #30 from Alexandre Demers --- (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 qui= ck > > 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 t= o 1? > > I may just have missed it, but could this be something missing? Same > > questions goes for GPU soft reset. >=20 > 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. >=20 > These functions have nothing to do with system suspend/hibernate and resu= me > 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: >=20 > list_for_each_entry(connector, &dev->mode_config.connector_list, head) { > drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); > } >=20 > And then the displays are enabled again in radeon_resume_kms(): >=20 > /* 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); > } >=20 > >=20 > > Before the culprit commit, we were setting bit 0 to 0 on stop and setti= ng it > > back to 1 on resume, which was working great. Why aren't we doing it an= ymore > > when suspending and resuming? >=20 > 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. >=20 > We'd like to avoid disabling the crtc during driver load or GPU reset to > avoid the visible flicker it causes. >=20 > [1]: > http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dcommit= diff; > h=3D81ee8fb6b52ec69eeed37fe7943446af1dccecc5 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. --=20 You are receiving this mail because: You are the assignee for the bug. --1352821532.a1Fd0.22685 Date: Tue, 13 Nov 2012 15:45:32 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Commen= t # 30 on bug 56139<= /a> from Alexandre Demers
(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 s=
uspend
> > 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? S=
ame
> > questions goes for GPU soft reset.
>=20
> It's set by the vbios at boot before the OS loads.  Once the driver lo=
ads,
> it's then handled by the modesetting code.  crtcs are enabled or disab=
led
> based on what's connected and what displays the user has chosen to ena=
ble.
>=20
> These functions have nothing to do with system suspend/hibernate and r=
esume
> directly.  evergreen_mc_stop() and evergreen_mc_resume() are for disab=
ling
> 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:
>=20
> list_for_each_entry(connector, &dev->mode_config.connector_list=
, head) {
>        drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
> }
>=20
> And then the displays are enabled again in radeon_resume_kms():
>=20
> /* 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);
> }
>=20
> >=20
> > 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?
>=20
> 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 la=
ter by
> the modesetting code.  Prior to that patch[1], we just saved and resto=
red
> the value of the register which is basically what you are proposing, b=
ut
> that didn't work otherwise we wouldn't have needed the subsequent patc=
hes.
>=20
> We'd like to avoid disabling the crtc during driver load or GPU reset =
to
> avoid the visible flicker it causes.
>=20
> [1]:
> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/li=
nux.git;a=3Dcommitdiff;
> h=3D81ee8fb6b52ec69eeed37fe7943446af1dccecc5

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: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1352821532.a1Fd0.22685-- --===============0659680584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0659680584==--