From patchwork Thu Feb 18 16:34:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 102739 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp686473lbl; Thu, 18 Feb 2016 08:35:56 -0800 (PST) X-Received: by 10.66.150.170 with SMTP id uj10mr11224952pab.91.1455813356721; Thu, 18 Feb 2016 08:35:56 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 6si10250197pfp.194.2016.02.18.08.35.56; Thu, 18 Feb 2016 08:35:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946402AbcBRQfy (ORCPT + 30 others); Thu, 18 Feb 2016 11:35:54 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:58082 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1426125AbcBRQfx (ORCPT ); Thu, 18 Feb 2016 11:35:53 -0500 Received: from wuerfel.lan. ([78.42.132.4]) by mrelayeu.kundenserver.de (mreue001) with ESMTPA (Nemesis) id 0MGb9E-1ajai1394i-00DEfx; Thu, 18 Feb 2016 17:35:13 +0100 From: Arnd Bergmann To: Russell King Cc: linux-arm-kernel@lists.infradead.org, Arnd Bergmann , Thomas Petazzoni , Jason Cooper , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Lior Amsalem , Nadav Haklai , Nicolas Pitre , Ard Biesheuvel , linux-kernel@vger.kernel.org Subject: [PATCH] [RESEND] ARM: PJ4: don't use PJ4B code on PJ4 Date: Thu, 18 Feb 2016 17:34:48 +0100 Message-Id: <1455813309-2556471-1-git-send-email-arnd@arndb.de> X-Mailer: git-send-email 2.7.0 X-Provags-ID: V03:K0:aByiTBQqs5pNbQblN2HxYddo1qWQ0bVYDoEjDnYrAb6qDnsBw/B W5EFcyupmoSEoNghdSf+pcKLUTWERJrSHvePVKj8oAxPIF7iJ+Hw7zZfcrQudcWkdNS+lsy /EfuUO822kcwJd8dnK8xvefUaCymtB84z1r+a+O0qQNw1e7OIByzyCcGYnwCCyHvYLYDF+n HsCLtEgKTHHr2GxzFdfyw== X-UI-Out-Filterresults: notjunk:1; V01:K0:ZOnDI2b4q9s=:GLKUg/PqEQtQwX2hHzYqUT zF9ZeiGqPS3awAVimXzzXfVMCI9bWhDtRYXKYseizoKU4uFAd14/ECwBJIXl+K7qzi94odUX8 DpUyFdLTWilJ4BJ45EIGQfr1vYNjApJiABLdDvIyHXZCnnb8bsaVke8sGobZNE8WpiYvgT5rR hc/eFPBWfwQsrEsL/9lE4tSrugQ3xGDgqK9dSPBVFwgiZ6i6gfq2nc4GhH20VgeOXyy8tipkT OwxQqGj76QMu3SOEE5LDln+m7IIwJJ5Jqaog/qCnq0pyDhUp+3/NOgY+avKUWJ+h7aChkuuHA lCyIMaCVFq1N2f33XNG3OUAac9e+aYIHqT1xMcv69bNJWik3Cq4KGI8DVUEaNnOlWsBTrgJtA NIuhIPTkWrXqxOIYaMIQhSPEx/5fbk74c2tceiuFbowYpPWRPue6fNglIo6BuKFfZ4x3pkLEO mJspScNy3F9y5X3T9Zue0tMOJTWoouskpqktDB3CT5SoCLN4RcwEy+dk8TcIttmpbQS5vs6nZ MojcqOkdU2WZnsc5hPE8gmpkizhFbBt9l9ocs5wSzKHrDI5trvQOToE3+gewEZIk00PaioKEV LH00KBEbsinWrxtSdyjW944gpuW8waLldPKzAhHkT8gbup3XO8ujpOesGRUZrfhNF3yOTx0NJ tOZFnrDWof2SR1b07TzqvfwCuiGil2cIjiHSpm9Nv0vP6K80HwF0tPJFmUNR2KgeVbA4= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We can have multiplatform kernels with PJ4 (Dove, MMP2) in combination with PJ4B (Armada 370) or PJ4B-MP (Berlin, Armada XP), and the processor functions that are defined for PJ4B use a mask that covers all three core types, rather than using the default ARMv7 type for the original PJ4. This adds a second entry for PJ4B-MP, so we at least get a consistent behavior between single-machine kernels and combined ones. I suspect however that we actually want different contents for each of the three cores, as PJ4B and PJ4B-MP appear to be at least as different as PJ4 is from PJ4B, in particular the support for the standard architecture extensions like IDIV and LPAE, and the PJ4B_ERRATA_4742 workaround apparently does not apply to PJ4B-MP but might apply to PJ4. Signed-off-by: Arnd Bergmann Fixes: 049be07053eb ("ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B") --- I sent this out previously as an RFC but did not get any reply. I'm pretty sure we still need the patch, or an extended version of it, but I'd be much happier if someone could actually look into the contents. --- arch/arm/mm/proc-v7.S | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) -- 2.7.0 diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 0f8963a7e7d9..7239fd55b159 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -576,10 +576,17 @@ __v7_ca8_proc_info: #ifdef CONFIG_CPU_PJ4B .type __v7_pj4b_proc_info, #object __v7_pj4b_proc_info: - .long 0x560f5800 - .long 0xff0fff00 + .long 0x562f5840 + .long 0xfffffff0 __v7_proc __v7_pj4b_proc_info, __v7_pj4b_setup, proc_fns = pj4b_processor_functions .size __v7_pj4b_proc_info, . - __v7_pj4b_proc_info + + .type __v7_pj4bmp_proc_info, #object +__v7_pj4bmp_proc_info: + .long 0x561f5810 + .long 0xfffffff0 + __v7_proc __v7_pj4bmp_proc_info, __v7_pj4b_setup, proc_fns = pj4b_processor_functions + .size __v7_pj4bmp_proc_info, . - __v7_pj4bmp_proc_info #endif /*