From: Christian Trefzer <ctrefzer@gmx.de>
To: Andrew Morton <akpm@osdl.org>
Cc: torvalds@osdl.org, adaplas@pol.net,
linux-fbdev-devel@lists.sourceforge.net,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 24/24] neofb: avoid resetting display config on unblank
Date: Wed, 15 Feb 2006 09:42:35 +0100 [thread overview]
Message-ID: <20060215084235.GA10220@zeus.uziel.local> (raw)
In-Reply-To: <20060214215943.37902fc4.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]
Hi Andrew,
first of all, my apologies for this mess. Finally, I got things right
wrt. the driver, now let me see if I can submit the patch properly, for
once : /
On Tue, Feb 14, 2006 at 09:59:43PM -0800, Andrew Morton wrote:
> The earlier patch has already been merged. Please check that the version
> which I merged into -mm still makes sense.
>
> The above isn't a very good changelog entry. It doesn't tell us what
> problem the patch fixes and it doesn't tell us how it fixes it.
Thanks for the slap. Here goes:
Actually, there were two mistakes in the register-read-on-(un)blank
approach.
- First, without proper register (un)locking the value read back will
always be zero, and this is what I missed entirely until just now. Due
to this, the logic could not be verified at all and I tried some bogus
checks which are completely stupid.
- Second, the LCD status bit will always be set to zero when the
backlight has been turned off. Reading the value back during unblank
will disable the LCD unconditionally, regardless of the state it is
supposed to be in, since we set it to zero beforehand.
So this is what we do now:
- create a new variable in struct neofb_par, and use that to determine
whether to read back registers (initialized to true)
- before actually blanking the screen, read back the register to sense
any possible change made through Fn key combo
- use proper neoUnlock() / neoLock() to actually read something
- every call to neofb_blank() determines if we read back next time:
blanking disables readback, unblanking (FB_BLANK_UNBLANK) enables it
This should give us a nice and clean state machine. Has been thoroughly
tested on a Dell Latitude CPiA / NM220 Chip docked to a C/Dock2 with
attached CRT in all possible combinations of LCD/CRT on/off. I changed
the config via Fn key, let the console blank, unblanked by keypress -
works flawlessly.
Below patch applies against what should currently be in Linus' tree, as
my previous error-prone attempt has already been merged. I'd call this
neofb-read-display-config-properly.patch as it applies on top of my
previous already-merged mess.
Andrew, please discard any other patches of mine still in -mm, this
would be the solution to this issue unless somebody else finds a
problem.
The only problem left wrt. neofb AFAICS would be the initialization of
CRT-only resulting in no signal being received by the monitor. This is
in no way changed by any of my patches.
> "Signed-off-by:", please.
Signed-off-by: Christian Trefzer <ctrefzer@gmx.de>
--- a/include/video/neomagic.h 2006-01-03 04:21:10.000000000 +0100
+++ b/include/video/neomagic.h 2006-02-09 20:59:20.164839408 +0100
@@ -159,6 +159,7 @@
unsigned char PanelDispCntlReg1;
unsigned char PanelDispCntlReg2;
unsigned char PanelDispCntlReg3;
+ unsigned char PanelDispCntlRegRead;
unsigned char PanelVertCenterReg1;
unsigned char PanelVertCenterReg2;
unsigned char PanelVertCenterReg3;
--- a/drivers/video/neofb.c 2006-02-15 06:27:58.000000000 +0100
+++ b/drivers/video/neofb.c 2006-02-15 08:56:14.295858976 +0100
@@ -843,6 +843,9 @@
par->SysIfaceCntl2 = 0xc0; /* VESA Bios sets this to 0x80! */
+ /* Initialize: by default, we want display config register to be read */
+ par->PanelDispCntlRegRead = 1;
+
/* Enable any user specified display devices. */
par->PanelDispCntlReg1 = 0x00;
if (par->internal_display)
@@ -1334,12 +1337,16 @@
struct neofb_par *par = (struct neofb_par *)info->par;
int seqflags, lcdflags, dpmsflags, reg;
- /*
- * Reload the value stored in the register, might have been changed via
- * FN keystroke
- */
- par->PanelDispCntlReg1 = vga_rgfx(NULL, 0x20) & 0x03;
+ /* Reload the value stored in the register, if sensible. It might have
+ * been changed via FN keystroke. */
+ if (par->PanelDispCntlRegRead) {
+ neoUnlock();
+ par->PanelDispCntlReg1 = vga_rgfx(NULL, 0x20) & 0x03;
+ neoLock(&par->state);
+ }
+ par->PanelDispCntlRegRead = !blank_mode;
+
switch (blank_mode) {
case FB_BLANK_POWERDOWN: /* powerdown - both sync lines down */
seqflags = VGA_SR01_SCREEN_OFF; /* Disable sequencer */
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
parent reply other threads:[~2006-02-15 8:42 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20060214215943.37902fc4.akpm@osdl.org>]
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=20060215084235.GA10220@zeus.uziel.local \
--to=ctrefzer@gmx.de \
--cc=adaplas@pol.net \
--cc=akpm@osdl.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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;
as well as URLs for NNTP newsgroup(s).