From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Will Deacon <Will.Deacon@arm.com>,
Vaibhav Bedia <vaibhav.bedia@ti.com>
Subject: Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
Date: Fri, 2 Aug 2013 11:22:43 -0400 [thread overview]
Message-ID: <51FBCEC3.4030207@ti.com> (raw)
In-Reply-To: <51FBC610.9030900@arm.com>
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@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@arm.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>>
>> Acked-by: Sricharan R <r.sricharan@ti.com>
>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@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.
Regards,
Santosh
next prev parent reply other threads:[~2013-08-02 15:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 18:17 [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices Santosh Shilimkar
2013-08-02 9:53 ` Will Deacon
2013-08-02 12:32 ` Santosh Shilimkar
2013-08-02 14:18 ` Dave Martin
2013-08-02 15:18 ` Santosh Shilimkar
2013-08-02 14:45 ` Sudeep KarkadaNagesha
2013-08-02 15:22 ` Santosh Shilimkar [this message]
2013-08-02 15:45 ` Sudeep KarkadaNagesha
2013-08-02 15:48 ` Will Deacon
2013-08-12 18:34 ` Santosh Shilimkar
2013-08-13 11:19 ` Will Deacon
2013-08-13 13:31 ` Santosh Shilimkar
2013-08-23 17:08 ` Sekhar Nori
2013-08-23 17:17 ` Santosh Shilimkar
2013-08-23 17:41 ` Sekhar Nori
2013-09-24 17:08 ` Will Deacon
2013-09-24 17:43 ` Santosh Shilimkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51FBCEC3.4030207@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=Sudeep.KarkadaNagesha@arm.com \
--cc=Will.Deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=vaibhav.bedia@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).