On Thu, Dec 23, 2010 at 1:54 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai tiwai@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650 drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here. The laptop display (LVDS) becomes blank. Reverting the commit fixes the problem.
The question is whose BIOS is wrong?
I don't think so.
The Lenovo U160's or the Sandybridge SDV? And why does it work for that other OS? <Insert rhetorical question of the day here.>
Quite frankly, I don't think the question should *ever* be "whose BIOS is wrong?"
You should always take for granted that the BIOS is wrong. It's not a question of "blame the BIOS", it's a question of facts of life.
It's 100% pointless to point fingers and say "the HP BIOS is wrong" or "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that relies on the BIOS to such a degree that it either works or not based on it is by definition broken.
Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release.
I've no idea but since this is spread-spectrum related the bios may not enable spread-spectrum on the panel, though really the question is as always, what does Windows do.
Dave.
Linus _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel