Bug 65995 - [HSW mobile Acer notebook] eDP can't light up in boot to text mode
[HSW mobile Acer notebook] eDP can't light up in boot to text mode
Status: CLOSED WONTFIX
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
Other All
: high critical
Assigned To: Todd Previte
Intel GFX Bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-21 06:27 UTC by shui yangwei
Modified: 2014-03-25 15:01 UTC (History)
2 users (show)

See Also:


Attachments
dmesg: eDP can't light up when machine booting up (95.13 KB, text/plain)
2013-06-21 06:27 UTC, shui yangwei
no flags Details
intel_reg_dumper with i915 loaded (10.09 KB, text/plain)
2013-06-25 06:23 UTC, shui yangwei
no flags Details
intel_reg_dumper without i915 (10.13 KB, text/plain)
2013-06-25 06:24 UTC, shui yangwei
no flags Details
dmesg: eDP can't light up and there's error && call trace (98.30 KB, text/plain)
2013-09-17 01:58 UTC, shui yangwei
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description shui yangwei 2013-06-21 06:27:27 UTC
Created attachment 81148 [details]
dmesg: eDP can't light up when machine booting up

Environment:
---------------------
HW info: 
Acer Haswell Notebook Aspire V3 772G 17.3 ; 
Host bridge ID=0x0c04 (rev 06);
VGA ID=0x0416 (rev06);
CPU: i7-4702MQ 2.2GHz; 
BIOS:v1.04 MEM: 4G ;

Kernel: (drm-intel-nightly)19b2dbde5732170a03bd82cc8bd442cf88d856f7
Some additional commit info:
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jun 12 10:15:12 2013 +0100

    drm/i915: Restore fences after resume and GPU resets

Description:
---------------------
I have tried many kernels, when machine boot up, eDP can display well in BIOS, but failed to display after system finished initialized. If I removed i915, eDP can display again.

The followed phenomenon:
1. eDP failed to display if boot to level 3.
2. eDP light up again by start X(but it need to connect another display pipe).
Comment 1 Daniel Vetter 2013-06-24 16:23:59 UTC
Can you please attach the intel_reg_dumper output for both the case when i915 is loaded (broken config) and when it is not loaded (working config from bios)?
Comment 2 Jesse Barnes 2013-06-25 00:53:18 UTC
Dumb patch to try:

--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3064,7 +3064,7 @@ intel_dp_init_connector(struct intel_digital_port *intel_d
                        type = DRM_MODE_CONNECTOR_eDP;
                break;
        case PORT_D:
-               if (HAS_PCH_SPLIT(dev) && intel_dpd_is_edp(dev))
+               if ((HAS_PCH_SPLIT(dev) && intel_dpd_is_edp(dev)) || 1)
                        type = DRM_MODE_CONNECTOR_eDP;
                break;
        default:        /* silence GCC warning */
Comment 3 shui yangwei 2013-06-25 05:40:54 UTC
(In reply to comment #2)
> Dumb patch to try:
> 
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3064,7 +3064,7 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_d
>                         type = DRM_MODE_CONNECTOR_eDP;
>                 break;
>         case PORT_D:
> -               if (HAS_PCH_SPLIT(dev) && intel_dpd_is_edp(dev))
> +               if ((HAS_PCH_SPLIT(dev) && intel_dpd_is_edp(dev)) || 1)
>                         type = DRM_MODE_CONNECTOR_eDP;
>                 break;
>         default:        /* silence GCC warning */

Test with -next-queued latest:
--------------------------------
commit 1acd12dc0d6a20f6bc7c6c7f2ef7119e15d3fe64

    drm/i915: Introduce an HAS_IPS() macro

    Follow the trend and don't code conditions with platforms but with
    features.

    Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This patch can't append directly, then I modify the change manually. And the test result is the same with before.
Comment 4 shui yangwei 2013-06-25 06:23:27 UTC
Created attachment 81387 [details]
intel_reg_dumper with i915 loaded

(In reply to comment #1)
> Can you please attach the intel_reg_dumper output for both the case when
> i915 is loaded (broken config) and when it is not loaded (working config
> from bios)?

OK, I attached the intel_reg_dumper output here.

Test with -next-queued latest:
--------------------------------
commit 1acd12dc0d6a20f6bc7c6c7f2ef7119e15d3fe64

    drm/i915: Introduce an HAS_IPS() macro

    Follow the trend and don't code conditions with platforms but with
    features.

    Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 5 shui yangwei 2013-06-25 06:24:58 UTC
Created attachment 81388 [details]
intel_reg_dumper without i915
Comment 6 Chris Wilson 2013-06-25 08:50:24 UTC
The BIOS is not driving the eDP natively, but through the VGA plane. (Using low res modes, scaling up, and importantly using the PIPE_A transcoder rather than PIPE_EDP). So I don't think it is comparable.

If the reg dump is correct, the panel is 18bpp, but the pipe is setup to supply 24bpp, which seems suspicious.
Comment 7 Chris Wilson 2013-06-25 16:53:56 UTC
Possibly related bug https://bugzilla.kernel.org/show_bug.cgi?id=59841 with a hack:


diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 24a44ed..3ad6bef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -102,7 +102,7 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
 static int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
-       return (pixel_clock * bpp + 9) / 10;
+       return (pixel_clock * bpp + 9) / 10 * 40 / 39;
 }

 static int
Comment 8 shui yangwei 2013-06-26 01:50:50 UTC
(In reply to comment #7)
> Possibly related bug https://bugzilla.kernel.org/show_bug.cgi?id=59841 with
> a hack:
> 
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 24a44ed..3ad6bef 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -102,7 +102,7 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
>  static int
>  intel_dp_link_required(int pixel_clock, int bpp)
>  {
> -       return (pixel_clock * bpp + 9) / 10;
> +       return (pixel_clock * bpp + 9) / 10 * 40 / 39;
>  }
> 
>  static int

I tried this patch on latest -next-queued, and I find issue also exists. I don't think this is related to the bug you give. When I start X and with another pipe connected, then eDP could light up.
Comment 9 shui yangwei 2013-06-28 06:28:12 UTC
A new find:
When resume from S3, eDP can light up with text mode. You can get detail S3 related dmesg from the bug I list below:
Bug 66296 - [HSW mobile] Resume from S3 cause "Call Trace" on new acer product
Comment 10 Daniel Vetter 2013-07-02 08:11:48 UTC
Can you please check the patches from https://bugs.freedesktop.org/show_bug.cgi?id=66294#c5

Maybe this is another case of the Windows 8 backlight fallout.
Comment 11 shui yangwei 2013-07-02 08:20:46 UTC
(In reply to comment #10)
> Can you please check the patches from
> https://bugs.freedesktop.org/show_bug.cgi?id=66294#c5
> 
> Maybe this is another case of the Windows 8 backlight fallout.

These two bug is not related, I'm just tested both of the bugs on Acer, and the kernel patches also been tested on this machine, this issue always exists. Because eDP displayed well if starting X, but failed to light up with text mode.
Comment 12 Jesse Barnes 2013-07-16 00:16:35 UTC
What's the full model # for this machine?
Comment 13 shui yangwei 2013-07-16 03:26:29 UTC
(In reply to comment #12)
> What's the full model # for this machine?

Acer: V3-772G-747a4G75Makk
Model NO: VA73
Comment 14 Todd Previte 2013-08-06 14:53:41 UTC
I have not been able to reproduce this issue on my HSW ULT using kernels from stable, -next and torvalds. Will continue to look for this issue and investigate further should it arise.
Comment 15 shui yangwei 2013-08-07 00:47:12 UTC
(In reply to comment #14)
> I have not been able to reproduce this issue on my HSW ULT using kernels
> from stable, -next and torvalds. Will continue to look for this issue and
> investigate further should it arise.

It's an unique issue on this Acer product. And this issue unable to reproduce on other HSW machines, include HSW ULT, mobile and desktop.
Comment 16 Todd Previte 2013-08-16 21:09:48 UTC
In that case, it might be necessary for us to get one of these units sent to us here. I'll see what I can do from here until we have one in-house
Comment 17 Todd Previte 2013-08-16 21:09:58 UTC
In that case, it might be necessary for us to get one of these units sent to us here. I'll see what I can do from here until we have one in-house.
Comment 18 Paulo Zanoni 2013-08-19 14:35:43 UTC
(In reply to comment #0)
> Created attachment 81148 [details]
> dmesg: eDP can't light up when machine booting up
> 
> Environment:
> ---------------------
> HW info: 
> Acer Haswell Notebook Aspire V3 772G 17.3 ; 
> Host bridge ID=0x0c04 (rev 06);
> VGA ID=0x0416 (rev06);
> CPU: i7-4702MQ 2.2GHz; 
> BIOS:v1.04 MEM: 4G ;
> 
> Kernel: (drm-intel-nightly)19b2dbde5732170a03bd82cc8bd442cf88d856f7
> Some additional commit info:
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Jun 12 10:15:12 2013 +0100
> 
>     drm/i915: Restore fences after resume and GPU resets
> 
> Description:
> ---------------------
> I have tried many kernels, when machine boot up, eDP can display well in
> BIOS, but failed to display after system finished initialized. If I removed
> i915, eDP can display again.
> 
> The followed phenomenon:
> 1. eDP failed to display if boot to level 3.
> 2. eDP light up again by start X(but it need to connect another display
> pipe).

The last time I saw a problem with such description on my machine, it was a Backlight bug.

What if you boot to level 3, then start X, then SSH to the machine and "DISPLAY=:0 xrandr --output eDP1 --set BACKLIGHT 15"?
Comment 19 shui yangwei 2013-08-20 01:27:33 UTC
(In reply to comment #18)
> (In reply to comment #0)
> > Description:
> > ---------------------
> > I have tried many kernels, when machine boot up, eDP can display well in
> > BIOS, but failed to display after system finished initialized. If I removed
> > i915, eDP can display again.
> > 
> > The followed phenomenon:
> > 1. eDP failed to display if boot to level 3.
> > 2. eDP light up again by start X(but it need to connect another display
> > pipe).
> 
> The last time I saw a problem with such description on my machine, it was a
> Backlight bug.
> 
> What if you boot to level 3, then start X, then SSH to the machine and
> "DISPLAY=:0 xrandr --output eDP1 --set BACKLIGHT 15"?

I tried the steps as you said, and eDP is also unlighted.
Comment 20 Trevor Bortins 2013-08-20 17:32:05 UTC
This all sounds remarkably similar to my issue on the new Acer Aspire S7-392 with the Haswell HD 4400 and a 1920x1080 touchscreen--I assume it's IPS, it's really nice-looking.

I've been able to get it to run every resolution but its native one when X starts.  It will display on boot on these kernels:

1. http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11-rc1-saucy/
(but doesn't work on rc2)
2. http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2013-08-08-saucy/
(but doesn't work on the 2013-08-09 kernel)

So something in those time periods regressed.  I'm not sure what kernel that "drm-next" one is, because the Ubuntu site also has a "drm-intel-next" folder.  No idea what they're doing.

I partially lied.  It will display fine on its native resolution in a particular case: if you boot up into the black screen on any "non-working" kernel, like 3.11-rc5 or -rc6, you can log in and xrandr to a different resolution and it turns on just fine--but you must switch to tty, then back to X for the backlight to turn on.

I can open a new bug if this seems different to you guys.  I'm happy to provide whatever logs are required here.
Comment 21 Trevor Bortins 2013-08-20 17:32:57 UTC
I forgot to add that acpi_backlight=vendor is required for my panel's behavior, and it is running on the i915 module.
Comment 22 shui yangwei 2013-08-21 01:56:45 UTC
(In reply to comment #21)
> I forgot to add that acpi_backlight=vendor is required for my panel's
> behavior, and it is running on the i915 module.

I'm a little confused about your description. I think you can file a new bug, and paste the phenomenon of what you caught, then give us the bug's link here. We are all tested on fedora, and can't find a workable kernel. I'm also appreciate you can test it on fedora, then assure whether these two machine really reflect the same issue.
Comment 23 Todd Previte 2013-08-26 21:37:35 UTC
I logged in and took a look around the logs. Can you try using drm-intel-nightly and see if the behavior exists there? Also, there are some call traces in the logs that were not mentioned here. I'd like to see if those persist as well.
Comment 24 Guang Yang 2013-08-28 02:55:45 UTC
(In reply to comment #23)
> I logged in and took a look around the logs. Can you try using
> drm-intel-nightly and see if the behavior exists there? Also, there are some
> call traces in the logs that were not mentioned here. I'd like to see if
> those persist as well.
Thx, Todd,The eDP still can't work after booting with drm-intel-nightly kernel. And after rebooting, I can't find any call traces in logs.
Comment 25 Paulo Zanoni 2013-09-16 17:58:11 UTC
What happens if you try this patch?

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8c70a83..df49828 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -795,11 +795,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
        /* Walk through all bpp values. Luckily they're all nicely spaced with 2
         * bpc in between. */
        bpp = pipe_config->pipe_bpp;
-       if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) {
-               DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided %i\n",
-                             dev_priv->vbt.edp_bpp);
-               bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);
-       }

        for (; bpp >= 6*3; bpp -= 2*3) {
                mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
Comment 26 shui yangwei 2013-09-17 01:58:48 UTC
Created attachment 85943 [details]
dmesg: eDP can't light up and there's error && call trace

(In reply to comment #25)
> What happens if you try this patch?
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 8c70a83..df49828 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -795,11 +795,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>         /* Walk through all bpp values. Luckily they're all nicely spaced
> with 2
>          * bpc in between. */
>         bpp = pipe_config->pipe_bpp;
> -       if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) {
> -               DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided
> %i\n",
> -                             dev_priv->vbt.edp_bpp);
> -               bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);
> -       }
> 
>         for (; bpp >= 6*3; bpp -= 2*3) {
>                 mode_rate = intel_dp_link_required(adjusted_mode->clock,
> bpp);


Applying this patch on latest -next-queued kernel, this issue also exists. I append the dmesg here.
Comment 27 Todd Previte 2013-11-11 23:24:36 UTC
There was some confusion as to the nature and circumstances for this particular issue that have been resolved. That sad, I can reliably reproduce this issue on the Acer notebook so I expect to have an update with additional information soon.
Comment 28 Paulo Zanoni 2013-12-05 13:02:02 UTC
We added a few workarounds and fixes since the last time you tested. Could you please test drm-intel-nightly again and confirm if the bug still exists?
Comment 29 Guang Yang 2013-12-06 01:18:53 UTC
We have shipped that machine to Todd for debugging. Todd, any updated?
Comment 30 Todd Previte 2014-03-25 15:01:40 UTC
No longer an issue per Gordon. Closing.