Bug 73567

Created attachment 91971 [details]
dmesg of latest intel-drm-nightly after boot

Created attachment 91972 [details]
dmesg of latest intel-drm-nightly after boot with ignore bpp clamp patch

Created attachment 91975 [details]
ASUS ux302la opregion dump

We've had to duplicate the hack in the hsw code:

commit 1021442098ee9328fdd4d113d63a3a7f2f40c37b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Nov 18 07:38:16 2013 +0100

    drm/i915: Replicate BIOS eDP bpp clamping hack for hsw

*** This bug has been marked as a duplicate of bug 71049 ***

BTW, kernel 3.13rc8 must be working.

(In reply to comment #5)
> BTW, kernel 3.13rc8 must be working.

I just tried 3.13-rc8 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/ and it is NOT working : blank screen on boot.

Strange ... Can you please attach a drm.debug=0xe dmesg from that kernel?

(In reply to comment #6)
> (In reply to comment #5)
> > BTW, kernel 3.13rc8 must be working.
> 
> I just tried 3.13-rc8 from
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/ and it is
> NOT working : blank screen on boot.

Are you the original reporter of this bug? If not, do you have an *identical* machine to the reporter?

(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > BTW, kernel 3.13rc8 must be working.
> > 
> > I just tried 3.13-rc8 from
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/ and it is
> > NOT working : blank screen on boot.
> 
> Are you the original reporter of this bug? If not, do you have an
> *identical* machine to the reporter?

I'm not the original reporter of the bug, I have an identical machine : UX302LG w/ the same issue: I'm the reporter of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544 that helped/led to this bugreport.

(In reply to comment #9)
> I'm not the original reporter of the bug, I have an identical machine :
> UX302LG w/ the same issue: I'm the reporter of
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544 that helped/led
> to this bugreport.

Thanks for verifying this, and apologies; we just have plenty of cases where people chime in with "me too" with totally irrelevant hardware and software.

(In reply to comment #10)
> (In reply to comment #9)
> > I'm not the original reporter of the bug, I have an identical machine :
> > UX302LG w/ the same issue: I'm the reporter of
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544 that helped/led
> > to this bugreport.
> 
> Thanks for verifying this, and apologies; we just have plenty of cases where
> people chime in with "me too" with totally irrelevant hardware and software.

This is very understandable, no worries.
I will try to get the dmesg output log using drm.debug=0xe unless somebody does it before me.

Created attachment 92047 [details]
dmesg of 3.13-rc8 on ux302lg with drm.debug=0xe

As requested, dmesg with debug activated using ux302LG and 3.13-rc8

Daniel, 

I'm already running drm-intel-nightly which includes that commit.
That particular hack does indeed run (see attached dmesg log at the beginning) but the panel is still blank. I saw the same hack at intel_dp_get_config, but in my machine intel_dp_get_config does not get called at all.

The culprit is clamping bpp from 24 to 18 bpp at intel_dp_compute_config. When the bpp clamping code is disabled and the panel runs at 24 bpp there are no more blank screen issues. 


(In reply to comment #4)
> We've had to duplicate the hack in the hsw code:
> 
> commit 1021442098ee9328fdd4d113d63a3a7f2f40c37b
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Mon Nov 18 07:38:16 2013 +0100
> 
>     drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
> 
> *** This bug has been marked as a duplicate of bug 71049 ***

(In reply to comment #5)
> BTW, kernel 3.13rc8 must be working.

With 3.13rc8 I See the same blank screen issues. Note that I'm running drm-intel-nightly already as well (dmesg log already attached at the beginning).

(In reply to comment #13)
> Daniel, 
> 
> I'm already running drm-intel-nightly which includes that commit.
> That particular hack does indeed run (see attached dmesg log at the
> beginning) but the panel is still blank. I saw the same hack at
> intel_dp_get_config, but in my machine intel_dp_get_config does not get
> called at all.
> 
> The culprit is clamping bpp from 24 to 18 bpp at intel_dp_compute_config.
> When the bpp clamping code is disabled and the panel runs at 24 bpp there
> are no more blank screen issues. 

Please try this on drm-intel-nightly, and report what the debug says:

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 74749c6..dbc5a16 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1491,6 +1491,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
                break;
        }
 
+       DRM_DEBUG_KMS("encoder type %d, pipe_bpp %d, vbt.edp_bpp %d, ddi ctl %08x\n",
+                     encoder->type, pipe_config->pipe_bpp,
+                     dev_priv->vbt.edp_bpp, temp);
+
        if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp_bpp &&
            pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
                /*

It prints out:

 [drm:intel_ddi_get_config], encoder type 8, pipe_bpp 18, vbt.edp_bpp 18, ddi ctl 82210002

(In reply to comment #0)
> Any sequence that turns off/on the panel (suspend/resume, modesetting)
> results in a blank screen.

Wait. Does this mean it works when you first boot it?

Does 'dmesg | grep intel_ddi_get_config' give you multiple results, with possibly different output?

(In reply to comment #17)
> Does 'dmesg | grep intel_ddi_get_config' give you multiple results, with
> possibly different output?

*with* the patch from comment #15, if that wasn't clear.

(In reply to comment #17)
> (In reply to comment #0)
> > Any sequence that turns off/on the panel (suspend/resume, modesetting)
> > results in a blank screen.
> 
> Wait. Does this mean it works when you first boot it?

Yes it works when I first boot it. Which BTW, only started working on boot after this patch in december:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=dff392dbd258381a6c3164f38420593f2d291e3b


> 
> Does 'dmesg | grep intel_ddi_get_config' give you multiple results, with
> possibly different output?

With drm-intel-nightly and patch from comment #15, I get a couple of results but they all look like this:

[drm:intel_ddi_get_config], encoder type 8, pipe_bpp 18, vbt.edp_bpp 18, ddi ctl 82210002

FWIW Asus has so far refused to provide any help, saying that they do not "support Linux". Getting a new UEFI to fix this is not looking good...

I just noticed the latest drm-intel-nightly (commit f27f16540be56813df2ebb8e1106dd5c258f07c3) has fixed the issue.

After bisecting, it seems the blank screen issues I was getting after modesetting or suspend/resume have been fixed starting from commit:

commit b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Dec 19 14:29:44 2013 -0200

    drm/i915: set the backlight panel delays registers to 1

(In reply to comment #21)
> I just noticed the latest drm-intel-nightly (commit
> f27f16540be56813df2ebb8e1106dd5c258f07c3) has fixed the issue.
> 
> After bisecting, it seems the blank screen issues I was getting after
> modesetting or suspend/resume have been fixed starting from commit:
> 
> commit b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date:   Thu Dec 19 14:29:44 2013 -0200
> 
>     drm/i915: set the backlight panel delays registers to 1

I'm slightly surprised by this outcome. Alberto, would it be too much trouble to double check with the commit before that, and then with that commit, to make sure it's this commit that really fixes the issue for you. Thanks.

I have to refute this:
trying to modset or suspend using intel-drm-nightly from 2014-01-26 doesn't work with my machine (UX302LG). 
Though I have screen from boot using the intel-drm-nightly kernels, for me the issue still is present whatever the branch.

(In reply to comment #22)
> (In reply to comment #21)
> > I just noticed the latest drm-intel-nightly (commit
> > f27f16540be56813df2ebb8e1106dd5c258f07c3) has fixed the issue.
> > 
> > After bisecting, it seems the blank screen issues I was getting after
> > modesetting or suspend/resume have been fixed starting from commit:
> > 
> > commit b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526
> > Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Date:   Thu Dec 19 14:29:44 2013 -0200
> > 
> >     drm/i915: set the backlight panel delays registers to 1
> 
> I'm slightly surprised by this outcome. Alberto, would it be too much
> trouble to double check with the commit before that, and then with that
> commit, to make sure it's this commit that really fixes the issue for you.
> Thanks.

I just double checked again and yes with the commit before b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526 - i.e this one:

commit 412b61d83a2d3e74527633097820db7510f97ce1
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jan 17 15:59:39 2014 +0200

    drm/i915: Fix new_config and new_enabled for load detect


suspend/resume and modesetting result in a black screen. 

Using b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526 there are no blank screen issues in my machine at least.

(In reply to comment #24)
> I just double checked again and yes with the commit before

Alberto, thanks for checking this.


(In reply to comment #23)
> I have to refute this:
> trying to modset or suspend using intel-drm-nightly from 2014-01-26 doesn't
> work with my machine (UX302LG). 
> Though I have screen from boot using the intel-drm-nightly kernels, for me
> the issue still is present whatever the branch.

tehownt@gmail.com, please try the patch from comment #15 and attach the dmesg. Thanks.

(In reply to comment #23)
> I have to refute this:
> trying to modset or suspend using intel-drm-nightly from 2014-01-26 doesn't
> work with my machine (UX302LG). 
> Though I have screen from boot using the intel-drm-nightly kernels, for me
> the issue still is present whatever the branch.

-nightly on that day was broken for a few hours, so please also retest with a new -nightly.

Created attachment 92927 [details]
dmesg of 2014-01-28 drm-intel-nightly on ux302LG with drm.debug=0xe

Tried with 2014-01-28 nightly and didn't work (screen on boot, blank on resume from suspend).
Output from dmesg with drm.debug=0xe added.

As for including the patch from comment #15 , I'm unfortunately not set up with a compile/build env on the machine. I can test quickly if I'm provided with a kernel that includes this patch though.

(In reply to comment #27)
> Tried with 2014-01-28 nightly and didn't work (screen on boot, blank on
> resume from suspend).
> Output from dmesg with drm.debug=0xe added.

Why "acpi_osi=" in kernel cmdline?

(In reply to comment #28)
> (In reply to comment #27)
> > Tried with 2014-01-28 nightly and didn't work (screen on boot, blank on
> > resume from suspend).
> > Output from dmesg with drm.debug=0xe added.
> 
> Why "acpi_osi=" in kernel cmdline?

Fixes a couple of other issues : Airplane mode key and Screen backlight control key (doesn't work otherwise, c.f. https://bugs.launchpad.net/ubuntu/+bug/1270661) Yeah, that laptop is a gift :)

(In reply to comment #29)
> (In reply to comment #28)
> > Why "acpi_osi=" in kernel cmdline?
> 
> Fixes a couple of other issues : Airplane mode key and Screen backlight
> control key (doesn't work otherwise, c.f.
> https://bugs.launchpad.net/ubuntu/+bug/1270661) Yeah, that laptop is a gift
> :)

Did you try the newer kernels without that, wrt this bug?

(In reply to comment #30)
> (In reply to comment #29)
> 
> Did you try the newer kernels without that, wrt this bug?

Yes, 2014-01-28 drm-intel-next & 3.13.0-5 (Ubuntu) both fail.

Created attachment 93205 [details] [review]
Patch adding quirk to avoid bpp clamping

Since we know that ignoring bpp clamping actually works (tehownt can confirm), can intel consider a quirk based patch for this laptop model as in this patch?

Thanks.

(In reply to comment #32)
> Created attachment 93205 [details] [review] [review]
> Patch adding quirk to avoid bpp clamping
> 
> Since we know that ignoring bpp clamping actually works (tehownt can
> confirm), can intel consider a quirk based patch for this laptop model as in
> this patch?
> 
> Thanks.

I can confirm that using custom i915.ko based on this patch under 3.13.0-5 fixes the issue, screen on boot & screen on resume work fine and stable.

So what can we do to move forward? Any thoughts on the quirk based solution I posted earlier?

I notice that the bug hasn't been updated in a while, a patch that fixes the issue exists and can be integrated in the same way as bug 71049 (quirk-based bpp clamping bypass).
Can this patch be reviewed & integrated so that we can consider the issue fixed with this laptop and move on ?

(In reply to comment #35)
> I notice that the bug hasn't been updated in a while, a patch that fixes the
> issue exists and can be integrated in the same way as bug 71049 (quirk-based
> bpp clamping bypass).

The fix for bug 71049 is specifically *not* quirk based. 

> Can this patch be reviewed & integrated so that we can consider the issue
> fixed with this laptop and move on ?

Adding quirks instead of finding the root cause is problematic in a few ways.

Only the users of a specific laptop can "move on". There will be others, and there will be no end to it. It's not likely that only a very specific machine would suffer from this. We wouldn't be able to move on.

Working around this on a quirk by quirk basis as the bug reports slowly come in, from a very select group of people, for a very limited selection of machines, is actually counterproductive to making the driver work properly for everybody.

With the quirks in, it's also quite hard to revert those and try to switch to a real fix when one is found. The quirked machines must not regress, but at the same time it's difficult to get testing feedback from the original reporters.

Thanks for your understanding and patience.

We've merged a number of patches that might affect this since the last comments. Please try recent drm-intel-nightly branch and report back. Thanks.

(In reply to comment #37)
> We've merged a number of patches that might affect this since the last
> comments. Please try recent drm-intel-nightly branch and report back. Thanks.

No blank screen issues in my UX302LA either at boot, or when mode setting or when suspend/resuming.

Tested via:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-04-11-trusty/

(In reply to comment #38)
> (In reply to comment #37)
> > We've merged a number of patches that might affect this since the last
> > comments. Please try recent drm-intel-nightly branch and report back. Thanks.
> 
> No blank screen issues in my UX302LA either at boot, or when mode setting or
> when suspend/resuming.
> 
> Tested via:
> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-04-11-
> trusty/

Will test & report for UX302LG asap.

Created attachment 97254 [details]
kernel 20140411 dmesg w/ drm.debug=0xe

Hello,

so far it works on the UX302LG, i've attached the dmesg with drm.debug=0xe enabled, I see the screen flashing black after grub but it works thereafter.

So one or some of our fixes has indeed fixed the bug. If anyone wants to reverse bisect from broken to first good, we'd be able to identify and backport the fix(es) to stable kernels.