From patchwork Thu Nov 6 12:53:34 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jani Nikula X-Patchwork-Id: 5241741 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D06A09F387 for ; Thu, 6 Nov 2014 12:53:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B5C992010F for ; Thu, 6 Nov 2014 12:53:42 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id AB1B720108 for ; Thu, 6 Nov 2014 12:53:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D8966EF95; Thu, 6 Nov 2014 04:53:41 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 065AF6EF95; Thu, 6 Nov 2014 04:53:39 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 06 Nov 2014 04:53:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="412396674" Received: from jnikula-mobl.fi.intel.com (HELO localhost) ([10.237.72.54]) by FMSMGA003.fm.intel.com with ESMTP; 06 Nov 2014 04:45:03 -0800 From: Jani Nikula To: Arnd Hannemann , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org In-Reply-To: <545B4D64.1010807@arndnet.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <545B3BEA.2090105@arndnet.de> <87sihw3by4.fsf@intel.com> <545B4D64.1010807@arndnet.de> User-Agent: Notmuch/0.18.2+163~g3d266bb (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 06 Nov 2014 14:53:34 +0200 Message-ID: <87mw8432y9.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] 3.18.0-rc3: i915: eDP connected Display stays blank X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 06 Nov 2014, Arnd Hannemann wrote: > Hi, > > thanks for your quick response. > > Am 06.11.2014 um 10:39 schrieb Jani Nikula: >> On Thu, 06 Nov 2014, Arnd Hannemann 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. 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) 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;