Re: [PATCH V2 18/24] irqchip: mips-gic: Stop using per-platform mapping tables

[Qais Yousef]

On 01/15/2015 04:29 PM, James Hogan wrote:
> On 15/01/15 11:59, James Hogan wrote:
> > Hi Andrew,
> >
> > On 18/09/14 22:47, Andrew Bresticker wrote:
> > > Now that the GIC properly uses IRQ domains, kill off the per-platform
> > > routing tables that were used to make the GIC appear transparent.
> > >
> > > This includes:
> > >   - removing the mapping tables and the support for applying them,
> > >   - moving GIC IPI support to the GIC driver,
> > >   - properly routing the i8259 through the GIC on Malta, and
> > >   - updating IRQ assignments on SEAD-3 when the GIC is present.
> > >
> > > Platforms no longer will pass an interrupt mapping table to gic_init.
> > > Instead, they will pass the CPU interrupt vector (2 - 7) that they
> > > expect the GIC to route interrupts to.  Note that in EIC mode this
> > > value is ignored and all GIC interrupts are routed to EIC vector 1.
> > >
> > > Signed-off-by: Andrew Bresticker <abrestic@xxxxxxxxxxxx>
> > > Acked-by: Jason Cooper <jason@xxxxxxxxxxxxxx>
> > > Reviewed-by: Qais Yousef <qais.yousef@xxxxxxxxxx>
> > > Tested-by: Qais Yousef <qais.yousef@xxxxxxxxxx>
> > This commit (18743d2781d01d34d132f952a2e16353ccb4c3de) appears to break
> > boot of interAptiv, dual core, dual vpe per core, on malta with
> > malta_defconfig.
> >
> > It gets to here:
> > ...
> > CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
> > FPU revision is: 0173a000
> > Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
> > Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
> > MIPS secondary cache 1024kB, 8-way, linesize 32 bytes.
> > Synchronize counters for CPU 1: done.
> > Brought up 2 CPUs
> >
> > and then appears to just hang. Passing nosmp works around it, allowing
> > it to get to userland.
> >
> > Is that a problem you've already come across?
> >
> > I'll keep debugging.
> Right, it appears the CPU IRQ line that the GIC is using doesn't get
> unmasked (STATUSF_IP2) when a new VPE is brought up, so only the first
> CPU will actually get any interrupts after your patch (including the
> rather critical IPIs), i.e. hacking it in vsmp_init_secondary() in
> smp-mt.c allows it to boot.
>
> Hmm, I'll have a think about what the most generic fix is, since
> arbitrary stuff may or may not have registered handlers for the raw CPU
> interrupts (timer, performance counter, gic etc)...
>
> Cheers
> James

Is this similar to the issue addressed by this (ff1e29ade4c6 MIPS: 
smp-cps: Enable all hardware interrupts on secondary CPUs)?

Qais
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/