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