From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH 1/5] drm/i915: make edp panel power sequence
 setup more robust
Date: Tue, 23 Oct 2012 07:23:28 -0700
Message-ID: <20121023072328.792f81e4@jbarnes-desktop>
References: <1350759465-7171-1-git-send-email-daniel.vetter@ffwll.ch>
	<1350759465-7171-2-git-send-email-daniel.vetter@ffwll.ch>
	<20121022150425.033bc3ef@jbarnes-desktop>
	<CAKMK7uH_04fLe5WyRzZtAMFzynsQZfzskSNincvT5zgWEEkdTw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com
	[67.222.54.6])
	by gabe.freedesktop.org (Postfix) with SMTP id 137A69E9AD
	for <intel-gfx@lists.freedesktop.org>;
	Tue, 23 Oct 2012 07:22:28 -0700 (PDT)
In-Reply-To: <CAKMK7uH_04fLe5WyRzZtAMFzynsQZfzskSNincvT5zgWEEkdTw@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Tue, 23 Oct 2012 09:23:00 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> On Tue, Oct 23, 2012 at 12:04 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > If the current field is not zero and doesn't match the VBT, we might
> > add a debug statement.  It could indicate a BIOS programmed value that
> > didn't involve a VBT update (I can imagine some vendors might do
> > this).  Overwriting the current with the different VBT value may lead
> > to breakage or sub-optimal timings.
> 
> We dump the current values (read out from the PP regs), the vbt values
> and now also the new values we write back into the regs. That not good
> enough?

I suppose, it just means more digging if there's a mismatch.

-- 
Jesse Barnes, Intel Open Source Technology Center