3.18.0-rc3: i915: eDP connected Display stays blank

3.18.0-rc3: i915: eDP connected Display stays blank

[Arnd Hannemann]

Hi,

I have a Thinkpad T440s (Haswell) connected to two additional Monitors
via a Docking Station (MST).

During Bootup all three displays work, even when X is started.
However, if the laptop display is turned off once (either because of
power saving, or via xrandr), it fails to "come back".
That is if I try to re-enable it the Display stays blank.
I believe this used to work in 3.17.

Here is the xrandr Ouput of the edp, when its enabled (but staying blank):
Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm
   1920x1080      60.0*+   59.9

here is the debug output, while trying to enable it:


[  416.314290] [drm:drm_mode_setcrtc] [CONNECTOR:19:eDP-1]
[  416.314294] [drm:intel_crtc_set_config] [CRTC:12] [FB:149] #connectors=1 (x y) (0 0)
[  416.314299] [drm:intel_set_config_compute_mode_changes] inactive crtc, full mode set
[  416.314303] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:12], mode_changed=1, fb_changed=1
[  416.314305] [drm:intel_modeset_stage_output_state] encoder changed, full mode switch
[  416.314309] [drm:intel_modeset_stage_output_state] [CONNECTOR:19:eDP-1] to [CRTC:12]
[  416.314312] [drm:intel_modeset_stage_output_state] [CONNECTOR:39:DP-3] to [CRTC:8]
[  416.314315] [drm:intel_modeset_stage_output_state] [CONNECTOR:43:DP-4] to [CRTC:16]
[  416.314317] [drm:intel_modeset_stage_output_state] crtc changed, full mode switch
[  416.314321] [drm:intel_modeset_stage_output_state] crtc enabled, full mode switch
[  416.314325] [drm:intel_modeset_affected_pipes] set mode pipe masks: modeset: 2, prepare: 2, disable: 0
[  416.314329] [drm:connected_sink_compute_bpp] [CONNECTOR:19:eDP-1] checking for sink bpp constrains
[  416.314332] [drm:connected_sink_compute_bpp] clamping display bpp (was 24) to EDID reported max of 18
[  416.314337] [drm:intel_dp_compute_config] DP link computation with max lane count 2 max bw 0a pixel clock 140100KHz
[  416.314341] [drm:intel_dp_compute_config] DP link bw 0a lane count 2 clock 270000 bpp 18
[  416.314343] [drm:intel_dp_compute_config] DP link bw required 252180 available 432000
[  416.314347] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 18, dithering: 1
[  416.314351] [drm:intel_dump_pipe_config] [CRTC:12][modeset] config for pipe B
[  416.314353] [drm:intel_dump_pipe_config] cpu_transcoder: D
[  416.314355] [drm:intel_dump_pipe_config] pipe bpp: 18, dithering: 1
[  416.314359] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0
[  416.314363] [drm:intel_dump_pipe_config] dp: 1, gmch_m: 4896849, gmch_n: 8388608, link_m: 272047, link_n: 524288, tu: 64
[  416.314392] [drm:intel_dump_pipe_config] dp: 1, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0
[  416.314406] [drm:intel_dump_pipe_config] requested mode:
[  416.314422] [drm:drm_mode_debug_printmodeline] Modeline 0:"" 0 140100 1920 1980 2016 2092 1080 1083 1088 1116 0x0 0x9
[  416.314435] [drm:intel_dump_pipe_config] adjusted mode:
[  416.314453] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 140100 1920 1980 2016 2092 1080 1083 1088 1116 0x48 0x9
[  416.314468] [drm:intel_dump_crtc_timings] crtc timings: 140100 1920 1980 2016 2092 1080 1083 1088 1116, type: 0x48 flags: 0x9
[  416.314482] [drm:intel_dump_pipe_config] port clock: 270000
[  416.314496] [drm:intel_dump_pipe_config] pipe src size: 1920x1080
[  416.314510] [drm:intel_dump_pipe_config] gmch pfit: control: 0x00000000, ratios: 0x00000000, lvds border: 0x00000000
[  416.314521] [drm:intel_dump_pipe_config] pch pfit: pos: 0x00000000, size: 0x00000000, disabled
[  416.314524] [drm:intel_dump_pipe_config] ips: 0
[  416.314527] [drm:intel_dump_pipe_config] double wide: 0
[  416.314568] [drm:intel_edp_panel_on] Turn eDP power on
[  416.314575] [drm:wait_panel_power_cycle] Wait for panel power cycle
[  416.314585] [drm:wait_panel_status] mask b800000f value 00000000 status 00000000 control abcd0008
[  416.314591] [drm:wait_panel_status] Wait complete
[  416.314599] [drm:wait_panel_on] Wait for panel power on
[  416.314606] [drm:wait_panel_status] mask b000000f value 80000008 status 0000000a control abcd000b
[  416.522545] [drm:wait_panel_status] Wait complete
[  416.523689] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[  416.524311] [drm:intel_dp_start_link_train] clock recovery OK
[  416.525224] [drm:intel_dp_complete_link_train] Channel EQ done. DP Training successful
[  416.525528] [drm:intel_edp_backlight_on]
[  416.525533] [drm:intel_panel_enable_backlight] pipe B
[  416.525541] [drm:intel_panel_actually_set_backlight] set backlight PWM = 10
[  416.530518] [drm:intel_edp_psr_match_conditions] PSR disable by flag
[  416.538553] [drm:ironlake_update_primary_plane] Writing base 030B0000 00000000 0 0 15360
[  416.538575] [drm:intel_connector_check_state] [CONNECTOR:19:eDP-1]
[  416.538584] [drm:intel_connector_check_state] [CONNECTOR:39:DP-3]
[  416.538587] [drm:intel_connector_check_state] [CONNECTOR:43:DP-4]
[  416.538590] [drm:check_encoder_state] [ENCODER:18:TMDS-18]
[  416.538594] [drm:check_encoder_state] [ENCODER:26:TMDS-26]
[  416.538597] [drm:check_encoder_state] [ENCODER:28:DP MST-28]
[  416.538599] [drm:check_encoder_state] [ENCODER:29:DP MST-29]
[  416.538602] [drm:check_encoder_state] [ENCODER:30:DP MST-30]
[  416.538604] [drm:check_encoder_state] [ENCODER:33:TMDS-33]
[  416.538607] [drm:check_encoder_state] [ENCODER:35:DP MST-35]
[  416.538610] [drm:check_encoder_state] [ENCODER:36:DP MST-36]
[  416.538612] [drm:check_encoder_state] [ENCODER:37:DP MST-37]
[  416.538615] [drm:check_crtc_state] [CRTC:8]
[  416.538626] [drm:check_crtc_state] [CRTC:12]
[  416.538636] [drm:check_crtc_state] [CRTC:16]
[  416.538646] [drm:check_shared_dpll_state] WRPLL 1
[  416.538649] [drm:check_shared_dpll_state] WRPLL 2
[  416.538699] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=851/851
[  416.538702] [drm:intel_panel_actually_set_backlight] set backlight PWM = 851
[  416.538835] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=851/851
[  416.538840] [drm:intel_panel_actually_set_backlight] set backlight PWM = 851
[  416.538848] [drm:intel_edp_backlight_power] panel power control backlight disable
[  416.742563] [drm:add_framebuffer_internal] [FB:156]
[  419.195100] [drm:edp_panel_vdd_off_sync] Turning eDP VDD off
[  419.195112] [drm:edp_panel_vdd_off_sync] PP_STATUS: 0x80000008 PP_CONTROL: 0xabcd0003


I'm happy to provide further input.

Best Regards
Arnd
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3.18.0-rc3: i915: eDP connected Display stays blank

[Jani Nikula]

On Thu, 06 Nov 2014, Arnd Hannemann <arnd@arndnet.de> wrote:
> Hi,
>
> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
> via a Docking Station (MST).
>
> During Bootup all three displays work, even when X is started.
> However, if the laptop display is turned off once (either because of
> power saving, or via xrandr), it fails to "come back".
> That is if I try to re-enable it the Display stays blank.
> I believe this used to work in 3.17.
>
> Here is the xrandr Ouput of the edp, when its enabled (but staying blank):
> Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
> eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm
>    1920x1080      60.0*+   59.9
>
> here is the debug output, while trying to enable it:
>

...

> [  416.538848] [drm:intel_edp_backlight_power] panel power control backlight disable
>
>
> I'm happy to provide further input.

What does cat /sys/class/backlight/intel_backlight/bl_power say? What if
you echo 0 there?

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 3.18.0-rc3: i915: eDP connected Display stays blank

[Arnd Hannemann]

Hi,

thanks for your quick response.

Am 06.11.2014 um 10:39 schrieb Jani Nikula:
> On Thu, 06 Nov 2014, Arnd Hannemann <arnd@arndnet.de> wrote:
>> Hi,
>>
>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>> via a Docking Station (MST).
>>
>> During Bootup all three displays work, even when X is started.
>> However, if the laptop display is turned off once (either because of
>> power saving, or via xrandr), it fails to "come back".
>> That is if I try to re-enable it the Display stays blank.
>> I believe this used to work in 3.17.
>>
>> Here is the xrandr Ouput of the edp, when its enabled (but staying blank):
>> Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
>> eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm
>>    1920x1080      60.0*+   59.9
>>
>> here is the debug output, while trying to enable it:
>>
> 
> ...
> 
>> [  416.538848] [drm:intel_edp_backlight_power] panel power control backlight disable
>>
>>
>> I'm happy to provide further input.
> 
> What does cat /sys/class/backlight/intel_backlight/bl_power say? What if

root@kallisto:~# cat /sys/class/backlight/intel_backlight/bl_power
1

> you echo 0 there?

:-) Works my display comes back, when I echo 0 there.

Is user-space doing something wrong here?

Best regards
Arnd

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: 3.18.0-rc3: i915: eDP connected Display stays blank

[Jani Nikula]

On Thu, 06 Nov 2014, Arnd Hannemann <arnd@arndnet.de> wrote:
> Hi,
>
> thanks for your quick response.
>
> Am 06.11.2014 um 10:39 schrieb Jani Nikula:
>> On Thu, 06 Nov 2014, Arnd Hannemann <arnd@arndnet.de> wrote:
>>> Hi,
>>>
>>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>>> via a Docking Station (MST).
>>>
>>> During Bootup all three displays work, even when X is started.
>>> However, if the laptop display is turned off once (either because of
>>> power saving, or via xrandr), it fails to "come back".
>>> That is if I try to re-enable it the Display stays blank.
>>> I believe this used to work in 3.17.
>>>
>>> Here is the xrandr Ouput of the edp, when its enabled (but staying blank):
>>> Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
>>> eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm
>>>    1920x1080      60.0*+   59.9
>>>
>>> here is the debug output, while trying to enable it:
>>>
>> 
>> ...
>> 
>>> [  416.538848] [drm:intel_edp_backlight_power] panel power control backlight disable
>>>
>>>
>>> I'm happy to provide further input.
>> 
>> What does cat /sys/class/backlight/intel_backlight/bl_power say? What if
>
> root@kallisto:~# cat /sys/class/backlight/intel_backlight/bl_power
> 1
>
>> you echo 0 there?
>
> :-) Works my display comes back, when I echo 0 there.
>
> Is user-space doing something wrong here?

If the userspace wishes to switch off backlight, then it's doing nothing
wrong at all! ;)

Here's the story as I know it.

Once upon a time someone added the bl_power attribute to the sysfs class
backlight interface. Even though the name implies a boolean backlight
power, the values are in fact FB_BLANK_* from fb.h, and power on is
FB_BLANK_UNBLANK, or 0. All the other values are various levels of
blanking which make little sense to backlight, and thus any non-zero
values mean power off. [1]

Until recently, intel_backlight of drm/i915 did not support bl_power at
all. We ignored the attribute altogether. However changing bl_power from
its default 0 did cause a backlight update hook to be called. In some
edge cases doing this fixed some backlight issues by reprogramming the
backlight intensity, and probably lead to the false assumption that
bl_power needed to be set to 1 to enable power.

Now that we've enabled support for bl_power attribute (on eDP at least),
the previously harmless, or sometimes even helpful, bl_power=1 actually
does what it means. That is, switch off the backlight.

Please try this patch (untested) to find out the culprit.

diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index bddc8b17a4d8..8cf5c6cdeef5 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -143,6 +143,7 @@ static ssize_t bl_power_store(struct device *dev, struct device_attribute *attr,
 	rc = -ENXIO;
 	mutex_lock(&bd->ops_lock);
 	if (bd->ops) {
+		printk(KERN_INFO "bl_power %lu by %s\n", power, current->comm);
 		pr_debug("set power to %lu\n", power);
 		if (bd->props.power != power) {
 			bd->props.power = power;


BR,
Jani.




[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/stable/sysfs-class-backlight
("Read the documentation and you'll get it right" does not score well in
Rusty's API design manifesto)

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: 3.18.0-rc3: i915: eDP connected Display stays blank

[Arnd Hannemann]

Hi,

Am 06.11.2014 um 13:53 schrieb Jani Nikula:

>> root@kallisto:~# cat /sys/class/backlight/intel_backlight/bl_power
>> 1
>>
>>> you echo 0 there?
>>
>> :-) Works my display comes back, when I echo 0 there.
>>
>> Is user-space doing something wrong here?
> 
> If the userspace wishes to switch off backlight, then it's doing nothing
> wrong at all! ;)
> 
> Here's the story as I know it.
> 
> Once upon a time someone added the bl_power attribute to the sysfs class
> backlight interface. Even though the name implies a boolean backlight
> power, the values are in fact FB_BLANK_* from fb.h, and power on is
> FB_BLANK_UNBLANK, or 0. All the other values are various levels of
> blanking which make little sense to backlight, and thus any non-zero
> values mean power off. [1]
> 
> Until recently, intel_backlight of drm/i915 did not support bl_power at
> all. We ignored the attribute altogether. However changing bl_power from
> its default 0 did cause a backlight update hook to be called. In some
> edge cases doing this fixed some backlight issues by reprogramming the
> backlight intensity, and probably lead to the false assumption that
> bl_power needed to be set to 1 to enable power.
> 
> Now that we've enabled support for bl_power attribute (on eDP at least),
> the previously harmless, or sometimes even helpful, bl_power=1 actually
> does what it means. That is, switch off the backlight.
> 

Thanks for your elaborated answer.

> Please try this patch (untested) to find out the culprit.

Thanks, its the intel xorg driver:
[  255.777798] bl_power 1 by Xorg

I seems it was already corrected upstream, by Chris Wilson two days ago:
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7ecc778691c452285f754743a93a46fa1d3da52f


Best regards
Arnd
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx