On Thu, 14 Oct 2010 11:22:45 -0500 <david.hag...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
