All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: Linux 2.6.39 on Cavium CN38xx
Date: Sun, 12 Jun 2011 09:41:55 -0700	[thread overview]
Message-ID: <20110612164155.GA30615@ericsson.com> (raw)
In-Reply-To: <1307751642.8271.315.camel@groeck-laptop>

On Fri, Jun 10, 2011 at 08:20:42PM -0400, Guenter Roeck wrote:
[ ... ]

> Hi David,
> 
> Turns out my primary problem is that octeon_irq_setup_secondary_ciu()
> sets C0_STATUS to 0x1000efe0, ie all interrupts except IP4 are enabled.
> This mask is primarily set through octeon_irq_percpu_enable(), which
> sets C0_STATUS to 0x1000e3e0. The value differs from CPU 0, where
> C0_STATUS is set to 0x10008ce0.
> 
> This causes persistent spurious interrupts on our boards (both with
> CN38xx and CN58xx), where C0_CAUSE persistently reads as zero in the
> interrupt handling code but interrupts are triggered anyway. The
> spurious interrupt problem goes away if I mask out IP0, IP1, IP5, and
> IP6 at the end of octeon_irq_setup_secondary_ciu().
> 
Answering part of my own question: The interrupt enable bits for secondary CPUs
are all set through octeon_irq_core_eoi(), which is called from the per-CPU
initialization code and enables each interrupt even if "desired_en" is false
for a given bit. I modified octeon_irq_core_eoi() to

	if (cd->desired_en)
                set_c0_status(0x100 << cd->bit); 

which takes care of the problem. No idea if that is correct, though.

The actual interrupt causing trouble and spurious interrupts in my case is,
oddly enough, STATUSF_IP0. So far I have been unable to track down how that
is triggered; I don't see the bit being set set in C0_CAUSE anywhere.

Are there any means to trigger an IP0 interrupt other than by writing STATUSF_IP0 
into the C0_CAUSE register ?

Thanks,
Guenter

  reply	other threads:[~2011-06-12 16:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 21:08 Linux 2.6.39 on Cavium CN38xx Guenter Roeck
2011-06-09 21:41 ` David Daney
2011-06-09 22:06   ` Guenter Roeck
2011-06-09 22:06     ` Guenter Roeck
2011-06-09 22:59     ` David Daney
2011-06-11  0:20       ` Guenter Roeck
2011-06-12 16:41         ` Guenter Roeck [this message]
2011-06-13 21:10           ` David Daney
2011-06-13 21:51             ` Guenter Roeck
2011-06-14  3:34               ` Guenter Roeck
2011-06-14 16:55                 ` David Daney
2011-06-14 18:09                   ` Guenter Roeck

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=20110612164155.GA30615@ericsson.com \
    --to=guenter.roeck@ericsson.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=linux-mips@linux-mips.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.