lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hmxby6ehi.wl%tiwai@suse.de>
Date:	Mon, 14 Nov 2011 14:05:45 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Daniel Mack <zonque@...il.com>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	dri-devel@...ts.freedesktop.org, jbarnes@...tuousgeek.org,
	harald@...hat.com, Keith Packard <keithp@...thp.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Strange effect with i915 backlight controller

At Mon, 14 Nov 2011 13:03:46 +0100,
Daniel Mack wrote:
> 
> On 11/14/2011 11:39 AM, Takashi Iwai wrote:
> > [Added Chris to Cc]
> > 
> > At Sun, 13 Nov 2011 17:24:09 +0100,
> > Daniel Mack wrote:
> >>
> >> Hi Takashi,
> >>
> >> On 11/10/2011 04:39 PM, Takashi Iwai wrote:
> >>> At Thu, 10 Nov 2011 16:11:29 +0100,
> >>> Daniel Mack wrote:
> >>>>
> >>>> On 11/08/2011 01:57 AM, Daniel Mack wrote:
> >>>>> Didn't get any response yet, hence copying LKML for a broader audience.
> >>>>
> >>>> Nobody, really?
> >>>>
> >>>> This is a rather annoying regression, as touching the brightness keys
> >>>> appearantly switches off the whole machine. I'm sure this is trivial to
> >>>> fix, I just don't have the insight of this driver and the chipset.
> >>>
> >>> I vaguely remember that the bit 0 is invalid on some old chips.
> >>> Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
> >>> may work.
> >>
> >> Thank you for looking into this.
> >>
> >>> ---
> >>> diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
> >>> index 499d4c0..be952d1 100644
> >>> --- a/drivers/gpu/drm/i915/intel_panel.c
> >>> +++ b/drivers/gpu/drm/i915/intel_panel.c
> >>> @@ -249,8 +249,11 @@ static void intel_panel_actually_set_backlight(struct drm_device *dev, u32 level
> >>>  	if (IS_PINEVIEW(dev)) {
> >>>  		tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
> >>>  		level <<= 1;
> >>> -	} else
> >>> +	} else {
> >>>  		tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
> >>> +		if (INTEL_INFO(dev)->gen < 4)
> >>> +			tmp &= ~1;
> >>> +	}
> >>>  	I915_WRITE(BLC_PWM_CTL, tmp | level);
> >>>  }
> >>>  
> >>
> >> This seems to be the right intention, but the value you want to modify
> >> under this condition is 'level', not 'tmp'.
> > 
> > Ah, of course.  Sorry for that.
> > 
> >> With this amendment of your
> >> patch, things work perfectly fine here.
> > 
> > OK, then perhaps a better fix is to change the check to be equivalent
> > with pineview, as you mentioned in the original post.  The handling of
> > bit 0 for old chips was lost during the refactoring of backlight code
> > since 2.6.37.
> > 
> > Does the patch below work for you?
> 
> Will test, but I only have occasional access to the machine, so this
> will have to wait for some days.

It's an old bug over a year, so no need to hurry.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ