[PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
Sudeep.KarkadaNagesha at arm.com
Fri Aug 2 11:45:46 EDT 2013
On 02/08/13 16:22, Santosh Shilimkar wrote:
> On Friday 02 August 2013 10:45 AM, Sudeep KarkadaNagesha wrote:
>> On 01/08/13 19:17, Santosh Shilimkar wrote:
>>> From: Vaibhav Bedia <vaibhav.bedia at ti.com>
>>> 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 <will.deacon at arm.com>
>>> Cc: Russell King <linux at arm.linux.org.uk>
>>> Acked-by: Sricharan R <r.sricharan at ti.com>
>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia at ti.com>
>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>> 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 ?
> I don't know if there is Cortex-A9 based SOC which don't implement SCU
> CP15 base address register, so can't comment really why not always use
> CP15 based method. I am not even sure if there are other reasons behind
> DT usage.
I may be wrong, but it's just my understanding as I see that ARM ARM
clearly states CRn=15 space is IMPLEMENTATION DEFINED registers and we
can't expect it to work on all IMPLEMENTATIONS.
I just had a glance at all the usage of CR15 space of CP15 register, its
either platform specific or under specific errata/condition.
Will/Dave/Russell can confirm if it's safe to access these registers on
any implementation or you may need to make it conditional.
More information about the linux-arm-kernel