Re: i8042 access timings

[Bukie Mabayoje <bukiemab@gte.net>]

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/