Re: Linux 2.6.39 on Cavium CN38xx

[David Daney <ddaney@caviumnetworks.com>]

On 06/12/2011 09:41 AM, Guenter Roeck wrote:
> 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);
>

That shouldn't be needed.  The logic in irq_cpu_online() should only 
call chip->irq_cpu_online() if the irq is enabled.


> 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 ?
>

No.  Nothing that I know of ever uses IP0 and IP1, so they should always 
be cleared.

David Daney.