Re(2): Heathrow interrupt weirdness
Re(2): Heathrow interrupt weirdness
- Subject: Re(2): Heathrow interrupt weirdness
- From: Benjamin Herrenschmidt <email@hidden>
- Date: Tue, 11 Dec 2001 10:51:37 +0100
On Mon, Dec 10, 2001, Josh de Cesare <email@hidden> 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.