Re: [PATCH] Intel FB pixel clock calculation fix

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.

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

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

[suresh gani]

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/

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

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

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