[lkml]   [2005]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: i8042 access timings
On Tue, 25 Jan 2005 11:51:39 +0100, Andries Brouwer <> wrote:
> On Tue, Jan 25, 2005 at 02:41:14AM -0500, Dmitry Torokhov wrote:
> > Recently there was a patch from Alan regarding access timing violations
> > in i8042. It made me curious as we only wait between accesses to status
> > register but not data register. I peeked into FreeBSD code and they use
> > delays to access both registers and I wonder if that's the piece that
> > makes i8042 mysteriously fail on some boards.
> You are following this much more closely than I do, but isn't the
> usual complaint "2.4 works, 2.6 fails"?

Quite often it is but too much has changed in input layer to pinpoing
exact cause of the failure and I am open to any suggestions. Common
problems I see:

1. ACPI sometimes interferes with i8042, especially battery status
polling. I am concerned about embedded controller access as well, it
looks like it takes sweet time to read/write data to it and ec.c does
it with interrupts disabled. I have a patch that enables interrupts
but nobody seems to be interested in testing. ACPI interference ranges
from losing bytes and bytes arriving with > 0.5 sec delay to "Can't
read/write CTR" type of errors. And on the other hand I see some
boxces need ACPI or they will not talk to i8042 (although I suspect
cold boot will also fix that).
How many 2.4 boxes have ACPI on? I honestly do not know.

2. USB legacy emulation - we used to have PS/2 initialization in
GPM/Xfree which means that USB modules (if any) are already loaded and
requested handoff so results were very consistent. Now it all depends
on who's first. There were couple of PCI quirk patches doing early USB
handoff but they have not been applied out of fear breaking some
boxes. I wonder if there are concrete examples of such patches
breaking boxes, how many and whether DMI decode/workaround will be
beneficial for these.

Also, In 2.4 if BIOS detected PS/2 mouse we trusted it and did not do
any additional checks, now that i8042 is not x86 specific we do
everything by hand and it looks like some hardware is not expecting

Still, I wonder if implementing these delays will give IO controller
better chances to react to our queries and will get rid of some

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.105 / U:4.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site