the ppc_n_lost_interrupts thing...

the ppc_n_lost_interrupts thing...

[Jun Sun]

Hi, all,

I am a newbie to PowerPC-linux.  Hopefully this question is
not too dumb.

When I looked into the interrupt related code in ppc-linux,
I got totally confused by the "ppc_n_lost_interrupts"
variable.

Here is the comment from pmac_pic.c file :

        /*
         * Unfortunately, setting the bit in the enable register
         * when the device interrupt is already on *doesn't* set
         * the bit in the flag register or request another
interrupt.
         */

>From this, I can infer that ppc_n_lost_interrupts is used to
"fake" a new interrupt at the end of an interrupt handling.
However,
what I don't understand is - how could this possibly detect an
interrupt that happens while the CPU is blocking external
interrupt?
In this case, ppc_n_lost_interrupts won't be incremented and when
the external interrupt is re-enabled, we won't be able to get
into interrupt mode.

That does not sound right to me.  Could someone shed a light on
this whole "ppc_n_lost_interrupt" thing?  Thanks in advance.


Jun

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: the ppc_n_lost_interrupts thing...

[Benjamin Herrenschmidt]

On Thu, Jan 27, 2000, Jun Sun <jsun@mvista.com> wrote:

>I am a newbie to PowerPC-linux.  Hopefully this question is
>not too dumb.

Definitely not ;) Here's my understanding:

>From this, I can infer that ppc_n_lost_interrupts is used to
>"fake" a new interrupt at the end of an interrupt handling.

That's it.

>However,
>what I don't understand is - how could this possibly detect an
>interrupt that happens while the CPU is blocking external
>interrupt?
>In this case, ppc_n_lost_interrupts won't be incremented and when
>the external interrupt is re-enabled, we won't be able to get
>into interrupt mode.

The interrupt will be lost only when it's masked in the controller while
beeing issued by the device. It's a PIC bug.

So, we need to check it out only when unmasking the interrupt -in the
controller-. That's what we do in pmac-pic.c. If interrupts are masked on
the CPU but not on the controller, they are not lost. If they are masked
in both, it's not a problem neither, at least until someone tries to
umask one in the controller.

Note that our implementation if restore_flags() will check
lost_interrupts since the unmask call can be done while MSR_EE is 0.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: the ppc_n_lost_interrupts thing...

[Jun Sun]

Benjamin Herrenschmidt wrote:
> >However,
> >what I don't understand is - how could this possibly detect an
> >interrupt that happens while the CPU is blocking external
> >interrupt?
> >In this case, ppc_n_lost_interrupts won't be incremented and when
> >the external interrupt is re-enabled, we won't be able to get
> >into interrupt mode.
>
> The interrupt will be lost only when it's masked in the controller while
> beeing issued by the device. It's a PIC bug.
>

Hmm, I assume that not every power pc board would have this problem.
Which PIC is having this problem?  The one used in Mac?

If this is the case, it would be nice that the workaround code can be
put in the #ifdef scope.  Just a thought.

> So, we need to check it out only when unmasking the interrupt -in the
> controller-. That's what we do in pmac-pic.c. If interrupts are masked on
> the CPU but not on the controller, they are not lost. If they are masked
> in both, it's not a problem neither, at least until someone tries to
> umask one in the controller.
>
> Note that our implementation if restore_flags() will check
> lost_interrupts since the unmask call can be done while MSR_EE is 0.
>

Thanks a lot.  I got it.

Jun

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/