Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933213AbXIKMTS (ORCPT ); Tue, 11 Sep 2007 08:19:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752988AbXIKMTC (ORCPT ); Tue, 11 Sep 2007 08:19:02 -0400 Received: from khc.piap.pl ([195.187.100.11]:56115 "EHLO khc.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752954AbXIKMTA (ORCPT ); Tue, 11 Sep 2007 08:19:00 -0400 To: Andrew Morton Cc: sylvain.meyer@worldonline.fr, , "Antonino A. Daplas" , linux-fbdev-devel@lists.sourceforge.net Subject: Re: [PATCH] Intel FB pixel clock calculation fix References: <20070910225221.f0eaf22c.akpm@linux-foundation.org> From: Krzysztof Halasa Date: Tue, 11 Sep 2007 14:18:57 +0200 In-Reply-To: <20070910225221.f0eaf22c.akpm@linux-foundation.org> (Andrew Morton's message of "Mon, 10 Sep 2007 22:52:21 -0700") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 953 Lines: 25 Andrew Morton writes: >> Intel framebuffer mis-calculated pixel clocks. > and... what are the consequences of this miscalculation? I need to know > such things so that I can decide whether a change is needed in 2.6.23. And > 2.6.22. The pixel clock (and thus both H and V sync) will be slower than requested, so if you set the minimum allowed the display may not sync. In case of really old CRT display it could theoretically damage it. I'm using it with PAL TV (using RGB input - SCART connector) and the bug prevented it from working at all (TV requirements are more strict and made the bug visible). I think 2.6.22 would be overkill, .23 - not sure. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/