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 <[email protected]> --- 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:
pgp27gfzcF5nk.pgp
Description: PGP signature
- Prev by Date: Re: RFC: disk geometry via sysfs
- Next by Date: Re: Stuck creating sysfs hooks for a driver..
- Previous by thread: Linux time routines
- Next by thread: Fucking St.Valentine
- Index(es):
 |