public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Indan Zupancic <indan@nul.nu>
Cc: Michal Hocko <mhocko@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: Linux 2.6.37
Date: Wed, 12 Jan 2011 12:07:23 +0000	[thread overview]
Message-ID: <b9dded$hknqnh@orsmga002.jf.intel.com> (raw)
In-Reply-To: <b34be07ef0c3e8fc82c29d4299f262e4.squirrel@webmail.greenhost.nl>

On Wed, 12 Jan 2011 01:35:49 +0100 (CET), "Indan Zupancic" <indan@nul.nu> wrote:
> Yeah, the second patch is a bit of a desperate attempt because Larry reported that
> it didn't fix his problem.
> 
> About your patch, you still do:
> 
> +void intel_panel_setup_backlight(struct drm_device *dev)
> +{
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +
> +	dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> +	dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
> +}
> 
> While my patch changes that to:
> 
> +	u32 level;
> 
> -	if (dev_priv->backlight_level == 0)
> -		dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
> +	if (dev_priv->backlight_level == 0) {
> +		level = intel_panel_get_backlight(dev);
> +		if (level == 0)
> +			level = intel_panel_get_max_backlight(dev);
> +		dev_priv->backlight_level = level;
> +	}
> 
> Your patch uses intel_panel_get_max_backlight() to check if the backlight is
> enabled. Is this always correct, or may it cause bugs in the future?

That was a typo, cut'n'pasting the line from above.

> Anyway, my main concern with unconditionally setting the backlight level to
> the maximum is that any stored brightness level (by the BIOS or whatever) may
> be lost, and that the screen is set to maximum brightness at each boot. This
> is certainly the behaviour I've seen with an unpatched kernel. So I propose to
> do what my patch does and set it to intel_panel_get_backlight(dev) if that
> returns non-zero. Something like this:

Sure, s/intel_panel_get_max_backlight/intel_panel_get_backlight/ and we
get the behaviour we both want - preserving the current backlight unless
none is set.

> While I'm glad this problem is being fixed upstream, it would be nice to get
> some credit for finding the source of the problem.

Sorry. You found the bug but I felt your rationale was off. However, I was
amiss in not giving you the credit you fully deserved.
-Chris

commit 9c1c388a53e5df8819e898106a64e34d0994a5d4
Author: Indan Zupancic <indan@nul.nu>
Date:   Wed Jan 12 11:59:19 2011 +0000

    drm/i915/panel: The backlight is enabled if the current value is non-zero
    
    ... and not if the maximum is non-zero. This fixes the typo introduced
    in 47356eb6728501452 and preserves the backlight value from boot.
    
    [ickle: My thanks also to Indan Zupancic for diagnosing the original
            regression and suggesting the appropriate fix.]
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: stable@kernel.org # after 47356eb6728501452

diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_pan
index e00d200..27c79c7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -278,6 +278,6 @@ void intel_panel_setup_backlight(struct drm_device
*dev)
 {
        struct drm_i915_private *dev_priv = dev->dev_private;
 
-       dev_priv->backlight_level = intel_panel_get_max_backlight(dev);
+       dev_priv->backlight_level = intel_panel_max_backlight(dev);
        dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
 }

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-01-12 12:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05  1:15 Linux 2.6.37 Linus Torvalds
2011-01-06 10:48 ` Michal Hocko
2011-01-06 16:29   ` Linus Torvalds
2011-01-06 17:03     ` Michal Hocko
2011-01-06 17:49     ` Chris Wilson
2011-01-06 20:55       ` Alex Riesen
2011-01-06 21:03         ` Chris Wilson
2011-01-06 21:08         ` Alex Riesen
2011-01-07 15:52           ` Michal Hocko
2011-01-11 13:33   ` Pavel Machek
2011-01-11 14:28     ` Michal Hocko
2011-01-11 14:47     ` Alex Riesen
2011-01-11 17:19   ` Michal Hocko
2011-01-11 17:37     ` Michal Hocko
2011-01-11 18:37       ` Michal Hocko
2011-01-11 17:39     ` Chris Wilson
2011-01-11 17:44       ` Michal Hocko
2011-01-12  0:35       ` Indan Zupancic
2011-01-12 12:07         ` Chris Wilson [this message]
2011-01-12 12:14           ` Chris Wilson
2011-01-13  0:35           ` Indan Zupancic
  -- strict thread matches above, loose matches on Subject: below --
2011-01-07 19:20 Zephaniah E. Loss-Cutler-Hull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='b9dded$hknqnh@orsmga002.jf.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=indan@nul.nu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.cz \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox