Re: i8042 access timings
From: Jaco Kroon
Date: Thu Jan 27 2005 - 01:24:29 EST
Sebastian Piechocki wrote:
As I said I'm sending you mails from kernel masters:)
Thanks.
If you haven't such a problem, please send them your dmesg with i8042.debug
and acpi=off.
I made an alternative plan. I applied a custom patch that gives me far less
output and prevents scrolling and gets what I hope is what is required.
With acpi=on I get the following output:
i8042_init()
ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [MSE0] at irq 12
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
i8042_allocate_kbd_port()
i8042_port_register()
With acpi=off I get this:
i8042_init()
i8042: ACPI detection disabled
i8042_controller_init()
i8042_flush()
i8042_check_aux()
i8042_flush()
i8042_check_aux: passed
i8042_check_mux()
i8042_enable_mux_mode()
i8042_flush()
i8042_open(): mux_version==19
i8042.c: Detected active multiplexing controller, rev 1.9.
i8042_enable_mux_ports()
i8042_allocate_mux_port()
i8042_port_register()
Ok, some explanation is probably in order, I just put a printk(KERN_INFO
"function_name()\n" at the top of practically every function and then I
filled up i8042_check_aux() because that is where the error is detected.
In the first case (the interesting one) these lines pop up:
i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
Which indicates (as far as my understanding goes) that the command times
out, as such the param value stays the same (ready for re-use in the
second command). The second commands succeeds but does not return one
of the expected (0x00, 0xff, 0xfa) values, instead it returns the value
as expected by the first command (0xa5). The last value on both lines
is the return value. From the second snippet:
i8042_flush()
i8042_check_aux: passed
Indicates that the outer test passed first time round, ie, exit code 0
and return param of 0xa5. What I have done to get mine working with
acpi=on is applied the following patch (apologies if mozilla breaks this):
======================
--- linux-2.6.10/drivers/input/serio/i8042.c 2004-12-24
23:33:52.000000000 +0200
+++ linux-2.6.10-patched/drivers/input/serio/i8042.c 2005-01-24
21:44:33.790291480 +0200
@@ -595,7 +595,7 @@
*/
if (i8042_command(¶m, I8042_CMD_AUX_TEST)
- || (param && param != 0xfa && param != 0xff))
+ || (param && param != 0xfa && param != 0xa5 &&
param != 0xff))
return -1;
}
======================
Which I don't think is the proper solution, more likely the problem lies
in the i8042_command function. Unfortunately I don't have time right
now to add more debug code (to possibly only issue those dbg statements
upto a certain point in order to reduce the amount of output).
> As I remember with acpi=off i8042 detects multplexer MUX with four ports!
> I tried to make a hack for mux detection, but mux was detected and
touchpad
> was not:(
Yes. This seems correct, however the touchoad worked "perfectly" for me
when I booted with acpi=off.
Dmitry,
did you see this one?
Since everything but the I8042_CMD_AUX_LOOP/AUX_TEST thing apparently
works, this is not the case of ACPI setting the wrong ports or something
fundamental like that. It looks like some state of the keyboard controller
just disables the loopback command and/or the AUX_TEST command.
Might the "no KBD" case be something similar?
I'm probably a bit off here, but what "no KBD" case? On these
particular notebooks we both had to compile in specifically USB1.1
support in order to have keyboard support, but since I want USB support
in any case this is not a problem for me (although I would love to know
what caused this).
Sebastian, can you make your hack also print out what the errors were (in
particular, was it "i8042_command()" that failed, or was it that the
return value was different from the expected ones, and if so - what?)
I hope my debug did exactly that.
From the orriginal mail sent to me by Sebastian:
In method:
i8042_check_aux
There is:
param = 0x5a;
if (i8042_command(¶m, I8042_CMD_AUX_LOOP) || param != 0xa5)
{
/*
* External connection test - filters out AT-soldered PS/2 i8042's
* 0x00 - no error, 0x01-0x03 - clock/data stuck, 0xff - general error
* 0xfa - no error on some notebooks which ignore the spec
* Because it's common for chipsets to return error on perfectly
functioning
* AUX ports, we test for this only when the LOOP command failed.
*/
if (i8042_command(¶m, I8042_CMD_AUX_TEST)
|| (param && param != 0xfa && param != 0xff))
return -1;
}
I have commented the line with return -1.
I know that this solution is very stupid, but works fine.
I use 2.6.11-rc1-mm1 kernel, and my touchpad is detected as ALPS.
I think this is some special situation, that need extra detection
possibility? Am I right?
Not sure yet. It could be that the patch I've got covers all cases but
highly unlikely.
I can imagine a new chipset (I don't have the ATI IXP handy) that
wouldn't care to implement the loopback and test commands on the AUX
port. But what really surprises me here that disabling ACPI actually helps.
But I do. So if you have any ideas I could try, or documentation to
point me at, now is the time.
Since Sebastian writes that the AUX check ends with a timeout, we also
know that it never returns any datam so adding the printk() is probably
pointless.
From the above - isn't it simply that the timeout is too short?
Somehow enabling ACPI makes the timer go weird? Will disabling HPET
make a difference?
Sebastian, here are a few shots in the dark: Does disabling Legacy USB
emulation in the BIOS help? It might. Could you enable i8042.c DEBUG and
compare the traces in the working and non-working cases side by side
whether there is anything different prior to this failure point?
It doesn't look like there is any "legacy USB" options in the BIOS. I
might just be missing it though :).
Right, long mail, sorry about that.
Jaco
--
There are only 10 kinds of people in this world,
those that understand binary and those that don't.
http://www.kroon.co.za/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/