Questions on interrupt vector assignment on MPC8641D
Scott Wood
scottwood at freescale.com
Fri Oct 15 03:32:30 EST 2010
On Thu, 14 Oct 2010 11:22:45 -0500
<david.hagood at gmail.com> wrote:
> As I read the code:
> /* Read feature register, calculate num CPUs and, for non-ISU
> * MPICs, num sources as well. On ISU MPICs, sources are counted
> * as ISUs are added
> */
> greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
> mpic->num_cpus = ((greg_feature & MPIC_GREG_FEATURE_LAST_CPU_MASK)
> >> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
> if (isu_size == 0)
> mpic->num_sources =
> ((greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
> >> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
> So it would seem to me that the "greg_feature" is saying I have 88
> interrupts.
>
> I've tried setting the ISU size to 256:
> mpic1 = mpic_alloc(np, res.start,
> MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
> 256, 256,
> " MPIC ");
> And that kills the kernel as we init the mpic.
>
> SO, I guess the question in, what sets "greg_feature", as it would seem to
> be incorrect.
It comes from FRR[NIRQ]. It seems that this chip takes a
less-than-useful interpretation of what that field means -- it gives
the actual number of sources, not the size of the sparsely populated
array.
If you look at current kernels, you'll find an MPIC_BROKEN_FRR_NIRQS
flag to work around this.
It's not very clear to me what distinction the MPIC code is
trying to make between irq_count and num_sources in the first place,
though.
-Scott
More information about the Linuxppc-dev
mailing list