From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Jackson Subject: Re: Flicker-free boot in DRM Date: Mon, 31 Oct 2011 12:56:58 -0400 Message-ID: <4EAED35A.4040307@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTP id 90C3EA0913 for ; Mon, 31 Oct 2011 10:55:45 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: Keith Packard Cc: "drivers, Intel" List-Id: intel-gfx@lists.freedesktop.org On 10/30/11 12:24 AM, Keith Packard wrote: > On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" wrote: > >> * I've got LVDS pulling the current mode out of the hardware > > With a machine that has a native VBE mode for the panel, the problem is > that clock computed from the hardware settings is not quite the same as > the clock requested in the mode. I think the clock computation must be > slightly off, but even with that fixed, it will probably not quite > match. I think we'll need a magic flag in this mode telling DRM to allow > a bit of fuzz in clock matching. Yeah, it won't be precise. That's why there's PLL search code at all, and why it has a fuzz factor for finding "good enough". I ran the math for the maximum error in the PLL search back when I was fixing a case where it fell through and failed to find timings at all. See 6ba770dc5c334aff1c055c8728d34656e0f091e2. - ajax