From patchwork Wed Oct 1 22:09:29 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 5014801 Return-Path: X-Original-To: patchwork-linux-arm-msm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4DD08BEEA6 for ; Wed, 1 Oct 2014 22:09:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4B32A2020F for ; Wed, 1 Oct 2014 22:09:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11D28201FE for ; Wed, 1 Oct 2014 22:09:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751929AbaJAWJc (ORCPT ); Wed, 1 Oct 2014 18:09:32 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:38355 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644AbaJAWJb (ORCPT ); Wed, 1 Oct 2014 18:09:31 -0400 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id DE97513FF21; Wed, 1 Oct 2014 22:09:30 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id C0D4213FF2A; Wed, 1 Oct 2014 22:09:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SUSPICIOUS_RECIPS, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from [10.46.167.8] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sboyd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 4C55B13FF21; Wed, 1 Oct 2014 22:09:30 +0000 (UTC) Message-ID: <542C7B99.60500@codeaurora.org> Date: Wed, 01 Oct 2014 15:09:29 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, Will Deacon , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations References: <1411076592-6157-1-git-send-email-sboyd@codeaurora.org> <1411076592-6157-3-git-send-email-sboyd@codeaurora.org> <20140918224625.GF5182@n2100.arm.linux.org.uk> <541C74C1.9060504@codeaurora.org> <20141001215043.GS5182@n2100.arm.linux.org.uk> In-Reply-To: <20141001215043.GS5182@n2100.arm.linux.org.uk> X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Spam-Level: * X-Virus-Scanned: ClamAV using ClamSMTP On 10/01/14 14:50, Russell King - ARM Linux wrote: > On Fri, Sep 19, 2014 at 11:24:01AM -0700, Stephen Boyd wrote: >> >> Do you, or anyone else, know of other implementations? I *hope* that >> this same exercise was done by the VFP architects before they >> re-purposed bits but who knows. If nobody is actually setting these >> higher bits then is there any problem widening the mask (besides it >> being slightly confusing)? > There are certainly non-ARM implementations around, eg: > > VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 Can you provide the raw value of the id register or at least bits 22:16? This print is currently masking off the bits so we don't know what's there. All we know is that bit 20 is not set because it doesn't fail to initialize vfp. > > which is from Marvell Dove. I don't know how the other Marvell offerings > identify. I wouldn't be surprised if there were other implementations > from other vendors too. > > However, if we do have any implementation which indicates that it does > not support both single and double precision ops (bit 20), then today > the VFP support code refuses to initialise, and the system will behave > as if there is no VFP present. > > So, the problem case is whether we do have non-ARM produced implementations > where the VFP code refuses to init, which would then be misidentified as > some insane architecture version. > I'm not aware of anything. You would know better than I though. That check assumes a v2. We should update that check to only look for v2 or less (this isn't based on the current patch but can be squashed in). ---8<--- diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c index 2f37e1d6cb45..22d6a1171a4e 100644 --- a/arch/arm/vfp/vfpmodule.c +++ b/arch/arm/vfp/vfpmodule.c @@ -738,14 +738,18 @@ static int __init vfp_init(void) vfp_vector = vfp_null_entry; pr_info("VFP support v0.3: "); - if (VFP_arch) + if (VFP_arch) { pr_cont("not present\n"); - else if (vfpsid & FPSID_NODOUBLE) { - pr_cont("no double precision support\n"); } else { hotcpu_notifier(vfp_hotplug, 0); VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT; /* Extract the architecture version */ + + if (VFP_arch < 2 && (vfpsid & FPSID_NODOUBLE)) { + pr_cont("no double precision support\n"); + return 0; + } + pr_cont("implementor %02x architecture %d part %02x variant %x rev %x\n", (vfpsid & FPSID_IMPLEMENTER_MASK) >> FPSID_IMPLEMENTER_BIT, (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT,