On Wed, 22 Dec 2010 19:54:31 -0800 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > 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. Oh I wish we could just do that. Strictly speaking though this isn't so much of a BIOS issue as it is a ROM issue. Platform vendors provide no way of getting at platform configuration details related to graphics aside from the tables they flash into ROM along with the VBIOS. The tables are just like an EDID ROM on a display: they communicate data we have no other way of getting. In the particular case of SSC, there's a board down spread spectrum clock reference source at a fixed frequency. We can't automatically determine it at runtime (asking the user "can you see this" at boot time isn't really an option), so we need to rely on the VBT to tell us. The Windows driver uses this data as well, but obviously either it's incorrect on our SDV (possible) or we're failing to parse the data correctly (likely). It's also possible we're failing to look at a bit that says "use/don't use SSC on this platform" making the frequency field meaningless. We'll figure it out or disable SSC enabling altogether failing that (risking interference with other components like wireless and sound). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
