2007-09-10 19:24:56

by Krzysztof Halasa

Subject: [PATCH] Intel FB pixel clock calculation fix

Intel framebuffer mis-calculated pixel clocks.

Signed-off-by: Krzysztof Halasa <[email protected]>

--- 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)

2007-09-11 05:52:39

by Andrew Morton

Subject: Re: [PATCH] Intel FB pixel clock calculation fix

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]>
>
> --- 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.

2007-09-11 12:19:18

by Krzysztof Halasa

Subject: Re: [PATCH] Intel FB pixel clock calculation fix

Andrew Morton <[email protected]> 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

2007-10-26 17:52:02

by Pavel Machek

Subject: Re: [PATCH] Intel FB pixel clock calculation fix

On Tue 2007-09-11 14:18:57, Krzysztof Halasa wrote:
> Andrew Morton <[email protected]> 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

2007-10-26 19:58:19

by Krzysztof Halasa

Subject: Re: [PATCH] Intel FB pixel clock calculation fix

Pavel Machek <[email protected]> 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