lkml.org 
[lkml]   [2015]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2 18/24] irqchip: mips-gic: Stop using per-platform mapping tables
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@chromium.org>
>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>> Reviewed-by: Qais Yousef <qais.yousef@imgtec.com>
>> Tested-by: Qais Yousef <qais.yousef@imgtec.com>
>
> 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

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2015-01-15 17:41    [W:0.168 / U:1.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site