Bug 59785

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?

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.

Created attachment 73593 [details]
Dmesg log file from 3.7.4

Includes a switch to the radeon and then back to the intel

Created attachment 73594 [details]
Xorg log for intel

Created attachment 73595 [details]
Xorg log for radeon

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.

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.

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.

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.

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.

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.

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.

Created attachment 73714 [details] [review]
Changes to intel_display.c that fixed the problem

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?

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.

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.

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.

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....

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.

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

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))

The previous change fixes this Bug on my hardware HP laptop with hybrids gpu (intel irolake / amd radeon)

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.

Created attachment 82989 [details] [review]
drm/i915: do not disable backlight on vgaswitcheroo switch off

All, please try the attached patch.

Testing feedback on the patch would be appreciated to move this bug forward. Thanks.

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!

(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 :-)

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