From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752359Ab0LVRHU (ORCPT <rfc822;w@1wt.eu>);
	Wed, 22 Dec 2010 12:07:20 -0500
Received: from cantor.suse.de ([195.135.220.2]:57828 "EHLO mx1.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752027Ab0LVRHT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 22 Dec 2010 12:07:19 -0500
Date: Wed, 22 Dec 2010 18:07:17 +0100
Message-ID: <s5h1v59vire.wl%tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@linux.ie>, torvalds@linux-foundation.org,
        DRI mailing list <dri-devel@lists.freedesktop.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [git pull] drm fixes
In-Reply-To: <c6d829$pujifv@fmsmga001.fm.intel.com>
References: <alpine.DEB.2.00.1012212339090.30885@skynet.skynet.ie>
	<s5hei99vkqj.wl%tiwai@suse.de>
	<c6d829$pujifv@fmsmga001.fm.intel.com>
User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.2
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

At Wed, 22 Dec 2010 16:59:06 +0000,
Chris Wilson 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? The Lenovo U160's or the
> Sandybridge SDV? And why does it work for that other OS? <Insert
> rhetorical question of the day here.>
> 
> It's back to the square one for one or the other platform...

Yeah, we can blame BIOS :)  And, this is likely the BIOS on my machine
here that is broken.

But this seems like an issue that you can't rely solely on VBT.  We
can never guarantee that BIOS is correct (who can?), and there is no
way to avoid this change as long as it's hard-coded.  We've hit
another regression by VBT check (e-DP  wrongly detected; kernel bug
24822), so I think judging the behavior only from BIOS is rather
dangerous.


thanks,

Takashi