* i8042 access timings @ 2005-01-25 7:41 Dmitry Torokhov 2005-01-25 10:51 ` Andries Brouwer ` (3 more replies) 0 siblings, 4 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-25 7:41 UTC (permalink / raw) To: linux-input; +Cc: Alan Cox, linux-kernel, Vojtech Pavlik Hi, 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? -- Dmitry ===== drivers/input/serio/i8042.c 1.79 vs edited ===== --- 1.79/drivers/input/serio/i8042.c 2005-01-25 00:54:50 -05:00 +++ edited/drivers/input/serio/i8042.c 2005-01-25 02:04:56 -05:00 @@ -137,8 +137,8 @@ static int i8042_wait_read(void) { int i = 0; - while ((~i8042_read_status() & I8042_STR_OBF) && (i < I8042_CTL_TIMEOUT)) { - udelay(50); + while ((~i8042_read_status() & I8042_STR_OBF) && i < I8042_CTL_TIMEOUT) { + udelay(I8042_STR_DELAY); i++; } return -(i == I8042_CTL_TIMEOUT); @@ -147,8 +147,8 @@ static int i8042_wait_write(void) { int i = 0; - while ((i8042_read_status() & I8042_STR_IBF) && (i < I8042_CTL_TIMEOUT)) { - udelay(50); + while ((i8042_read_status() & I8042_STR_IBF) && i < I8042_CTL_TIMEOUT) { + udelay(I8042_STR_DELAY); i++; } return -(i == I8042_CTL_TIMEOUT); @@ -162,17 +162,20 @@ static int i8042_flush(void) { unsigned long flags; - unsigned char data; + unsigned char str, data; int i = 0; spin_lock_irqsave(&i8042_lock, flags); - while ((i8042_read_status() & I8042_STR_OBF) && (i++ < I8042_BUFFER_SIZE)) { - udelay(50); + do { + str = i8042_read_status(); + if (~str & I8042_STR_OBF) + break; + udelay(I8042_DATA_DELAY); data = i8042_read_data(); - 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); 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(); @@ -424,6 +431,7 @@ ret = 0; goto out; } + udelay(I8042_DATA_DELAY); data = i8042_read_data(); spin_unlock_irqrestore(&i8042_lock, flags); ===== drivers/input/serio/i8042.h 1.12 vs edited ===== --- 1.12/drivers/input/serio/i8042.h 2005-01-22 02:22:51 -05:00 +++ edited/drivers/input/serio/i8042.h 2005-01-25 01:44:36 -05:00 @@ -30,12 +30,19 @@ #endif /* - * This is in 50us units, the time we wait for the i8042 to react. This + * i8042 I/O recovery times + */ +#define I8042_STR_DELAY 20 +#define I8042_DATA_DELAY 7 + + +/* + * This is in 20us units, 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 10000 +#define I8042_CTL_TIMEOUT 25000 /* * When the device isn't opened and it's interrupts aren't used, we poll it at ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 7:41 i8042 access timings Dmitry Torokhov @ 2005-01-25 10:51 ` Andries Brouwer 2005-01-25 19:17 ` Dmitry Torokhov 2005-01-25 12:44 ` Alan Cox ` (2 subsequent siblings) 3 siblings, 1 reply; 47+ messages in thread From: Andries Brouwer @ 2005-01-25 10:51 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, Alan Cox, linux-kernel, Vojtech Pavlik 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"? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 10:51 ` Andries Brouwer @ 2005-01-25 19:17 ` Dmitry Torokhov 2005-01-25 19:25 ` Vojtech Pavlik 2005-01-25 19:46 ` Andries Brouwer 0 siblings, 2 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-25 19:17 UTC (permalink / raw) To: Andries Brouwer; +Cc: linux-input, Alan Cox, linux-kernel, Vojtech Pavlik On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <aebr@win.tue.nl> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 19:17 ` Dmitry Torokhov @ 2005-01-25 19:25 ` Vojtech Pavlik 2005-01-25 19:41 ` Dmitry Torokhov 2005-01-25 19:46 ` Andries Brouwer 1 sibling, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-25 19:25 UTC (permalink / raw) To: dtor_core; +Cc: Andries Brouwer, linux-input, Alan Cox, linux-kernel On Tue, Jan 25, 2005 at 02:17:33PM -0500, Dmitry Torokhov wrote: > On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <aebr@win.tue.nl> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 19:25 ` Vojtech Pavlik @ 2005-01-25 19:41 ` Dmitry Torokhov 0 siblings, 0 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-25 19:41 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Andries Brouwer, linux-input, Alan Cox, linux-kernel On Tue, 25 Jan 2005 20:25:20 +0100, Vojtech Pavlik <vojtech@suse.cz> 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 <aebr@win.tue.nl> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 19:17 ` Dmitry Torokhov 2005-01-25 19:25 ` Vojtech Pavlik @ 2005-01-25 19:46 ` Andries Brouwer 2005-01-25 20:37 ` Lee Revell 1 sibling, 1 reply; 47+ messages in thread From: Andries Brouwer @ 2005-01-25 19:46 UTC (permalink / raw) To: dtor_core Cc: Andries Brouwer, linux-input, Alan Cox, linux-kernel, Vojtech Pavlik 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 19:46 ` Andries Brouwer @ 2005-01-25 20:37 ` Lee Revell 2005-01-27 15:14 ` Alan Cox 0 siblings, 1 reply; 47+ messages in thread From: Lee Revell @ 2005-01-25 20:37 UTC (permalink / raw) To: Andries Brouwer Cc: dtor_core, linux-input, Alan Cox, linux-kernel, Vojtech Pavlik 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 20:37 ` Lee Revell @ 2005-01-27 15:14 ` Alan Cox 2005-01-27 16:24 ` Vojtech Pavlik ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Alan Cox @ 2005-01-27 15:14 UTC (permalink / raw) To: Lee Revell Cc: Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List, Vojtech Pavlik 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 15:14 ` Alan Cox @ 2005-01-27 16:24 ` Vojtech Pavlik 2005-01-27 16:34 ` Bill Rugolsky Jr. 2005-01-27 17:45 ` Andries Brouwer 2 siblings, 0 replies; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-27 16:24 UTC (permalink / raw) To: Alan Cox Cc: Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List On Thu, Jan 27, 2005 at 03:14:36PM +0000, 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 15:14 ` Alan Cox 2005-01-27 16:24 ` Vojtech Pavlik @ 2005-01-27 16:34 ` Bill Rugolsky Jr. 2005-01-27 16:37 ` Vojtech Pavlik 2005-01-27 17:45 ` Andries Brouwer 2 siblings, 1 reply; 47+ messages in thread From: Bill Rugolsky Jr. @ 2005-01-27 16:34 UTC (permalink / raw) To: Alan Cox Cc: Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List, Vojtech Pavlik On Thu, Jan 27, 2005 at 03:14:36PM +0000, 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 16:34 ` Bill Rugolsky Jr. @ 2005-01-27 16:37 ` Vojtech Pavlik 2005-02-13 0:16 ` Bill Rugolsky Jr. 0 siblings, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-27 16:37 UTC (permalink / raw) To: Bill Rugolsky Jr. Cc: Alan Cox, Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote: > On Thu, Jan 27, 2005 at 03:14:36PM +0000, 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 16:37 ` Vojtech Pavlik @ 2005-02-13 0:16 ` Bill Rugolsky Jr. 2005-02-13 8:22 ` Vojtech Pavlik 0 siblings, 1 reply; 47+ messages in thread From: Bill Rugolsky Jr. @ 2005-02-13 0:16 UTC (permalink / raw) To: Vojtech Pavlik Cc: Alan Cox, Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List 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-backout 2005-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-backout 2005-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_DELAY 20 + +/* + * 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 10000 +#define I8042_CTL_TIMEOUT 25000 /* * When the device isn't opened and it's interrupts aren't used, we poll it at ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-02-13 0:16 ` Bill Rugolsky Jr. @ 2005-02-13 8:22 ` Vojtech Pavlik 2005-02-13 16:17 ` Bill Rugolsky Jr. 0 siblings, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-02-13 8:22 UTC (permalink / raw) To: Bill Rugolsky Jr., Alan Cox, Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-02-13 8:22 ` Vojtech Pavlik @ 2005-02-13 16:17 ` Bill Rugolsky Jr. 0 siblings, 0 replies; 47+ messages in thread From: Bill Rugolsky Jr. @ 2005-02-13 16:17 UTC (permalink / raw) To: Vojtech Pavlik Cc: Alan Cox, Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 15:14 ` Alan Cox 2005-01-27 16:24 ` Vojtech Pavlik 2005-01-27 16:34 ` Bill Rugolsky Jr. @ 2005-01-27 17:45 ` Andries Brouwer 2005-01-28 14:55 ` Vojtech Pavlik 2 siblings, 1 reply; 47+ messages in thread From: Andries Brouwer @ 2005-01-27 17:45 UTC (permalink / raw) To: Alan Cox Cc: Lee Revell, Andries Brouwer, dtor_core, linux-input, Linux Kernel Mailing List, Vojtech Pavlik 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 17:45 ` Andries Brouwer @ 2005-01-28 14:55 ` Vojtech Pavlik 0 siblings, 0 replies; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-28 14:55 UTC (permalink / raw) To: Andries Brouwer Cc: Alan Cox, Lee Revell, dtor_core, linux-input, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 7:41 i8042 access timings Dmitry Torokhov 2005-01-25 10:51 ` Andries Brouwer @ 2005-01-25 12:44 ` Alan Cox 2005-01-25 12:44 ` Alan Cox 2005-01-26 15:43 ` Vojtech Pavlik 3 siblings, 0 replies; 47+ messages in thread From: Alan Cox @ 2005-01-25 12:44 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, Linux Kernel Mailing List, Vojtech Pavlik 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 7:41 i8042 access timings Dmitry Torokhov 2005-01-25 10:51 ` Andries Brouwer 2005-01-25 12:44 ` Alan Cox @ 2005-01-25 12:44 ` Alan Cox 2005-01-26 15:43 ` Vojtech Pavlik 3 siblings, 0 replies; 47+ messages in thread From: Alan Cox @ 2005-01-25 12:44 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, Linux Kernel Mailing List, Vojtech Pavlik 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-25 7:41 i8042 access timings Dmitry Torokhov ` (2 preceding siblings ...) 2005-01-25 12:44 ` Alan Cox @ 2005-01-26 15:43 ` Vojtech Pavlik 2005-01-26 16:36 ` Dmitry Torokhov 3 siblings, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-26 15:43 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input, Alan Cox, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-26 15:43 ` Vojtech Pavlik @ 2005-01-26 16:36 ` Dmitry Torokhov 2005-01-26 17:05 ` linux-os 2005-01-27 10:19 ` Vojtech Pavlik 0 siblings, 2 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-26 16:36 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-input, Alan Cox, linux-kernel On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <vojtech@suse.cz> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-26 16:36 ` Dmitry Torokhov @ 2005-01-26 17:05 ` linux-os 2005-01-26 18:30 ` Dmitry Torokhov 2005-01-27 10:19 ` Vojtech Pavlik 1 sibling, 1 reply; 47+ messages in thread From: linux-os @ 2005-01-26 17:05 UTC (permalink / raw) To: dtor_core; +Cc: Vojtech Pavlik, linux-input, Alan Cox, linux-kernel On Wed, 26 Jan 2005, Dmitry Torokhov wrote: > On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <vojtech@suse.cz> 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-26 17:05 ` linux-os @ 2005-01-26 18:30 ` Dmitry Torokhov 0 siblings, 0 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-26 18:30 UTC (permalink / raw) To: linux-os; +Cc: Vojtech Pavlik, linux-input, Alan Cox, linux-kernel On Wed, 26 Jan 2005 12:05:47 -0500 (EST), linux-os <linux-os@analogic.com> wrote: > On Wed, 26 Jan 2005, Dmitry Torokhov wrote: > > > On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <vojtech@suse.cz> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-26 16:36 ` Dmitry Torokhov 2005-01-26 17:05 ` linux-os @ 2005-01-27 10:19 ` Vojtech Pavlik 1 sibling, 0 replies; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-27 10:19 UTC (permalink / raw) To: dtor_core; +Cc: linux-input, Alan Cox, linux-kernel On Wed, Jan 26, 2005 at 11:36:41AM -0500, Dmitry Torokhov wrote: > On Wed, 26 Jan 2005 16:43:07 +0100, Vojtech Pavlik <vojtech@suse.cz> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <200501260040.46288.sebekpi@poczta.onet.pl>]
* Re: i8042 access timings [not found] <200501260040.46288.sebekpi@poczta.onet.pl> @ 2005-01-27 6:23 ` Jaco Kroon 2005-01-27 10:25 ` Vojtech Pavlik ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Jaco Kroon @ 2005-01-27 6:23 UTC (permalink / raw) To: sebekpi; +Cc: Vojtech Pavlik, Andrew Morton, Linus Torvalds, linux-kernel 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.c 2004-12-24 23:33:52.000000000 +0200 +++ linux-2.6.10-patched/drivers/input/serio/i8042.c 2005-01-24 21:44:33.790291480 +0200 @@ -595,7 +595,7 @@ */ if (i8042_command(¶m, 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(¶m, 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(¶m, 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 my touchpad is detected as ALPS. >> >>I think this is some special situation, that need extra detection >>possibility? Am I right? Not sure yet. It could be that the patch I've got covers all cases but highly unlikely. >>I can imagine a new chipset (I don't have the ATI IXP handy) that >>wouldn't care to implement the loopback and test commands on the AUX >>port. But what really surprises me here that disabling ACPI actually helps. But I do. So if you have any ideas I could try, or documentation to point me at, now is the time. >>Since Sebastian writes that the AUX check ends with a timeout, we also >>know that it never returns any datam so adding the printk() is probably >>pointless. From the above - isn't it simply that the timeout is too short? Somehow enabling ACPI makes the timer go weird? Will disabling HPET make a difference? >>Sebastian, here are a few shots in the dark: Does disabling Legacy USB >>emulation in the BIOS help? It might. Could you enable i8042.c DEBUG and >>compare the traces in the working and non-working cases side by side >>whether there is anything different prior to this failure point? It doesn't look like there is any "legacy USB" options in the BIOS. I might just be missing it though :). Right, long mail, sorry about that. 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/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 6:23 ` Jaco Kroon @ 2005-01-27 10:25 ` Vojtech Pavlik 2005-01-27 11:12 ` Sebastian Piechocki 2005-01-27 18:09 ` Linus Torvalds 2005-01-27 20:23 ` Andries Brouwer 2 siblings, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-27 10:25 UTC (permalink / raw) To: Jaco Kroon; +Cc: sebekpi, Andrew Morton, Linus Torvalds, linux-kernel 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.c 2004-12-24 > 23:33:52.000000000 +0200 > +++ linux-2.6.10-patched/drivers/input/serio/i8042.c 2005-01-24 > 21:44:33.790291480 +0200 > @@ -595,7 +595,7 @@ > */ > > if (i8042_command(¶m, 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(¶m, 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(¶m, 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 my touchpad is detected as ALPS. > >> > >>I think this is some special situation, that need extra detection > >>possibility? Am I right? > Not sure yet. It could be that the patch I've got covers all cases but > highly unlikely. > > >>I can imagine a new chipset (I don't have the ATI IXP handy) that > >>wouldn't care to implement the loopback and test commands on the AUX > >>port. But what really surprises me here that disabling ACPI actually > >>helps. > But I do. So if you have any ideas I could try, or documentation to > point me at, now is the time. > > >>Since Sebastian writes that the AUX check ends with a timeout, we also > >>know that it never returns any datam so adding the printk() is probably > >>pointless. > From the above - isn't it simply that the timeout is too short? > Somehow enabling ACPI makes the timer go weird? Will disabling HPET > make a difference? > > >>Sebastian, here are a few shots in the dark: Does disabling Legacy USB > >>emulation in the BIOS help? It might. Could you enable i8042.c DEBUG and > >>compare the traces in the working and non-working cases side by side > >>whether there is anything different prior to this failure point? > > It doesn't look like there is any "legacy USB" options in the BIOS. I > might just be missing it though :). > > Right, long mail, sorry about that. > > 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/ > -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 10:25 ` Vojtech Pavlik @ 2005-01-27 11:12 ` Sebastian Piechocki 2005-01-27 11:31 ` Vojtech Pavlik 0 siblings, 1 reply; 47+ messages in thread From: Sebastian Piechocki @ 2005-01-27 11:12 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Jaco Kroon, Andrew Morton, Linus Torvalds, linux-kernel 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 sebekpi@poczta.onet.pl ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 11:12 ` Sebastian Piechocki @ 2005-01-27 11:31 ` Vojtech Pavlik 2005-01-27 17:33 ` Jaco Kroon 0 siblings, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-27 11:31 UTC (permalink / raw) To: Sebastian Piechocki Cc: Jaco Kroon, Andrew Morton, Linus Torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 11:31 ` Vojtech Pavlik @ 2005-01-27 17:33 ` Jaco Kroon 0 siblings, 0 replies; 47+ messages in thread From: Jaco Kroon @ 2005-01-27 17:33 UTC (permalink / raw) To: Vojtech Pavlik Cc: Sebastian Piechocki, Andrew Morton, Linus Torvalds, linux-kernel 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/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 6:23 ` Jaco Kroon 2005-01-27 10:25 ` Vojtech Pavlik @ 2005-01-27 18:09 ` Linus Torvalds 2005-01-27 20:29 ` Andries Brouwer 2005-01-27 20:51 ` Jaco Kroon 2005-01-27 20:23 ` Andries Brouwer 2 siblings, 2 replies; 47+ messages in thread From: Linus Torvalds @ 2005-01-27 18:09 UTC (permalink / raw) To: Jaco Kroon; +Cc: sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 18:09 ` Linus Torvalds @ 2005-01-27 20:29 ` Andries Brouwer 2005-01-27 20:41 ` Dmitry Torokhov 2005-01-28 13:17 ` Vojtech Pavlik 2005-01-27 20:51 ` Jaco Kroon 1 sibling, 2 replies; 47+ messages in thread From: Andries Brouwer @ 2005-01-27 20:29 UTC (permalink / raw) To: Linus Torvalds Cc: Jaco Kroon, sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 20:29 ` Andries Brouwer @ 2005-01-27 20:41 ` Dmitry Torokhov 2005-01-27 23:11 ` Andries Brouwer 2005-01-28 13:17 ` Vojtech Pavlik 1 sibling, 1 reply; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-27 20:41 UTC (permalink / raw) To: Andries Brouwer Cc: Linus Torvalds, Jaco Kroon, sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel On Thu, 27 Jan 2005 21:29:47 +0100, Andries Brouwer <aebr@win.tue.nl> 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 20:41 ` Dmitry Torokhov @ 2005-01-27 23:11 ` Andries Brouwer 0 siblings, 0 replies; 47+ messages in thread From: Andries Brouwer @ 2005-01-27 23:11 UTC (permalink / raw) To: dtor_core Cc: Andries Brouwer, Linus Torvalds, Jaco Kroon, sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel > > 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 20:29 ` Andries Brouwer 2005-01-27 20:41 ` Dmitry Torokhov @ 2005-01-28 13:17 ` Vojtech Pavlik 2005-01-28 14:20 ` Jaco Kroon 1 sibling, 1 reply; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-28 13:17 UTC (permalink / raw) To: Andries Brouwer Cc: Linus Torvalds, Jaco Kroon, sebekpi, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-28 13:17 ` Vojtech Pavlik @ 2005-01-28 14:20 ` Jaco Kroon 2005-01-28 18:39 ` Vojtech Pavlik 0 siblings, 1 reply; 47+ messages in thread From: Jaco Kroon @ 2005-01-28 14:20 UTC (permalink / raw) To: Vojtech Pavlik Cc: Andries Brouwer, Linus Torvalds, sebekpi, Andrew Morton, linux-kernel 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/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-28 14:20 ` Jaco Kroon @ 2005-01-28 18:39 ` Vojtech Pavlik 2005-01-29 19:59 ` Jaco Kroon 2005-01-29 20:02 ` Randy.Dunlap 0 siblings, 2 replies; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-28 18:39 UTC (permalink / raw) To: Jaco Kroon Cc: Andries Brouwer, Linus Torvalds, sebekpi, Andrew Morton, linux-kernel 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 Labs, SuSE CR ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-28 18:39 ` Vojtech Pavlik @ 2005-01-29 19:59 ` Jaco Kroon 2005-01-29 23:21 ` Dmitry Torokhov 2005-01-29 20:02 ` Randy.Dunlap 1 sibling, 1 reply; 47+ messages in thread From: Jaco Kroon @ 2005-01-29 19:59 UTC (permalink / raw) To: Vojtech Pavlik Cc: Andries Brouwer, Linus Torvalds, sebekpi, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2491 bytes --] 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/ [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 3166 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-29 19:59 ` Jaco Kroon @ 2005-01-29 23:21 ` Dmitry Torokhov 0 siblings, 0 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-29 23:21 UTC (permalink / raw) To: Jaco Kroon Cc: Vojtech Pavlik, Andries Brouwer, Linus Torvalds, sebekpi, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-28 18:39 ` Vojtech Pavlik 2005-01-29 19:59 ` Jaco Kroon @ 2005-01-29 20:02 ` Randy.Dunlap 1 sibling, 0 replies; 47+ messages in thread From: Randy.Dunlap @ 2005-01-29 20:02 UTC (permalink / raw) To: Vojtech Pavlik Cc: Jaco Kroon, Andries Brouwer, Linus Torvalds, sebekpi, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 18:09 ` Linus Torvalds 2005-01-27 20:29 ` Andries Brouwer @ 2005-01-27 20:51 ` Jaco Kroon 2005-01-27 21:17 ` Linus Torvalds 1 sibling, 1 reply; 47+ messages in thread From: Jaco Kroon @ 2005-01-27 20:51 UTC (permalink / raw) To: Linus Torvalds; +Cc: sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 20:51 ` Jaco Kroon @ 2005-01-27 21:17 ` Linus Torvalds 2005-01-27 22:12 ` Jaco Kroon 0 siblings, 1 reply; 47+ messages in thread From: Linus Torvalds @ 2005-01-27 21:17 UTC (permalink / raw) To: Jaco Kroon; +Cc: sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 21:17 ` Linus Torvalds @ 2005-01-27 22:12 ` Jaco Kroon 2005-01-27 22:36 ` Linus Torvalds 2005-01-28 11:04 ` Vojtech Pavlik 0 siblings, 2 replies; 47+ messages in thread From: Jaco Kroon @ 2005-01-27 22:12 UTC (permalink / raw) To: Linus Torvalds; +Cc: sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 i8042_acpi_aux_driver. I don't think this has anything to do with our problem though. Would it be helpfull to dump the entire i8042_read_status() value at various points? 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/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 22:12 ` Jaco Kroon @ 2005-01-27 22:36 ` Linus Torvalds 2005-01-27 23:40 ` Dmitry Torokhov ` (2 more replies) 2005-01-28 11:04 ` Vojtech Pavlik 1 sibling, 3 replies; 47+ messages in thread From: Linus Torvalds @ 2005-01-27 22:36 UTC (permalink / raw) To: Jaco Kroon; +Cc: sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 22:36 ` Linus Torvalds @ 2005-01-27 23:40 ` Dmitry Torokhov 2005-01-28 5:52 ` Jaco Kroon 2005-02-04 19:54 ` Bukie Mabayoje 2 siblings, 0 replies; 47+ messages in thread From: Dmitry Torokhov @ 2005-01-27 23:40 UTC (permalink / raw) To: Linus Torvalds Cc: Jaco Kroon, sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 22:36 ` Linus Torvalds 2005-01-27 23:40 ` Dmitry Torokhov @ 2005-01-28 5:52 ` Jaco Kroon 2005-02-04 19:54 ` Bukie Mabayoje 2 siblings, 0 replies; 47+ messages in thread From: Jaco Kroon @ 2005-01-28 5:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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 is it commented out in the first place? 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/ -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 22:36 ` Linus Torvalds 2005-01-27 23:40 ` Dmitry Torokhov 2005-01-28 5:52 ` Jaco Kroon @ 2005-02-04 19:54 ` Bukie Mabayoje 2 siblings, 0 replies; 47+ messages in thread From: Bukie Mabayoje @ 2005-02-04 19:54 UTC (permalink / raw) To: Linus Torvalds Cc: Jaco Kroon, sebekpi, Vojtech Pavlik, Andrew Morton, linux-kernel 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/A5 42/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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 22:12 ` Jaco Kroon 2005-01-27 22:36 ` Linus Torvalds @ 2005-01-28 11:04 ` Vojtech Pavlik 1 sibling, 0 replies; 47+ messages in thread From: Vojtech Pavlik @ 2005-01-28 11:04 UTC (permalink / raw) To: Jaco Kroon; +Cc: Linus Torvalds, sebekpi, Andrew Morton, linux-kernel 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: i8042 access timings 2005-01-27 6:23 ` Jaco Kroon 2005-01-27 10:25 ` Vojtech Pavlik 2005-01-27 18:09 ` Linus Torvalds @ 2005-01-27 20:23 ` Andries Brouwer 2 siblings, 0 replies; 47+ messages in thread From: Andries Brouwer @ 2005-01-27 20:23 UTC (permalink / raw) To: Jaco Kroon Cc: sebekpi, Vojtech Pavlik, Andrew Morton, Linus Torvalds, linux-kernel 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(¶m, I8042_CMD_AUX_LOOP) || param != 0xa5) { if (i8042_command(¶m, 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=10000 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2005-02-13 16:17 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-25 7:41 i8042 access timings Dmitry Torokhov 2005-01-25 10:51 ` Andries Brouwer 2005-01-25 19:17 ` Dmitry Torokhov 2005-01-25 19:25 ` Vojtech Pavlik 2005-01-25 19:41 ` Dmitry Torokhov 2005-01-25 19:46 ` Andries Brouwer 2005-01-25 20:37 ` Lee Revell 2005-01-27 15:14 ` Alan Cox 2005-01-27 16:24 ` Vojtech Pavlik 2005-01-27 16:34 ` Bill Rugolsky Jr. 2005-01-27 16:37 ` Vojtech Pavlik 2005-02-13 0:16 ` Bill Rugolsky Jr. 2005-02-13 8:22 ` Vojtech Pavlik 2005-02-13 16:17 ` Bill Rugolsky Jr. 2005-01-27 17:45 ` Andries Brouwer 2005-01-28 14:55 ` Vojtech Pavlik 2005-01-25 12:44 ` Alan Cox 2005-01-25 12:44 ` Alan Cox 2005-01-26 15:43 ` Vojtech Pavlik 2005-01-26 16:36 ` Dmitry Torokhov 2005-01-26 17:05 ` linux-os 2005-01-26 18:30 ` Dmitry Torokhov 2005-01-27 10:19 ` Vojtech Pavlik [not found] <200501260040.46288.sebekpi@poczta.onet.pl> 2005-01-27 6:23 ` Jaco Kroon 2005-01-27 10:25 ` Vojtech Pavlik 2005-01-27 11:12 ` Sebastian Piechocki 2005-01-27 11:31 ` Vojtech Pavlik 2005-01-27 17:33 ` Jaco Kroon 2005-01-27 18:09 ` Linus Torvalds 2005-01-27 20:29 ` Andries Brouwer 2005-01-27 20:41 ` Dmitry Torokhov 2005-01-27 23:11 ` Andries Brouwer 2005-01-28 13:17 ` Vojtech Pavlik 2005-01-28 14:20 ` Jaco Kroon 2005-01-28 18:39 ` Vojtech Pavlik 2005-01-29 19:59 ` Jaco Kroon 2005-01-29 23:21 ` Dmitry Torokhov 2005-01-29 20:02 ` Randy.Dunlap 2005-01-27 20:51 ` Jaco Kroon 2005-01-27 21:17 ` Linus Torvalds 2005-01-27 22:12 ` Jaco Kroon 2005-01-27 22:36 ` Linus Torvalds 2005-01-27 23:40 ` Dmitry Torokhov 2005-01-28 5:52 ` Jaco Kroon 2005-02-04 19:54 ` Bukie Mabayoje 2005-01-28 11:04 ` Vojtech Pavlik 2005-01-27 20:23 ` Andries Brouwer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).