All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <bh40@calva.net>
To: Jun Sun <jsun@mvista.com>, linuxppc-dev@lists.linuxppc.org
Subject: Re: the ppc_n_lost_interrupts thing...
Date: Fri, 28 Jan 2000 11:21:26 +0100	[thread overview]
Message-ID: <20000128112126.007819@mailhost.mipsys.com> (raw)
In-Reply-To: <3891008C.A83C47B4@mvista.com>


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/

  reply	other threads:[~2000-01-28 10:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-28  2:35 the ppc_n_lost_interrupts thing Jun Sun
2000-01-28 10:21 ` Benjamin Herrenschmidt [this message]
2000-02-02 23:38   ` Jun Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000128112126.007819@mailhost.mipsys.com \
    --to=bh40@calva.net \
    --cc=jsun@mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.