Bug 59785 - [dual-gpu regression] Display shuts off when switching to discrete graphics card
Summary: [dual-gpu regression] Display shuts off when switching to discrete graphics card
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Jani Nikula
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-24 05:31 UTC by David Mallon
Modified: 2017-07-24 22:59 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Git bisect log (2.45 KB, text/plain)
2013-01-24 05:31 UTC, David Mallon
no flags Details
Dmesg log file from 3.7.4 (181.32 KB, text/plain)
2013-01-24 17:07 UTC, David Mallon
no flags Details
Xorg log for intel (37.24 KB, text/plain)
2013-01-24 17:08 UTC, David Mallon
no flags Details
Xorg log for radeon (52.99 KB, text/plain)
2013-01-24 17:08 UTC, David Mallon
no flags Details
Changes to intel_display.c that fixed the problem (5.61 KB, patch)
2013-01-27 06:16 UTC, David Mallon
no flags Details | Splinter Review
Proposed fix (680 bytes, patch)
2013-01-29 21:20 UTC, David Mallon
no flags Details | Splinter Review
Don't clamp backlight when disabling on gen4+ (1.57 KB, patch)
2013-04-16 13:41 UTC, Daniel Vetter
no flags Details | Splinter Review
drm/i915: do not disable backlight on vgaswitcheroo switch off (2.15 KB, patch)
2013-07-25 11:02 UTC, Jani Nikula
no flags Details | Splinter Review

Description David Mallon 2013-01-24 05:31:21 UTC
Created attachment 73549 [details]
Git bisect log

I have an HP Envy 14 with a muxed intel/radeon graphics setup. After commit "[ea9d758d6ddb9f4bb9639619100743e8f5fa85a0] drm/i915: push commit_output_state past the crtc/encoder preparing" I now get a completely black (no backlight) screen when switching from the intel to the radeon card. I bisected between 3.6.11 and 3.7-rc1 and found the above mentioned commit to be the culprit. I attempted to revert the commit in the 3.7 tree, but too many other alterations had been made on top of it to successfully revert.
Comment 1 Daniel Vetter 2013-01-24 10:02:37 UTC
Can you please boot with drm.debug=0xe and attach your complete dmesg?

Also, when you switch back to intel, does the screen work again?
Comment 2 Chris Wilson 2013-01-24 16:19:43 UTC
Can you also please describe your configuration and what you expect to happen? iiuc, you have a muxed configuration sharing the LVDS so I am a little scared that we can affect the display state of the other gpu.
Comment 3 David Mallon 2013-01-24 17:07:17 UTC
Created attachment 73593 [details]
Dmesg log file from 3.7.4

Includes a switch to the radeon and then back to the intel
Comment 4 David Mallon 2013-01-24 17:08:03 UTC
Created attachment 73594 [details]
Xorg log for intel
Comment 5 David Mallon 2013-01-24 17:08:21 UTC
Created attachment 73595 [details]
Xorg log for radeon
Comment 6 David Mallon 2013-01-24 17:15:20 UTC
Switching back to the intel card does indeed turn the screen back on. My Envy 14 has an i5-460m with a radeon 5650m. As far as I can tell, it seems like the intel card drives the backlight control since prior to 3.7 I only had the single backlight controller in /sys/class/backlight. Just looking at the commit from the bisect I see two adds that I assume could potentially disable the control of the display output settings:

+ dev_priv->display.crtc_disable(&intel_crtc->base);

+ for_each_encoder_on_crtc(dev, crtc, encoder)
+   encoder->disable(encoder);

Thanks for the quick response, and let me know if there is more info I can supply.
Comment 7 Daniel Vetter 2013-01-24 21:01:09 UTC
Well, we do shut down the backlight when disabling the LVDS output, at least the intel backlight. To confirm that theory, can you please list all the backlight controllers you have in /sys/class/backlight and which ones are affecting your screen brightness? Please check both when the intel and when the radeon gpu is enabled with the mux.
Comment 8 David Mallon 2013-01-24 22:40:51 UTC
I used a script to try setting both the radeon and intel backlights to max after switching to the radeon, and still no change. It seems almost like the panel is being completely disabled when the intel card shuts off.
Comment 9 David Mallon 2013-01-25 05:55:50 UTC
I should also add that in 3.6.11 I only have an intel backlight, but on 3.7.4 I have both radeon and intel backlights. Only the intel backlight affects brightness when the intel card is enabled, and neither affects the brightness when the radeon is enabled.
Comment 10 Chris Wilson 2013-01-25 11:13:35 UTC
That sounds like the root cause of the issue - that you have no acpi (or mux?) driver for the backlight that knows how to route it through the mux.
Comment 11 David Mallon 2013-01-25 19:06:37 UTC
Was the lvds (or at least the encoders/crtc) left enabled prior to the commit from my bisect log? If so, I can attempt to remove the disable instruction from intel_display.c to see if it fixes the problem. Unless the git bisect was inaccurate, it must be something fairly simple that originally triggered the issue since the commit in question is rather small. I am fairly new to the kernel code, but I am willing to give some things a shot if you guys can help point me in the right direction.
Comment 12 David Mallon 2013-01-27 06:15:54 UTC
I managed to fix the issue by reverting the ironlake_crtc_disable and ironlake_crtc_enable functions in intel_display.c back to the state they were in for 3.6.11. The attached patch shows what I ended up changing to get this to compile with the 3.7.4 tree. The unfortunate part is that I don't know enough about the internal workings to determine the specific issue, but maybe you guys can interpret why these changes helped.
Comment 13 David Mallon 2013-01-27 06:16:35 UTC
Created attachment 73714 [details] [review]
Changes to intel_display.c that fixed the problem
Comment 14 Daniel Vetter 2013-01-27 16:21:43 UTC
Can you please grab the latest git of http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ and then attach the output of intel_reg_dumper for both a working and a broken kernel when the radeon gpu is enabled and the intel gpu disabled with the mux?
Comment 15 David Mallon 2013-01-29 21:20:47 UTC
Created attachment 73875 [details] [review]
Proposed fix

I systematically tested the previous patch to find the specific line changes that had caused the problem. This patch isolates two changes that, when reverted, fix the issue.
Comment 16 Daniel Vetter 2013-01-29 22:34:52 UTC
Hm, that'll break pretty horribly, and I think we're looking at the wrong things.

Can you play around whether just disabling the callbacks in intel_lvds.c for these function pointers (and not for all the other encoders helps)? I.e. something like:

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index 8c61876..c1586d3 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -203,6 +203,8 @@ static void intel_disable_lvds(struct intel_encoder *encoder)
        struct drm_i915_private *dev_priv = dev->dev_private;
        u32 ctl_reg, stat_reg;
 
+       return;
+
        if (HAS_PCH_SPLIT(dev)) {
                ctl_reg = PCH_PP_CONTROL;
                stat_reg = PCH_PP_STATUS;

If that still works as a workaround, please test whether writing the ctl_reg or disabling the backlight is the crucial piece.

I guess we just need to drill down until we have the root-cause like that, then either fix it or apply a quirk. But since you seem to be good at messsing with the source, that should be doable.
Comment 17 David Mallon 2013-01-30 00:10:48 UTC
Good call on that one. It was in fact the line in intel_lvds.c that shuts off the backlight that is the culprit. Just commenting out that one line fixed all.
Comment 18 Andreas Demmer 2013-02-15 13:56:54 UTC
What is the current state? 

I face the same problem (see: https://bugzilla.novell.com/show_bug.cgi?id=802617) and git cloned xf86-driver-intel but there is no intel_lvds.c to fix? Any help is appreciated....
Comment 19 Daniel Vetter 2013-02-15 17:39:10 UTC
David, can you please attach your latest hack (the one which comments out the backlight disabling) for reference?

Andreas: The problem is in the kernel, you need to patch that one. Also, if you don't have the exact same machine there's a good chance that you have a different bug (but similar symptoms). Please open a new bug report in that case, we can easily close duplicates once we have enough evidence, but untangling different bugs mixed into one report is far more messy.
Comment 20 Andreas Demmer 2013-02-19 13:46:50 UTC
Actually, I do have extactly the same machine! ;-)

Model: HP Envy 14-1010eg
Integrated graphics: Intel Arrandale, i915 driver
Discrete graphics: ATI Radeon HD 5650

Kernel: Linux envy 3.7.7-1.2-desktop #1 SMP PREEMPT Wed Feb 13 09:33:05 UTC 2013 (d55bd47) x86_64 x86_64 x86_64 GNU/Linux
Comment 21 Aximab 2013-04-13 21:21:20 UTC
Here is the reference david Mallon should have given
regards


# git diff  HEAD drivers/gpu/drm/i915/intel_lvds.c: 



--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -217,7 +217,7 @@ static void intel_disable_lvds(struct intel_encoder
*encoder)
                stat_reg = PP_STATUS;
        }

-       intel_panel_disable_backlight(dev);
+/*        intel_panel_disable_backlight(dev); */

        I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
        if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
Comment 22 Aximab 2013-04-13 21:54:22 UTC
The previous change fixes this Bug on my hardware HP laptop with hybrids gpu (intel irolake / amd radeon)
Comment 23 Daniel Vetter 2013-04-16 13:41:07 UTC
Created attachment 78082 [details] [review]
Don't clamp backlight when disabling on gen4+

Can everyone affected by this bug please test the attached patch? It hopefully fixes the backlight issues without causing problems on other systems - since on most systems we really want to disable the backlight.
Comment 24 Jani Nikula 2013-07-25 11:02:19 UTC
Created attachment 82989 [details] [review]
drm/i915: do not disable backlight on vgaswitcheroo switch off

All, please try the attached patch.
Comment 25 Jani Nikula 2013-07-26 11:56:57 UTC
Testing feedback on the patch would be appreciated to move this bug forward. Thanks.
Comment 26 sfievet 2013-07-30 19:51:07 UTC
I have a 3820TG intel Ironlake/radeon 6550M hybrid laptop, and I am affected by this bug too. I tried your "drm/i915: do not disable backlight on vgaswitcheroo switch off" patch on kernel 3.11-rc3 and it works.

I have been able to switch from integrated to discrete and back with success.
...But only 3 times :-( 

I did the following sequence :
step #1 : login to X on integrated (intel HD)
    cat /sys/kernel/debug/vgaswitcheroo/switch 
    0:DIS-Audio: :Pwr:0000:02:00.1
    1:IGD:+:Pwr:0000:00:02.0
    2:DIS: :Pwr:0000:02:00.0
    echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch

step #2 : login to X on discrete (radeon 6550M)
    cat /sys/kernel/debug/vgaswitcheroo/switch
    0:DIS-Audio: :Pwr:0000:02:00.1
    1:IGD: :Off:0000:00:02.0
    2:DIS:+:Pwr:0000:02:00.0
    echo DIGD > /sys/kernel/debug/vgaswitcheroo/switch

step #3 : login to X on integrated (intel HD)
    cat /sys/kernel/debug/vgaswitcheroo/switch
    0:DIS-Audio: :Off:0000:02:00.1
    1:IGD:+:Pwr:0000:00:02.0
    2:DIS: :Off:0000:02:00.0
    echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch

This time the radeon messes up the display immediately, i.e. it happens before I logout from X. But that's a nice improvement!
Comment 27 sfievet 2013-08-05 20:14:35 UTC
(In reply to comment #26)

I opened a dedicated kernel bug report for my own problem here : https://bugzilla.kernel.org/show_bug.cgi?id=60606.
Long story short, my issue is likely HW specific and someone found a workaround which actually works for me as well, even for multiple switches :-)
Comment 28 Daniel Vetter 2013-08-07 08:30:20 UTC
Patch is merged to drm-intel-fixes:

commit 428cf5a505c5c81789ad0a7551ba7644ff3d1523
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Jul 25 14:31:30 2013 +0300

    drm/i915: do not disable backlight on vgaswitcheroo switch off


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.