Intel FB pixel clock calculation fix
PATCH 1/1 Intel FB pixel clock calculation fix
Intel framebuffer mis-calculated pixel clocks.
drivers/video/intelfb/intelfbhw.c +3 -3
@@ -924,10 +920,10 @@ calc_pll_params(int index, int clock, u32 *retm1, u32 *retm2, u32 *retn, u32 *reif (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)
Quoted 10 lines · On Mon, 10 Sep 2007 21:24:42 +0200 Krzysztof Halasa <[email protected]> wrote:
Intel framebuffer mis-calculated pixel clocks.
Signed-off-by Krzysztof Halasa <[email protected]>drivers/video/intelfb/intelfbhw.c +0
-0@@ -924,10 +920,10 @@ calc_pll_params(int index, int clock, u32 *retm1, u32 *retm2, u32 *retn, u32 *reif (m > pll->max_m) m = pll->max_m -1 ;for (testm = m -1 ; testm <= m; testm++) {
drivers/video/intelfb/intelfbhw.c calc_pll_params(int index, int clock, u32 *retm1, u32 *retm2, u32 *retn, u32 *re · line 929
Quoted 10 lines
drivers/video/intelfb/intelfbhw.c +3
-3- 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/
Quoted 5 lines · Andrew Morton
Quoted 1 line
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.
Signature · 1 line
Krzysztof Halasa
please send me a source code of framebuffer smaple applicatin program in embedded systems
Quoted 31 lines · Krzysztof Halasa
Quoted 4 lines · Andrew Morton
Quoted 1 line
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
Quoted 1 line
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
Signature · 13 lines
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/Quoted 13 lines · Krzysztof Halasa
Quoted 5 lines · Andrew Morton
Quoted 1 line
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.
Quoted 5 lines
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
Signature · 8 lines
(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/
Quoted 4 lines · Pavel Machek
Quoted 1 line · Krzysztof Halasa
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 :-)
Signature · 1 line
Krzysztof Halasa