On Thu, 27 Jan 2005, Jaco Kroon wrote:
>
> Hmm, just an idea, shouldn't the i8042_write_command be waiting until
> the device has asserted the pin to indicate that the buffer is busy?
No. Because then you might end up waiting forever for the _opposite_
reason, namely that the hardware was so fast that you never saw it 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?
>
> No. No difference, still the same result.
Oh, well. It was such a good theory, especially as it works fine with ACPI
off (if I understood your report correctly), so some other state is what
seems to bring it on.
> > (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.)
>
> 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.
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/
