Re: i8042 access timings

Re: i8042 access timings

[Jaco Kroon]

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(&param, I8042_CMD_AUX_TEST)
-                       || (param && param != 0xfa && param != 0xff))
+                       || (param && param != 0xfa  && param != 0xa5 && 
param != 0xff))
                                 return -1;
         }

======================

Which I don't think is the proper solution, more likely the problem lies 
in the i8042_command function.  Unfortunately I don't have time right 
now to add more debug code (to possibly only issue those dbg statements 
upto a certain point in order to reduce the amount of output).

 > As I remember with acpi=off i8042 detects multplexer MUX with four ports!
 > I tried to make a hack for mux detection, but mux was detected and 
touchpad
 > was not:(
Yes.  This seems correct, however the touchoad worked "perfectly" for me 
when I booted with acpi=off.

> Dmitry,
>  did you see this one?
> 
> Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
> works, this is not the case of ACPI setting the wrong ports or something 
> fundamental like that. It looks like some state of the keyboard controller 
> just disables the loopback command and/or the AUX_TEST command.
> 
> Might the "no KBD" case be something similar?
I'm probably a bit off here, but what "no KBD" case?  On these 
particular notebooks we both had to compile in specifically USB1.1 
support in order to have keyboard support, but since I want USB support 
in any case this is not a problem for me (although I would love to know 
what caused this).

> Sebastian, can you make your hack also print out what the errors were (in 
> particular, was it "i8042_command()" that failed, or was it that the 
> return value was different from the expected ones, and if so - what?)
I hope my debug did exactly that.

 From the orriginal mail sent to me by Sebastian:
>>In method:
>>  i8042_check_aux
>>
>>There is:
>>param = 0x5a;
>>        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != 0xa5) 
>>{
>>
>>/*
>> * External connection test - filters out AT-soldered PS/2 i8042's
>> * 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
>> * 0xfa - no error on some notebooks which ignore the spec
>> * Because it's common for chipsets to return error on perfectly 
>>functioning
>> * AUX ports, we test for this only when the LOOP command failed.
>> */
>>
>>                if (i8042_command(&param, I8042_CMD_AUX_TEST)
>>                        || (param && param != 0xfa && param != 0xff))
>>                                return -1;
>>        }
>>
>>I have commented the line with return -1.
>>I know that this solution is very stupid, but works fine.
>>I use 2.6.11-rc1-mm1 kernel, and 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/

Re: i8042 access timings

[Vojtech Pavlik]

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(&param, I8042_CMD_AUX_TEST)
> -                       || (param && param != 0xfa && param != 0xff))
> +                       || (param && param != 0xfa  && param != 0xa5 && 
> param != 0xff))
>                                 return -1;
>         }
> 
> ======================
> 
> Which I don't think is the proper solution, more likely the problem lies 
> in the i8042_command function.  Unfortunately I don't have time right 
> now to add more debug code (to possibly only issue those dbg statements 
> upto a certain point in order to reduce the amount of output).
> 
> > As I remember with acpi=off i8042 detects multplexer MUX with four ports!
> > I tried to make a hack for mux detection, but mux was detected and 
> touchpad
> > was not:(
> Yes.  This seems correct, however the touchoad worked "perfectly" for me 
> when I booted with acpi=off.
> 
> >Dmitry,
> > did you see this one?
> >
> >Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
> >works, this is not the case of ACPI setting the wrong ports or something 
> >fundamental like that. It looks like some state of the keyboard controller 
> >just disables the loopback command and/or the AUX_TEST command.
> >
> >Might the "no KBD" case be something similar?
> I'm probably a bit off here, but what "no KBD" case?  On these 
> particular notebooks we both had to compile in specifically USB1.1 
> support in order to have keyboard support, but since I want USB support 
> in any case this is not a problem for me (although I would love to know 
> what caused this).
> 
> >Sebastian, can you make your hack also print out what the errors were (in 
> >particular, was it "i8042_command()" that failed, or was it that the 
> >return value was different from the expected ones, and if so - what?)
> I hope my debug did exactly that.
> 
> From the orriginal mail sent to me by Sebastian:
> >>In method:
> >> i8042_check_aux
> >>
> >>There is:
> >>param = 0x5a;
> >>       if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != 0xa5) 
> >>{
> >>
> >>/*
> >>* External connection test - filters out AT-soldered PS/2 i8042's
> >>* 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
> >>* 0xfa - no error on some notebooks which ignore the spec
> >>* Because it's common for chipsets to return error on perfectly 
> >>functioning
> >>* AUX ports, we test for this only when the LOOP command failed.
> >>*/
> >>
> >>               if (i8042_command(&param, I8042_CMD_AUX_TEST)
> >>                       || (param && param != 0xfa && param != 0xff))
> >>                               return -1;
> >>       }
> >>
> >>I have commented the line with return -1.
> >>I know that this solution is very stupid, but works fine.
> >>I use 2.6.11-rc1-mm1 kernel, and 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

Re: i8042 access timings

[Sebastian Piechocki]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Jaco Kroon]

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/

Re: i8042 access timings

[Linus Torvalds]

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

Re: i8042 access timings

[Andries Brouwer]

On Thu, Jan 27, 2005 at 08:23:07AM +0200, Jaco Kroon wrote:

> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0

The code is

        param = 0x5a;
        if (i8042_command(&param, I8042_CMD_AUX_LOOP) || param != 0xa5) {
                if (i8042_command(&param, I8042_CMD_AUX_TEST)
                        || (param && param != 0xfa && param != 0xff))
                                return -1;
        }

where
#define I8042_CMD_AUX_LOOP 0x11d3: write d3, write 5a, read ->param
#define I8042_CMD_AUX_TEST 0x01a9: write a9, read ->param

In my docs (http://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html#ss10.3)
d3 is classified under "Obscure, probably obsolete, commands".
The reason is that there is hardware that does not implement d3.
Originally it was special to MCA. Later it was also used as part of
the Synaptics multiplexing handshake.

Now you read one byte after the command a9 and get a5 - clearly the 5a
that was written and complemented. So it looks like the d3 really worked.

The first i8042_command() returned -1, but it really wrote the 5a,
so it did i8042_write_command(d3) and i8042_write_data(5a) and then
the i8042_wait_read() returned -1, a timeout.

Since the byte was there to read, the flag was lost that indicated
that data was available. Hmm. Sequence of actions:

	inb(64);	// until bit 1 clear
	outb(d3, 64);
	inb(64);	// until bit 1 clear
	outb(5a, 60);
	inb(64);	// until bit 0 set - timeout

	inb(64);	// until bit 1 clear
	outb(a9, 64);
	inb(64);	// until bit 0 set
	inb(64);	// test for AUX
	inb(60);

I am afraid I don't understand what happens.
One can imagine that the second inb(64) comes too quickly
so that we write the 5a too quickly. But all happens as it
should: the d3 is executed, the 5a is moved from input buffer
to output buffer, the AUXB bit is set, only the ready flag never comes,
not within I8042_CTL_TIMEOUT=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

Re: i8042 access timings

[Andries Brouwer]

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

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[Jaco Kroon]

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/

Re: i8042 access timings

[Linus Torvalds]

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

Re: i8042 access timings

[Jaco Kroon]

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/

Re: i8042 access timings

[Linus Torvalds]

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

Re: i8042 access timings

[Andries Brouwer]

> > 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.

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[Jaco Kroon]

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/

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Jaco Kroon]

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/

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Jaco Kroon]

[-- 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 --]

Re: i8042 access timings

[Randy.Dunlap]

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

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[Bukie Mabayoje]

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/

Re: i8042 access timings

[Bill Rugolsky Jr.]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Bill Rugolsky Jr.]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Andries Brouwer]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Bill Rugolsky Jr.]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Alan Cox]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[linux-os]

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.

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[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.
> 
> 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

Re: i8042 access timings

[Lee Revell]

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

Re: i8042 access timings

[Andries Brouwer]

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

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[Vojtech Pavlik]

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

Re: i8042 access timings

[Dmitry Torokhov]

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

Re: i8042 access timings

[Alan Cox]

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

Re: i8042 access timings

[Alan Cox]

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

Re: i8042 access timings

[Andries Brouwer]

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"?

i8042 access timings

[Dmitry Torokhov]

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