[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702220054460.17121@pentafluge.infradead.org>
Date: Thu, 22 Feb 2007 01:07:38 +0000 (GMT)
From: James Simmons <jsimmons@...radead.org>
To: Richard Purdie <rpurdie@...ys.net>
cc: Yaroslav Halchenko <lists@...russian.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: no backlight on radeon after recent kernel "upgrade"s
> On Wed, 2007-02-21 at 00:56 -0500, Yaroslav Halchenko wrote:
> > I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
> > Iv'e tried, but, once again, I experienced the same issue with 19-mm?
> > kernels.
> >
> > I built 2.6.20-mm2 without backlight support
> > $> grep BACKLIGH /boot/config-2.6.20-mm2
> > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> > # CONFIG_FB_BACKLIGHT is not set
> > # CONFIG_FB_RIVA_BACKLIGHT is not set
> > # CONFIG_FB_RADEON_BACKLIGHT is not set
> >
> > that "eliminated" the problem. Also I can see the screen with pure
> > 2.6.20 with backlight support (whatever it does since after
> > loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
> >
> > *$> grep BACKLIGH /boot/config-2.6.20
> > # CONFIG_FB_BACKLIGHT is not set
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > CONFIG_BACKLIGHT_DEVICE=y
> >
> >
> > > Also, do you normally see files under /sys/class/lcd?
> > nope... after I load lcd module, no files under :-/ regardless either it
> > is mm or not. But there are files under /sys/class/backlight/ for mm2
> > compiled with backlight support (whenever the screen is dark as per my
> > original email)
>
> There should be no files appearing under /sys/class/lcd, so thats all
> normal. There is another report with similar symptoms which also sounds
> like enabling the following options are at fault:
Correct. LCD class was never used by anyone.
> # CONFIG_FB_RIVA_BACKLIGHT is not set
> # CONFIG_FB_RADEON_BACKLIGHT is not set
>
> I suspect these options only work on certain hardware and aren't
> generic. James, any idea what hardware these do/don't work with?
>
> Worst case, we set them to depend on PMAC_BACKLIGHT again I guess...
Ug. Previously it did the selecting for you. If you selected
backlight support the fbdev backlight would just come to life. This caused
problems for the case of having ACPI backlight and a fbdev driver with
backlight support. Two drivers controling the same hardware is not the
greatest idea. I made it so that people explictly had to pick the backlight
with a fbdev device. The other reason for this change was not every
one is using a LCD display. I have a system at home that uses a CRT.
Plus their is the case of "standard" PC graphics cards being used
in embedded devices. In this case even tho the graphics card has backlight
support the external lcd/backlight is routed through gpio independent of
the embedded graphics card. In such case we don't want to enable the
backlight for the graphics card but enable it.
In a nut shell the solution is select the backlight support for your
fbdev driver if you need it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists