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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
