Hi James, Qais, On Thu, Jan 15, 2015 at 8:36 AM, Qais Yousef <qais.yousef@xxxxxxxxxx> wrote: > 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)? I believe so. James, I think you can apply a similar patch to smp-mt.c:vsmp_init_secondary. Thanks, Andrew
