* Re: [PATCH] Intel FB pixel clock calculation fix [not found] <m3ir6il3wl.fsf@maximus.localdomain> @ 2007-09-11 5:52 ` Andrew Morton 2007-09-11 12:18 ` Krzysztof Halasa 0 siblings, 1 reply; 5+ messages in thread From: Andrew Morton @ 2007-09-11 5:52 UTC (permalink / raw) To: Krzysztof Halasa Cc: Antonino A. Daplas, sylvain.meyer, linux-fbdev-devel, linux-kernel On Mon, 10 Sep 2007 21:24:42 +0200 Krzysztof Halasa <khc@pm.waw.pl> wrote: > Intel framebuffer mis-calculated pixel clocks. > > Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> > > --- a/drivers/video/intelfb/intelfbhw.c > +++ b/drivers/video/intelfb/intelfbhw.c > @@ -924,10 +920,10 @@ calc_pll_params(int index, int clock, u32 *retm1, u32 *retm2, u32 *retn, u32 *re > if (m > pll->max_m) > m = pll->max_m - 1; > for (testm = m - 1; testm <= m; testm++) { > - f_out = calc_vclock3(index, m, n, p); > + f_out = calc_vclock3(index, testm, n, p); > if (splitm(index, testm, &m1, &m2)) { > - WRN_MSG("cannot split m = %d\n", m); > - n++; > + WRN_MSG("cannot split m = %d\n", > + testm); > continue; > } > if (clock > f_out) 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. Thanks. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Intel FB pixel clock calculation fix 2007-09-11 5:52 ` [PATCH] Intel FB pixel clock calculation fix Andrew Morton @ 2007-09-11 12:18 ` Krzysztof Halasa 2007-09-12 4:17 ` suresh gani 2007-10-26 17:51 ` Pavel Machek 0 siblings, 2 replies; 5+ messages in thread From: Krzysztof Halasa @ 2007-09-11 12:18 UTC (permalink / raw) To: Andrew Morton Cc: sylvain.meyer, linux-kernel, Antonino A. Daplas, linux-fbdev-devel Andrew Morton <akpm@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Intel FB pixel clock calculation fix 2007-09-11 12:18 ` Krzysztof Halasa @ 2007-09-12 4:17 ` suresh gani 2007-10-26 17:51 ` Pavel Machek 1 sibling, 0 replies; 5+ messages in thread From: suresh gani @ 2007-09-12 4:17 UTC (permalink / raw) To: linux-fbdev-devel please send me a source code of framebuffer smaple applicatin program in embedded systems On 9/11/07, Krzysztof Halasa <khc@pm.waw.pl> wrote: > Andrew Morton <akpm@linux-foundation.org> 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 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Linux-fbdev-devel mailing list > Linux-fbdev-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > -- Regards SURESH S GANI SOFTWARE ENGINEER. SPA COMPUTERS PVT LTD. -An Embedded Systems Company. HAL Second Stage Indiranagar. Bangalore-8. mob:9902703238 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Intel FB pixel clock calculation fix 2007-09-11 12:18 ` Krzysztof Halasa 2007-09-12 4:17 ` suresh gani @ 2007-10-26 17:51 ` Pavel Machek 2007-10-26 19:58 ` Krzysztof Halasa 1 sibling, 1 reply; 5+ messages in thread From: Pavel Machek @ 2007-10-26 17:51 UTC (permalink / raw) To: Krzysztof Halasa Cc: Antonino A. Daplas, Andrew Morton, sylvain.meyer, linux-fbdev-devel, linux-kernel On Tue 2007-09-11 14:18:57, Krzysztof Halasa wrote: > Andrew Morton <akpm@linux-foundation.org> 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. I don't think this is -stable kind of bug. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Intel FB pixel clock calculation fix 2007-10-26 17:51 ` Pavel Machek @ 2007-10-26 19:58 ` Krzysztof Halasa 0 siblings, 0 replies; 5+ messages in thread From: Krzysztof Halasa @ 2007-10-26 19:58 UTC (permalink / raw) To: Pavel Machek Cc: Andrew Morton, sylvain.meyer, linux-kernel, Antonino A. Daplas, linux-fbdev-devel Pavel Machek <pavel@ucw.cz> writes: > On Tue 2007-09-11 14:18:57, Krzysztof Halasa wrote: >> I think 2.6.22 would be overkill, .23 - not sure. > > I don't think this is -stable kind of bug. Given the timeframe, I can only agree once again :-) -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-10-26 19:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <m3ir6il3wl.fsf@maximus.localdomain>
2007-09-11 5:52 ` [PATCH] Intel FB pixel clock calculation fix Andrew Morton
2007-09-11 12:18 ` Krzysztof Halasa
2007-09-12 4:17 ` suresh gani
2007-10-26 17:51 ` Pavel Machek
2007-10-26 19:58 ` Krzysztof Halasa
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).