So a few people complained that
commit 177cf92de4aa97ec1435987e91696ed8b5023130 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Tue Apr 1 22:14:59 2014 +0200
drm/crtc-helpers: fix dpms on logic
which was merged into 3.15-rc1, broke resume on radeons. Strangely git bisect lead everyone to
commit 25f397a429dfa43f22c278d0119a60a343aa568f Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Fri Jul 19 18:57:11 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
which was merged long ago and actually part of 3.14.
Digging deeper I've noticed (again) that with these changes the call to drm_helper_resume_force_mode in the radeon resume handlers was a no-op previously because everything gets shut down on suspend. radeon does this with explicit calls to drm_helper_connector_dpms with DPMS_OFF. But with 177c we now force the dpms state to ON, so suddenly resume_force_mode actually forced something.
This was the intention of the change after all, the problem is that radeon resumes the fbdev console layer _before_ restoring the display, through calling fb_set_suspend. And fbcon does an immediate ->set_par, which in turn causes the same force mode restore to happen.
Two concurrent modeset operations didn't lead to happiness. Fix this by delaying the fbcon resume until the end of the readeon resum functions.
References: https://lkml.org/lkml/2014/5/29/1043 References: https://lkml.org/lkml/2014/5/2/388 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751 Tested-by: Ken Moffat zarniwhoop@ntlworld.com Cc: Alex Deucher alexdeucher@gmail.com Cc: Ken Moffat zarniwhoop@ntlworld.com Cc: Dave Airlie airlied@redhat.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/radeon/radeon_device.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 9aa1afd1786e..8f434c6c4540 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1533,11 +1533,6 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon)
radeon_restore_bios_scratch_regs(rdev);
- if (fbcon) { - radeon_fbdev_set_suspend(rdev, 0); - console_unlock(); - } - /* init dig PHYs, disp eng pll */ if (rdev->is_atom_bios) { radeon_atom_encoder_init(rdev); @@ -1562,6 +1557,12 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon) }
drm_kms_helper_poll_enable(dev); + + if (fbcon) { + radeon_fbdev_set_suspend(rdev, 0); + console_unlock(); + } + return 0; }
On Fri, May 30, 2014 at 10:37 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
So a few people complained that
commit 177cf92de4aa97ec1435987e91696ed8b5023130 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Tue Apr 1 22:14:59 2014 +0200
drm/crtc-helpers: fix dpms on logicwhich was merged into 3.15-rc1, broke resume on radeons. Strangely git bisect lead everyone to
commit 25f397a429dfa43f22c278d0119a60a343aa568f Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Fri Jul 19 18:57:11 2013 +0200
drm/crtc-helper: explicit DPMS on after modesetwhich was merged long ago and actually part of 3.14.
Digging deeper I've noticed (again) that with these changes the call to drm_helper_resume_force_mode in the radeon resume handlers was a no-op previously because everything gets shut down on suspend. radeon does this with explicit calls to drm_helper_connector_dpms with DPMS_OFF. But with 177c we now force the dpms state to ON, so suddenly resume_force_mode actually forced something.
This was the intention of the change after all, the problem is that radeon resumes the fbdev console layer _before_ restoring the display, through calling fb_set_suspend. And fbcon does an immediate ->set_par, which in turn causes the same force mode restore to happen.
Two concurrent modeset operations didn't lead to happiness. Fix this by delaying the fbcon resume until the end of the readeon resum functions.
References: https://lkml.org/lkml/2014/5/29/1043 References: https://lkml.org/lkml/2014/5/2/388 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751 Tested-by: Ken Moffat zarniwhoop@ntlworld.com Cc: Alex Deucher alexdeucher@gmail.com Cc: Ken Moffat zarniwhoop@ntlworld.com Cc: Dave Airlie airlied@redhat.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch
Thanks!
Reviewed-by: Alex Deucher alexander.deucher@amd.com
drivers/gpu/drm/radeon/radeon_device.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 9aa1afd1786e..8f434c6c4540 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1533,11 +1533,6 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon)
radeon_restore_bios_scratch_regs(rdev);
if (fbcon) {radeon_fbdev_set_suspend(rdev, 0);console_unlock();}/* init dig PHYs, disp eng pll */ if (rdev->is_atom_bios) { radeon_atom_encoder_init(rdev);@@ -1562,6 +1557,12 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon) }
drm_kms_helper_poll_enable(dev);
if (fbcon) {radeon_fbdev_set_suspend(rdev, 0);console_unlock();}return 0;}
-- 1.9.2
So a few people complained that
commit 177cf92de4aa97ec1435987e91696ed8b5023130 Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Tue Apr 1 22:14:59 2014 +0200
drm/crtc-helpers: fix dpms on logic
which was merged into 3.15-rc1, broke resume on radeons. Strangely git bisect lead everyone to
commit 25f397a429dfa43f22c278d0119a60a343aa568f Author: Daniel Vetter daniel.vetter@ffwll.ch Date: Fri Jul 19 18:57:11 2013 +0200
drm/crtc-helper: explicit DPMS on after modeset
which was merged long ago and actually part of 3.14.
Digging deeper I've noticed (again) that the call to drm_helper_resume_force_mode in the radeon resume handlers was a no-op previously because everything gets shut down on suspend. radeon does this with explicit calls to drm_helper_connector_dpms with DPMS_OFF. But with 177c we now force the dpms state to ON, so suddenly resume_force_mode actually forced the crtcs back on.
This is the intention of the change after all, the problem is that radeon resumes the fbdev console layer _before_ restoring the display, through calling fb_set_suspend. And fbcon does an immediate ->set_par, which in turn causes the same forced mode restore to happen.
Two concurrent modeset operations didn't lead to happiness. Fix this by delaying the fbcon resume until the end of the readeon resum functions.
v2: Fix up a bit of the spelling fail.
References: https://lkml.org/lkml/2014/5/29/1043 References: https://lkml.org/lkml/2014/5/2/388 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751 Tested-by: Ken Moffat zarniwhoop@ntlworld.com Cc: Alex Deucher alexdeucher@gmail.com Cc: Ken Moffat zarniwhoop@ntlworld.com Cc: Dave Airlie airlied@redhat.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/radeon/radeon_device.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 9aa1afd1786e..8f434c6c4540 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1533,11 +1533,6 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon)
radeon_restore_bios_scratch_regs(rdev);
- if (fbcon) { - radeon_fbdev_set_suspend(rdev, 0); - console_unlock(); - } - /* init dig PHYs, disp eng pll */ if (rdev->is_atom_bios) { radeon_atom_encoder_init(rdev); @@ -1562,6 +1557,12 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon) }
drm_kms_helper_poll_enable(dev); + + if (fbcon) { + radeon_fbdev_set_suspend(rdev, 0); + console_unlock(); + } + return 0; }
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Daniel Vetter