Hi Brad,
Out of morbid curiosity I grabbed an older MacOS AppleSMC.kext (10.7) and ran it through the disassembler. Every read/write to the SMC starts the same way with a check to make sure the SMC is in a sane state. If it's not, a read command is sent to try and kick it back into line : Wait for 0x04 to clear. This is 1,000,000 iterations of "read status, check if 0x04 is set, delay 10uS". If it clears, move on. If it doesn't, try and send a read command (just the command 0x10) and wait for the busy flag to clear again with the same loop. So in theory if the SMC was locked up, it'd be into the weeds for 20 seconds before it pushed the error out. So, lets say we've waited long enough and the busy flag dropped : Each command write is : Wait for 0x02 to clear. This is 1,000,000 iterations of "read status, check if 0x02 is set, delay 10uS". Send command Each data byte write is : Wait for 0x02 to clear. This is 1,000,000 iterations of "read status, check if 0x02 is set, delay 10uS". Immediate and single status read, check 0x04. If not set, abort. Send data byte Each data byte read is : read staus, wait for 0x01 and 0x04 to be set. delay 10uS and repeat. Abort if fail. Each timeout is 1,000,000 loops with a 10uS delay. So aside from the startup set which occurs on *every* read or write set, status checks happen before a command or data write, and not at all after. Under no circumstances are writes of any kind re-tried, but these timeouts are up to 10 seconds!
Great findings here. But from this, it would seem we are doing almost the right thing already, no? The essential difference seems to be that where the kext does a read to wake up the SMC, while we retry the first command until it works. If would of course be very interesting to know if that makes a difference.
That would indicate that the requirement for retries on the early Mac means we're not waiting long enough somewhere. Not that I'm suggesting we do another re-work, but when I get back in front of my iMac which does 17 transactions per second with this driver, I might re-work it similar to the Apple driver and see what happens. Oh, and it looks like the 0x40 flag that is on mine is the "I have an interrupt pending" flag, and the result should be able to be read from 0x31F. I'll play with that when I get time. That probably explains why IRQ9 screams until the kernel gags it on this machine as it's not being given any love.
Sounds good, getting interrupts working would have been nice. Henrik
