Re: [PATCH] i915: Initialize panel timing registers if VBIOS did not.

From: Bryan Freed <bfreed@chromium.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org,
	Olof Johansson <olofj@chromium.org>,
	Mandeep Baines <msb@chromium.org>
Subject: Re: [PATCH] i915: Initialize panel timing registers if VBIOS did not.
Date: Fri, 8 Oct 2010 11:35:42 -0700	[thread overview]
Message-ID: <AANLkTi=a+0ghGTfRP+27FYwbFjyo9FUc0uzHANSaiaTo@mail.gmail.com> (raw)
In-Reply-To: <89k77n$p5t7tl@fmsmga001.fm.intel.com>

[-- Attachment #1.1: Type: text/plain, Size: 1951 bytes --]

I took a look at several panel datasheets I found around here, and the one
issue some of them mentioned is that these timings (particularly T2 on
powerup and T3 on powerdown) are used to prevent latch-up.

That makes sense.  We do not want to drive pixels to a device that has 0V on
VDD.  This change sets a default of 40ms / 35ms (as per our panel of
interest) in the event we see both values at 0ms.  So this change can only
make things better (ie, latch-up less likely).

One "weakness" is that I do not explicitly check the T2 and T3 timings in
the PP_ON and PP_OFF registers.  I try to detect a lack of VBIOS
initialization by checking for 0 valued registers.  I rather think this is
the right approach.

The other timings in these registers are cosmetic.  For example, "do not
turn on the backlight before the panel is driving its pixels which is T5
after turning on the pixel clock."

bryan.

On Fri, Oct 8, 2010 at 2:58 AM, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> On Thu, 7 Oct 2010 17:05:46 -0700, Bryan Freed <bfreed@chromium.org>
> wrote:
> > The time between start of the pixel clock and backlight enable is a basic
> > panel timing constraint.  If the Panel Power On/Off registers are found
> > to be 0, assume we are booting without VBIOS initialization and set these
> > registers to something reasonable.
>
> That looks cleaner. Obviously my only concern is what happens if we ever
> see a second device that posts without setting up the registers. We may as
> well compile in the VBT for every single manufactured device... Or we
> could add a ROM table the manufacturers must include that provides the
> necessary register values for their hardware. There must be some
> replacement for the BIOS, a device description table at least?
>
> Does any one have a strong "this will damage my hardware" objection? Are
> the values safe enough for *any* device?
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>

[-- Attachment #1.2: Type: text/html, Size: 2490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx