From patchwork Thu Nov 6 04:49:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Packham X-Patchwork-Id: 5239131 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 92E5F9F8B3 for ; Thu, 6 Nov 2014 05:03:19 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B178620158 for ; Thu, 6 Nov 2014 05:03:18 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0AAC42013D for ; Thu, 6 Nov 2014 05:03:17 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XmFBq-0005Ry-5i; Thu, 06 Nov 2014 05:00:58 +0000 Received: from gate2.alliedtelesis.co.nz ([2001:df5:b000:5::4]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XmFBl-0005KO-RD for linux-arm-kernel@lists.infradead.org; Thu, 06 Nov 2014 05:00:55 +0000 Received: from mmarshal3.atlnz.lc (mmarshal3.atlnz.lc [10.32.18.43]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by gate2.alliedtelesis.co.nz (Postfix) with ESMTPS id 2CFE3844CF for ; Thu, 6 Nov 2014 17:50:12 +1300 (NZDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alliedtelesis.co.nz; s=mail; t=1415249412; bh=LoPNVlpXaatszSkXNdC36n7aFpi8AwDaHpyq3zri/Vw=; h=From:To:Cc:Subject:Date; b=M0ti3aMTeG4yWky7D8/8ICRaLT6be6rKSgmvM9+7H8SKlO4H7Z6ZtP6p59pNa/lar ZXhBC68msLaP9lujj125SXBmngJZiDmT2k4sboa2/9fki/Q/AfLFHkCLIo3ltfZxke KYSk14YGCg/X8eE324fLyqGCVa9NG+btlxHSQUZk= Received: from alliedtelesyn.co.nz (Not Verified[10.32.16.32]) by mmarshal3.atlnz.lc with MailMarshal (v7, 1, 0, 4874) id ; Thu, 06 Nov 2014 17:50:11 +1300 Received: from MAIL/SpoolDir by alliedtelesyn.co.nz (Mercury 1.48); 6 Nov 14 17:50:37 +1300 Received: from SpoolDir by MAIL (Mercury 1.48); 6 Nov 14 17:50:36 +1300 Received: from chrisp-dl.ws.atlnz.lc (10.33.22.20) by alliedtelesyn.co.nz (Mercury 1.48) with ESMTP; 6 Nov 14 17:50:34 +1300 Received: by chrisp-dl.ws.atlnz.lc (Postfix, from userid 1030) id 367B0C1139; Thu, 6 Nov 2014 17:50:08 +1300 (NZDT) From: Chris Packham To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH] ARM: mvebu: Let the device-tree determine smp_ops Date: Thu, 6 Nov 2014 17:49:56 +1300 Message-Id: <1415249396-2985-1-git-send-email-chris.packham@alliedtelesis.co.nz> X-Mailer: git-send-email 2.2.0.rc0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141105_210054_476094_D5CB243E X-CRM114-Status: GOOD ( 17.92 ) X-Spam-Score: -0.7 (/) Cc: Chris Packham X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham 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 The machine specific SMP operations can be configured either via setup_arch or via arm_dt_init_cpu_maps. For the ARMADA_370_XP_DT devices both of these are called and setup_arch wins because it is called last. This means that it is not possible to substitute a different set of SMP operations via the device-tree. All of the ARMADA_370_XP_DT compatible devices are either single core or declare an enable-method in the dts (via one of armada-xp-mv78230.dtsi, armada-xp-mv78260.dtsi or armada-xp-mv78460.dtsi). Remove the smp assignment from board-v7.c so that the SMP operations set via the device-tree aren't discarded. Signed-off-by: Chris Packham --- Hi, (This is the first patch I've sent to the arm-lkml so beware of my newbie-ness) I'm working on a new board that uses a integrated CPU that according to the vendor is "based on the ARMADA-XP", more on that to come in the future hopefully. For the most part things just work if I use a .dts based on the mv78260. One difference I've encountered is in the way the secondary CPU is initialised, which requires me to supply a slightly different set of machine specific SMP operations so I can bring up the 2nd core. It looks like I should be able to supply a different /cpus/enable-method in the .dts and once I define the corresponding set of operations it should be picked up. Which leads me to what I think could be a bug (or just a lack of clear specification). The smp ops are set by both arm_dt_init_cpu_maps (from the enable-method) and setup_arch (from mdesc). The latter always wins because it is called last and doesn't check to see if smp_ops has already been set. This is my attempt at fixing the problem by not setting mdesc.smp for the ARMADA_370_XP_DT machines thus preventing setup_arch from overriding what has been setup by arm_dt_init_cpu_maps. Thanks, Chris arch/arm/mach-mvebu/board-v7.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c index 6478626..894974b 100644 --- a/arch/arm/mach-mvebu/board-v7.c +++ b/arch/arm/mach-mvebu/board-v7.c @@ -206,7 +206,6 @@ static const char * const armada_370_xp_dt_compat[] = { DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)") .l2c_aux_val = 0, .l2c_aux_mask = ~0, - .smp = smp_ops(armada_xp_smp_ops), .init_machine = mvebu_dt_init, .init_irq = mvebu_init_irq, .restart = mvebu_restart,