[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yunr5ae4vjg.fsf@aiko.keithp.com>
Date: Thu, 10 Mar 2011 11:36:51 -0800
From: Keith Packard <keithp@...thp.com>
To: Takashi Iwai <tiwai@...e.de>, Indan Zupancic <indan@....nu>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DRI mailing list <dri-devel@...ts.freedesktop.org>,
Alex Riesen <raa.lkml@...il.com>,
Tino Keitel <tino.keitel@...ei.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
stable@...nel.org
Subject: Re: [PATCH] drm/i915: Revive combination mode for backlight control
On Thu, 10 Mar 2011 14:02:12 +0100, Takashi Iwai <tiwai@...e.de> wrote:
> This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
>
> drm/i915: Do not handle backlight combination mode specially
>
> since this commit introduced other regressions due to untouched LBPC
> register, e.g. the backlight dimmed after resume.
>
> In addition to the revert, this patch includes a fix for the original
> issue (weird backlight levels) by removing the wrong bit shift for
> computing the current backlight level.
> Also, including typo fixes (lpbc -> lbpc).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
> Acked-by: Indan Zupancic <indan@....nu>
> Cc: <stable@...nel.org>
> Signed-off-by: Takashi Iwai <tiwai@...e.de>
This looks good, and ensures that LBPC ranges from 0 - 0xfe as required.
The one thing we want is a comment that explains
> + val &= ~1;
The reason for this is that some ancient platforms wire this bit to
be "go to max backlight", or at least that's why this was in the 2D
driver from which this code was derived.
Reviewed-by: Keith Packard <keithp@...thp.com>
Reviewed-by: Jesse Barnes <jbarnes@...tuousgeek.org>
--
keith.packard@...el.com
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists