Bug 9762 - radeonfb and Xpress 200m 5955
Summary: radeonfb and Xpress 200m 5955
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Console/Framebuffers (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: James Simmons
URL:
Keywords:
Depends on:
Blocks: 9243
  Show dependency tree
 
Reported: 2008-01-16 01:33 UTC by Alex
Modified: 2008-01-18 08:41 UTC (History)
1 user (show)

See Also:
Kernel Version: >=2.6.23
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
add 1280x800 mode into modedb (493 bytes, patch)
2008-01-16 08:37 UTC, Alex
Details | Diff

Description Alex 2008-01-16 01:33:24 UTC
Latest working kernel version: 2.6.23
Earliest failing kernel version: any
Distribution: gentoo
Hardware Environment: Radeon XPress 200m 5955
Software Environment: 
Problem Description: framebuffer is ok only with default parameters only (it is 1280x800-8@60). If parameters are video=radeonfb:1280x800-32@60 then xres, yres and xres_virtual are ok but yres_virtual is 1024. It can be corrected by fbset utility so I think it can be corrected in the driver code also.

Steps to reproduce: video=radeonfb:1280x800-32@60 or video=radeonfb:1280x800-16@60
Comment 1 Anonymous Emailer 2008-01-16 01:57:21 UTC
Reply-To: akpm@linux-foundation.org

On Wed, 16 Jan 2008 01:33:25 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=9762
> 
>            Summary: radeonfb and Xpress 200m 5955
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: >=2.6.23
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Console/Framebuffers
>         AssignedTo: jsimmons@infradead.org
>         ReportedBy: alevkovich@tut.by
> 
> 
> Latest working kernel version: 2.6.23
> Earliest failing kernel version: any
> Distribution: gentoo
> Hardware Environment: Radeon XPress 200m 5955
> Software Environment: 
> Problem Description: framebuffer is ok only with default parameters only (it
> is
> 1280x800-8@60). If parameters are video=radeonfb:1280x800-32@60 then xres,
> yres
> and xres_virtual are ok but yres_virtual is 1024. It can be corrected by
> fbset
> utility so I think it can be corrected in the driver code also.
> 
> Steps to reproduce: video=radeonfb:1280x800-32@60 or
> video=radeonfb:1280x800-16@60
> 

damn, another post-2.6.2 regression.

Does anyone know whether this is likely to be a radeonfb problem or an
fbdev core problem?
Comment 2 Anonymous Emailer 2008-01-16 07:23:45 UTC
Reply-To: geert@linux-m68k.org

On Wed, 16 Jan 2008, Andrew Morton wrote:
> On Wed, 16 Jan 2008 01:33:25 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=9762
> > 
> >            Summary: radeonfb and Xpress 200m 5955
> >            Product: Drivers
> >            Version: 2.5
> >      KernelVersion: >=2.6.23
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Console/Framebuffers
> >         AssignedTo: jsimmons@infradead.org
> >         ReportedBy: alevkovich@tut.by
> > 
> > 
> > Latest working kernel version: 2.6.23
> > Earliest failing kernel version: any
> > Distribution: gentoo
> > Hardware Environment: Radeon XPress 200m 5955
> > Software Environment: 
> > Problem Description: framebuffer is ok only with default parameters only
> (it is
> > 1280x800-8@60). If parameters are video=radeonfb:1280x800-32@60 then xres,
> yres
> > and xres_virtual are ok but yres_virtual is 1024. It can be corrected by
> fbset
> > utility so I think it can be corrected in the driver code also.
> > 
> > Steps to reproduce: video=radeonfb:1280x800-32@60 or
> > video=radeonfb:1280x800-16@60
> 
> damn, another post-2.6.2 regression.
> 
> Does anyone know whether this is likely to be a radeonfb problem or an
> fbdev core problem?

Perhaps

commit 1c5dd170927b1aa8e3a01d43d611b840336cdaf2
Author: Michal Januszewski <spock@gentoo.org>
Date:   Tue Oct 16 01:29:19 2007 -0700

    fbdev: find mode with the highest/safest refresh rate in fb_find_mode()
    
    Currently, if the refresh rate is not specified, fb_find_mode() returns the
    first known video mode with the requested resolution, which provides no
    guarantees wrt the refresh rate.  Change this so that the mode with the
    highest refresh rate is returned when the driver provides a custom video mod
e
    database and the monitor limits, and a mode with the safe 60 Hz refresh rate
    otherwise.

M. alevkovich, can you please try to back out that change?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
Comment 3 Alex 2008-01-16 08:37:34 UTC
Created attachment 14481 [details]
add 1280x800 mode into modedb
Comment 4 Alex 2008-01-16 08:38:39 UTC
There are no problems with refresh rate. There is problem with yres_virtual. It should be 800. Anyway I found the solution. Please look into the attached patch.
Comment 5 Anonymous Emailer 2008-01-16 11:12:59 UTC
Reply-To: akpm@linux-foundation.org

On Wed, 16 Jan 2008 16:23:22 +0100 (CET) Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Wed, 16 Jan 2008, Andrew Morton wrote:
> > On Wed, 16 Jan 2008 01:33:25 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9762
> > > 
> > >            Summary: radeonfb and Xpress 200m 5955
> > >            Product: Drivers
> > >            Version: 2.5
> > >      KernelVersion: >=2.6.23
> > >           Platform: All
> > >         OS/Version: Linux
> > >               Tree: Mainline
> > >             Status: NEW
> > >           Severity: normal
> > >           Priority: P1
> > >          Component: Console/Framebuffers
> > >         AssignedTo: jsimmons@infradead.org
> > >         ReportedBy: alevkovich@tut.by
> > > 
> > > 
> > > Latest working kernel version: 2.6.23
> > > Earliest failing kernel version: any
> > > Distribution: gentoo
> > > Hardware Environment: Radeon XPress 200m 5955
> > > Software Environment: 
> > > Problem Description: framebuffer is ok only with default parameters only
> (it is
> > > 1280x800-8@60). If parameters are video=radeonfb:1280x800-32@60 then
> xres, yres
> > > and xres_virtual are ok but yres_virtual is 1024. It can be corrected by
> fbset
> > > utility so I think it can be corrected in the driver code also.
> > > 
> > > Steps to reproduce: video=radeonfb:1280x800-32@60 or
> > > video=radeonfb:1280x800-16@60
> > 
> > damn, another post-2.6.2 regression.
> > 
> > Does anyone know whether this is likely to be a radeonfb problem or an
> > fbdev core problem?
> 
> Perhaps
> 
> commit 1c5dd170927b1aa8e3a01d43d611b840336cdaf2
> Author: Michal Januszewski <spock@gentoo.org>
> Date:   Tue Oct 16 01:29:19 2007 -0700
> 
>     fbdev: find mode with the highest/safest refresh rate in fb_find_mode()
>     
>     Currently, if the refresh rate is not specified, fb_find_mode() returns
>     the
>     first known video mode with the requested resolution, which provides no
>     guarantees wrt the refresh rate.  Change this so that the mode with the
>     highest refresh rate is returned when the driver provides a custom video
>     mod
> e
>     database and the monitor limits, and a mode with the safe 60 Hz refresh
>     rate
>     otherwise.

Thanks.

> M. alevkovich, can you please try to back out that change?
> 

Here's a patch against 2.6.24-rc8 which performs that reversion:

--- a/drivers/video/modedb.c~revert-1
+++ a/drivers/video/modedb.c
@@ -608,43 +608,26 @@ done:
 	DPRINTK("Trying specified video mode%s %ix%i\n",
 	    refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
 
-	if (!refresh_specified) {
-		/*
-		 * If the caller has provided a custom mode database and a
-		 * valid monspecs structure, we look for the mode with the
-		 * highest refresh rate.  Otherwise we play it safe it and
-		 * try to find a mode with a refresh rate closest to the
-		 * standard 60 Hz.
-		 */
-		if (db != modedb &&
-		    info->monspecs.vfmin && info->monspecs.vfmax &&
-		    info->monspecs.hfmin && info->monspecs.hfmax &&
-		    info->monspecs.dclkmax) {
-			refresh = 1000;
-		} else {
-			refresh = 60;
-		}
-	}
-
-	diff = -1;
+	diff = refresh;
 	best = -1;
 	for (i = 0; i < dbsize; i++) {
-		if ((name_matches(db[i], name, namelen) ||
-		    (res_specified && res_matches(db[i], xres, yres))) &&
-		    !fb_try_mode(var, info, &db[i], bpp)) {
-			if (refresh_specified && db[i].refresh == refresh) {
-				return 1;
-			} else {
-				if (abs(db[i].refresh - refresh) < diff) {
-					diff = abs(db[i].refresh - refresh);
-					best = i;
+		if (name_matches(db[i], name, namelen) ||
+		    (res_specified && res_matches(db[i], xres, yres))) {
+			if(!fb_try_mode(var, info, &db[i], bpp)) {
+				if(!refresh_specified || db[i].refresh == refresh)
+					return 1;
+				else {
+					if(diff > abs(db[i].refresh - refresh)) {
+						diff = abs(db[i].refresh - refresh);
+						best = i;
+					}
 				}
 			}
 		}
 	}
 	if (best != -1) {
 		fb_try_mode(var, info, &db[best], bpp);
-		return (refresh_specified) ? 2 : 1;
+		return 2;
 	}
 
 	diff = xres + yres;
_
Comment 6 Rafael J. Wysocki 2008-01-16 14:36:01 UTC
This patch from Alex, attached as
http://bugzilla.kernel.org/attachment.cgi?id=14481&action=view,
is reported to fix the problem.

--- linux-2.6.23/drivers/video/modedb.c	2008-01-16 18:23:48.183178912 +0200
+++ linux-2.6.23/drivers/video/modedb.c	2008-01-16 18:17:04.000000000 +0200
@@ -259,6 +259,10 @@
 	/* 1366x768, 60 Hz, 47.403 kHz hsync, WXGA 16:9 aspect ratio */
 	NULL, 60, 1366, 768, 13806, 120, 10, 14, 3, 32, 5,
 	0, FB_VMODE_NONINTERLACED
+   }, {
+	/* 1280x800, 60 Hz, 47.403 kHz hsync, WXGA 16:10 aspect ratio */
+	NULL, 60, 1280, 800, 12048, 200, 64, 24, 1, 136, 3,
+	0, FB_VMODE_NONINTERLACED
     },
 };
 
Comment 7 Adrian Bunk 2008-01-18 08:41:12 UTC
The fix is now as commit 545c4423335469de06af7f7c95e97c1122c1c818 in Linus' tree.

Note You need to log in before you can comment on or make changes to this bug.