public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jordan Crouse" <jordan.crouse-5C7GfCeVMHo@public.gmane.org>
To: linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: apm_console_blank()
Date: Mon, 28 Mar 2005 10:20:35 -0700	[thread overview]
Message-ID: <20050328102035.5fcd9a61@cosmic.amd.com> (raw)
In-Reply-To: <1111963367.3503.152.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

Everyone, put on your legacy helmets... :)

Attached is a diff against apm.c fixing what I think was a flaw in
the logic of the function apm_console_blank().

Previously, the code tried to power down device 0x100, and, unless that
returned no error, it tried to do the same to device 0x1FF, and unless
*that* returned no error, it tried to power down device 0x101. 
Then, it would try to engage the power management or return a
message based on only the error message of the last call.

Now, it turns out that page 41 of the APM specification indicates that
the system should be engaged, but the devices should start out
disengaged, which is what our BIOS does.  I do understand the system is
engaged at boot time if the apm_bios flags indicate APM_BIOS_DISENGAGED.
What I don't know is if our BIOS should be setting this flag or
not (normally when I get bugs like this, I question why thousands of
systems before me have somehow managed to do the right thing, and it
usually means that we're doing something boneheaded).

If it is not critical that the BIOS be engaged at boot time, then one
would expect that a device could possibly still be disengaged when the
console tries to blank the screen.  So, I went ahead and modified the
code slightly so that any set_power_state() call that returns
NOT_ENGAGED will go ahead and try to engage the device.

Comments and flames welcome.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>


--- linux-2.6.11.orig/arch/i386/kernel/apm.c	2005-03-28 10:05:01.000000000 -0700
+++ linux-2.6.11/arch/i386/kernel/apm.c	2005-03-28 10:05:12.000000000 -0700
@@ -1058,25 +1058,26 @@
  *	all video devices. Typically the BIOS will do laptop backlight
and  *	monitor powerdown for us.
  */
- 
-static int apm_console_blank(int blank)
-{
-	int	error;
-	u_short	state;
+
+static int apm_console_blank(int blank) {
+	
+	int error, i;
+	u_short state;
+	u_short dev[3] = { 0x100, 0x1FF, 0x101 };
 
 	state = blank ? APM_STATE_STANDBY : APM_STATE_READY;
-	/* Blank the first display device */
-	error = set_power_state(0x100, state);
-	if ((error != APM_SUCCESS) && (error != APM_NO_ERROR)) {
-		/* try to blank them all instead */
-		error = set_power_state(0x1ff, state);
-		if ((error != APM_SUCCESS) && (error != APM_NO_ERROR))
-			/* try to blank device one instead */
-			error = set_power_state(0x101, state);
+
+	for(i = 0; i < 3; i++) {		
+		error = set_power_state(dev[i], state);
+
+		if ((error == APM_SUCCESS) || (error == APM_NO_ERROR))
+			return 1;
+
+		if (error == APM_NOT_ENGAGED)
+			break;	       
 	}
-	if ((error == APM_SUCCESS) || (error == APM_NO_ERROR))
-		return 1;
-	if (error == APM_NOT_ENGAGED) {
+
+	if (error == APM_NOT_ENGAGED && state != APM_STATE_READY) {
 		static int tried;
 		int eng_error;
 		if (tried++ == 0) {
@@ -1089,7 +1090,8 @@
 				return apm_console_blank(blank);
 		}
 	}
-	apm_error("set display", error);
+
+	apm_error("set display", error);	
 	return 0;
 }
 #endif







[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2005-03-28 17:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-27 22:42 [RFC] Driver States Adam Belay
     [not found] ` <1111963367.3503.152.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2005-03-28 16:29   ` Jordan Crouse
     [not found]     ` <20050328092925.2c2736de-aftB2sG12IhaqnLngUycEA@public.gmane.org>
2005-04-01  4:01       ` David Brownell
2005-03-28 17:20   ` Jordan Crouse [this message]
     [not found]     ` <20050328102035.5fcd9a61-aftB2sG12IhaqnLngUycEA@public.gmane.org>
2005-03-29 18:51       ` apm_console_blank() Pavel Machek
2005-03-30  5:57   ` [RFC] Driver States Patrick Mochel
     [not found]     ` <Pine.LNX.4.50.0503292155120.26543-100000-x8k/2hhmB0w5etPau2IXcQ@public.gmane.org>
2005-03-30 22:45       ` Adam Belay
2005-04-05  9:24         ` Pavel Machek
2005-04-06 19:51           ` Adam Belay
2005-04-08 10:31             ` Pavel Machek

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=20050328102035.5fcd9a61@cosmic.amd.com \
    --to=jordan.crouse-5c7gfcevmho@public.gmane.org \
    --cc=linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.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