[Intel-gfx] [PATCH] i915: Initialize panel timing registers if VBIOS did not.
jg at freedesktop.org
Fri Oct 8 13:11:47 PDT 2010
On 10/08/2010 02:35 PM, Bryan Freed wrote:
> 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).
Yeah, there is a minimum frame rate you need to drive LCD's at, which is
somewhat dependent on the details of the liquid crystal material itself;
you really don't want them to crystallise fully. I know from working
with Mary Lou Jepson on the OLPC LCD panel that 25hz was fully safe for
that technology (and the liquid crystals themselves weren't anything
unusual in that panel). She is entirely expert at LCD technology.
Having some sanity check seems good and correlates with what I know, to
handle the case of not being given any valid information.
> 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."
> On Fri, Oct 8, 2010 at 2:58 AM, Chris Wilson<chris at chris-wilson.co.uk>wrote:
>> On Thu, 7 Oct 2010 17:05:46 -0700, Bryan Freed<bfreed at chromium.org>
>>> 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 Wilson, Intel Open Source Technology Centre
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
More information about the Intel-gfx