From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Moritz Muehlenhoff <jmm@inutil.org>,
linux-fbdev-devel@lists.sourceforge.net
Subject: Re: Linux 2.6.12-rc2
Date: Thu, 26 May 2005 15:14:58 +1000 [thread overview]
Message-ID: <1117084498.9076.57.camel@gaston> (raw)
In-Reply-To: <20050525215637.252cbaba.akpm@osdl.org>
On Wed, 2005-05-25 at 21:56 -0700, Andrew Morton wrote:
> Moritz Muehlenhoff <jmm@inutil.org> wrote:
> >
> > Linus Torvalds wrote:
> > > Benjamin Herrenschmidt:
> > > o radeonfb: Implement proper workarounds for PLL accesses
> > > o radeonfb: DDC i2c fix
> > > o radeonfb: Fix mode setting on CRT monitors
> > > o radeonfb: Preserve TMDS setting
> >
> > One of these patches introduced two regressions on my Thinkpad X31 with
> > "ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])":
> >
> > 1. When resuming from S3 suspend and having switched off the backlight
> > with radeontool the backlight isn't switched back on any more.
> >
> > 2. I'm using fbcon as my primary work environment, but tty switching has
> > become _very_ sloppy, it's at least a second now, while with 2.6.11 it
> > was as fast as a few ms. Is this caused by the "proper PLL accesses"?
> >
>
> Moritz, can you tell us whether either of these problems remain in 2.6.12-rc5?
The later will not be fixed. It's a side effect of some workarounds ATI
had me put in for the M6 which has a theorical hardware bug... unless we
decide the bug never happens and comment out the fix =P
The former, I'm not sure. x86 BIOSes are doing all sort of funny things,
I'm not sure what's going on specifically in this case. Also, the
backlight control code has known issues that I haven't find a way to fix
completely for everybody yet, it seems that different "races" of panels
need different solutions here, and by fixing one sort, I break another.
I'm still trying to get ATI to give me more infos about that, but
without luck so far.
However, why would you need to switch the backlight off with radeontool
when going to S3 ? You should let the firmware do it, or radeonfb do it,
but not manually. What if you just leave it "alone", what happens when
you go to/from S3 ? And if stays off, can you bring it back with
radeontool ?
Ben.
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
next prev parent reply other threads:[~2005-05-26 5:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.58.0504040945100.32180@ppc970.osdl.org>
[not found] ` <Pine.LNX.4.58.0504041430070.2215@ppc970.osdl.org>
[not found] ` <E1DJE6t-0001T5-UD@localhost.localdomain>
2005-05-26 4:56 ` Linux 2.6.12-rc2 Andrew Morton
2005-05-26 5:14 ` Benjamin Herrenschmidt [this message]
2005-05-26 10:45 ` Moritz Muehlenhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1117084498.9076.57.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=jmm@inutil.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox