[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.022 / U:5.204 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site