On 01/08/13 19:17, Santosh Shilimkar wrote:
> From: Vaibhav Bedia <[email protected]>
> 
> The generic code is well equipped to differentiate between
> SMP and UP configurations.However, there are some devices which
> use Cortex-A9 MP core IP with 1 CPU as configuration. To let
> these SOCs to co-exist in a CONFIG_SMP=y build by leveraging
> the SMP_ON_UP support, we need to additionally check the
> number the cores in Cortex-A9 MPCore configuration. Without
> such a check in place, the startup code tries to execute
> ALT_SMP() set of instructions which lead to CPU faults.
> 
> The issue was spotted on TI's Aegis device and this patch
> makes now the device work with omap2plus_defconfig which
> enables SMP by default. The change is kept limited to only
> Cortex-A9 MPCore detection code.
> 
> Cc: Will Deacon <[email protected]>
> Cc: Russell King <[email protected]>
> 
> Acked-by: Sricharan R <[email protected]>
> Signed-off-by: Vaibhav Bedia <[email protected]>
> Signed-off-by: Santosh Shilimkar <[email protected]>
> ---
>  arch/arm/kernel/head.S |   18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 9cf6063..4924b11 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -486,7 +486,23 @@ __fixup_smp:
>       mrc     p15, 0, r0, c0, c0, 5   @ read MPIDR
>       and     r0, r0, #0xc0000000     @ multiprocessing extensions and
>       teq     r0, #0x80000000         @ not part of a uniprocessor system?
> -     moveq   pc, lr                  @ yes, assume SMP
> +     bne    __fixup_smp_on_up        @ no, assume UP
> +
> +     @ Core indicates it is SMP.  Check for Aegis SOC where a single
> +     @ Cortex-A9 CPU is present but SMP operations fault.
> +     mov     r4, #0x41000000
> +     orr     r4, r4, #0x0000c000
> +     orr     r4, r4, #0x00000090
> +     teq     r3, r4                  @ Check for ARM Cortex-A9
> +     movne   pc, lr                  @ Not ARM Cortex-A9,
> +
> +     mrc     p15, 4, r0, c15, c0     @ get SCU base address
Correct me if I am interpreting this wrong, but CRn=15 here which is
IMPLEMENTATION DEFINED registers.

If not, then I wonder why few platform have to read SCU base from DT or
some header, why not this way ?

Regards,
Sudeep


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to