lkml.org 
[lkml]   [2005]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: i8042 access timings


On Fri, 28 Jan 2005, Jaco Kroon wrote:
> >>
> >>ok, how would I try this? Where can I find an example to code it from?
> >> Sorry, I should probably be grepping ...
> > If the udelay() didn't work, then this one isn't worth worryign about
> > either. Back to the drawing board.
> Yea. But for interrests sake, what do you mean with a serializing IO
> instruction?

If you use "outb_p()" instead of an "outb()", the regular IO instruction
will be followed by another out to another port on the motherboard: that
will not only cause a delay, it should also force at least the host bridge
to have no outstanding posted writes (the host bridge shouldn't post IO
port writes anyway, but hey, it won't hurt to try to make even more sure
of that).

> I also tried increasing the total timeout value to about 5 seconds
> (versus the default half second), still no success, so the device is
> simply not sending back the requested values.

If it was the other way around (that it works with ACPI _on_), I'd assume
that ACPI just disables some broken BIOS SMM emulation code. But I just
don't see ACPI _enabling_ SMM emulation. That would be just too strange,
and against the whole point of the legacy keyboard emulation stuff - you
want to do legacy keyboard emulation if the OS is old, not if it's new.

It may be that ACPI ends up enabling some silly power control SMM sequence
that wakes up on keyboard accesses, and screws up the emulation. That
sounds pretty strange too, I have to say - even if SMM/ACPI would like to
trap keyboard command sequences, I'd have expected it to just pass them
through after looking at them.

One option may be that SMM/ACPI traps the _received_ characters, and
incorrectly eats the reply, because it thinks it's some special key
sequence (and should cause SMM/ACPI to make the screen brighter or
something silly like that).

Does anybody know/remember what the keycode 0xA5 means?

> I still stand with the theory that it is sending back the value we want
> for the first request on the second one (managed to get this one by
> explicitly turning i8042_debug on and off in the code):
>
> i8042_init()
> ACPI: PS/2 Keyboard Controller [KBC0] at I/O 0x60, 0x64, irq 1
> ACPI: PS/2 Mouse Controller [MSE0] at irq 12
> i8042_controller_init()
> i8042_flush()
> drivers/input/serio/i8042.c: 20 -> i8042 (command) [4]
> drivers/input/serio/i8042.c: 47 <- i8042 (return) [4]
> drivers/input/serio/i8042.c: 60 -> i8042 (command) [5]
> drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [5]
> i8042_check_aux()
> drivers/input/serio/i8042.c: Interrupt 12, without any data [9]
> i8042_flush()
> drivers/input/serio/i8042.c: d3 -> i8042 (command) [13]
> drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [13]
> drivers/input/serio/i8042.c: -- i8042 (timeout) [875]
> i8042_check_aux: param_in=0x5a, command=AUX_LOOP, param_out=5a <= -1
> drivers/input/serio/i8042.c: a9 -> i8042 (command) [879]
> drivers/input/serio/i8042.c: a5 <- i8042 (return) [879]
> i8042_check_aux: param_in=??, command=AUX_TEST, param_out=a5 <= 0
>
> I've rebooted a couple of times and that interrupt is in exactly the
> same place every time. And int 12 is indeed the AUX device, could this
> be a clue?

Does it change if you change the initial value of "param" (0x5a) to
something else?

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.077 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site