Setting the power state prior to restoring the display hardware leads to blank screens on some systems. Drop the power state set from dpm resume. The power state will get set as part of the mode set sequence. Also add an explicit power state set after mode set resume to cover PX and headless systems.
bug: https://bugzilla.kernel.org/show_bug.cgi?id=76761
Signed-off-by: Alex Deucher alexander.deucher@amd.com Cc: stable@vger.kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c | 6 ++---- drivers/gpu/drm/radeon/radeon_device.c | 5 +++++ drivers/gpu/drm/radeon/radeon_pm.c | 1 - 3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 998435d..baa1459 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -270,8 +270,6 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) switch (mode) { case DRM_MODE_DPMS_ON: radeon_crtc->enabled = true; - /* adjust pm to dpms changes BEFORE enabling crtcs */ - radeon_pm_compute_clocks(rdev); atombios_enable_crtc(crtc, ATOM_ENABLE); if (ASIC_IS_DCE3(rdev) && !ASIC_IS_DCE6(rdev)) atombios_enable_crtc_memreq(crtc, ATOM_ENABLE); @@ -289,10 +287,10 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) atombios_enable_crtc_memreq(crtc, ATOM_DISABLE); atombios_enable_crtc(crtc, ATOM_DISABLE); radeon_crtc->enabled = false; - /* adjust pm to dpms changes AFTER disabling crtcs */ - radeon_pm_compute_clocks(rdev); break; } + /* adjust pm to dpms */ + radeon_pm_compute_clocks(rdev); }
static void diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 9aa1afd..20bc5af 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1562,6 +1562,11 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon) }
drm_kms_helper_poll_enable(dev); + + /* set the power state here in case we are a PX system or headless */ + if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled) + radeon_pm_compute_clocks(rdev); + return 0; }
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 6fac8ef..304c476 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1068,7 +1068,6 @@ static void radeon_pm_resume_dpm(struct radeon_device *rdev) if (ret) goto dpm_resume_fail; rdev->pm.dpm_enabled = true; - radeon_pm_compute_clocks(rdev); return;
dpm_resume_fail:
Am 30.05.2014 18:40, schrieb Alex Deucher:
Setting the power state prior to restoring the display hardware leads to blank screens on some systems. Drop the power state set from dpm resume. The power state will get set as part of the mode set sequence. Also add an explicit power state set after mode set resume to cover PX and headless systems.
bug: https://bugzilla.kernel.org/show_bug.cgi?id=76761
Signed-off-by: Alex Deucher alexander.deucher@amd.com Cc: stable@vger.kernel.org
I've just added this to my 3.15 queue, but it looks like Linus is going to tag 3.15 tomorrow and Dave already send out his most likely last pull request.
Going to send out another pull request in the evening if I can get the VM crashes resolved as well, but I doubt it will be included.
Christian.
drivers/gpu/drm/radeon/atombios_crtc.c | 6 ++---- drivers/gpu/drm/radeon/radeon_device.c | 5 +++++ drivers/gpu/drm/radeon/radeon_pm.c | 1 - 3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 998435d..baa1459 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -270,8 +270,6 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) switch (mode) { case DRM_MODE_DPMS_ON: radeon_crtc->enabled = true;
/* adjust pm to dpms changes BEFORE enabling crtcs */radeon_pm_compute_clocks(rdev);@@ -289,10 +287,10 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) atombios_enable_crtc_memreq(crtc, ATOM_DISABLE); atombios_enable_crtc(crtc, ATOM_DISABLE); radeon_crtc->enabled = false;
/* adjust pm to dpms changes AFTER disabling crtcs */radeon_pm_compute_clocks(rdev);
/* adjust pm to dpms */
radeon_pm_compute_clocks(rdev); }
static void
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 9aa1afd..20bc5af 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1562,6 +1562,11 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon) }
drm_kms_helper_poll_enable(dev);
- /* set the power state here in case we are a PX system or headless */
- if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled)
radeon_pm_compute_clocks(rdev);- return 0; }
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 6fac8ef..304c476 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1068,7 +1068,6 @@ static void radeon_pm_resume_dpm(struct radeon_device *rdev) if (ret) goto dpm_resume_fail; rdev->pm.dpm_enabled = true;
radeon_pm_compute_clocks(rdev); return;
dpm_resume_fail:
I've just added this to my 3.15 queue, but it looks like Linus is going to tag 3.15 tomorrow and Dave already send out his most likely last pull request.
Going to send out another pull request in the evening if I can get the VM crashes resolved as well, but I doubt it will be included.
Since Linus is playing with the merge window overlap, I've taken this patch into my -fixes to send to him for the final one.
Please try and get a radeon tree asap for -next.
Dave.
Am 02.06.2014 05:39, schrieb Dave Airlie:
I've just added this to my 3.15 queue, but it looks like Linus is going to tag 3.15 tomorrow and Dave already send out his most likely last pull request.
Going to send out another pull request in the evening if I can get the VM crashes resolved as well, but I doubt it will be included.
Since Linus is playing with the merge window overlap, I've taken this patch into my -fixes to send to him for the final one.
OK. In this case I'm preparing another -fixes pull request for you, got two or three more patches that probably need CC stable as well.
Please try and get a radeon tree asap for -next.
Alex already prepared a drm-next-3.16-wip tree, but this one still needs a rebase and is also missing a couple of more things that I like to get into 3.16 as well.
Christian.
On Mon, Jun 2, 2014 at 4:10 AM, Christian König deathsimple@vodafone.de wrote:
Am 02.06.2014 05:39, schrieb Dave Airlie:
I've just added this to my 3.15 queue, but it looks like Linus is going to tag 3.15 tomorrow and Dave already send out his most likely last pull request.
Going to send out another pull request in the evening if I can get the VM crashes resolved as well, but I doubt it will be included.
Since Linus is playing with the merge window overlap, I've taken this patch into my -fixes to send to him for the final one.
OK. In this case I'm preparing another -fixes pull request for you, got two or three more patches that probably need CC stable as well.
Please try and get a radeon tree asap for -next.
Alex already prepared a drm-next-3.16-wip tree, but this one still needs a rebase and is also missing a couple of more things that I like to get into 3.16 as well.
Let me know what additional patches you wanted to put in and I'll put the tree up. I'm rebased and ready to go.
Alex
Am 02.06.2014 17:14, schrieb Alex Deucher:
On Mon, Jun 2, 2014 at 4:10 AM, Christian König deathsimple@vodafone.de wrote:
Am 02.06.2014 05:39, schrieb Dave Airlie:
I've just added this to my 3.15 queue, but it looks like Linus is going to tag 3.15 tomorrow and Dave already send out his most likely last pull request.
Going to send out another pull request in the evening if I can get the VM crashes resolved as well, but I doubt it will be included.
Since Linus is playing with the merge window overlap, I've taken this patch into my -fixes to send to him for the final one.
OK. In this case I'm preparing another -fixes pull request for you, got two or three more patches that probably need CC stable as well.
Please try and get a radeon tree asap for -next.
Alex already prepared a drm-next-3.16-wip tree, but this one still needs a rebase and is also missing a couple of more things that I like to get into 3.16 as well.
Let me know what additional patches you wanted to put in and I'll put the tree up. I'm rebased and ready to go.
Please merge my drm-fixes-3.15 branch and push the result to fdo first. The new module parameters need code from both sides to be properly apply able.
Christian.
Alex
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Christian König -
Dave Airlie