[git pull] drm fixes
jbarnes at virtuousgeek.org
Thu Dec 23 08:51:06 PST 2010
On Wed, 22 Dec 2010 19:54:31 -0800
Linus Torvalds <torvalds at linux-foundation.org> 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
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
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
More information about the dri-devel