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

[James Hogan]

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

Attachment: signature.asc
Description: OpenPGP digital signature