linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: disable LVDS downclock by default

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: <20100114211610.GA2030@emergent.ellipticsemi.com>
Date:	Thu, 14 Jan 2010 16:16:10 -0500
From:	Nick Bowler <nbowler@...iptictech.com>
To:	Peter Clifton <pcjc2@....ac.uk>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>, airlied@...ux.ie,
	intel-gfx@...ts.freedesktop.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: disable LVDS downclock by default

On 20:58 Thu 14 Jan     , Peter Clifton wrote:
> On Thu, 2010-01-14 at 12:48 -0800, Jesse Barnes wrote:
> > Many platform support this feature, and it can provide significant
> > power savings when the reduced refresh rate is low.  However, on some
> > platforms a secondary (reduced) timing is provided but not actually
> > supported by the hardware.  This results in undesirable flicker at
> > runtime.
> > 
> > So disable the feature by default, but allow users to opt-in to the
> > reduced clock behavior with a new module parameter, lvds_downclock,
> > that can be set to 1 to enable the feature.
> 
> Would it not be a better idea to turn this feature on by default, then
> use quirks to disable it on the afflicted borken machines?

If there is a high degree of confidence that correct quirks are in place
for all "afflicted borken machines", then this is probably OK.

The difference between 2.6.32 and 2.6.33-rc1 on the T500 is phenominal:
the LVDS display is so erratic in the latter as to be almost completely
useless.  There is a patch on fdo bugzilla which makes the display less
broken, but there is still distracting flicker.

> Requiring special module parameters to enable the feature, almost
> guarantees that no normal end-users will end up benefiting from the
> feature. Many of whom will have bought machines which don't have screwey
> BIOS implementations.

On the other hand, it completely guarantees that no normal end-users
will end up with useless displays as a result of the feature.  Many of
whom have bough machines which have screwey BIOS implementations (or
whatever the problem actually is).

> I think (on a general note) that vendors supplying defective BIOSen or
> config should be "named and shamed" in quirk tables - so eventually they
> will get something done about the problems for future models.

Is it really a defective BIOS?  I don't have my laptop handy right now,
but the lower refresh mode is reported in the EDID and can be set
successfully (no idea if the change actually does anything).  However,
there is a visible artifact whenever a transition occurs.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
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/