Re: i8042 access timings
On Sun, Feb 13, 2005 at 09:22:46AM +0100, Vojtech Pavlik wrote: > And I suppose it was running just fine without the patch as well? Correct. > The question was whether the patch helps, or whether it is not needed. If you look again at the patch I posted, it only borrowed a few lines of the patch from Dmitry that started this thread; I eliminated Alan's recent udelay(50) addition, reduced the loop delay, and added debug printks to the *_wait routines to determine whether the loop is ever taken. At least so far, those debugging statements have produced no output. I'll use the machine a bit and report back if I trigger anything. Regards, Bill Rugolsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Sat, Feb 12, 2005 at 07:16:59PM -0500, Bill Rugolsky Jr. wrote: > Sorry for the long delay in replying; the HiNote needed some effort to get > the thing up and running again. [Various bits of hardware are broken; > the power switch, floppy, and CD-ROM are busted/flakey.] I've now got > Fedora Core 3 running on it. I was pleasantly surprised that the 2.6.9 > i83265 PCMCIA module loads, and the internal Xircom CEM56 network/modem works. > [Broken with 2.6.10+ though; the fix is probably trivial.] > > I wasn't sure exactly what to test. I applied the following patch > to 2.6.11-rc3-bk9, and booted with i8042_debug=1. So far, it works > as expected, and there is nothing of interest in the kernel log. > [Also worked with the FC3 2.6.9 kernel and this patch+DEBUG.] > > Now that things are up and running, I will apply any patches that you > would like tested. And I suppose it was running just fine without the patch as well? The question was whether the patch helps, or whether it is not needed. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Sat, Feb 12, 2005 at 07:16:59PM -0500, Bill Rugolsky Jr. wrote: Sorry for the long delay in replying; the HiNote needed some effort to get the thing up and running again. [Various bits of hardware are broken; the power switch, floppy, and CD-ROM are busted/flakey.] I've now got Fedora Core 3 running on it. I was pleasantly surprised that the 2.6.9 i83265 PCMCIA module loads, and the internal Xircom CEM56 network/modem works. [Broken with 2.6.10+ though; the fix is probably trivial.] I wasn't sure exactly what to test. I applied the following patch to 2.6.11-rc3-bk9, and booted with i8042_debug=1. So far, it works as expected, and there is nothing of interest in the kernel log. [Also worked with the FC3 2.6.9 kernel and this patch+DEBUG.] Now that things are up and running, I will apply any patches that you would like tested. And I suppose it was running just fine without the patch as well? The question was whether the patch helps, or whether it is not needed. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Sun, Feb 13, 2005 at 09:22:46AM +0100, Vojtech Pavlik wrote: And I suppose it was running just fine without the patch as well? Correct. The question was whether the patch helps, or whether it is not needed. If you look again at the patch I posted, it only borrowed a few lines of the patch from Dmitry that started this thread; I eliminated Alan's recent udelay(50) addition, reduced the loop delay, and added debug printks to the *_wait routines to determine whether the loop is ever taken. At least so far, those debugging statements have produced no output. I'll use the machine a bit and report back if I trigger anything. Regards, Bill Rugolsky - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 05:37:14PM +0100, Vojtech Pavlik wrote:
> On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
> > I have a Digital HiNote collecting dust which had this keyboard problem
> > with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like,
> > but I won't be able to get to it until the weekend.
>
> That'd be very nice indeed.
Sorry for the long delay in replying; the HiNote needed some effort to get
the thing up and running again. [Various bits of hardware are broken;
the power switch, floppy, and CD-ROM are busted/flakey.] I've now got
Fedora Core 3 running on it. I was pleasantly surprised that the 2.6.9
i83265 PCMCIA module loads, and the internal Xircom CEM56 network/modem works.
[Broken with 2.6.10+ though; the fix is probably trivial.]
I wasn't sure exactly what to test. I applied the following patch
to 2.6.11-rc3-bk9, and booted with i8042_debug=1. So far, it works
as expected, and there is nothing of interest in the kernel log.
[Also worked with the FC3 2.6.9 kernel and this patch+DEBUG.]
Now that things are up and running, I will apply any patches that you
would like tested.
Bill Rugolsky
--- linux/drivers/input/serio/i8042.c.udelay-backout2005-02-12
16:22:48.647851998 -0500
+++ linux/drivers/input/serio/i8042.c 2005-02-12 16:23:39.963997609 -0500
@@ -131,9 +131,10 @@
{
int i = 0;
while ((~i8042_read_status() & I8042_STR_OBF) && (i <
I8042_CTL_TIMEOUT)) {
- udelay(50);
+ udelay(I8042_STR_DELAY);
i++;
}
+ if (i > 0) dbg("i8042_wait_read: looped %d times",i);
return -(i == I8042_CTL_TIMEOUT);
}
@@ -141,9 +142,10 @@
{
int i = 0;
while ((i8042_read_status() & I8042_STR_IBF) && (i <
I8042_CTL_TIMEOUT)) {
- udelay(50);
+ udelay(I8042_STR_DELAY);
i++;
}
+ if (i > 0) dbg("i8042_wait_write: looped %d times",i);
return -(i == I8042_CTL_TIMEOUT);
}
@@ -161,7 +163,6 @@
spin_lock_irqsave(_lock, flags);
while ((i8042_read_status() & I8042_STR_OBF) && (i++ <
I8042_BUFFER_SIZE)) {
- udelay(50);
data = i8042_read_data();
dbg("%02x <- i8042 (flush, %s)", data,
i8042_read_status() & I8042_STR_AUXDATA ? "aux" :
"kbd");
--- linux/drivers/input/serio/i8042.h.udelay-backout2005-02-12
16:22:48.647851998 -0500
+++ linux/drivers/input/serio/i8042.h 2005-02-12 16:23:39.964997456 -0500
@@ -30,12 +30,18 @@
#endif
/*
- * This is in 50us units, the time we wait for the i8042 to react. This
+ * The time (in us) that we wait for the i8042 to react.
+ */
+
+#define I8042_STR_DELAY20
+
+/*
+ * This is in units of the time we wait for the i8042 to react. This
* has to be long enough for the i8042 itself to timeout on sending a byte
* to a non-existent mouse.
*/
-#define I8042_CTL_TIMEOUT 1
+#define I8042_CTL_TIMEOUT 25000
/*
* When the device isn't opened and it's interrupts aren't used, we poll it at
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 05:37:14PM +0100, Vojtech Pavlik wrote:
On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
I have a Digital HiNote collecting dust which had this keyboard problem
with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like,
but I won't be able to get to it until the weekend.
That'd be very nice indeed.
Sorry for the long delay in replying; the HiNote needed some effort to get
the thing up and running again. [Various bits of hardware are broken;
the power switch, floppy, and CD-ROM are busted/flakey.] I've now got
Fedora Core 3 running on it. I was pleasantly surprised that the 2.6.9
i83265 PCMCIA module loads, and the internal Xircom CEM56 network/modem works.
[Broken with 2.6.10+ though; the fix is probably trivial.]
I wasn't sure exactly what to test. I applied the following patch
to 2.6.11-rc3-bk9, and booted with i8042_debug=1. So far, it works
as expected, and there is nothing of interest in the kernel log.
[Also worked with the FC3 2.6.9 kernel and this patch+DEBUG.]
Now that things are up and running, I will apply any patches that you
would like tested.
Bill Rugolsky
--- linux/drivers/input/serio/i8042.c.udelay-backout2005-02-12
16:22:48.647851998 -0500
+++ linux/drivers/input/serio/i8042.c 2005-02-12 16:23:39.963997609 -0500
@@ -131,9 +131,10 @@
{
int i = 0;
while ((~i8042_read_status() I8042_STR_OBF) (i
I8042_CTL_TIMEOUT)) {
- udelay(50);
+ udelay(I8042_STR_DELAY);
i++;
}
+ if (i 0) dbg(i8042_wait_read: looped %d times,i);
return -(i == I8042_CTL_TIMEOUT);
}
@@ -141,9 +142,10 @@
{
int i = 0;
while ((i8042_read_status() I8042_STR_IBF) (i
I8042_CTL_TIMEOUT)) {
- udelay(50);
+ udelay(I8042_STR_DELAY);
i++;
}
+ if (i 0) dbg(i8042_wait_write: looped %d times,i);
return -(i == I8042_CTL_TIMEOUT);
}
@@ -161,7 +163,6 @@
spin_lock_irqsave(i8042_lock, flags);
while ((i8042_read_status() I8042_STR_OBF) (i++
I8042_BUFFER_SIZE)) {
- udelay(50);
data = i8042_read_data();
dbg(%02x - i8042 (flush, %s), data,
i8042_read_status() I8042_STR_AUXDATA ? aux :
kbd);
--- linux/drivers/input/serio/i8042.h.udelay-backout2005-02-12
16:22:48.647851998 -0500
+++ linux/drivers/input/serio/i8042.h 2005-02-12 16:23:39.964997456 -0500
@@ -30,12 +30,18 @@
#endif
/*
- * This is in 50us units, the time we wait for the i8042 to react. This
+ * The time (in us) that we wait for the i8042 to react.
+ */
+
+#define I8042_STR_DELAY20
+
+/*
+ * This is in units of the time we wait for the i8042 to react. This
* has to be long enough for the i8042 itself to timeout on sending a byte
* to a non-existent mouse.
*/
-#define I8042_CTL_TIMEOUT 1
+#define I8042_CTL_TIMEOUT 25000
/*
* When the device isn't opened and it's interrupts aren't used, we poll it at
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote: > On Fri, 28 Jan 2005, Jaco Kroon wrote: > > >> > > >>ok, how would I try this? Where can I find an example to code it from? > > >> Sorry, I should probably be grepping ... > > > If the udelay() didn't work, then this one isn't worth worryign about > > > either. Back to the drawing board. > > Yea. But for interrests sake, what do you mean with a serializing IO > > instruction? > > If you use "outb_p()" instead of an "outb()", the regular IO instruction > will be followed by another out to another port on the motherboard: that > will not only cause a delay, it should also force at least the host bridge > to have no outstanding posted writes (the host bridge shouldn't post IO > port writes anyway, but hey, it won't hurt to try to make even more sure > of that). > > > I also tried increasing the total timeout value to about 5 seconds > > (versus the default half second), still no success, so the device is > > simply not sending back the requested values. > > If it was the other way around (that it works with ACPI _on_), I'd assume > that ACPI just disables some broken BIOS SMM emulation code. But I just > don't see ACPI _enabling_ SMM emulation. That would be just too strange, > and against the whole point of the legacy keyboard emulation stuff - you > want to do legacy keyboard emulation if the OS is old, not if it's new. > > It may be that ACPI ends up enabling some silly power control SMM sequence > that wakes up on keyboard accesses, and screws up the emulation. That > sounds pretty strange too, I have to say - even if SMM/ACPI would like to > trap keyboard command sequences, I'd have expected it to just pass them > through after looking at them. > > One option may be that SMM/ACPI traps the _received_ characters, and > incorrectly eats the reply, because it thinks it's some special key > sequence (and should cause SMM/ACPI to make the screen brighter or > something silly like that). > > Does anybody know/remember what the keycode 0xA5 means? So far , the only place I can find a 0xA5 is under the PS/2 Keyboard numbers and scan codes. KeyNumber Set 1 Make/Break Set 2 Make/Break Set 3 Make/Break Base Case Uppercase 38 25/A542/F0 42 42/F0 42 k K I am not familiar with how PS/2 uses it scan code. Unlike the AT it only have one Scan code to a Key Number. > > > > I still stand with the theory that it is sending back the value we want > > for the first request on the second one (managed to get this one by > > explicitly turning i8042_debug on and off in the code): > > > > i8042_init() > > ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 > > ACPI: PS/2 Mouse Controller [MSE0] at irq 12 > > i8042_controller_init() > > i8042_flush() > > drivers/input/serio/i8042.c: 20 -> i8042 (command) [4] > > drivers/input/serio/i8042.c: 47 <- i8042 (return) [4] > > drivers/input/serio/i8042.c: 60 -> i8042 (command) [5] > > drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5] > > i8042_check_aux() > > drivers/input/serio/i8042.c: Interrupt 12, without any data [9] > > i8042_flush() > > drivers/input/serio/i8042.c: d3 -> i8042 (command) [13] > > drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13] > > drivers/input/serio/i8042.c: -- i8042 (timeout) [875] > > i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1 > > drivers/input/serio/i8042.c: a9 -> i8042 (command) [879] > > drivers/input/serio/i8042.c: a5 <- i8042 (return) [879] > > i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0 > > > > I've rebooted a couple of times and that interrupt is in exactly the > > same place every time. And int 12 is indeed the AUX device, could this > > be a clue? > > Does it change if you change the initial value of "param" (0x5a) to > something else? > > Linus > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote: On Fri, 28 Jan 2005, Jaco Kroon wrote: ok, how would I try this? Where can I find an example to code it from? Sorry, I should probably be grepping ... If the udelay() didn't work, then this one isn't worth worryign about either. Back to the drawing board. Yea. But for interrests sake, what do you mean with a serializing IO instruction? If you use outb_p() instead of an outb(), the regular IO instruction will be followed by another out to another port on the motherboard: that will not only cause a delay, it should also force at least the host bridge to have no outstanding posted writes (the host bridge shouldn't post IO port writes anyway, but hey, it won't hurt to try to make even more sure of that). I also tried increasing the total timeout value to about 5 seconds (versus the default half second), still no success, so the device is simply not sending back the requested values. If it was the other way around (that it works with ACPI _on_), I'd assume that ACPI just disables some broken BIOS SMM emulation code. But I just don't see ACPI _enabling_ SMM emulation. That would be just too strange, and against the whole point of the legacy keyboard emulation stuff - you want to do legacy keyboard emulation if the OS is old, not if it's new. It may be that ACPI ends up enabling some silly power control SMM sequence that wakes up on keyboard accesses, and screws up the emulation. That sounds pretty strange too, I have to say - even if SMM/ACPI would like to trap keyboard command sequences, I'd have expected it to just pass them through after looking at them. One option may be that SMM/ACPI traps the _received_ characters, and incorrectly eats the reply, because it thinks it's some special key sequence (and should cause SMM/ACPI to make the screen brighter or something silly like that). Does anybody know/remember what the keycode 0xA5 means? So far , the only place I can find a 0xA5 is under the PS/2 Keyboard numbers and scan codes. KeyNumber Set 1 Make/Break Set 2 Make/Break Set 3 Make/Break Base Case Uppercase 38 25/A542/F0 42 42/F0 42 k K I am not familiar with how PS/2 uses it scan code. Unlike the AT it only have one Scan code to a Key Number. I still stand with the theory that it is sending back the value we want for the first request on the second one (managed to get this one by explicitly turning i8042_debug on and off in the code): i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 - i8042 (command) [4] drivers/input/serio/i8042.c: 47 - i8042 (return) [4] drivers/input/serio/i8042.c: 60 - i8042 (command) [5] drivers/input/serio/i8042.c: 56 - i8042 (parameter) [5] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [9] i8042_flush() drivers/input/serio/i8042.c: d3 - i8042 (command) [13] drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13] drivers/input/serio/i8042.c: -- i8042 (timeout) [875] i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1 drivers/input/serio/i8042.c: a9 - i8042 (command) [879] drivers/input/serio/i8042.c: a5 - i8042 (return) [879] i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0 I've rebooted a couple of times and that interrupt is in exactly the same place every time. And int 12 is indeed the AUX device, could this be a clue? Does it change if you change the initial value of param (0x5a) to something else? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Saturday 29 January 2005 14:59, Jaco Kroon wrote: > > Compiling USB 1.1 support does the very same thing as specifying > > usb-handoff on the command like - tells the BIOS to keep its hands off > > the USB _and_ PS/2 controllers. > > I'm missing something, I have USB1.1 compiled in, then why does the > touchpad not work if it does the very same thing as usb-handoff? USB initializes very late, after i8042 and psmouse has already run their probes. So unless there is "usb-handoff" psmouse talks to a fake BIOS-emulated mouse, not a real touchpad. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Vojtech Pavlik wrote: On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote: Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. Ok, I'm not too clued up with recent hardware and the BIOS programming that goes with it (being a system admin/application programmer), what exactly is usb-handoff? usb-handoff is a kernel option that enables a PCI quirk routine that takes the USB controller out of BIOS's hands. Until that is done (the linux USB drivers also do it, only later), the BIOS owns the USB controller and tries to emulate a PS/2 mouse and keyboard for systems which can't handle USB. acpi=off obviously just turns all acpi support in the kernel off. Indeed. SCI is also a new abbreviation I haven't seen before. System Configuration Interrupt. In addition to SMI (System Management Interrupt), these are two interrupts the BIOS uses to do its job behind the operating system's back. ACPI 2.0 spec says: System Control Interrupt (SCI) A system interrupt used by hardware to notify the OS of ACPI events. The SCI is an active, low, shareable, level interrupt. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Vojtech Pavlik wrote: What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. This makes sense in a weird kind of way. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. SCI interrupt routing? I have tried with pci=routeirq and that hasn't helped either. IRQ balancing perhaps? I don't like the interrupt message, I'll check why it's enabled so early. It may have a good reason to, as well. Other than that, it looks very much OK. That was with usb-handoff. It also resulted in the black screen of bios-death upon reboot though :). So as with acpi=off, we get a correct return. Now that usb is mentioned, I think either myself or Sebastian has mentioned that the keyboard does not work unless USB1.1 support is compiled in. Another clue possibly? Compiling USB 1.1 support does the very same thing as specifying usb-handoff on the command like - tells the BIOS to keep its hands off the USB _and_ PS/2 controllers. I'm missing something, I have USB1.1 compiled in, then why does the touchpad not work if it does the very same thing as usb-handoff? Another question - would it be usefull at all to see what happens if the AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST rely on the fact that AUX_LOOP must first fail/timeout somehow? No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail similarly when BIOS is active. That is correct. It fails with timeout. This for me confirms the fact that it is responding one command too late. aka, we send a command, it times out, we send another, it sends the result of the first. Right, any new (or variations of existing ones) theories that I can try out to make this touchpad work correctly? I can simply hack out the test for the touchpad but that doesn't solve the problem for others. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ smime.p7s Description: S/MIME Cryptographic Signature
Re: i8042 access timings
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote: > Vojtech Pavlik wrote: > >On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: > > > > > >>>So what _might_ happen is that we write the command, and then > >>>i8042_wait_write() thinks that there is space to write the data > >>>immediately, and writes the data, but now the data got lost because the > >>>buffer was busy. > >> > >>Hmm - I just answered the same post and concluded that I didnt understand, > >>so you have progressed further. I considered the same possibility, > >>but the data was not lost since we read it again later. > >>Only the ready flag was lost. > > > > > >What I believe is happening is that we're talking to SMM emulation of > >the i8042, which doesn't have a clue about these commands, while the > >underlying real hardware implementation does. And because of that they > >disagree on what should happen when the command is issued, and since the > >SMM emulation lazily synchronizes with the real HW, we only get the data > >back with the next command. > > > >I still don't have an explanation why both 'usb-handoff' and 'acpi=off' > >help, I'd expect only the first to, but it might be related to the SCI > >interrupt routing which isn't done when 'acpi=off'. Just a wild guess. > > > > Ok, I'm not too clued up with recent hardware and the BIOS programming > that goes with it (being a system admin/application programmer), what > exactly is usb-handoff? usb-handoff is a kernel option that enables a PCI quirk routine that takes the USB controller out of BIOS's hands. Until that is done (the linux USB drivers also do it, only later), the BIOS owns the USB controller and tries to emulate a PS/2 mouse and keyboard for systems which can't handle USB. > acpi=off obviously just turns all acpi support > in the kernel off. Indeed. > SCI is also a new abbreviation I haven't seen > before. System Configuration Interrupt. In addition to SMI (System Management Interrupt), these are two interrupts the BIOS uses to do its job behind the operating system's back. > Whilst I've seen SMM before, I'm not sure what it stands for (I SMM is System Management Mode. It's a special mode of the CPU, which is entered when a SMI is triggered by some event, like an port write trap in the case of the emulated PS/2 mouse. Using SMM the BIOS can emulate any device it wishes to, and the OS will think it's real. It's an even more privileged mode than what the OS runs in. > assume it's something to do with simulation of legacy devices for older > operating systems)? It also does thermal monitoring, often is used for turning the backlight off on notebooks, and handling various magic Fn- key combinations. > From the kernel-parameters documentation: > > usb-handoff [HW] Enably early USB BIOS -> OS handoff > > I guess this means the OS takes over control of the USB devices at an > earlier stage than usual - possibly before ACPI gets initialised? Before the i8042 keyboard driver gets initialized. That's the important part, because the handoff stops the BIOS from emulating a PS/2 mouse, and thus blocking access to the real PS/2 mouse controller. > I'm > unable to determine much from looking at drivers/pci/quirks.c (which is > where the usb-handoff parameter is defined). > > usb-handoff=1 does however also fix the problem. Ok. This makes it > even more confusing (and probably more complicated). The appropriate > section from dmesg that shows that it is working correctly: > > i8042_init() > ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 > ACPI: PS/2 Mouse Controller [MSE0] at irq 12 > i8042_controller_init() > i8042_flush() > drivers/input/serio/i8042.c: 20 -> i8042 (command) [4] > drivers/input/serio/i8042.c: 47 <- i8042 (return) [4] > drivers/input/serio/i8042.c: 60 -> i8042 (command) [4] > drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [4] > i8042_check_aux() > drivers/input/serio/i8042.c: Interrupt 12, without any data [8] > i8042_flush() > drivers/input/serio/i8042.c: d3 -> i8042 (command) [13] > drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13] > drivers/input/serio/i8042.c: a5 <- i8042 (return) [13] > i8042_check_aux: passed I don't like the interrupt message, I'll check why it's enabled so early. It may have a good reason to, as well. Other than that, it looks very much OK. > So as with acpi=off, we get a correct return. Now that usb is > mentioned, I think either myself or Sebastian has mentioned that the > keyboard does not work unless USB1.1 support is compiled in. Another > clue possibly? Compiling USB 1.1 support does the very same thing as specifying usb-handoff on the command like - tells the BIOS to keep its hands off the USB _and_ PS/2 controllers. > Another question - would it be usefull at all to see what happens if the > AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST > rely on the fact that AUX_LOOP must first fail/timeout somehow? No. You can
Re: i8042 access timings
On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote: Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. Ok, I'm not too clued up with recent hardware and the BIOS programming that goes with it (being a system admin/application programmer), what exactly is usb-handoff? usb-handoff is a kernel option that enables a PCI quirk routine that takes the USB controller out of BIOS's hands. Until that is done (the linux USB drivers also do it, only later), the BIOS owns the USB controller and tries to emulate a PS/2 mouse and keyboard for systems which can't handle USB. acpi=off obviously just turns all acpi support in the kernel off. Indeed. SCI is also a new abbreviation I haven't seen before. System Configuration Interrupt. In addition to SMI (System Management Interrupt), these are two interrupts the BIOS uses to do its job behind the operating system's back. Whilst I've seen SMM before, I'm not sure what it stands for (I SMM is System Management Mode. It's a special mode of the CPU, which is entered when a SMI is triggered by some event, like an port write trap in the case of the emulated PS/2 mouse. Using SMM the BIOS can emulate any device it wishes to, and the OS will think it's real. It's an even more privileged mode than what the OS runs in. assume it's something to do with simulation of legacy devices for older operating systems)? It also does thermal monitoring, often is used for turning the backlight off on notebooks, and handling various magic Fn- key combinations. From the kernel-parameters documentation: usb-handoff [HW] Enably early USB BIOS - OS handoff I guess this means the OS takes over control of the USB devices at an earlier stage than usual - possibly before ACPI gets initialised? Before the i8042 keyboard driver gets initialized. That's the important part, because the handoff stops the BIOS from emulating a PS/2 mouse, and thus blocking access to the real PS/2 mouse controller. I'm unable to determine much from looking at drivers/pci/quirks.c (which is where the usb-handoff parameter is defined). usb-handoff=1 does however also fix the problem. Ok. This makes it even more confusing (and probably more complicated). The appropriate section from dmesg that shows that it is working correctly: i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 - i8042 (command) [4] drivers/input/serio/i8042.c: 47 - i8042 (return) [4] drivers/input/serio/i8042.c: 60 - i8042 (command) [4] drivers/input/serio/i8042.c: 56 - i8042 (parameter) [4] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [8] i8042_flush() drivers/input/serio/i8042.c: d3 - i8042 (command) [13] drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13] drivers/input/serio/i8042.c: a5 - i8042 (return) [13] i8042_check_aux: passed I don't like the interrupt message, I'll check why it's enabled so early. It may have a good reason to, as well. Other than that, it looks very much OK. So as with acpi=off, we get a correct return. Now that usb is mentioned, I think either myself or Sebastian has mentioned that the keyboard does not work unless USB1.1 support is compiled in. Another clue possibly? Compiling USB 1.1 support does the very same thing as specifying usb-handoff on the command like - tells the BIOS to keep its hands off the USB _and_ PS/2 controllers. Another question - would it be usefull at all to see what happens if the AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST rely on the fact that AUX_LOOP must first fail/timeout somehow? No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail similarly when BIOS is active. -- Vojtech Pavlik SuSE
Re: i8042 access timings
Vojtech Pavlik wrote: What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. This makes sense in a weird kind of way. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. SCI interrupt routing? I have tried with pci=routeirq and that hasn't helped either. IRQ balancing perhaps? I don't like the interrupt message, I'll check why it's enabled so early. It may have a good reason to, as well. Other than that, it looks very much OK. That was with usb-handoff. It also resulted in the black screen of bios-death upon reboot though :). So as with acpi=off, we get a correct return. Now that usb is mentioned, I think either myself or Sebastian has mentioned that the keyboard does not work unless USB1.1 support is compiled in. Another clue possibly? Compiling USB 1.1 support does the very same thing as specifying usb-handoff on the command like - tells the BIOS to keep its hands off the USB _and_ PS/2 controllers. I'm missing something, I have USB1.1 compiled in, then why does the touchpad not work if it does the very same thing as usb-handoff? Another question - would it be usefull at all to see what happens if the AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST rely on the fact that AUX_LOOP must first fail/timeout somehow? No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail similarly when BIOS is active. That is correct. It fails with timeout. This for me confirms the fact that it is responding one command too late. aka, we send a command, it times out, we send another, it sends the result of the first. Right, any new (or variations of existing ones) theories that I can try out to make this touchpad work correctly? I can simply hack out the test for the touchpad but that doesn't solve the problem for others. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ smime.p7s Description: S/MIME Cryptographic Signature
Re: i8042 access timings
Vojtech Pavlik wrote: On Fri, Jan 28, 2005 at 04:20:58PM +0200, Jaco Kroon wrote: Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. Ok, I'm not too clued up with recent hardware and the BIOS programming that goes with it (being a system admin/application programmer), what exactly is usb-handoff? usb-handoff is a kernel option that enables a PCI quirk routine that takes the USB controller out of BIOS's hands. Until that is done (the linux USB drivers also do it, only later), the BIOS owns the USB controller and tries to emulate a PS/2 mouse and keyboard for systems which can't handle USB. acpi=off obviously just turns all acpi support in the kernel off. Indeed. SCI is also a new abbreviation I haven't seen before. System Configuration Interrupt. In addition to SMI (System Management Interrupt), these are two interrupts the BIOS uses to do its job behind the operating system's back. ACPI 2.0 spec says: System Control Interrupt (SCI) A system interrupt used by hardware to notify the OS of ACPI events. The SCI is an active, low, shareable, level interrupt. -- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Saturday 29 January 2005 14:59, Jaco Kroon wrote: Compiling USB 1.1 support does the very same thing as specifying usb-handoff on the command like - tells the BIOS to keep its hands off the USB _and_ PS/2 controllers. I'm missing something, I have USB1.1 compiled in, then why does the touchpad not work if it does the very same thing as usb-handoff? USB initializes very late, after i8042 and psmouse has already run their probes. So unless there is usb-handoff psmouse talks to a fake BIOS-emulated mouse, not a real touchpad. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 06:45:06PM +0100, Andries Brouwer wrote: > Discussion: > > Dmitry: > Here are patches with some delays. One never knows - maybe they > help someone. > > Andries: > Only insert delays in the kernel source when either we know about > at least one person who reports that it helps, or about data sheets > that specify that the delay is required. Otherwise one creates > myths and superstition. > > Lee Revell: > > > Seems like a comment along the lines of "foo hardware doesn't work right > > > unless we delay a bit here" is the obvious solution. Then someone can > > > easily disprove it later. > > At present the comment would be > "Here is a delay - nobody knows why we are adding it". > > Alan: > > Myths are not really involved here. The IBM PC hardware specifications > > are fairly well defined > > If there is a data sheet that requires the delay I am of course happy. > If there are test results that show that it helps, I am happy as well. > But the given motivation was "you never know - it might help". Bad. I fully agree. And I won't merge the delay patch in the current state. It may be useful for testing with systems that are failing, though. On the other hand, I don't believe any of todays systems need any delays, and that most of the problems are caused by the kernel pushing the limits of what SMM emulation can do, where the real hardware wouldn't have problems with it. > The present situation is that often 2.4 works and 2.6 fails. And the most common case is the SMM code messing up 2.6 detection. 2.4 is lucky by doing the mouse initalization after the USB modules have loaded, not doing any MUX detection at all, etc. It still has problems on systems where there is no AUX yet BIOS reports it and a user opens /dev/psaux. > Not because of some delay that is also absent in 2.4. > Often because of all those keyboard commands we send to the hardware. > Sometimes also because of ACPI. Intel, VIA, nVidia and ALi embedded i8042 cells handle the commands with ease. Extended notebooks i8042's usually handle multiplexing, and as such don't have problems with the commands either. SiS seems not to implement a few commands in some of their chipsets, but issuing the not implemented commands has no adverse effects. Where computer makers cut corners a LOT is the BIOS. And doing SMM mouse emulation when you have both a real PS/2 mouse and an USB mouse is really tricky, not only because of the data mixing intricacies, but also because of the wide variety of PS/2 and USB hardware. Some USB mice ignore the SetIdle call and this causes the SMM to send an endless stream of simulated PS/2 mouse data for example. A way to save us most of the headaches in 2.6 would be to always do the usb handoff, unless disabled by a kernel option, by reversing the logic of the "usb-handoff" kernel option. That way, the playing field for i8042.c would be level with 2.4. Without it, the driver has to avoid much more obstacles. [Hmm, a thought. Since MUX and SMM emulation are mutually exclusive, maybe the i8042 driver should disable MUX detection unless usb-handoff has been specified ... unfortunately most people will not notice and have problems with their Synaptics touchpads.] -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. Ok, I'm not too clued up with recent hardware and the BIOS programming that goes with it (being a system admin/application programmer), what exactly is usb-handoff? acpi=off obviously just turns all acpi support in the kernel off. SCI is also a new abbreviation I haven't seen before. Whilst I've seen SMM before, I'm not sure what it stands for (I assume it's something to do with simulation of legacy devices for older operating systems)? From the kernel-parameters documentation: usb-handoff [HW] Enably early USB BIOS -> OS handoff I guess this means the OS takes over control of the USB devices at an earlier stage than usual - possibly before ACPI gets initialised? I'm unable to determine much from looking at drivers/pci/quirks.c (which is where the usb-handoff parameter is defined). usb-handoff=1 does however also fix the problem. Ok. This makes it even more confusing (and probably more complicated). The appropriate section from dmesg that shows that it is working correctly: i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 -> i8042 (command) [4] drivers/input/serio/i8042.c: 47 <- i8042 (return) [4] drivers/input/serio/i8042.c: 60 -> i8042 (command) [4] drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [4] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [8] i8042_flush() drivers/input/serio/i8042.c: d3 -> i8042 (command) [13] drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13] drivers/input/serio/i8042.c: a5 <- i8042 (return) [13] i8042_check_aux: passed So as with acpi=off, we get a correct return. Now that usb is mentioned, I think either myself or Sebastian has mentioned that the keyboard does not work unless USB1.1 support is compiled in. Another clue possibly? Another question - would it be usefull at all to see what happens if the AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST rely on the fact that AUX_LOOP must first fail/timeout somehow? Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: > > So what _might_ happen is that we write the command, and then > > i8042_wait_write() thinks that there is space to write the data > > immediately, and writes the data, but now the data got lost because the > > buffer was busy. > > Hmm - I just answered the same post and concluded that I didnt understand, > so you have progressed further. I considered the same possibility, > but the data was not lost since we read it again later. > Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Fri, Jan 28, 2005 at 12:12:19AM +0200, Jaco Kroon wrote: > Yes. You understand correctly. Booting with acpi=off though has deadly > implications when rebooting though (bios gives you the black screen of > void). So I would like to keep booting with acpi=off down to an > absolute minimum. Did you ever try using "acpi=off" together with "i8042.nomux=1"? That could help with the rebooting problem (iirc, you had a multiplexing controller, didn't you?). Also, if you could try whether "usb-handoff" instead of "acpi-off" has the same effect, like it has for Sebastian, that'd be a good data point, too. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Fri, Jan 28, 2005 at 12:12:19AM +0200, Jaco Kroon wrote: Yes. You understand correctly. Booting with acpi=off though has deadly implications when rebooting though (bios gives you the black screen of void). So I would like to keep booting with acpi=off down to an absolute minimum. Did you ever try using acpi=off together with i8042.nomux=1? That could help with the rebooting problem (iirc, you had a multiplexing controller, didn't you?). Also, if you could try whether usb-handoff instead of acpi-off has the same effect, like it has for Sebastian, that'd be a good data point, too. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 09:29:47PM +0100, Andries Brouwer wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. What I believe is happening is that we're talking to SMM emulation of the i8042, which doesn't have a clue about these commands, while the underlying real hardware implementation does. And because of that they disagree on what should happen when the command is issued, and since the SMM emulation lazily synchronizes with the real HW, we only get the data back with the next command. I still don't have an explanation why both 'usb-handoff' and 'acpi=off' help, I'd expect only the first to, but it might be related to the SCI interrupt routing which isn't done when 'acpi=off'. Just a wild guess. Ok, I'm not too clued up with recent hardware and the BIOS programming that goes with it (being a system admin/application programmer), what exactly is usb-handoff? acpi=off obviously just turns all acpi support in the kernel off. SCI is also a new abbreviation I haven't seen before. Whilst I've seen SMM before, I'm not sure what it stands for (I assume it's something to do with simulation of legacy devices for older operating systems)? From the kernel-parameters documentation: usb-handoff [HW] Enably early USB BIOS - OS handoff I guess this means the OS takes over control of the USB devices at an earlier stage than usual - possibly before ACPI gets initialised? I'm unable to determine much from looking at drivers/pci/quirks.c (which is where the usb-handoff parameter is defined). usb-handoff=1 does however also fix the problem. Ok. This makes it even more confusing (and probably more complicated). The appropriate section from dmesg that shows that it is working correctly: i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 - i8042 (command) [4] drivers/input/serio/i8042.c: 47 - i8042 (return) [4] drivers/input/serio/i8042.c: 60 - i8042 (command) [4] drivers/input/serio/i8042.c: 56 - i8042 (parameter) [4] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [8] i8042_flush() drivers/input/serio/i8042.c: d3 - i8042 (command) [13] drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13] drivers/input/serio/i8042.c: a5 - i8042 (return) [13] i8042_check_aux: passed So as with acpi=off, we get a correct return. Now that usb is mentioned, I think either myself or Sebastian has mentioned that the keyboard does not work unless USB1.1 support is compiled in. Another clue possibly? Another question - would it be usefull at all to see what happens if the AUX_LOOP test is never performed but only AUX_TEST? Or does AUX_TEST rely on the fact that AUX_LOOP must first fail/timeout somehow? Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 06:45:06PM +0100, Andries Brouwer wrote: Discussion: Dmitry: Here are patches with some delays. One never knows - maybe they help someone. Andries: Only insert delays in the kernel source when either we know about at least one person who reports that it helps, or about data sheets that specify that the delay is required. Otherwise one creates myths and superstition. Lee Revell: Seems like a comment along the lines of foo hardware doesn't work right unless we delay a bit here is the obvious solution. Then someone can easily disprove it later. At present the comment would be Here is a delay - nobody knows why we are adding it. Alan: Myths are not really involved here. The IBM PC hardware specifications are fairly well defined If there is a data sheet that requires the delay I am of course happy. If there are test results that show that it helps, I am happy as well. But the given motivation was you never know - it might help. Bad. I fully agree. And I won't merge the delay patch in the current state. It may be useful for testing with systems that are failing, though. On the other hand, I don't believe any of todays systems need any delays, and that most of the problems are caused by the kernel pushing the limits of what SMM emulation can do, where the real hardware wouldn't have problems with it. The present situation is that often 2.4 works and 2.6 fails. And the most common case is the SMM code messing up 2.6 detection. 2.4 is lucky by doing the mouse initalization after the USB modules have loaded, not doing any MUX detection at all, etc. It still has problems on systems where there is no AUX yet BIOS reports it and a user opens /dev/psaux. Not because of some delay that is also absent in 2.4. Often because of all those keyboard commands we send to the hardware. Sometimes also because of ACPI. Intel, VIA, nVidia and ALi embedded i8042 cells handle the commands with ease. Extended notebooks i8042's usually handle multiplexing, and as such don't have problems with the commands either. SiS seems not to implement a few commands in some of their chipsets, but issuing the not implemented commands has no adverse effects. Where computer makers cut corners a LOT is the BIOS. And doing SMM mouse emulation when you have both a real PS/2 mouse and an USB mouse is really tricky, not only because of the data mixing intricacies, but also because of the wide variety of PS/2 and USB hardware. Some USB mice ignore the SetIdle call and this causes the SMM to send an endless stream of simulated PS/2 mouse data for example. A way to save us most of the headaches in 2.6 would be to always do the usb handoff, unless disabled by a kernel option, by reversing the logic of the usb-handoff kernel option. That way, the playing field for i8042.c would be level with 2.4. Without it, the driver has to avoid much more obstacles. [Hmm, a thought. Since MUX and SMM emulation are mutually exclusive, maybe the i8042 driver should disable MUX detection unless usb-handoff has been specified ... unfortunately most people will not notice and have problems with their Synaptics touchpads.] -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote: > > On Fri, 28 Jan 2005, Jaco Kroon wrote: > ok, how would I try this? Where can I find an example to code it from? Sorry, I should probably be grepping ... >>> >>>If the udelay() didn't work, then this one isn't worth worryign about >>>either. Back to the drawing board. >> >>Yea. But for interrests sake, what do you mean with a serializing IO >>instruction? > If you use "outb_p()" instead of an "outb()", the regular IO instruction > will be followed by another out to another port on the motherboard: that > will not only cause a delay, it should also force at least the host bridge > to have no outstanding posted writes (the host bridge shouldn't post IO > port writes anyway, but hey, it won't hurt to try to make even more sure > of that). No go. Does not help at all. Very nifty idea to force another character through the bus to cause a delay though. >>I also tried increasing the total timeout value to about 5 seconds >>(versus the default half second), still no success, so the device is >>simply not sending back the requested values. > > > If it was the other way around (that it works with ACPI _on_), I'd assume > that ACPI just disables some broken BIOS SMM emulation code. But I just > don't see ACPI _enabling_ SMM emulation. That would be just too strange, > and against the whole point of the legacy keyboard emulation stuff - you > want to do legacy keyboard emulation if the OS is old, not if it's new. I don't see this notebook running any non-ACPI enabled OS. It would just be too broken (consider the black screen of void if one boots with acpi=off). Some very old legacy OSs would not even have USB1.1 support which will kill the keyboard. > > It may be that ACPI ends up enabling some silly power control SMM sequence > that wakes up on keyboard accesses, and screws up the emulation. That > sounds pretty strange too, I have to say - even if SMM/ACPI would like to > trap keyboard command sequences, I'd have expected it to just pass them > through after looking at them. Why? If it is going to make the screen dimmer/brighter after pressing the keys - what is the use of passing them through to the OS? After all, the user has already seen the "effect" these keys caused and giving them to the OS to do something else with will end up being counter intuitive to the user. > > One option may be that SMM/ACPI traps the _received_ characters, and > incorrectly eats the reply, because it thinks it's some special key > sequence (and should cause SMM/ACPI to make the screen brighter or > something silly like that). Interresting idea. The Fn+F6/F7 keys does indeed make the screen brighter and dimmer, and afaik these gets trapped by SMM/ACPI in the BIOS and never even gets to Linux. > Does anybody know/remember what the keycode 0xA5 means? >>I still stand with the theory that it is sending back the value we want >>for the first request on the second one (managed to get this one by >>explicitly turning i8042_debug on and off in the code): >> >>i8042_init() >>ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 >>ACPI: PS/2 Mouse Controller [MSE0] at irq 12 >>i8042_controller_init() >>i8042_flush() >>drivers/input/serio/i8042.c: 20 -> i8042 (command) [4] >>drivers/input/serio/i8042.c: 47 <- i8042 (return) [4] >>drivers/input/serio/i8042.c: 60 -> i8042 (command) [5] >>drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5] >>i8042_check_aux() >>drivers/input/serio/i8042.c: Interrupt 12, without any data [9] >>i8042_flush() >>drivers/input/serio/i8042.c: d3 -> i8042 (command) [13] >>drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13] >>drivers/input/serio/i8042.c: -- i8042 (timeout) [875] >>i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1 >>drivers/input/serio/i8042.c: a9 -> i8042 (command) [879] >>drivers/input/serio/i8042.c: a5 <- i8042 (return) [879] >>i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0 >> >>I've rebooted a couple of times and that interrupt is in exactly the >>same place every time. And int 12 is indeed the AUX device, could this >>be a clue? > > Does it change if you change the initial value of "param" (0x5a) to > something else? I've changed the initial input to 0xbb and the output from the second command changed to 0x44. So it does indeed look like my theory might be workable. Just a thought, the acpi_driver i8042_acpi_aux_driver struct has an .add option, that gets called when ACPI detects the AUX device. ic8042_acpi_aux_add() gets called *before* we attempt initialisation/detectiong of the device. Shouln't this be sufficient to say yes, there is such a device, this is it's port and irq numbers? As such, do we still need to go through the AUX_LOOP and AUX_TEST process to determine whether the device is installed or not? On the other hand, why would asking ACPI what the correct interrupt is break it? In i8042_platform_init() (i8042-x86ia64io.h) there is a commented
Re: i8042 access timings
On Thursday 27 January 2005 17:36, Linus Torvalds wrote: > > I also tried increasing the total timeout value to about 5 seconds > > (versus the default half second), still no success, so the device is > > simply not sending back the requested values. > > If it was the other way around (that it works with ACPI _on_), I'd assume > that ACPI just disables some broken BIOS SMM emulation code. But I just > don't see ACPI _enabling_ SMM emulation. That would be just too strange, > and against the whole point of the legacy keyboard emulation stuff - you > want to do legacy keyboard emulation if the OS is old, not if it's new. It is my understanding that ACPI and legacy emulation are to a certain degree tangent to each other. You can work in ACPI mode and still use USB legacy emulation and you could be in legacy mode but with USB loaded and USB legacy emulation turned off. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
> > Only the ready flag was lost. > No, note that if there was valid data we would see 0xa5 instead of > 0x5a that was in the buffer - because in i8042_command we invert data > coming from AUX port. We misunderstand each other. Let me repeat. The following happens: We wait, then write d3, wait, then write 5a, wait for input, timeout. We wait, then write a9, wait for input, read 5a from AUXB. (That 5a is inverted to a5 to signal that it came from AUXB.) Of course, that 5a is the result of the 5a that we sent via the d3 command. But why does that command time out? For some reason the information that there is a byte ready to be read was not transmitted to the status register. But as soon as we gave another command, a9 in this case, this system remembered that something was ready, and set the appropriate status bit. One might experiment a little - see for example whether other commands than a9 suffice in "waking the kbd controller". All is fine, only the flag was lost, nobody knows why. Maybe just because the d3 implementation is buggy. That has been seen more often. But there is another part that we must think about - the fragment i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [9] i8042_flush() Andries By the way, we should remove this silly response byte inversion and just store a separate bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Fri, 28 Jan 2005, Jaco Kroon wrote: > >> > >>ok, how would I try this? Where can I find an example to code it from? > >> Sorry, I should probably be grepping ... > > If the udelay() didn't work, then this one isn't worth worryign about > > either. Back to the drawing board. > Yea. But for interrests sake, what do you mean with a serializing IO > instruction? If you use "outb_p()" instead of an "outb()", the regular IO instruction will be followed by another out to another port on the motherboard: that will not only cause a delay, it should also force at least the host bridge to have no outstanding posted writes (the host bridge shouldn't post IO port writes anyway, but hey, it won't hurt to try to make even more sure of that). > I also tried increasing the total timeout value to about 5 seconds > (versus the default half second), still no success, so the device is > simply not sending back the requested values. If it was the other way around (that it works with ACPI _on_), I'd assume that ACPI just disables some broken BIOS SMM emulation code. But I just don't see ACPI _enabling_ SMM emulation. That would be just too strange, and against the whole point of the legacy keyboard emulation stuff - you want to do legacy keyboard emulation if the OS is old, not if it's new. It may be that ACPI ends up enabling some silly power control SMM sequence that wakes up on keyboard accesses, and screws up the emulation. That sounds pretty strange too, I have to say - even if SMM/ACPI would like to trap keyboard command sequences, I'd have expected it to just pass them through after looking at them. One option may be that SMM/ACPI traps the _received_ characters, and incorrectly eats the reply, because it thinks it's some special key sequence (and should cause SMM/ACPI to make the screen brighter or something silly like that). Does anybody know/remember what the keycode 0xA5 means? > I still stand with the theory that it is sending back the value we want > for the first request on the second one (managed to get this one by > explicitly turning i8042_debug on and off in the code): > > i8042_init() > ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 > ACPI: PS/2 Mouse Controller [MSE0] at irq 12 > i8042_controller_init() > i8042_flush() > drivers/input/serio/i8042.c: 20 -> i8042 (command) [4] > drivers/input/serio/i8042.c: 47 <- i8042 (return) [4] > drivers/input/serio/i8042.c: 60 -> i8042 (command) [5] > drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5] > i8042_check_aux() > drivers/input/serio/i8042.c: Interrupt 12, without any data [9] > i8042_flush() > drivers/input/serio/i8042.c: d3 -> i8042 (command) [13] > drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13] > drivers/input/serio/i8042.c: -- i8042 (timeout) [875] > i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1 > drivers/input/serio/i8042.c: a9 -> i8042 (command) [879] > drivers/input/serio/i8042.c: a5 <- i8042 (return) [879] > i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0 > > I've rebooted a couple of times and that interrupt is in exactly the > same place every time. And int 12 is indeed the AUX device, could this > be a clue? Does it change if you change the initial value of "param" (0x5a) to something else? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the hardware was so fast that you never saw it busy.
I've tried it anyway:
static inline void i8042_write_command(int val)
{
outb(val, I8042_COMMAND_REG);
while(~i8042_read_status() & I8042_STR_IBF);
}
This to me just gives surety that we don't miss that asserted signal,
but a udelay() before the test would do exactly the same thing. And
yes, your argument for the lockup is very, very valid.
The IO delay should be _before_ the read of the status, not after it.
So how about adding an extra "udelay(50)" to either the top of
i8042_wait_write(), or to the bottom of "i8042_write_command()"? Does that
make any difference?
No. No difference, still the same result.
Oh, well. It was such a good theory, especially as it works fine with ACPI
off (if I understood your report correctly), so some other state is what
seems to bring it on.
Yes. You understand correctly. Booting with acpi=off though has deadly
implications when rebooting though (bios gives you the black screen of
void). So I would like to keep booting with acpi=off down to an
absolute minimum.
(50 usec is probably overkill, and an alternative is to just make the
write_data/write_command inline functions in i8042-io.h use the
"inb_p/outb_p" versions that put a serializing IO instruction in between,
which should give you a nice 1us delay even on modern hardware.)
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
Yea. But for interrests sake, what do you mean with a serializing IO
instruction?
I also tried increasing the total timeout value to about 5 seconds
(versus the default half second), still no success, so the device is
simply not sending back the requested values.
I still stand with the theory that it is sending back the value we want
for the first request on the second one (managed to get this one by
explicitly turning i8042_debug on and off in the code):
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
drivers/input/serio/i8042.c: 20 -> i8042 (command) [4]
drivers/input/serio/i8042.c: 47 <- i8042 (return) [4]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [5]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5]
i8042_check_aux()
drivers/input/serio/i8042.c: Interrupt 12, without any data [9]
i8042_flush()
drivers/input/serio/i8042.c: d3 -> i8042 (command) [13]
drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13]
drivers/input/serio/i8042.c: -- i8042 (timeout) [875]
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
drivers/input/serio/i8042.c: a9 -> i8042 (command) [879]
drivers/input/serio/i8042.c: a5 <- i8042 (return) [879]
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
I've rebooted a couple of times and that interrupt is in exactly the
same place every time. And int 12 is indeed the AUX device, could this
be a clue? Ok, with acpi=off and i8042.debug=1 I get:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 47 <- i8042 (return) [0]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [1]
i8042_check_aux()
i8042_flush()
drivers/input/serio/i8042.c: d3 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: a5 <- i8042 (return) [1]
i8042_check_aux: passed
At which point it makes no further sense to dump stuff out as with
acpi=on this has already failed.
Note that we are sending in 0x5a and expecting back 0xa5, which is
exactly what we get back from the second request. Also note that
without ACPI we get the right value back first time round. ACPI imho is
doing something wrong (or the test needs to change due to ACPI). Since
it only breaks (to the best of my knowledge) on Toshiba Satellite
P10-??? notebooks this seems to be a bug in the BIOS more likely.
Right, the message about ACPI detection being disabled can be tracked to
i8042_x86ia64io.h, specifically i8042_acpi_init(). This function
performs two acpi_bus_register_driver calls (Not sure what different
return values means, suspect <0 == error, >=0 implies success but
somehow reflect the number of devices detected since -ENODEV is returned
should the call return 0?).
Here is however an oddity, in the case where the i8042_acpi_kbd_driver
registration returns 0 the driver promptly gets unregistered,
Re: i8042 access timings
On Thu, 27 Jan 2005, Jaco Kroon wrote: > > Hmm, just an idea, shouldn't the i8042_write_command be waiting until > the device has asserted the pin to indicate that the buffer is busy? No. Because then you might end up waiting forever for the _opposite_ reason, namely that the hardware was so fast that you never saw it busy. > > The IO delay should be _before_ the read of the status, not after it. > > > > So how about adding an extra "udelay(50)" to either the top of > > i8042_wait_write(), or to the bottom of "i8042_write_command()"? Does that > > make any difference? > > No. No difference, still the same result. Oh, well. It was such a good theory, especially as it works fine with ACPI off (if I understood your report correctly), so some other state is what seems to bring it on. > > (50 usec is probably overkill, and an alternative is to just make the > > write_data/write_command inline functions in i8042-io.h use the > > "inb_p/outb_p" versions that put a serializing IO instruction in between, > > which should give you a nice 1us delay even on modern hardware.) > > ok, how would I try this? Where can I find an example to code it from? > Sorry, I should probably be grepping ... If the udelay() didn't work, then this one isn't worth worryign about either. Back to the drawing board. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
as expected by the first command (0xa5). The last value on both lines
is the return value. From the second snippet:
No, I think the 0x5a you see is the 0x5a that is _still_ there, because we
never got any reply at all from the i8042_command(I8042_CMD_AUX_LOOP)
case, nor did the I8042_CMD_AUX_TEST thing do anything at all.
I suspect I didn't explain clearly. Note that the outer test expects a
0xa5 (we pass 0x5a in). That is what made me suspect that the second
request gets the first ones return value.
I have a suspicion: these commands are also one of the few ones that write
a data byte to the data port immediately after writing the command byte to
the status port.
Yes. The commands that write something is:
CTL_WCTR
KBD_LOOP (I quess this is what breaks if no USB1.1 present in kernel)
AUX_SEND (obviously)
AUX_LOOP (the one that we think is breaking)
MIX_SEND (obviously).
All of them send exactly one byte.
It so happens that if the hardware is slow to reach to the command byte,
we might read the status word _before_ the hardware has had time to even
say "ok, my input port is now full". We have a "udelay()" there in
i8042_wait_write(), but we have it _after_ we've done the
i8042_read_status(), so effectively the i8042_read_status() happens
immediately after the i8042_write_command().
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
Ie, some nice and tight loop. This has the downside that if we check
_just before_ the pin gets asserted, then delay and check again _after_
it has been cleared we will deadlock. So the udelay() before the loop
(or rewriting the loop to do{}while(...)) is probably a better solution,
although this will cause us to _always_ wait at least 50 microseconds
(not that that is a long time).
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and writes the data, but now the data got lost because the
buffer was busy.
This makes a lot of sense.
The IO delay should be _before_ the read of the status, not after it.
So how about adding an extra "udelay(50)" to either the top of
i8042_wait_write(), or to the bottom of "i8042_write_command()"? Does that
make any difference?
No. No difference, still the same result.
(50 usec is probably overkill, and an alternative is to just make the
write_data/write_command inline functions in i8042-io.h use the
"inb_p/outb_p" versions that put a serializing IO instruction in between,
which should give you a nice 1us delay even on modern hardware.)
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
Jaco
--
There are only 10 kinds of people in this world,
those that understand binary and those that don't.
http://www.kroon.co.za/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, 27 Jan 2005 21:29:47 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote: > On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote: > > > So what _might_ happen is that we write the command, and then > > i8042_wait_write() thinks that there is space to write the data > > immediately, and writes the data, but now the data got lost because the > > buffer was busy. > > Hmm - I just answered the same post and concluded that I didnt understand, > so you have progressed further. I considered the same possibility, > but the data was not lost since we read it again later. > Only the ready flag was lost. > No, note that if there was valid data we would dee 0xa5 instead of 0x5a that was in the buffer - because in i8042_command we invert data coming from AUX port. So Linus's theory seems feasible. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote: > So what _might_ happen is that we write the command, and then > i8042_wait_write() thinks that there is space to write the data > immediately, and writes the data, but now the data got lost because the > buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. > The IO delay should be _before_ the read of the status, not after it. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
The code is
param = 0x5a;
if (i8042_command(, I8042_CMD_AUX_LOOP) || param != 0xa5) {
if (i8042_command(, I8042_CMD_AUX_TEST)
|| (param && param != 0xfa && param != 0xff))
return -1;
}
where
#define I8042_CMD_AUX_LOOP 0x11d3: write d3, write 5a, read ->param
#define I8042_CMD_AUX_TEST 0x01a9: write a9, read ->param
In my docs (http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.3)
d3 is classified under "Obscure, probably obsolete, commands".
The reason is that there is hardware that does not implement d3.
Originally it was special to MCA. Later it was also used as part of
the Synaptics multiplexing handshake.
Now you read one byte after the command a9 and get a5 - clearly the 5a
that was written and complemented. So it looks like the d3 really worked.
The first i8042_command() returned -1, but it really wrote the 5a,
so it did i8042_write_command(d3) and i8042_write_data(5a) and then
the i8042_wait_read() returned -1, a timeout.
Since the byte was there to read, the flag was lost that indicated
that data was available. Hmm. Sequence of actions:
inb(64);// until bit 1 clear
outb(d3, 64);
inb(64);// until bit 1 clear
outb(5a, 60);
inb(64);// until bit 0 set - timeout
inb(64);// until bit 1 clear
outb(a9, 64);
inb(64);// until bit 0 set
inb(64);// test for AUX
inb(60);
I am afraid I don't understand what happens.
One can imagine that the second inb(64) comes too quickly
so that we write the 5a too quickly. But all happens as it
should: the d3 is executed, the 5a is moved from input buffer
to output buffer, the AUXB bit is set, only the ready flag never comes,
not within I8042_CTL_TIMEOUT=1 times 50 usec, that is 0.5 sec.
By the way, I have some old docs that describe sending a command by
repeat inb(64) until bit 1 clear
outb(cmd, 64)
repeat inb(64) until bit 1 set
and we only do the first half.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, 27 Jan 2005, Jaco Kroon wrote: > > Which indicates (as far as my understanding goes) that the command times > out, as such the param value stays the same (ready for re-use in the > second command). The second commands succeeds but does not return one > of the expected (0x00, 0xff, 0xfa) values, instead it returns the value > as expected by the first command (0xa5). The last value on both lines > is the return value. From the second snippet: No, I think the 0x5a you see is the 0x5a that is _still_ there, because we never got any reply at all from the i8042_command(I8042_CMD_AUX_LOOP) case, nor did the I8042_CMD_AUX_TEST thing do anything at all. I have a suspicion: these commands are also one of the few ones that write a data byte to the data port immediately after writing the command byte to the status port. It so happens that if the hardware is slow to reach to the command byte, we might read the status word _before_ the hardware has had time to even say "ok, my input port is now full". We have a "udelay()" there in i8042_wait_write(), but we have it _after_ we've done the i8042_read_status(), so effectively the i8042_read_status() happens immediately after the i8042_write_command(). So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. The IO delay should be _before_ the read of the status, not after it. So how about adding an extra "udelay(50)" to either the top of i8042_wait_write(), or to the bottom of "i8042_write_command()"? Does that make any difference? (50 usec is probably overkill, and an alternative is to just make the write_data/write_command inline functions in i8042-io.h use the "inb_p/outb_p" versions that put a serializing IO instruction in between, which should give you a nice 1us delay even on modern hardware.) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Discussion: Dmitry: Here are patches with some delays. One never knows - maybe they help someone. Andries: Only insert delays in the kernel source when either we know about at least one person who reports that it helps, or about data sheets that specify that the delay is required. Otherwise one creates myths and superstition. Lee Revell: > > Seems like a comment along the lines of "foo hardware doesn't work right > > unless we delay a bit here" is the obvious solution. Then someone can > > easily disprove it later. At present the comment would be "Here is a delay - nobody knows why we are adding it". Alan: > Myths are not really involved here. The IBM PC hardware specifications > are fairly well defined If there is a data sheet that requires the delay I am of course happy. If there are test results that show that it helps, I am happy as well. But the given motivation was "you never know - it might help". Bad. The present situation is that often 2.4 works and 2.6 fails. Not because of some delay that is also absent in 2.4. Often because of all those keyboard commands we send to the hardware. Sometimes also because of ACPI. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote: Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisał: On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote: Sebastian Piechocki wrote: As I said I'm sending you mails from kernel masters:) Thanks. If you haven't such a problem, please send them your dmesg with i8042.debug and acpi=off. I made an alternative plan. I applied a custom patch that gives me far less output and prevents scrolling and gets what I hope is what is required. ... could you just increase the timeout value to some insane amount? That should take care of the AUX_LOOP output getting back only after issuing the next command. Increasing the timeout doesn't help. I've increased timout ten times and the result is the same. OK, in that case the BIOS i8042 emulation just interferes badly with the real i8042 and I doubt we can do much else than keep the BIOS from interfering. And just how do we do that? -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote: > On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote: > > Myths are not really involved here. The IBM PC hardware specifications > > are fairly well defined and the various bits of "we glued a 2Mhz part > > onto the bus" stuff is all well documented. Nowdays its more complex > > because most kbc's aren't standalone low end microcontrollers but are > > chipset integrated cells or even software SMM emulations. > > > > The real test is to fish out something like an old Digital Hi-note > > laptop or an early 486 board with seperate kbc and try it. > > I have a Digital HiNote collecting dust which had this keyboard problem > with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like, > but I won't be able to get to it until the weekend. That'd be very nice indeed. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote: > Myths are not really involved here. The IBM PC hardware specifications > are fairly well defined and the various bits of "we glued a 2Mhz part > onto the bus" stuff is all well documented. Nowdays its more complex > because most kbc's aren't standalone low end microcontrollers but are > chipset integrated cells or even software SMM emulations. > > The real test is to fish out something like an old Digital Hi-note > laptop or an early 486 board with seperate kbc and try it. I have a Digital HiNote collecting dust which had this keyboard problem with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like, but I won't be able to get to it until the weekend. Bill Rugolsky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote: > On Maw, 2005-01-25 at 20:37, Lee Revell wrote: > > Seems like a comment along the lines of "foo hardware doesn't work right > > unless we delay a bit here" is the obvious solution. Then someone can > > easily disprove it later. > > Myths are not really involved here. The IBM PC hardware specifications > are fairly well defined and the various bits of "we glued a 2Mhz part > onto the bus" stuff is all well documented. Nowdays its more complex > because most kbc's aren't standalone low end microcontrollers but are > chipset integrated cells or even software SMM emulations. > > The real test is to fish out something like an old Digital Hi-note > laptop or an early 486 board with seperate kbc and try it. I'm testing it on an NexGen Nx586 VL-BUS board that has a separate i8042 controller. ;) Remember NexGen? -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Maw, 2005-01-25 at 20:37, Lee Revell wrote: > Seems like a comment along the lines of "foo hardware doesn't work right > unless we delay a bit here" is the obvious solution. Then someone can > easily disprove it later. Myths are not really involved here. The IBM PC hardware specifications are fairly well defined and the various bits of "we glued a 2Mhz part onto the bus" stuff is all well documented. Nowdays its more complex because most kbc's aren't standalone low end microcontrollers but are chipset integrated cells or even software SMM emulations. The real test is to fish out something like an old Digital Hi-note laptop or an early 486 board with seperate kbc and try it. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote: > Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisał: > > On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote: > > > Sebastian Piechocki wrote: > > > >As I said I'm sending you mails from kernel masters:) > > > > > > Thanks. > > > > > > >If you haven't such a problem, please send them your dmesg with > > > >i8042.debug and acpi=off. > > > > > > I made an alternative plan. I applied a custom patch that gives me > > > far less output and prevents scrolling and gets what I hope is what > > > is required. > > > > ... could you just increase the timeout value to some insane amount? > > That should take care of the AUX_LOOP output getting back only after > > issuing the next command. > > Increasing the timeout doesn't help. I've increased timout ten times and > the result is the same. OK, in that case the BIOS i8042 emulation just interferes badly with the real i8042 and I doubt we can do much else than keep the BIOS from interfering. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisał: > On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote: > > Sebastian Piechocki wrote: > > >As I said I'm sending you mails from kernel masters:) > > > > Thanks. > > > > >If you haven't such a problem, please send them your dmesg with > > >i8042.debug and acpi=off. > > > > I made an alternative plan. I applied a custom patch that gives me > > far less output and prevents scrolling and gets what I hope is what > > is required. > > ... could you just increase the timeout value to some insane amount? > That should take care of the AUX_LOOP output getting back only after > issuing the next command. Increasing the timeout doesn't help. I've increased timout ten times and the result is the same. -- Sebastian Piechocki [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
> Sebastian Piechocki wrote:
> >As I said I'm sending you mails from kernel masters:)
> Thanks.
>
> >If you haven't such a problem, please send them your dmesg with
> >i8042.debug and acpi=off.
>
> I made an alternative plan. I applied a custom patch that gives me far less
> output and prevents scrolling and gets what I hope is what is required.
... could you just increase the timeout value to some insane amount?
That should take care of the AUX_LOOP output getting back only after
issuing the next command.
Also, can you check if adding 'usb-handoff' to the kernel command line
helps you as well as it helped Sebastian?
>
>
> With acpi=on I get the following output:
> i8042_init()
> ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
> ACPI: PS/2 Mouse Controller [MSE0] at irq 12
> i8042_controller_init()
> i8042_flush()
> i8042_check_aux()
> i8042_flush()
> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
> i8042_allocate_kbd_port()
> i8042_port_register()
>
> With acpi=off I get this:
> i8042_init()
> i8042: ACPI detection disabled
> i8042_controller_init()
> i8042_flush()
> i8042_check_aux()
> i8042_flush()
> i8042_check_aux: passed
> i8042_check_mux()
> i8042_enable_mux_mode()
> i8042_flush()
> i8042_open(): mux_version==19
> i8042.c: Detected active multiplexing controller, rev 1.9.
> i8042_enable_mux_ports()
> i8042_allocate_mux_port()
> i8042_port_register()
>
> Ok, some explanation is probably in order, I just put a printk(KERN_INFO
> "function_name()\n" at the top of practically every function and then I
> filled up i8042_check_aux() because that is where the error is detected.
> In the first case (the interesting one) these lines pop up:
>
> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
>
> Which indicates (as far as my understanding goes) that the command times
> out, as such the param value stays the same (ready for re-use in the
> second command). The second commands succeeds but does not return one
> of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
> as expected by the first command (0xa5). The last value on both lines
> is the return value. From the second snippet:
>
> i8042_flush()
> i8042_check_aux: passed
>
> Indicates that the outer test passed first time round, ie, exit code 0
> and return param of 0xa5. What I have done to get mine working with
> acpi=on is applied the following patch (apologies if mozilla breaks this):
>
> ==
> --- linux-2.6.10/drivers/input/serio/i8042.c2004-12-24
> 23:33:52.0 +0200
> +++ linux-2.6.10-patched/drivers/input/serio/i8042.c2005-01-24
> 21:44:33.790291480 +0200
> @@ -595,7 +595,7 @@
> */
>
> if (i8042_command(, I8042_CMD_AUX_TEST)
> - || (param && param != 0xfa && param != 0xff))
> + || (param && param != 0xfa && param != 0xa5 &&
> param != 0xff))
> return -1;
> }
>
> ==
>
> Which I don't think is the proper solution, more likely the problem lies
> in the i8042_command function. Unfortunately I don't have time right
> now to add more debug code (to possibly only issue those dbg statements
> upto a certain point in order to reduce the amount of output).
>
> > As I remember with acpi=off i8042 detects multplexer MUX with four ports!
> > I tried to make a hack for mux detection, but mux was detected and
> touchpad
> > was not:(
> Yes. This seems correct, however the touchoad worked "perfectly" for me
> when I booted with acpi=off.
>
> >Dmitry,
> > did you see this one?
> >
> >Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
> >works, this is not the case of ACPI setting the wrong ports or something
> >fundamental like that. It looks like some state of the keyboard controller
> >just disables the loopback command and/or the AUX_TEST command.
> >
> >Might the "no KBD" case be something similar?
> I'm probably a bit off here, but what "no KBD" case? On these
> particular notebooks we both had to compile in specifically USB1.1
> support in order to have keyboard support, but since I want USB support
> in any case this is not a problem for me (although I would love to know
> what caused this).
>
> >Sebastian, can you make your hack also print out what the errors were (in
> >particular, was it "i8042_command()" that failed, or was it that the
> >return value was different from the expected ones, and if so - what?)
> I hope my debug did exactly that.
>
> From the orriginal mail sent to me by Sebastian:
> >>In method:
> >> i8042_check_aux
> >>
> >>There is:
> >>param = 0x5a;
> >> if (i8042_command(, I8042_CMD_AUX_LOOP) || param != 0xa5)
> >>{
> >>
> >>/*
>
Re: i8042 access timings
On Wed, Jan 26, 2005 at 11:36:41AM -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> > > @@ -213,7 +217,10 @@
> > > if (!retval)
> > > for (i = 0; i < ((command >> 8) & 0xf); i++) {
> > > if ((retval = i8042_wait_read())) break;
> > > - if (i8042_read_status() & I8042_STR_AUXDATA)
> > > + udelay(I8042_STR_DELAY);
> > > + str = i8042_read_status();
> > []
> > > + udelay(I8042_DATA_DELAY);
> > > + if (str & I8042_STR_AUXDATA)
> > > param[i] = ~i8042_read_data();
> > > else
> > > param[i] = i8042_read_data();
> >
> > We may as well drop the negation. It's a bad way to signal the data came
> > from the AUX port. Then we don't need the extra status read and can just
> > proceed to read the data, since IMO we don't need to wait inbetween,
> > even according to the IBM spec.
>
> Do you remember why it has been done to begin with?
Yes. It's only for the detection of the AUX port. I wanted to know
whether the byte we receive in the AUX_LOOP command really comes back
through the AUX interface and not through the KBD interface. Since there
isn't any other information path for signalling which interface
i8042_command() received the byte through, I just negated the value
there.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Wed, Jan 26, 2005 at 11:36:41AM -0500, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() I8042_STR_AUXDATA)
+ udelay(I8042_STR_DELAY);
+ str = i8042_read_status();
[]
+ udelay(I8042_DATA_DELAY);
+ if (str I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
Do you remember why it has been done to begin with?
Yes. It's only for the detection of the AUX port. I wanted to know
whether the byte we receive in the AUX_LOOP command really comes back
through the AUX interface and not through the KBD interface. Since there
isn't any other information path for signalling which interface
i8042_command() received the byte through, I just negated the value
there.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with
i8042.debug and acpi=off.
I made an alternative plan. I applied a custom patch that gives me far less
output and prevents scrolling and gets what I hope is what is required.
... could you just increase the timeout value to some insane amount?
That should take care of the AUX_LOOP output getting back only after
issuing the next command.
Also, can you check if adding 'usb-handoff' to the kernel command line
helps you as well as it helped Sebastian?
With acpi=on I get the following output:
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
i8042_allocate_kbd_port()
i8042_port_register()
With acpi=off I get this:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: passed
i8042_check_mux()
i8042_enable_mux_mode()
i8042_flush()
i8042_open(): mux_version==19
i8042.c: Detected active multiplexing controller, rev 1.9.
i8042_enable_mux_ports()
i8042_allocate_mux_port()
i8042_port_register()
Ok, some explanation is probably in order, I just put a printk(KERN_INFO
function_name()\n at the top of practically every function and then I
filled up i8042_check_aux() because that is where the error is detected.
In the first case (the interesting one) these lines pop up:
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
as expected by the first command (0xa5). The last value on both lines
is the return value. From the second snippet:
i8042_flush()
i8042_check_aux: passed
Indicates that the outer test passed first time round, ie, exit code 0
and return param of 0xa5. What I have done to get mine working with
acpi=on is applied the following patch (apologies if mozilla breaks this):
==
--- linux-2.6.10/drivers/input/serio/i8042.c2004-12-24
23:33:52.0 +0200
+++ linux-2.6.10-patched/drivers/input/serio/i8042.c2005-01-24
21:44:33.790291480 +0200
@@ -595,7 +595,7 @@
*/
if (i8042_command(param, I8042_CMD_AUX_TEST)
- || (param param != 0xfa param != 0xff))
+ || (param param != 0xfa param != 0xa5
param != 0xff))
return -1;
}
==
Which I don't think is the proper solution, more likely the problem lies
in the i8042_command function. Unfortunately I don't have time right
now to add more debug code (to possibly only issue those dbg statements
upto a certain point in order to reduce the amount of output).
As I remember with acpi=off i8042 detects multplexer MUX with four ports!
I tried to make a hack for mux detection, but mux was detected and
touchpad
was not:(
Yes. This seems correct, however the touchoad worked perfectly for me
when I booted with acpi=off.
Dmitry,
did you see this one?
Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
works, this is not the case of ACPI setting the wrong ports or something
fundamental like that. It looks like some state of the keyboard controller
just disables the loopback command and/or the AUX_TEST command.
Might the no KBD case be something similar?
I'm probably a bit off here, but what no KBD case? On these
particular notebooks we both had to compile in specifically USB1.1
support in order to have keyboard support, but since I want USB support
in any case this is not a problem for me (although I would love to know
what caused this).
Sebastian, can you make your hack also print out what the errors were (in
particular, was it i8042_command() that failed, or was it that the
return value was different from the expected ones, and if so - what?)
I hope my debug did exactly that.
From the orriginal mail sent to me by Sebastian:
In method:
i8042_check_aux
There is:
param = 0x5a;
if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xa5)
{
/*
* External connection test - filters out AT-soldered PS/2 i8042's
* 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
* 0xfa - no error on some notebooks
Re: i8042 access timings
Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisa: On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote: Sebastian Piechocki wrote: As I said I'm sending you mails from kernel masters:) Thanks. If you haven't such a problem, please send them your dmesg with i8042.debug and acpi=off. I made an alternative plan. I applied a custom patch that gives me far less output and prevents scrolling and gets what I hope is what is required. ... could you just increase the timeout value to some insane amount? That should take care of the AUX_LOOP output getting back only after issuing the next command. Increasing the timeout doesn't help. I've increased timout ten times and the result is the same. -- Sebastian Piechocki [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote: Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisa: On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote: Sebastian Piechocki wrote: As I said I'm sending you mails from kernel masters:) Thanks. If you haven't such a problem, please send them your dmesg with i8042.debug and acpi=off. I made an alternative plan. I applied a custom patch that gives me far less output and prevents scrolling and gets what I hope is what is required. ... could you just increase the timeout value to some insane amount? That should take care of the AUX_LOOP output getting back only after issuing the next command. Increasing the timeout doesn't help. I've increased timout ten times and the result is the same. OK, in that case the BIOS i8042 emulation just interferes badly with the real i8042 and I doubt we can do much else than keep the BIOS from interfering. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Maw, 2005-01-25 at 20:37, Lee Revell wrote: Seems like a comment along the lines of foo hardware doesn't work right unless we delay a bit here is the obvious solution. Then someone can easily disprove it later. Myths are not really involved here. The IBM PC hardware specifications are fairly well defined and the various bits of we glued a 2Mhz part onto the bus stuff is all well documented. Nowdays its more complex because most kbc's aren't standalone low end microcontrollers but are chipset integrated cells or even software SMM emulations. The real test is to fish out something like an old Digital Hi-note laptop or an early 486 board with seperate kbc and try it. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote: On Maw, 2005-01-25 at 20:37, Lee Revell wrote: Seems like a comment along the lines of foo hardware doesn't work right unless we delay a bit here is the obvious solution. Then someone can easily disprove it later. Myths are not really involved here. The IBM PC hardware specifications are fairly well defined and the various bits of we glued a 2Mhz part onto the bus stuff is all well documented. Nowdays its more complex because most kbc's aren't standalone low end microcontrollers but are chipset integrated cells or even software SMM emulations. The real test is to fish out something like an old Digital Hi-note laptop or an early 486 board with seperate kbc and try it. I'm testing it on an NexGen Nx586 VL-BUS board that has a separate i8042 controller. ;) Remember NexGen? -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote: Myths are not really involved here. The IBM PC hardware specifications are fairly well defined and the various bits of we glued a 2Mhz part onto the bus stuff is all well documented. Nowdays its more complex because most kbc's aren't standalone low end microcontrollers but are chipset integrated cells or even software SMM emulations. The real test is to fish out something like an old Digital Hi-note laptop or an early 486 board with seperate kbc and try it. I have a Digital HiNote collecting dust which had this keyboard problem with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like, but I won't be able to get to it until the weekend. Bill Rugolsky - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote: On Thu, Jan 27, 2005 at 03:14:36PM +, Alan Cox wrote: Myths are not really involved here. The IBM PC hardware specifications are fairly well defined and the various bits of we glued a 2Mhz part onto the bus stuff is all well documented. Nowdays its more complex because most kbc's aren't standalone low end microcontrollers but are chipset integrated cells or even software SMM emulations. The real test is to fish out something like an old Digital Hi-note laptop or an early 486 board with seperate kbc and try it. I have a Digital HiNote collecting dust which had this keyboard problem with the RH 6.x 2.2.x boot disk kernels, IIRC. I can test if you like, but I won't be able to get to it until the weekend. That'd be very nice indeed. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Vojtech Pavlik wrote: On Thu, Jan 27, 2005 at 12:12:23PM +0100, Sebastian Piechocki wrote: Dnia czwartek, 27 stycznia 2005 11:25, Vojtech Pavlik napisa: On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote: Sebastian Piechocki wrote: As I said I'm sending you mails from kernel masters:) Thanks. If you haven't such a problem, please send them your dmesg with i8042.debug and acpi=off. I made an alternative plan. I applied a custom patch that gives me far less output and prevents scrolling and gets what I hope is what is required. ... could you just increase the timeout value to some insane amount? That should take care of the AUX_LOOP output getting back only after issuing the next command. Increasing the timeout doesn't help. I've increased timout ten times and the result is the same. OK, in that case the BIOS i8042 emulation just interferes badly with the real i8042 and I doubt we can do much else than keep the BIOS from interfering. And just how do we do that? -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Discussion: Dmitry: Here are patches with some delays. One never knows - maybe they help someone. Andries: Only insert delays in the kernel source when either we know about at least one person who reports that it helps, or about data sheets that specify that the delay is required. Otherwise one creates myths and superstition. Lee Revell: Seems like a comment along the lines of foo hardware doesn't work right unless we delay a bit here is the obvious solution. Then someone can easily disprove it later. At present the comment would be Here is a delay - nobody knows why we are adding it. Alan: Myths are not really involved here. The IBM PC hardware specifications are fairly well defined If there is a data sheet that requires the delay I am of course happy. If there are test results that show that it helps, I am happy as well. But the given motivation was you never know - it might help. Bad. The present situation is that often 2.4 works and 2.6 fails. Not because of some delay that is also absent in 2.4. Often because of all those keyboard commands we send to the hardware. Sometimes also because of ACPI. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, 27 Jan 2005, Jaco Kroon wrote: Which indicates (as far as my understanding goes) that the command times out, as such the param value stays the same (ready for re-use in the second command). The second commands succeeds but does not return one of the expected (0x00, 0xff, 0xfa) values, instead it returns the value as expected by the first command (0xa5). The last value on both lines is the return value. From the second snippet: No, I think the 0x5a you see is the 0x5a that is _still_ there, because we never got any reply at all from the i8042_command(I8042_CMD_AUX_LOOP) case, nor did the I8042_CMD_AUX_TEST thing do anything at all. I have a suspicion: these commands are also one of the few ones that write a data byte to the data port immediately after writing the command byte to the status port. It so happens that if the hardware is slow to reach to the command byte, we might read the status word _before_ the hardware has had time to even say ok, my input port is now full. We have a udelay() there in i8042_wait_write(), but we have it _after_ we've done the i8042_read_status(), so effectively the i8042_read_status() happens immediately after the i8042_write_command(). So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. The IO delay should be _before_ the read of the status, not after it. So how about adding an extra udelay(50) to either the top of i8042_wait_write(), or to the bottom of i8042_write_command()? Does that make any difference? (50 usec is probably overkill, and an alternative is to just make the write_data/write_command inline functions in i8042-io.h use the inb_p/outb_p versions that put a serializing IO instruction in between, which should give you a nice 1us delay even on modern hardware.) Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
The code is
param = 0x5a;
if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xa5) {
if (i8042_command(param, I8042_CMD_AUX_TEST)
|| (param param != 0xfa param != 0xff))
return -1;
}
where
#define I8042_CMD_AUX_LOOP 0x11d3: write d3, write 5a, read -param
#define I8042_CMD_AUX_TEST 0x01a9: write a9, read -param
In my docs (http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.3)
d3 is classified under Obscure, probably obsolete, commands.
The reason is that there is hardware that does not implement d3.
Originally it was special to MCA. Later it was also used as part of
the Synaptics multiplexing handshake.
Now you read one byte after the command a9 and get a5 - clearly the 5a
that was written and complemented. So it looks like the d3 really worked.
The first i8042_command() returned -1, but it really wrote the 5a,
so it did i8042_write_command(d3) and i8042_write_data(5a) and then
the i8042_wait_read() returned -1, a timeout.
Since the byte was there to read, the flag was lost that indicated
that data was available. Hmm. Sequence of actions:
inb(64);// until bit 1 clear
outb(d3, 64);
inb(64);// until bit 1 clear
outb(5a, 60);
inb(64);// until bit 0 set - timeout
inb(64);// until bit 1 clear
outb(a9, 64);
inb(64);// until bit 0 set
inb(64);// test for AUX
inb(60);
I am afraid I don't understand what happens.
One can imagine that the second inb(64) comes too quickly
so that we write the 5a too quickly. But all happens as it
should: the d3 is executed, the 5a is moved from input buffer
to output buffer, the AUXB bit is set, only the ready flag never comes,
not within I8042_CTL_TIMEOUT=1 times 50 usec, that is 0.5 sec.
By the way, I have some old docs that describe sending a command by
repeat inb(64) until bit 1 clear
outb(cmd, 64)
repeat inb(64) until bit 1 set
and we only do the first half.
Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. The IO delay should be _before_ the read of the status, not after it. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, 27 Jan 2005 21:29:47 +0100, Andries Brouwer [EMAIL PROTECTED] wrote: On Thu, Jan 27, 2005 at 10:09:24AM -0800, Linus Torvalds wrote: So what _might_ happen is that we write the command, and then i8042_wait_write() thinks that there is space to write the data immediately, and writes the data, but now the data got lost because the buffer was busy. Hmm - I just answered the same post and concluded that I didnt understand, so you have progressed further. I considered the same possibility, but the data was not lost since we read it again later. Only the ready flag was lost. No, note that if there was valid data we would dee 0xa5 instead of 0x5a that was in the buffer - because in i8042_command we invert data coming from AUX port. So Linus's theory seems feasible. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
as expected by the first command (0xa5). The last value on both lines
is the return value. From the second snippet:
No, I think the 0x5a you see is the 0x5a that is _still_ there, because we
never got any reply at all from the i8042_command(I8042_CMD_AUX_LOOP)
case, nor did the I8042_CMD_AUX_TEST thing do anything at all.
I suspect I didn't explain clearly. Note that the outer test expects a
0xa5 (we pass 0x5a in). That is what made me suspect that the second
request gets the first ones return value.
I have a suspicion: these commands are also one of the few ones that write
a data byte to the data port immediately after writing the command byte to
the status port.
Yes. The commands that write something is:
CTL_WCTR
KBD_LOOP (I quess this is what breaks if no USB1.1 present in kernel)
AUX_SEND (obviously)
AUX_LOOP (the one that we think is breaking)
MIX_SEND (obviously).
All of them send exactly one byte.
It so happens that if the hardware is slow to reach to the command byte,
we might read the status word _before_ the hardware has had time to even
say ok, my input port is now full. We have a udelay() there in
i8042_wait_write(), but we have it _after_ we've done the
i8042_read_status(), so effectively the i8042_read_status() happens
immediately after the i8042_write_command().
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
Ie, some nice and tight loop. This has the downside that if we check
_just before_ the pin gets asserted, then delay and check again _after_
it has been cleared we will deadlock. So the udelay() before the loop
(or rewriting the loop to do{}while(...)) is probably a better solution,
although this will cause us to _always_ wait at least 50 microseconds
(not that that is a long time).
So what _might_ happen is that we write the command, and then
i8042_wait_write() thinks that there is space to write the data
immediately, and writes the data, but now the data got lost because the
buffer was busy.
This makes a lot of sense.
The IO delay should be _before_ the read of the status, not after it.
So how about adding an extra udelay(50) to either the top of
i8042_wait_write(), or to the bottom of i8042_write_command()? Does that
make any difference?
No. No difference, still the same result.
(50 usec is probably overkill, and an alternative is to just make the
write_data/write_command inline functions in i8042-io.h use the
inb_p/outb_p versions that put a serializing IO instruction in between,
which should give you a nice 1us delay even on modern hardware.)
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
Jaco
--
There are only 10 kinds of people in this world,
those that understand binary and those that don't.
http://www.kroon.co.za/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thu, 27 Jan 2005, Jaco Kroon wrote: Hmm, just an idea, shouldn't the i8042_write_command be waiting until the device has asserted the pin to indicate that the buffer is busy? No. Because then you might end up waiting forever for the _opposite_ reason, namely that the hardware was so fast that you never saw it busy. The IO delay should be _before_ the read of the status, not after it. So how about adding an extra udelay(50) to either the top of i8042_wait_write(), or to the bottom of i8042_write_command()? Does that make any difference? No. No difference, still the same result. Oh, well. It was such a good theory, especially as it works fine with ACPI off (if I understood your report correctly), so some other state is what seems to bring it on. (50 usec is probably overkill, and an alternative is to just make the write_data/write_command inline functions in i8042-io.h use the inb_p/outb_p versions that put a serializing IO instruction in between, which should give you a nice 1us delay even on modern hardware.) ok, how would I try this? Where can I find an example to code it from? Sorry, I should probably be grepping ... If the udelay() didn't work, then this one isn't worth worryign about either. Back to the drawing board. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote:
On Thu, 27 Jan 2005, Jaco Kroon wrote:
Hmm, just an idea, shouldn't the i8042_write_command be waiting until
the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the hardware was so fast that you never saw it busy.
I've tried it anyway:
static inline void i8042_write_command(int val)
{
outb(val, I8042_COMMAND_REG);
while(~i8042_read_status() I8042_STR_IBF);
}
This to me just gives surety that we don't miss that asserted signal,
but a udelay() before the test would do exactly the same thing. And
yes, your argument for the lockup is very, very valid.
The IO delay should be _before_ the read of the status, not after it.
So how about adding an extra udelay(50) to either the top of
i8042_wait_write(), or to the bottom of i8042_write_command()? Does that
make any difference?
No. No difference, still the same result.
Oh, well. It was such a good theory, especially as it works fine with ACPI
off (if I understood your report correctly), so some other state is what
seems to bring it on.
Yes. You understand correctly. Booting with acpi=off though has deadly
implications when rebooting though (bios gives you the black screen of
void). So I would like to keep booting with acpi=off down to an
absolute minimum.
(50 usec is probably overkill, and an alternative is to just make the
write_data/write_command inline functions in i8042-io.h use the
inb_p/outb_p versions that put a serializing IO instruction in between,
which should give you a nice 1us delay even on modern hardware.)
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
Yea. But for interrests sake, what do you mean with a serializing IO
instruction?
I also tried increasing the total timeout value to about 5 seconds
(versus the default half second), still no success, so the device is
simply not sending back the requested values.
I still stand with the theory that it is sending back the value we want
for the first request on the second one (managed to get this one by
explicitly turning i8042_debug on and off in the code):
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
drivers/input/serio/i8042.c: 20 - i8042 (command) [4]
drivers/input/serio/i8042.c: 47 - i8042 (return) [4]
drivers/input/serio/i8042.c: 60 - i8042 (command) [5]
drivers/input/serio/i8042.c: 56 - i8042 (parameter) [5]
i8042_check_aux()
drivers/input/serio/i8042.c: Interrupt 12, without any data [9]
i8042_flush()
drivers/input/serio/i8042.c: d3 - i8042 (command) [13]
drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13]
drivers/input/serio/i8042.c: -- i8042 (timeout) [875]
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
drivers/input/serio/i8042.c: a9 - i8042 (command) [879]
drivers/input/serio/i8042.c: a5 - i8042 (return) [879]
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
I've rebooted a couple of times and that interrupt is in exactly the
same place every time. And int 12 is indeed the AUX device, could this
be a clue? Ok, with acpi=off and i8042.debug=1 I get:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
drivers/input/serio/i8042.c: 20 - i8042 (command) [0]
drivers/input/serio/i8042.c: 47 - i8042 (return) [0]
drivers/input/serio/i8042.c: 60 - i8042 (command) [1]
drivers/input/serio/i8042.c: 56 - i8042 (parameter) [1]
i8042_check_aux()
i8042_flush()
drivers/input/serio/i8042.c: d3 - i8042 (command) [1]
drivers/input/serio/i8042.c: 5a - i8042 (parameter) [1]
drivers/input/serio/i8042.c: a5 - i8042 (return) [1]
i8042_check_aux: passed
At which point it makes no further sense to dump stuff out as with
acpi=on this has already failed.
Note that we are sending in 0x5a and expecting back 0xa5, which is
exactly what we get back from the second request. Also note that
without ACPI we get the right value back first time round. ACPI imho is
doing something wrong (or the test needs to change due to ACPI). Since
it only breaks (to the best of my knowledge) on Toshiba Satellite
P10-??? notebooks this seems to be a bug in the BIOS more likely.
Right, the message about ACPI detection being disabled can be tracked to
i8042_x86ia64io.h, specifically i8042_acpi_init(). This function
performs two acpi_bus_register_driver calls (Not sure what different
return values means, suspect 0 == error, =0 implies success but
somehow reflect the number of devices detected since -ENODEV is returned
should the call return 0?).
Here is however an oddity, in the case where the i8042_acpi_kbd_driver
registration returns 0 the driver promptly gets unregistered, this is
not the case for
Re: i8042 access timings
On Fri, 28 Jan 2005, Jaco Kroon wrote: ok, how would I try this? Where can I find an example to code it from? Sorry, I should probably be grepping ... If the udelay() didn't work, then this one isn't worth worryign about either. Back to the drawing board. Yea. But for interrests sake, what do you mean with a serializing IO instruction? If you use outb_p() instead of an outb(), the regular IO instruction will be followed by another out to another port on the motherboard: that will not only cause a delay, it should also force at least the host bridge to have no outstanding posted writes (the host bridge shouldn't post IO port writes anyway, but hey, it won't hurt to try to make even more sure of that). I also tried increasing the total timeout value to about 5 seconds (versus the default half second), still no success, so the device is simply not sending back the requested values. If it was the other way around (that it works with ACPI _on_), I'd assume that ACPI just disables some broken BIOS SMM emulation code. But I just don't see ACPI _enabling_ SMM emulation. That would be just too strange, and against the whole point of the legacy keyboard emulation stuff - you want to do legacy keyboard emulation if the OS is old, not if it's new. It may be that ACPI ends up enabling some silly power control SMM sequence that wakes up on keyboard accesses, and screws up the emulation. That sounds pretty strange too, I have to say - even if SMM/ACPI would like to trap keyboard command sequences, I'd have expected it to just pass them through after looking at them. One option may be that SMM/ACPI traps the _received_ characters, and incorrectly eats the reply, because it thinks it's some special key sequence (and should cause SMM/ACPI to make the screen brighter or something silly like that). Does anybody know/remember what the keycode 0xA5 means? I still stand with the theory that it is sending back the value we want for the first request on the second one (managed to get this one by explicitly turning i8042_debug on and off in the code): i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 - i8042 (command) [4] drivers/input/serio/i8042.c: 47 - i8042 (return) [4] drivers/input/serio/i8042.c: 60 - i8042 (command) [5] drivers/input/serio/i8042.c: 56 - i8042 (parameter) [5] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [9] i8042_flush() drivers/input/serio/i8042.c: d3 - i8042 (command) [13] drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13] drivers/input/serio/i8042.c: -- i8042 (timeout) [875] i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1 drivers/input/serio/i8042.c: a9 - i8042 (command) [879] drivers/input/serio/i8042.c: a5 - i8042 (return) [879] i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0 I've rebooted a couple of times and that interrupt is in exactly the same place every time. And int 12 is indeed the AUX device, could this be a clue? Does it change if you change the initial value of param (0x5a) to something else? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Only the ready flag was lost. No, note that if there was valid data we would see 0xa5 instead of 0x5a that was in the buffer - because in i8042_command we invert data coming from AUX port. We misunderstand each other. Let me repeat. The following happens: We wait, then write d3, wait, then write 5a, wait for input, timeout. We wait, then write a9, wait for input, read 5a from AUXB. (That 5a is inverted to a5 to signal that it came from AUXB.) Of course, that 5a is the result of the 5a that we sent via the d3 command. But why does that command time out? For some reason the information that there is a byte ready to be read was not transmitted to the status register. But as soon as we gave another command, a9 in this case, this system remembered that something was ready, and set the appropriate status bit. One might experiment a little - see for example whether other commands than a9 suffice in waking the kbd controller. All is fine, only the flag was lost, nobody knows why. Maybe just because the d3 implementation is buggy. That has been seen more often. But there is another part that we must think about - the fragment i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [9] i8042_flush() Andries By the way, we should remove this silly response byte inversion and just store a separate bit. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Thursday 27 January 2005 17:36, Linus Torvalds wrote: I also tried increasing the total timeout value to about 5 seconds (versus the default half second), still no success, so the device is simply not sending back the requested values. If it was the other way around (that it works with ACPI _on_), I'd assume that ACPI just disables some broken BIOS SMM emulation code. But I just don't see ACPI _enabling_ SMM emulation. That would be just too strange, and against the whole point of the legacy keyboard emulation stuff - you want to do legacy keyboard emulation if the OS is old, not if it's new. It is my understanding that ACPI and legacy emulation are to a certain degree tangent to each other. You can work in ACPI mode and still use USB legacy emulation and you could be in legacy mode but with USB loaded and USB legacy emulation turned off. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Linus Torvalds wrote: On Fri, 28 Jan 2005, Jaco Kroon wrote: ok, how would I try this? Where can I find an example to code it from? Sorry, I should probably be grepping ... If the udelay() didn't work, then this one isn't worth worryign about either. Back to the drawing board. Yea. But for interrests sake, what do you mean with a serializing IO instruction? If you use outb_p() instead of an outb(), the regular IO instruction will be followed by another out to another port on the motherboard: that will not only cause a delay, it should also force at least the host bridge to have no outstanding posted writes (the host bridge shouldn't post IO port writes anyway, but hey, it won't hurt to try to make even more sure of that). No go. Does not help at all. Very nifty idea to force another character through the bus to cause a delay though. I also tried increasing the total timeout value to about 5 seconds (versus the default half second), still no success, so the device is simply not sending back the requested values. If it was the other way around (that it works with ACPI _on_), I'd assume that ACPI just disables some broken BIOS SMM emulation code. But I just don't see ACPI _enabling_ SMM emulation. That would be just too strange, and against the whole point of the legacy keyboard emulation stuff - you want to do legacy keyboard emulation if the OS is old, not if it's new. I don't see this notebook running any non-ACPI enabled OS. It would just be too broken (consider the black screen of void if one boots with acpi=off). Some very old legacy OSs would not even have USB1.1 support which will kill the keyboard. It may be that ACPI ends up enabling some silly power control SMM sequence that wakes up on keyboard accesses, and screws up the emulation. That sounds pretty strange too, I have to say - even if SMM/ACPI would like to trap keyboard command sequences, I'd have expected it to just pass them through after looking at them. Why? If it is going to make the screen dimmer/brighter after pressing the keys - what is the use of passing them through to the OS? After all, the user has already seen the effect these keys caused and giving them to the OS to do something else with will end up being counter intuitive to the user. One option may be that SMM/ACPI traps the _received_ characters, and incorrectly eats the reply, because it thinks it's some special key sequence (and should cause SMM/ACPI to make the screen brighter or something silly like that). Interresting idea. The Fn+F6/F7 keys does indeed make the screen brighter and dimmer, and afaik these gets trapped by SMM/ACPI in the BIOS and never even gets to Linux. Does anybody know/remember what the keycode 0xA5 means? I still stand with the theory that it is sending back the value we want for the first request on the second one (managed to get this one by explicitly turning i8042_debug on and off in the code): i8042_init() ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1 ACPI: PS/2 Mouse Controller [MSE0] at irq 12 i8042_controller_init() i8042_flush() drivers/input/serio/i8042.c: 20 - i8042 (command) [4] drivers/input/serio/i8042.c: 47 - i8042 (return) [4] drivers/input/serio/i8042.c: 60 - i8042 (command) [5] drivers/input/serio/i8042.c: 56 - i8042 (parameter) [5] i8042_check_aux() drivers/input/serio/i8042.c: Interrupt 12, without any data [9] i8042_flush() drivers/input/serio/i8042.c: d3 - i8042 (command) [13] drivers/input/serio/i8042.c: 5a - i8042 (parameter) [13] drivers/input/serio/i8042.c: -- i8042 (timeout) [875] i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1 drivers/input/serio/i8042.c: a9 - i8042 (command) [879] drivers/input/serio/i8042.c: a5 - i8042 (return) [879] i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0 I've rebooted a couple of times and that interrupt is in exactly the same place every time. And int 12 is indeed the AUX device, could this be a clue? Does it change if you change the initial value of param (0x5a) to something else? I've changed the initial input to 0xbb and the output from the second command changed to 0x44. So it does indeed look like my theory might be workable. Just a thought, the acpi_driver i8042_acpi_aux_driver struct has an .add option, that gets called when ACPI detects the AUX device. ic8042_acpi_aux_add() gets called *before* we attempt initialisation/detectiong of the device. Shouln't this be sufficient to say yes, there is such a device, this is it's port and irq numbers? As such, do we still need to go through the AUX_LOOP and AUX_TEST process to determine whether the device is installed or not? On the other hand, why would asking ACPI what the correct interrupt is break it? In i8042_platform_init() (i8042-x86ia64io.h) there is a commented request_region() statement. Would this make a difference, and also, from the comment it would make sense to reserve that region, so why
Re: i8042 access timings
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with i8042.debug
and acpi=off.
I made an alternative plan. I applied a custom patch that gives me far less
output and prevents scrolling and gets what I hope is what is required.
With acpi=on I get the following output:
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
i8042_allocate_kbd_port()
i8042_port_register()
With acpi=off I get this:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: passed
i8042_check_mux()
i8042_enable_mux_mode()
i8042_flush()
i8042_open(): mux_version==19
i8042.c: Detected active multiplexing controller, rev 1.9.
i8042_enable_mux_ports()
i8042_allocate_mux_port()
i8042_port_register()
Ok, some explanation is probably in order, I just put a printk(KERN_INFO
"function_name()\n" at the top of practically every function and then I
filled up i8042_check_aux() because that is where the error is detected.
In the first case (the interesting one) these lines pop up:
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
as expected by the first command (0xa5). The last value on both lines
is the return value. From the second snippet:
i8042_flush()
i8042_check_aux: passed
Indicates that the outer test passed first time round, ie, exit code 0
and return param of 0xa5. What I have done to get mine working with
acpi=on is applied the following patch (apologies if mozilla breaks this):
==
--- linux-2.6.10/drivers/input/serio/i8042.c2004-12-24
23:33:52.0 +0200
+++ linux-2.6.10-patched/drivers/input/serio/i8042.c2005-01-24
21:44:33.790291480 +0200
@@ -595,7 +595,7 @@
*/
if (i8042_command(, I8042_CMD_AUX_TEST)
- || (param && param != 0xfa && param != 0xff))
+ || (param && param != 0xfa && param != 0xa5 &&
param != 0xff))
return -1;
}
==
Which I don't think is the proper solution, more likely the problem lies
in the i8042_command function. Unfortunately I don't have time right
now to add more debug code (to possibly only issue those dbg statements
upto a certain point in order to reduce the amount of output).
> As I remember with acpi=off i8042 detects multplexer MUX with four ports!
> I tried to make a hack for mux detection, but mux was detected and
touchpad
> was not:(
Yes. This seems correct, however the touchoad worked "perfectly" for me
when I booted with acpi=off.
Dmitry,
did you see this one?
Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
works, this is not the case of ACPI setting the wrong ports or something
fundamental like that. It looks like some state of the keyboard controller
just disables the loopback command and/or the AUX_TEST command.
Might the "no KBD" case be something similar?
I'm probably a bit off here, but what "no KBD" case? On these
particular notebooks we both had to compile in specifically USB1.1
support in order to have keyboard support, but since I want USB support
in any case this is not a problem for me (although I would love to know
what caused this).
Sebastian, can you make your hack also print out what the errors were (in
particular, was it "i8042_command()" that failed, or was it that the
return value was different from the expected ones, and if so - what?)
I hope my debug did exactly that.
From the orriginal mail sent to me by Sebastian:
In method:
i8042_check_aux
There is:
param = 0x5a;
if (i8042_command(, I8042_CMD_AUX_LOOP) || param != 0xa5)
{
/*
* External connection test - filters out AT-soldered PS/2 i8042's
* 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
* 0xfa - no error on some notebooks which ignore the spec
* Because it's common for chipsets to return error on perfectly
functioning
* AUX ports, we test for this only when the LOOP command failed.
*/
if (i8042_command(, I8042_CMD_AUX_TEST)
|| (param && param != 0xfa && param != 0xff))
return -1;
}
I have commented the line with return -1.
I know that this solution is very stupid, but works fine.
I use
Re: i8042 access timings
On Wed, 26 Jan 2005 12:05:47 -0500 (EST), linux-os
<[EMAIL PROTECTED]> wrote:
> On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
>
> > On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]>
> > wrote:
> >> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> >>> @@ -213,7 +217,10 @@
> >>> if (!retval)
> >>> for (i = 0; i < ((command >> 8) & 0xf); i++) {
> >>> if ((retval = i8042_wait_read())) break;
> >>> - if (i8042_read_status() & I8042_STR_AUXDATA)
> >>> + udelay(I8042_STR_DELAY);
> >>> + str = i8042_read_status();
> >> []
> >>> + udelay(I8042_DATA_DELAY);
> >>> + if (str & I8042_STR_AUXDATA)
> >>> param[i] = ~i8042_read_data();
> >>> else
> >>> param[i] = i8042_read_data();
> >>
> >> We may as well drop the negation. It's a bad way to signal the data came
> >> from the AUX port. Then we don't need the extra status read and can just
> >> proceed to read the data, since IMO we don't need to wait inbetween,
> >> even according to the IBM spec.
> >
> > Do you remember why it has been done to begin with?
> >
> > --
> > Dmitry
>
>
> The only time you need any delay at all is after you have send
...
Thank you Richard for this thorough explanation of IO access but I was
actually asking why we wanted to invert AUX data.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i < ((command >> 8) & 0xf); i++) {
if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() & I8042_STR_AUXDATA)
+ udelay(I8042_STR_DELAY);
+ str = i8042_read_status();
[]
+ udelay(I8042_DATA_DELAY);
+ if (str & I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
Do you remember why it has been done to begin with?
--
Dmitry
The only time you need any delay at all is after you have send
the chip a reset command (0xff). Of course if you expect the
device to turn ON/OFF something like the old A20 bit, then
you need to wait for it to (1) get the command, (2) interpret
it (it contains a uP), then read/modify write the appropriate
bit. That takes time. However, if you get an interrupt that
says "data are available", you read the data with no waiting.
It's there and has been for a long time. The status bits will
have always been set before the internal status event. There
is never any need to wait after that.
Most of the newer emulations are inside Super-IO chips. They
don't suffer the port I/O glitches that the old ISA-mapped
devices did. You done' even need the "_p" in the port read/writes
but we need to maintain compatibility with some old machines
so I wouldn't change that.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> > @@ -213,7 +217,10 @@
> > if (!retval)
> > for (i = 0; i < ((command >> 8) & 0xf); i++) {
> > if ((retval = i8042_wait_read())) break;
> > - if (i8042_read_status() & I8042_STR_AUXDATA)
> > + udelay(I8042_STR_DELAY);
> > + str = i8042_read_status();
> []
> > + udelay(I8042_DATA_DELAY);
> > + if (str & I8042_STR_AUXDATA)
> > param[i] = ~i8042_read_data();
> > else
> > param[i] = i8042_read_data();
>
> We may as well drop the negation. It's a bad way to signal the data came
> from the AUX port. Then we don't need the extra status read and can just
> proceed to read the data, since IMO we don't need to wait inbetween,
> even according to the IBM spec.
Do you remember why it has been done to begin with?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> Recently there was a patch from Alan regarding access timing violations
> in i8042. It made me curious as we only wait between accesses to status
> register but not data register. I peeked into FreeBSD code and they use
> delays to access both registers and I wonder if that's the piece that
> makes i8042 mysteriously fail on some boards.
>
> Anyway, regardless of whether access to data register should be done with
> delay as well there seem to be another timing access violation - in
> i8042_command we do i8042_wait_read which reads STR and then immediately
> do i8042_read_status to check AUXDATA bit.
>
> Does the patch below makes any sense?
>
> + do {
> + str = i8042_read_status();
> + if (~str & I8042_STR_OBF)
> + break;
> + udelay(I8042_DATA_DELAY);
> data = i8042_read_data();
In my opinion, there is no requirement to wait after status read
returned success and the actual reading of data. This way we'd have to
have the delay in the interrupt routine as well.
> - dbg("%02x <- i8042 (flush, %s)", data,
> - i8042_read_status() & I8042_STR_AUXDATA ? "aux" :
> "kbd");
> - }
> + dbg("%02x <- i8042 (flush, %s)", data, str & I8042_STR_AUXDATA
> ? "aux" : "kbd");
> + udelay(I8042_STR_DELAY);
> + } while (i++ < I8042_BUFFER_SIZE);
So the only problem in the flush routine is the debugging print.
> spin_unlock_irqrestore(_lock, flags);
>
> @@ -190,6 +193,7 @@
> static int i8042_command(unsigned char *param, int command)
> {
> unsigned long flags;
> + unsigned char str;
> int retval = 0, i = 0;
>
> if (i8042_noloop && command == I8042_CMD_AUX_LOOP)
> @@ -213,7 +217,10 @@
> if (!retval)
> for (i = 0; i < ((command >> 8) & 0xf); i++) {
> if ((retval = i8042_wait_read())) break;
> - if (i8042_read_status() & I8042_STR_AUXDATA)
> + udelay(I8042_STR_DELAY);
> + str = i8042_read_status();
[]
> + udelay(I8042_DATA_DELAY);
> + if (str & I8042_STR_AUXDATA)
> param[i] = ~i8042_read_data();
> else
> param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
Recently there was a patch from Alan regarding access timing violations
in i8042. It made me curious as we only wait between accesses to status
register but not data register. I peeked into FreeBSD code and they use
delays to access both registers and I wonder if that's the piece that
makes i8042 mysteriously fail on some boards.
Anyway, regardless of whether access to data register should be done with
delay as well there seem to be another timing access violation - in
i8042_command we do i8042_wait_read which reads STR and then immediately
do i8042_read_status to check AUXDATA bit.
Does the patch below makes any sense?
+ do {
+ str = i8042_read_status();
+ if (~str I8042_STR_OBF)
+ break;
+ udelay(I8042_DATA_DELAY);
data = i8042_read_data();
In my opinion, there is no requirement to wait after status read
returned success and the actual reading of data. This way we'd have to
have the delay in the interrupt routine as well.
- dbg(%02x - i8042 (flush, %s), data,
- i8042_read_status() I8042_STR_AUXDATA ? aux :
kbd);
- }
+ dbg(%02x - i8042 (flush, %s), data, str I8042_STR_AUXDATA
? aux : kbd);
+ udelay(I8042_STR_DELAY);
+ } while (i++ I8042_BUFFER_SIZE);
So the only problem in the flush routine is the debugging print.
spin_unlock_irqrestore(i8042_lock, flags);
@@ -190,6 +193,7 @@
static int i8042_command(unsigned char *param, int command)
{
unsigned long flags;
+ unsigned char str;
int retval = 0, i = 0;
if (i8042_noloop command == I8042_CMD_AUX_LOOP)
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() I8042_STR_AUXDATA)
+ udelay(I8042_STR_DELAY);
+ str = i8042_read_status();
[]
+ udelay(I8042_DATA_DELAY);
+ if (str I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() I8042_STR_AUXDATA)
+ udelay(I8042_STR_DELAY);
+ str = i8042_read_status();
[]
+ udelay(I8042_DATA_DELAY);
+ if (str I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
Do you remember why it has been done to begin with?
--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() I8042_STR_AUXDATA)
+ udelay(I8042_STR_DELAY);
+ str = i8042_read_status();
[]
+ udelay(I8042_DATA_DELAY);
+ if (str I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
Do you remember why it has been done to begin with?
--
Dmitry
The only time you need any delay at all is after you have send
the chip a reset command (0xff). Of course if you expect the
device to turn ON/OFF something like the old A20 bit, then
you need to wait for it to (1) get the command, (2) interpret
it (it contains a uP), then read/modify write the appropriate
bit. That takes time. However, if you get an interrupt that
says data are available, you read the data with no waiting.
It's there and has been for a long time. The status bits will
have always been set before the internal status event. There
is never any need to wait after that.
Most of the newer emulations are inside Super-IO chips. They
don't suffer the port I/O glitches that the old ISA-mapped
devices did. You done' even need the _p in the port read/writes
but we need to maintain compatibility with some old machines
so I wouldn't change that.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Wed, 26 Jan 2005 12:05:47 -0500 (EST), linux-os
[EMAIL PROTECTED] wrote:
On Wed, 26 Jan 2005, Dmitry Torokhov wrote:
On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik [EMAIL PROTECTED]
wrote:
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
@@ -213,7 +217,10 @@
if (!retval)
for (i = 0; i ((command 8) 0xf); i++) {
if ((retval = i8042_wait_read())) break;
- if (i8042_read_status() I8042_STR_AUXDATA)
+ udelay(I8042_STR_DELAY);
+ str = i8042_read_status();
[]
+ udelay(I8042_DATA_DELAY);
+ if (str I8042_STR_AUXDATA)
param[i] = ~i8042_read_data();
else
param[i] = i8042_read_data();
We may as well drop the negation. It's a bad way to signal the data came
from the AUX port. Then we don't need the extra status read and can just
proceed to read the data, since IMO we don't need to wait inbetween,
even according to the IBM spec.
Do you remember why it has been done to begin with?
--
Dmitry
The only time you need any delay at all is after you have send
...
Thank you Richard for this thorough explanation of IO access but I was
actually asking why we wanted to invert AUX data.
--
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with i8042.debug
and acpi=off.
I made an alternative plan. I applied a custom patch that gives me far less
output and prevents scrolling and gets what I hope is what is required.
With acpi=on I get the following output:
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
i8042_allocate_kbd_port()
i8042_port_register()
With acpi=off I get this:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: passed
i8042_check_mux()
i8042_enable_mux_mode()
i8042_flush()
i8042_open(): mux_version==19
i8042.c: Detected active multiplexing controller, rev 1.9.
i8042_enable_mux_ports()
i8042_allocate_mux_port()
i8042_port_register()
Ok, some explanation is probably in order, I just put a printk(KERN_INFO
function_name()\n at the top of practically every function and then I
filled up i8042_check_aux() because that is where the error is detected.
In the first case (the interesting one) these lines pop up:
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a = -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 = 0
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
as expected by the first command (0xa5). The last value on both lines
is the return value. From the second snippet:
i8042_flush()
i8042_check_aux: passed
Indicates that the outer test passed first time round, ie, exit code 0
and return param of 0xa5. What I have done to get mine working with
acpi=on is applied the following patch (apologies if mozilla breaks this):
==
--- linux-2.6.10/drivers/input/serio/i8042.c2004-12-24
23:33:52.0 +0200
+++ linux-2.6.10-patched/drivers/input/serio/i8042.c2005-01-24
21:44:33.790291480 +0200
@@ -595,7 +595,7 @@
*/
if (i8042_command(param, I8042_CMD_AUX_TEST)
- || (param param != 0xfa param != 0xff))
+ || (param param != 0xfa param != 0xa5
param != 0xff))
return -1;
}
==
Which I don't think is the proper solution, more likely the problem lies
in the i8042_command function. Unfortunately I don't have time right
now to add more debug code (to possibly only issue those dbg statements
upto a certain point in order to reduce the amount of output).
As I remember with acpi=off i8042 detects multplexer MUX with four ports!
I tried to make a hack for mux detection, but mux was detected and
touchpad
was not:(
Yes. This seems correct, however the touchoad worked perfectly for me
when I booted with acpi=off.
Dmitry,
did you see this one?
Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
works, this is not the case of ACPI setting the wrong ports or something
fundamental like that. It looks like some state of the keyboard controller
just disables the loopback command and/or the AUX_TEST command.
Might the no KBD case be something similar?
I'm probably a bit off here, but what no KBD case? On these
particular notebooks we both had to compile in specifically USB1.1
support in order to have keyboard support, but since I want USB support
in any case this is not a problem for me (although I would love to know
what caused this).
Sebastian, can you make your hack also print out what the errors were (in
particular, was it i8042_command() that failed, or was it that the
return value was different from the expected ones, and if so - what?)
I hope my debug did exactly that.
From the orriginal mail sent to me by Sebastian:
In method:
i8042_check_aux
There is:
param = 0x5a;
if (i8042_command(param, I8042_CMD_AUX_LOOP) || param != 0xa5)
{
/*
* External connection test - filters out AT-soldered PS/2 i8042's
* 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
* 0xfa - no error on some notebooks which ignore the spec
* Because it's common for chipsets to return error on perfectly
functioning
* AUX ports, we test for this only when the LOOP command failed.
*/
if (i8042_command(param, I8042_CMD_AUX_TEST)
|| (param param != 0xfa param != 0xff))
return -1;
}
I have commented the line with return -1.
I know that this solution is very stupid, but works fine.
I use 2.6.11-rc1-mm1 kernel, and
Re: i8042 access timings
On Tue, 2005-01-25 at 20:46 +0100, Andries Brouwer wrote: > On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: > > > Still, I wonder if implementing these delays will give IO controller > > better chances to react to our queries and will get rid of some > > failures. > > My objection is this: by doing this you create myths that may > be difficult to dispel later. I recall other situations where > there were superfluous restrictions and I had a hard time convincing > others of the fact that the tests weren't there for any good reason, > that there was no single instance of hardware on earth known to > work better with the added restrictions. Seems like a comment along the lines of "foo hardware doesn't work right unless we delay a bit here" is the obvious solution. Then someone can easily disprove it later. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, 25 Jan 2005 20:25:20 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: > > On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <[EMAIL PROTECTED]> > > wrote: > > > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: > > > > > > > Recently there was a patch from Alan regarding access timing violations > > > > in i8042. It made me curious as we only wait between accesses to status > > > > register but not data register. I peeked into FreeBSD code and they use > > > > delays to access both registers and I wonder if that's the piece that > > > > makes i8042 mysteriously fail on some boards. > > > > > > You are following this much more closely than I do, but isn't the > > > usual complaint "2.4 works, 2.6 fails"? > > > > > > > Quite often it is but too much has changed in input layer to pinpoing > > exact cause of the failure and I am open to any suggestions. Common > > problems I see: > > > > 1. ACPI sometimes interferes with i8042, especially battery status > > polling. I am concerned about embedded controller access as well, it > > looks like it takes sweet time to read/write data to it and ec.c does > > it with interrupts disabled. > > Furthermore, the EC and the i8042 are often the same chip, resulting in > the i8042 not answering when EC is busy. Enabling interrupts won't help. It might or it might not, I think it really depends on firmware implementation. > > Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do > > any additional checks, now that i8042 is not x86 specific we do > > everything by hand and it looks like some hardware is not expecting > > it... > > We may be able to loosen the checks again now that 98% of machines do > have the PS/2 mouse port if they have the AT keyboard port. > Maybe only for specific machines - the report was about a Toshiba and it looks like they have quite a few problems with their KBCs - bouncing keys, not being able to sustain full Synaptics 480 bytes/s rate... -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: > Still, I wonder if implementing these delays will give IO controller > better chances to react to our queries and will get rid of some > failures. My objection is this: by doing this you create myths that may be difficult to dispel later. I recall other situations where there were superfluous restrictions and I had a hard time convincing others of the fact that the tests weren't there for any good reason, that there was no single instance of hardware on earth known to work better with the added restrictions. So, I would prefer to only insert delays if at least one person reports that things improve if you do so. Or if you can point at data sheets that state that such delays are needed. Or perhaps if you can show that there were delays in 2.4 absent in 2.6. Apart from the "not creating myths" reason, there is another: as we know, the keyboard/mouse system is in a bad state in 2.6. It often happens that 2.6.x works and 2.6.y fails, and we ask a user to try intermediate stages to see what change made a difference. Applying random meaningless patches to the keyboard system creates additional noise and uncertainty. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: > On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: > > > > > Recently there was a patch from Alan regarding access timing violations > > > in i8042. It made me curious as we only wait between accesses to status > > > register but not data register. I peeked into FreeBSD code and they use > > > delays to access both registers and I wonder if that's the piece that > > > makes i8042 mysteriously fail on some boards. > > > > You are following this much more closely than I do, but isn't the > > usual complaint "2.4 works, 2.6 fails"? > > > > Quite often it is but too much has changed in input layer to pinpoing > exact cause of the failure and I am open to any suggestions. Common > problems I see: > > 1. ACPI sometimes interferes with i8042, especially battery status > polling. I am concerned about embedded controller access as well, it > looks like it takes sweet time to read/write data to it and ec.c does > it with interrupts disabled. Furthermore, the EC and the i8042 are often the same chip, resulting in the i8042 not answering when EC is busy. Enabling interrupts won't help. > 2. USB legacy emulation - we used to have PS/2 initialization in > GPM/Xfree which means that USB modules (if any) are already loaded and > requested handoff so results were very consistent. Now it all depends > on who's first. There were couple of PCI quirk patches doing early USB > handoff but they have not been applied out of fear breaking some > boxes. I wonder if there are concrete examples of such patches > breaking boxes, how many and whether DMI decode/workaround will be > beneficial for these. I still hope we could get those in after the handoff code is ironed out. It kept (keeps?) crashing some machines and not using USB is an easy way out of this if you don't have the handoff in the early init code. > Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do > any additional checks, now that i8042 is not x86 specific we do > everything by hand and it looks like some hardware is not expecting > it... We may be able to loosen the checks again now that 98% of machines do have the PS/2 mouse port if they have the AT keyboard port. > Still, I wonder if implementing these delays will give IO controller > better chances to react to our queries and will get rid of some > failures. Agreed. I'll check them tomorrow in detail and if I find them OK (I expect to), I'll merge the patch to my tree. Unfortunately I don't expect the delays themselves will fix much. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <[EMAIL PROTECTED]> wrote: > On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: > > > Recently there was a patch from Alan regarding access timing violations > > in i8042. It made me curious as we only wait between accesses to status > > register but not data register. I peeked into FreeBSD code and they use > > delays to access both registers and I wonder if that's the piece that > > makes i8042 mysteriously fail on some boards. > > You are following this much more closely than I do, but isn't the > usual complaint "2.4 works, 2.6 fails"? > Quite often it is but too much has changed in input layer to pinpoing exact cause of the failure and I am open to any suggestions. Common problems I see: 1. ACPI sometimes interferes with i8042, especially battery status polling. I am concerned about embedded controller access as well, it looks like it takes sweet time to read/write data to it and ec.c does it with interrupts disabled. I have a patch that enables interrupts but nobody seems to be interested in testing. ACPI interference ranges from losing bytes and bytes arriving with > 0.5 sec delay to "Can't read/write CTR" type of errors. And on the other hand I see some boxces need ACPI or they will not talk to i8042 (although I suspect cold boot will also fix that). How many 2.4 boxes have ACPI on? I honestly do not know. 2. USB legacy emulation - we used to have PS/2 initialization in GPM/Xfree which means that USB modules (if any) are already loaded and requested handoff so results were very consistent. Now it all depends on who's first. There were couple of PCI quirk patches doing early USB handoff but they have not been applied out of fear breaking some boxes. I wonder if there are concrete examples of such patches breaking boxes, how many and whether DMI decode/workaround will be beneficial for these. Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do any additional checks, now that i8042 is not x86 specific we do everything by hand and it looks like some hardware is not expecting it... Still, I wonder if implementing these delays will give IO controller better chances to react to our queries and will get rid of some failures. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote: > Hi, > Anyway, regardless of whether access to data register should be done with > delay as well there seem to be another timing access violation - in > i8042_command we do i8042_wait_read which reads STR and then immediately > do i8042_read_status to check AUXDATA bit. > > Does the patch below makes any sense? It looks right to me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote: > in i8042. It made me curious as we only wait between accesses to status > register but not data register. I peeked into FreeBSD code and they use > delays to access both registers and I wonder if that's the piece that > makes i8042 mysteriously fail on some boards. Maybe - my own experience is that the last boards I've seen that actually require the delays are the Digital Hinote laptops, so its only stuff only as far as I can tell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: > Recently there was a patch from Alan regarding access timing violations > in i8042. It made me curious as we only wait between accesses to status > register but not data register. I peeked into FreeBSD code and they use > delays to access both registers and I wonder if that's the piece that > makes i8042 mysteriously fail on some boards. You are following this much more closely than I do, but isn't the usual complaint "2.4 works, 2.6 fails"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: Recently there was a patch from Alan regarding access timing violations in i8042. It made me curious as we only wait between accesses to status register but not data register. I peeked into FreeBSD code and they use delays to access both registers and I wonder if that's the piece that makes i8042 mysteriously fail on some boards. You are following this much more closely than I do, but isn't the usual complaint 2.4 works, 2.6 fails? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote: in i8042. It made me curious as we only wait between accesses to status register but not data register. I peeked into FreeBSD code and they use delays to access both registers and I wonder if that's the piece that makes i8042 mysteriously fail on some boards. Maybe - my own experience is that the last boards I've seen that actually require the delays are the Digital Hinote laptops, so its only stuff only as far as I can tell - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Maw, 2005-01-25 at 07:41, Dmitry Torokhov wrote: Hi, Anyway, regardless of whether access to data register should be done with delay as well there seem to be another timing access violation - in i8042_command we do i8042_wait_read which reads STR and then immediately do i8042_read_status to check AUXDATA bit. Does the patch below makes any sense? It looks right to me - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer [EMAIL PROTECTED] wrote: On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: Recently there was a patch from Alan regarding access timing violations in i8042. It made me curious as we only wait between accesses to status register but not data register. I peeked into FreeBSD code and they use delays to access both registers and I wonder if that's the piece that makes i8042 mysteriously fail on some boards. You are following this much more closely than I do, but isn't the usual complaint 2.4 works, 2.6 fails? Quite often it is but too much has changed in input layer to pinpoing exact cause of the failure and I am open to any suggestions. Common problems I see: 1. ACPI sometimes interferes with i8042, especially battery status polling. I am concerned about embedded controller access as well, it looks like it takes sweet time to read/write data to it and ec.c does it with interrupts disabled. I have a patch that enables interrupts but nobody seems to be interested in testing. ACPI interference ranges from losing bytes and bytes arriving with 0.5 sec delay to Can't read/write CTR type of errors. And on the other hand I see some boxces need ACPI or they will not talk to i8042 (although I suspect cold boot will also fix that). How many 2.4 boxes have ACPI on? I honestly do not know. 2. USB legacy emulation - we used to have PS/2 initialization in GPM/Xfree which means that USB modules (if any) are already loaded and requested handoff so results were very consistent. Now it all depends on who's first. There were couple of PCI quirk patches doing early USB handoff but they have not been applied out of fear breaking some boxes. I wonder if there are concrete examples of such patches breaking boxes, how many and whether DMI decode/workaround will be beneficial for these. Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do any additional checks, now that i8042 is not x86 specific we do everything by hand and it looks like some hardware is not expecting it... Still, I wonder if implementing these delays will give IO controller better chances to react to our queries and will get rid of some failures. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer [EMAIL PROTECTED] wrote: On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: Recently there was a patch from Alan regarding access timing violations in i8042. It made me curious as we only wait between accesses to status register but not data register. I peeked into FreeBSD code and they use delays to access both registers and I wonder if that's the piece that makes i8042 mysteriously fail on some boards. You are following this much more closely than I do, but isn't the usual complaint 2.4 works, 2.6 fails? Quite often it is but too much has changed in input layer to pinpoing exact cause of the failure and I am open to any suggestions. Common problems I see: 1. ACPI sometimes interferes with i8042, especially battery status polling. I am concerned about embedded controller access as well, it looks like it takes sweet time to read/write data to it and ec.c does it with interrupts disabled. Furthermore, the EC and the i8042 are often the same chip, resulting in the i8042 not answering when EC is busy. Enabling interrupts won't help. 2. USB legacy emulation - we used to have PS/2 initialization in GPM/Xfree which means that USB modules (if any) are already loaded and requested handoff so results were very consistent. Now it all depends on who's first. There were couple of PCI quirk patches doing early USB handoff but they have not been applied out of fear breaking some boxes. I wonder if there are concrete examples of such patches breaking boxes, how many and whether DMI decode/workaround will be beneficial for these. I still hope we could get those in after the handoff code is ironed out. It kept (keeps?) crashing some machines and not using USB is an easy way out of this if you don't have the handoff in the early init code. Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do any additional checks, now that i8042 is not x86 specific we do everything by hand and it looks like some hardware is not expecting it... We may be able to loosen the checks again now that 98% of machines do have the PS/2 mouse port if they have the AT keyboard port. Still, I wonder if implementing these delays will give IO controller better chances to react to our queries and will get rid of some failures. Agreed. I'll check them tomorrow in detail and if I find them OK (I expect to), I'll merge the patch to my tree. Unfortunately I don't expect the delays themselves will fix much. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: Still, I wonder if implementing these delays will give IO controller better chances to react to our queries and will get rid of some failures. My objection is this: by doing this you create myths that may be difficult to dispel later. I recall other situations where there were superfluous restrictions and I had a hard time convincing others of the fact that the tests weren't there for any good reason, that there was no single instance of hardware on earth known to work better with the added restrictions. So, I would prefer to only insert delays if at least one person reports that things improve if you do so. Or if you can point at data sheets that state that such delays are needed. Or perhaps if you can show that there were delays in 2.4 absent in 2.6. Apart from the not creating myths reason, there is another: as we know, the keyboard/mouse system is in a bad state in 2.6. It often happens that 2.6.x works and 2.6.y fails, and we ask a user to try intermediate stages to see what change made a difference. Applying random meaningless patches to the keyboard system creates additional noise and uncertainty. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, 25 Jan 2005 20:25:20 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer [EMAIL PROTECTED] wrote: On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote: Recently there was a patch from Alan regarding access timing violations in i8042. It made me curious as we only wait between accesses to status register but not data register. I peeked into FreeBSD code and they use delays to access both registers and I wonder if that's the piece that makes i8042 mysteriously fail on some boards. You are following this much more closely than I do, but isn't the usual complaint 2.4 works, 2.6 fails? Quite often it is but too much has changed in input layer to pinpoing exact cause of the failure and I am open to any suggestions. Common problems I see: 1. ACPI sometimes interferes with i8042, especially battery status polling. I am concerned about embedded controller access as well, it looks like it takes sweet time to read/write data to it and ec.c does it with interrupts disabled. Furthermore, the EC and the i8042 are often the same chip, resulting in the i8042 not answering when EC is busy. Enabling interrupts won't help. It might or it might not, I think it really depends on firmware implementation. Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do any additional checks, now that i8042 is not x86 specific we do everything by hand and it looks like some hardware is not expecting it... We may be able to loosen the checks again now that 98% of machines do have the PS/2 mouse port if they have the AT keyboard port. Maybe only for specific machines - the report was about a Toshiba and it looks like they have quite a few problems with their KBCs - bouncing keys, not being able to sustain full Synaptics 480 bytes/s rate... -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i8042 access timings
On Tue, 2005-01-25 at 20:46 +0100, Andries Brouwer wrote: On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: Still, I wonder if implementing these delays will give IO controller better chances to react to our queries and will get rid of some failures. My objection is this: by doing this you create myths that may be difficult to dispel later. I recall other situations where there were superfluous restrictions and I had a hard time convincing others of the fact that the tests weren't there for any good reason, that there was no single instance of hardware on earth known to work better with the added restrictions. Seems like a comment along the lines of foo hardware doesn't work right unless we delay a bit here is the obvious solution. Then someone can easily disprove it later. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
