From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Date: Sun, 22 Nov 2015 00:14:14 +0100 Message-ID: <4519802.lamVCN5F0B@wuerfel> References: <1448068997-26631-1-git-send-email-sboyd@codeaurora.org> <6160413.CulAvzVaQj@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mout.kundenserver.de ([212.227.126.130]:60281 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754781AbbKUXPI convert rfc822-to-8bit (ORCPT ); Sat, 21 Nov 2015 18:15:08 -0500 In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= Cc: linux-arm-kernel@lists.infradead.org, Stephen Boyd , linux-arm-msm@vger.kernel.org, Steven Rostedt , linux-kernel@vger.kernel.org, Nicolas Pitre On Saturday 21 November 2015 22:11:36 M=E5ns Rullg=E5rd wrote: > Arnd Bergmann writes: > > On Saturday 21 November 2015 20:45:38 M=E5ns Rullg=E5rd wrote: > >> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann wrote: > >>=20 > >> The ARM ARM says anything with virt has idiv, lpae doesn't matter. > > > > Ok, and anything with virt also has lpae by definition. The questio= n is > > whether we care about using idiv on cores that do not have lpae, or= that > > have neither lpae nor virt. >=20 > The question is, are there any such cores? GCC doesn't know of any, = but > then it's missing most non-ARM designs. Exactly. Stephen should be able to find out about the Qualcomm cores, and http://comments.gmane.org/gmane.linux.ports.arm.kernel/426289 has some information about the others: * Brahma-B15 supports all three. * Dove (PJ4) reports idiv only in thumb mode, which I'm tempted to ign= ore for the kernel, as it supports neither lpae nor idiva. * Armada 370/XP (PJ4B) reports support for idiva and idivt, but accord= ing to https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJ= vq0YYY that may be a lie. * According to the same source, Krait fails to report idiva and idivt, but supports both anyway. However, I found reports on the web where /proc/cpuinfo correctly contains the flags on the same SoC (APQ8064) that was mentioned there, so maybe they were just running an old kernel. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Sun, 22 Nov 2015 00:14:14 +0100 Subject: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions In-Reply-To: References: <1448068997-26631-1-git-send-email-sboyd@codeaurora.org> <6160413.CulAvzVaQj@wuerfel> Message-ID: <4519802.lamVCN5F0B@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Saturday 21 November 2015 22:11:36 M?ns Rullg?rd wrote: > Arnd Bergmann writes: > > On Saturday 21 November 2015 20:45:38 M?ns Rullg?rd wrote: > >> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann wrote: > >> > >> The ARM ARM says anything with virt has idiv, lpae doesn't matter. > > > > Ok, and anything with virt also has lpae by definition. The question is > > whether we care about using idiv on cores that do not have lpae, or that > > have neither lpae nor virt. > > The question is, are there any such cores? GCC doesn't know of any, but > then it's missing most non-ARM designs. Exactly. Stephen should be able to find out about the Qualcomm cores, and http://comments.gmane.org/gmane.linux.ports.arm.kernel/426289 has some information about the others: * Brahma-B15 supports all three. * Dove (PJ4) reports idiv only in thumb mode, which I'm tempted to ignore for the kernel, as it supports neither lpae nor idiva. * Armada 370/XP (PJ4B) reports support for idiva and idivt, but according to https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY that may be a lie. * According to the same source, Krait fails to report idiva and idivt, but supports both anyway. However, I found reports on the web where /proc/cpuinfo correctly contains the flags on the same SoC (APQ8064) that was mentioned there, so maybe they were just running an old kernel. Arnd