Re: i8042 access timings

[Jaco Kroon <jaco@kroon.co.za>]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3166 bytes --]