On Mon, Dec 10, 2001, Josh de Cesare <decesare@apple.com> wrote:
We have know about the typos for some time. The are all
basically benign. We plan to fix them when there is time for the
changes to be properly tested. I plan to get rid of the pending
interrupt variable. They were a product of paranoia. When the
handler fires, if the level sensitive interrupts are active then they
will be dispatched. When I fix the driver I will go over the level
masks.
As far as lost interrupts I have not seen any. There is of
course the well know behavior of the interrupt controllers of this
type. If an interrupt becomes active (level or edge) while it is
masked, it will not generate an interrupt when it is unmasked.
Yes, that's well known and we have a workaround as well in linux, by testing the "level" register when unmasking. I'm not too sure if we might still lose edge interrupts there as their level may have been back to 0 already, but there's nothing much we can do if this is the case. I think my problem with the PMU _might_ be related to a buglet in my code where I write the "clear" register (we call it ack) twice, I've cleaned up my code a bit and am now waiting for more user reports. (Basically, I stopped receiving CB_1 interrupts after a while, can be pretty long, about several hours. Just forcing the driver to send a new interrupt ack command "fixed" it). BTW. I also noticed that on core99, I get spurrious GPIO1 interrupts. Basically, things acts like if after every "normal" GPIO1 interrupt, I get a spurrious one (that is the PMU doesn't return any data back from the interrupt ack command). It might be normal behaviour, but I suspect it may be also a subtle issue with the GPIO used for the interrupt. I don't know much about how GPIOs work on KeyLargo outside of setting the output enable & data bits, but I did find a few bit definitions in the AppleTexasAudio driver, which seem to explain that interrupt GPIOs can be programmed to trigger on dual-edge. That may explain why any 0-1-0 transition of ther PMU interrupt would cause 2 interrupts to be actually triggered. I'm not sure nor I know if Darwin has the same issue as the PMU driver isn't open source. It's mostly harmless except for the additional interrupt/CPU load caused which may slightly reduce battery life ;-) Regards, Ben.