Re: i8042 access timings

[Jaco Kroon]

Vojtech Pavlik wrote:
> > > What I believe is happening is that we're talking to SMM emulation of
> > > the i8042, which doesn't have a clue about these commands, while the
> > > underlying real hardware implementation does. And because of that they
> > > disagree on what should happen when the command is issued, and since the
> > > SMM emulation lazily synchronizes with the real HW, we only get the data
> > > back with the next command.

This makes sense in a weird kind of way.

> > > I still don't have an explanation why both 'usb-handoff' and 'acpi=off'
> > > help, I'd expect only the first to, but it might be related to the SCI
> > > interrupt routing which isn't done when 'acpi=off'. Just a wild guess.

SCI interrupt routing?  I have tried with pci=routeirq and that hasn't 
helped either.  IRQ balancing perhaps?

> I don't like the interrupt message, I'll check why it's enabled so
> early. It may have a good reason to, as well. Other than that, it looks
> very much OK.

That was with usb-handoff.  It also resulted in the black screen of 
bios-death upon reboot though :).

> > So as with acpi=off, we get a correct return.  Now that usb is 
> > mentioned, I think either myself or Sebastian has mentioned that the 
> > keyboard does not work unless USB1.1 support is compiled in.  Another 
> > clue possibly?
>
>
> Compiling USB 1.1 support does the very same thing as specifying
> usb-handoff on the command like - tells the BIOS to keep its hands off
> the USB _and_ PS/2 controllers.

I'm missing something, I have USB1.1 compiled in, then why does the 
touchpad not work if it does the very same thing as usb-handoff?

> > Another question - would it be usefull at all to see what happens if the 
> > AUX_LOOP test is never performed but only AUX_TEST?  Or does AUX_TEST 
> > rely on the fact that AUX_LOOP must first fail/timeout somehow?
> No. You can use AUX_TEST event before AUX_LOOP. But I expect it to fail
> similarly when BIOS is active.

That is correct.  It fails with timeout.  This for me confirms the fact 
that it is responding one command too late. aka, we send a command, it 
times out, we send another, it sends the result of the first.

Right, any new (or variations of existing ones) theories that I can try 
out to make this touchpad work correctly?  I can simply hack out the 
test for the touchpad but that doesn't solve the problem for others.

Jaco
--
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature