[PATCH] Intel FB pixel clock calculation fix

[PATCH] Intel FB pixel clock calculation fix

[Krzysztof Halasa]

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)

Re: [PATCH] Intel FB pixel clock calculation fix

[Andrew Morton]

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.

Re: [PATCH] Intel FB pixel clock calculation fix

[Krzysztof Halasa]

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

Re: [PATCH] Intel FB pixel clock calculation fix

[Pavel Machek]

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

Re: [PATCH] Intel FB pixel clock calculation fix

[Krzysztof Halasa]

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