Bug 65995

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

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 */

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

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>

Created attachment 81388 [details]
intel_reg_dumper without i915

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.

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

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

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

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.

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

What's the full model # for this machine?

(In reply to comment #12)
> What's the full model # for this machine?

Acer: V3-772G-747a4G75Makk
Model NO: VA73

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.

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

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

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.

(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"?

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

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.

I forgot to add that acpi_backlight=vendor is required for my panel's behavior, and it is running on the i915 module.

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

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.

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

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

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.

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.

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?

We have shipped that machine to Todd for debugging. Todd, any updated?

No longer an issue per Gordon. Closing.