From patchwork Tue Sep 24 17:43:53 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Santosh Shilimkar X-Patchwork-Id: 2934861 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 63A509F288 for ; Tue, 24 Sep 2013 17:44:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2283420336 for ; Tue, 24 Sep 2013 17:44:54 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 20B4B20374 for ; Tue, 24 Sep 2013 17:44:49 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VOWf6-0001lR-60; Tue, 24 Sep 2013 17:44:36 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VOWey-0007h7-B3; Tue, 24 Sep 2013 17:44:28 +0000 Received: from comal.ext.ti.com ([198.47.26.152]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VOWev-0007eM-NA for linux-arm-kernel@lists.infradead.org; Tue, 24 Sep 2013 17:44:26 +0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id r8OHhsJm015292; Tue, 24 Sep 2013 12:43:54 -0500 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id r8OHhsYR013427; Tue, 24 Sep 2013 12:43:54 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.2.342.3; Tue, 24 Sep 2013 12:43:54 -0500 Received: from [158.218.103.117] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id r8OHhrPv002038; Tue, 24 Sep 2013 12:43:54 -0500 Message-ID: <5241CF59.3000006@ti.com> Date: Tue, 24 Sep 2013 13:43:53 -0400 From: Santosh Shilimkar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Will Deacon Subject: Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices References: <1375381033-13220-1-git-send-email-santosh.shilimkar@ti.com> <51FBC610.9030900@arm.com> <51FBCEC3.4030207@ti.com> <51FBD42A.9040901@arm.com> <20130802154857.GD5292@mudshark.cambridge.arm.com> <52092AA5.3090005@ti.com> <20130813111943.GE30280@mudshark.cambridge.arm.com> <520A3518.3030301@ti.com> <20130924170849.GC32220@mudshark.cambridge.arm.com> In-Reply-To: <20130924170849.GC32220@mudshark.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130924_134425_836209_38E690CE X-CRM114-Status: GOOD ( 26.21 ) X-Spam-Score: -9.2 (---------) Cc: Sudeep KarkadaNagesha , "linux-omap@vger.kernel.org" , Russell King , Vaibhav Bedia , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tuesday 24 September 2013 01:08 PM, Will Deacon wrote: > Hi Santosh, > > On Tue, Aug 13, 2013 at 02:31:04PM +0100, Santosh Shilimkar wrote: >> On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote: >>> On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: >>>> On Friday 02 August 2013 11:48 AM, Will Deacon wrote: >>>>> I think this an A9-specific register, which reads as 0 on UP A9 and reads as >>>>> some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE >>>>> is zero. >>>>> >>>> What do we do here ? Should we document this in the code and proceed ? >>>> Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but >>>> I am open for any other alternative. >>> >>> The only other alternative I can think of is forcing people to have >>> CONFIG_SMP=n, but that blows away single zImage for your platform. >>> >> Yep which surely we don't want considering after so much effort we >> have it working first place. How about going ahead with assumption >> that PERIPH_BASE = 0 case doesn't work. > > It's been over a month and I can't think of anything better than this > without jeopardising the single zImage effort. However, it also doesn't seem > fair if we rule out the possibility of single zImage for future SoCs which > use 0x0 as their PERIPH_BASE (I don't know of any at the moment). > > So how about we go ahead with this, but add a big fat comment to the code in > head.S saying that, if a future SoC *does* use 0x0 as the PERIPH_BASE, then > the check will need to be #ifdef'd or equivalent for the Aegis platform? > I agree. Updated patch end of the email. If you are fine with this version, will stick it into RMK's patch system. Regards, Santosh From 05b1b43324f3e8d10a38f78dbcbf7632d4c3530c Mon Sep 17 00:00:00 2001 From: Vaibhav Bedia Date: Thu, 18 Jul 2013 13:01:53 -0400 Subject: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices 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. Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then the SCU address check code needs to be #ifdef'd for for the Aegis platform. Cc: Will Deacon Cc: Russell King Acked-by: Sricharan R Signed-off-by: Vaibhav Bedia Signed-off-by: Santosh Shilimkar --- arch/arm/kernel/head.S | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 2c7cc1e..476de57 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -487,7 +487,26 @@ __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, + + @ If a future SoC *does* use 0x0 as the PERIPH_BASE, then the + @ below address check will need to be #ifdef'd or equivalent + @ for the Aegis platform. + mrc p15, 4, r0, c15, c0 @ get SCU base address + teq r0, #0x0 @ '0' on actual UP A9 hardware + beq __fixup_smp_on_up @ So its an A9 UP + ldr r0, [r0, #4] @ read SCU Config + and r0, r0, #0x3 @ number of CPUs + teq r0, #0x0 @ is 1? + movne pc, lr __fixup_smp_on_up: adr r0, 1f