Possible patch for Dell keyboard lockup

[Pete Zaitcev]

Hello, All:

I have a situation where a Dell laptop would loose its
keyboard after resume (thanks to Ben LaHaise for
diagnosing this probelm). BIOS enables touchpad
when resumed and if a user touches touchpad, "hardware"
delivers IRQ 12 and will not deliver IRQ 1 until we
process the mouse event. Which we do not (in case
a USB mouse is used, for instance).

I may do what BIOS ought to do upon suspend, but it
does not feel right. So... do we need anything like that?
If yes, I may polish it up w.r.t. non-x86 etc.

-- Pete

diff -ur -X dontdiff linux-2.4.2-0.1.32/drivers/char/keyboard.c linux-2.4.2-0.1.32-p3/drivers/char/keyboard.c
--- linux-2.4.2-0.1.32/drivers/char/keyboard.c	Mon Mar 26 16:59:28 2001
+++ linux-2.4.2-0.1.32-p3/drivers/char/keyboard.c	Wed Mar 28 15:33:47 2001
@@ -162,6 +162,14 @@
 
 static struct pm_dev *pm_kbd;
 
+static int pm_kbd_request(struct pm_dev *dev, pm_request_t req, void *data)
+{
+	if (req == PM_RESUME) {
+		kbd_pm_resume();
+	}
+	return 0;
+}
+
 /*
  * Many other routines do put_queue, but I think either
  * they produce ASCII, or they produce some user-assigned
@@ -934,7 +942,7 @@
 	tasklet_enable(&keyboard_tasklet);
 	tasklet_schedule(&keyboard_tasklet);
 	
-	pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, NULL);
+	pm_kbd = pm_register(PM_SYS_DEV, PM_SYS_KBC, pm_kbd_request);
 
 	return 0;
 }
diff -ur -X dontdiff linux-2.4.2-0.1.32/drivers/char/pc_keyb.c linux-2.4.2-0.1.32-p3/drivers/char/pc_keyb.c
--- linux-2.4.2-0.1.32/drivers/char/pc_keyb.c	Mon Mar 26 17:00:03 2001
+++ linux-2.4.2-0.1.32-p3/drivers/char/pc_keyb.c	Wed Mar 28 15:41:06 2001
@@ -530,6 +530,31 @@
 	}
 }
 
+void pckbd_pm_resume(void)
+{
+	unsigned int flags;
+
+/* P3 */ printk("pckbd_pm_resume: queue %p aux_count %d\n", queue, aux_count);
+	if (queue) {			/* Aux port detected */
+		if (aux_count == 0) {	/* Mouse not in use */
+			spin_lock_irqsave(&kbd_controller_lock, flags);
+			/*
+			 * Dell Lat. C600 A06 enables mouse after resume.
+			 * When user touches the pad, it posts IRQ 12
+			 * (which we do not process), thus holding keyboard.
+			 */
+			kbd_write_command(KBD_CCMD_MOUSE_DISABLE);
+			/* kbd_write_cmd(AUX_INTS_OFF); */ /* Config & lock */
+			kb_wait();
+			kbd_write_command(KBD_CCMD_WRITE_MODE);
+			kb_wait();
+			kbd_write_output(AUX_INTS_OFF);
+			spin_unlock_irqrestore(&kbd_controller_lock, flags);
+/* P3 */ printk("pckbd_pm_resume: done\n");
+		}
+	}
+}
+
 /*
  * In case we run on a non-x86 hardware we need to initialize both the
  * keyboard controller and the keyboard.  On a x86, the BIOS will
diff -ur -X dontdiff linux-2.4.2-0.1.32/include/asm-i386/keyboard.h linux-2.4.2-0.1.32-p3/include/asm-i386/keyboard.h
--- linux-2.4.2-0.1.32/include/asm-i386/keyboard.h	Wed Feb 21 19:11:45 2001
+++ linux-2.4.2-0.1.32-p3/include/asm-i386/keyboard.h	Wed Mar 28 15:11:13 2001
@@ -26,6 +26,7 @@
 			   char raw_mode);
 extern char pckbd_unexpected_up(unsigned char keycode);
 extern void pckbd_leds(unsigned char leds);
+extern void pckbd_pm_resume(void);
 extern void pckbd_init_hw(void);
 extern unsigned char pckbd_sysrq_xlate[128];
 
@@ -34,6 +35,7 @@
 #define kbd_translate		pckbd_translate
 #define kbd_unexpected_up	pckbd_unexpected_up
 #define kbd_leds		pckbd_leds
+#define kbd_pm_resume		pckbd_pm_resume
 #define kbd_init_hw		pckbd_init_hw
 #define kbd_sysrq_xlate		pckbd_sysrq_xlate