linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

           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).