Groups > linux.kernel > #1274584 > unrolled thread

[RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

Started by	Stephen Boyd <sboyd@codeaurora.org>
First post	2015-11-21 02:30 +0100
Last post	2015-11-21 21:50 +0100
Articles	20 on this page of 58 — 8 participants

Back to article view | Back to linux.kernel

  [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
    [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
      Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-21 11:20 +0100
        Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Steven Rostedt <rostedt@goodmis.org> - 2015-11-23 22:00 +0100
        Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:00 +0100
          Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-23 22:10 +0100
            Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:20 +0100
              Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-23 22:40 +0100
                Re: [RFC/PATCH 2/3] recordmcount: Record locations of  __aeabi_{u}idiv() calls on ARM Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 02:10 +0100
    [RFC/PATCH 1/3] scripts: Allow recordmcount to be used without tracing enabled Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
    [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-21 02:30 +0100
      Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Måns Rullgård <mans@mansr.com> - 2015-11-21 13:00 +0100
        Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with  udiv/sdiv instructions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:00 +0100
          Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Måns Rullgård <mans@mansr.com> - 2015-11-23 22:00 +0100
            Re: [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with  udiv/sdiv instructions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:20 +0100
    Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-21 21:50 +0100
      Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-21 22:10 +0100
        Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-21 23:20 +0100
          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 00:20 +0100
            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 00:30 +0100
              Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Peter Maydell <peter.maydell@linaro.org> - 2015-11-22 14:40 +0100
                Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 20:30 +0100
                  Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-22 20:40 +0100
                  Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-22 20:50 +0100
                    Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 21:00 +0100
                      Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-22 21:10 +0100
                        Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 21:40 +0100
                          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-22 21:50 +0100
                            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-22 22:20 +0100
                      Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Nicolas Pitre <nicolas.pitre@linaro.org> - 2015-11-23 03:40 +0100
                        Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 09:20 +0100
                          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv  library functions Christopher Covington <cov@codeaurora.org> - 2015-11-23 15:20 +0100
                            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 16:40 +0100
                              Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 21:40 +0100
                                Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 22:30 +0100
                                  Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-23 22:40 +0100
                                    Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-23 23:00 +0100
                                      Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 00:20 +0100
                                        Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 11:20 +0100
                                          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 13:20 +0100
                                            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 14:50 +0100
                                          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-25 03:00 +0100
                                            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-25 08:30 +0100
                                      Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 01:20 +0100
                                        Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 10:00 +0100
                                          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 11:40 +0100
                                            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 11:50 +0100
                                              Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 13:20 +0100
                                                Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 13:30 +0100
                                                  Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Måns Rullgård <mans@mansr.com> - 2015-11-24 15:10 +0100
                                                  Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 15:10 +0100
                                                Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 13:30 +0100
                                          Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 11:50 +0100
                                            Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Stephen Boyd <sboyd@codeaurora.org> - 2015-11-24 21:10 +0100
                                              Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 21:40 +0100
                                                Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-24 22:20 +0100
                                        Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library  functions Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-11-24 11:40 +0100
    Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann <arnd@arndb.de> - 2015-11-21 21:50 +0100

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#1274868

From	Peter Maydell <peter.maydell@linaro.org>
Date	2015-11-22 14:40 +0100
Message-ID	<qxD21-4nO-3@gated-at.bofh.it>
In reply to	#1274769

On 21 November 2015 at 23:21, Arnd Bergmann <arnd@arndb.de> wrote:
> Regarding PJ4, it's still unclear whether that has the same
> problem and it only reports idivt when it actually supports idiva,
> or whether the lack of idiva support on PJ4 is instead the reason
> why the ARM ARM was updated to have separate flags.

SDIV/IDIV were originally introduced for R and M profile only
and there the Thumb encodings of SDIV/IDIV are mandatory
whereas the ARM ones are optional (and weren't initially
defined at all). So if you're looking for CPUs with only the
Thumb encodings I would try checking older R profile cores
like the Cortex-R4.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274927

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-22 20:30 +0100
Message-ID	<qxIuK-88H-7@gated-at.bofh.it>
In reply to	#1274868

On Sunday 22 November 2015 13:29:29 Peter Maydell wrote:
> On 21 November 2015 at 23:21, Arnd Bergmann <arnd@arndb.de> wrote:
> > Regarding PJ4, it's still unclear whether that has the same
> > problem and it only reports idivt when it actually supports idiva,
> > or whether the lack of idiva support on PJ4 is instead the reason
> > why the ARM ARM was updated to have separate flags.
> 
> SDIV/IDIV were originally introduced for R and M profile only
> and there the Thumb encodings of SDIV/IDIV are mandatory
> whereas the ARM ones are optional (and weren't initially
> defined at all). So if you're looking for CPUs with only the
> Thumb encodings I would try checking older R profile cores
> like the Cortex-R4.

The question is really about Marvell Dove, MMP and Armada 370,
which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
and report idivt support but idiva.

There are a couple of explanations here:

a) Marvell really implemented only idivt but not idiva
   and reports it correctly, and the people from
   https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY
   just misinterpreted the flags

b) the dartlag.org folks are correct, and it supports neither
   idivt nor idiva, and the /proc/cpuinfo flag is just wrong
   and requires a fixup

c) like Krait, it actually implements both idiva and idivt but
   gets the reporting wrong.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274929

From	Måns Rullgård <mans@mansr.com>
Date	2015-11-22 20:40 +0100
Message-ID	<qxIEq-8c0-5@gated-at.bofh.it>
In reply to	#1274927

Arnd Bergmann <arnd@arndb.de> writes:

> On Sunday 22 November 2015 13:29:29 Peter Maydell wrote:
>> On 21 November 2015 at 23:21, Arnd Bergmann <arnd@arndb.de> wrote:
>> > Regarding PJ4, it's still unclear whether that has the same
>> > problem and it only reports idivt when it actually supports idiva,
>> > or whether the lack of idiva support on PJ4 is instead the reason
>> > why the ARM ARM was updated to have separate flags.
>> 
>> SDIV/IDIV were originally introduced for R and M profile only
>> and there the Thumb encodings of SDIV/IDIV are mandatory
>> whereas the ARM ones are optional (and weren't initially
>> defined at all). So if you're looking for CPUs with only the
>> Thumb encodings I would try checking older R profile cores
>> like the Cortex-R4.
>
> The question is really about Marvell Dove, MMP and Armada 370,
> which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> and report idivt support but idiva.
>
> There are a couple of explanations here:
>
> a) Marvell really implemented only idivt but not idiva
>    and reports it correctly, and the people from
>    https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY
>    just misinterpreted the flags
>
> b) the dartlag.org folks are correct, and it supports neither
>    idivt nor idiva, and the /proc/cpuinfo flag is just wrong
>    and requires a fixup
>
> c) like Krait, it actually implements both idiva and idivt but
>    gets the reporting wrong.

It's trivial to test for someone who has one.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274932 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Russell King - ARM Linux <linux@arm.linux.org.uk>
Date	2015-11-22 20:50 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qxIO5-8fj-5@gated-at.bofh.it>
In reply to	#1274927

On Sun, Nov 22, 2015 at 08:25:27PM +0100, Arnd Bergmann wrote:
> The question is really about Marvell Dove, MMP and Armada 370,
> which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> and report idivt support but idiva.

Well, it's pretty hard to test when binutils blocks your ability to
write assembly using the instructions.

root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -marm
/tmp/cc8WPQiB.s: Assembler messages:
/tmp/cc8WPQiB.s:32: Error: selected processor does not support ARM mode `udiv ip,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -mthumb
/tmp/ccRzgAlM.s: Assembler messages:
/tmp/ccRzgAlM.s:36: Error: selected processor does not support Thumb mode `udiv r6,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -mthumb
/tmp/cc1JYyFD.s: Assembler messages:
/tmp/cc1JYyFD.s:36: Error: selected processor does not support Thumb mode `udiv r6,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -marm
/tmp/ccEQbQpp.s: Assembler messages:
/tmp/ccEQbQpp.s:32: Error: selected processor does not support ARM mode `udiv ip,r5,r4'

That's binutils 2.24 and gcc 4.8.4 as found on Ubuntu 14.04.  I'm
sorry, but I don't have spare time to work out what the opcodes
would be.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274934

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-22 21:00 +0100
Message-ID	<qxIXM-8iK-13@gated-at.bofh.it>
In reply to	#1274932

On Sunday 22 November 2015 19:47:05 Russell King - ARM Linux wrote:
> On Sun, Nov 22, 2015 at 08:25:27PM +0100, Arnd Bergmann wrote:
> > The question is really about Marvell Dove, MMP and Armada 370,
> > which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> > and report idivt support but idiva.
> 
> Well, it's pretty hard to test when binutils blocks your ability to
> write assembly using the instructions.
> 
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -marm
> /tmp/cc8WPQiB.s: Assembler messages:
> /tmp/cc8WPQiB.s:32: Error: selected processor does not support ARM mode `udiv ip,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -mthumb
> /tmp/ccRzgAlM.s: Assembler messages:
> /tmp/ccRzgAlM.s:36: Error: selected processor does not support Thumb mode `udiv r6,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -mthumb
> /tmp/cc1JYyFD.s: Assembler messages:
> /tmp/cc1JYyFD.s:36: Error: selected processor does not support Thumb mode `udiv r6,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -marm
> /tmp/ccEQbQpp.s: Assembler messages:
> /tmp/ccEQbQpp.s:32: Error: selected processor does not support ARM mode `udiv ip,r5,r4'
> 
> That's binutils 2.24 and gcc 4.8.4 as found on Ubuntu 14.04.  I'm
> sorry, but I don't have spare time to work out what the opcodes
> would be.
> 

does it work with -mcpu=cortex-a15?  I've tried crosstool as versions
2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
all seem to behave as expected, failing with -mcpu=cortex-a9 and
marvell-pj4 but succeeding with -mcpu=cortex-a15 or marvell-pj4+idiv.

I've also found some /proc/cpuinfo output to cross-reference SoCs
to their core names.

		variant	part	revision	name		features
mmp2:		0	0x581	5		PJ4		idivt
dove:		0	0x581	5		PJ4		idivt
Armada 370	1	0x581	1		PJ4B		idivt
mmp3:		2	0x584	2		PJ4-MP		idiva idivt lpae
Armada XP	2	0x584	2		PJ4-MP		idiva idivt lpae
Berlin		2	0x584	2		PJ4-MP		idiva idivt lpae

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274937 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Russell King - ARM Linux <linux@arm.linux.org.uk>
Date	2015-11-22 21:10 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qxJ7r-9Y-5@gated-at.bofh.it>
In reply to	#1274934

On Sun, Nov 22, 2015 at 08:58:08PM +0100, Arnd Bergmann wrote:
> does it work with -mcpu=cortex-a15?  I've tried crosstool as versions
> 2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
> all seem to behave as expected, failing with -mcpu=cortex-a9 and
> marvell-pj4 but succeeding with -mcpu=cortex-a15 or marvell-pj4+idiv.

Appears not:

root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -marm
/tmp/ccSovg32.s: Assembler messages:
/tmp/ccSovg32.s:32: Error: selected processor does not support ARM mode `udiv ip,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -mthumb
/tmp/cchbT3EE.s: Assembler messages:
/tmp/cchbT3EE.s:36: Error: selected processor does not support Thumb mode `udiv r6,r5,r4'

Same without the +idiv.

> I've also found some /proc/cpuinfo output to cross-reference SoCs
> to their core names.
> 
> 		variant	part	revision	name		features
> mmp2:		0	0x581	5		PJ4		idivt
> dove:		0	0x581	5		PJ4		idivt

Yes, that agrees with my dove.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274943

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-22 21:40 +0100
Message-ID	<qxJAt-mn-13@gated-at.bofh.it>
In reply to	#1274937

[Multipart message — attachments visible in raw view] — view raw

On Sunday 22 November 2015 20:03:26 Russell King - ARM Linux wrote:
> On Sun, Nov 22, 2015 at 08:58:08PM +0100, Arnd Bergmann wrote:
> > does it work with -mcpu=cortex-a15?  I've tried crosstool as versions
> > 2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
> > all seem to behave as expected, failing with -mcpu=cortex-a9 and
> > marvell-pj4 but succeeding with -mcpu=cortex-a15 or marvell-pj4+idiv.
> 
> Appears not:
> 
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -marm
> /tmp/ccSovg32.s: Assembler messages:
> /tmp/ccSovg32.s:32: Error: selected processor does not support ARM mode `udiv ip,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -mthumb
> /tmp/cchbT3EE.s: Assembler messages:
> /tmp/cchbT3EE.s:36: Error: selected processor does not support Thumb mode `udiv r6,r5,r4'
> 
> Same without the +idiv.

I've attached files with those instructions, maybe that helps.

> > I've also found some /proc/cpuinfo output to cross-reference SoCs
> > to their core names.
> > 
> > 		variant	part	revision	name		features
> > mmp2:		0	0x581	5		PJ4		idivt
> > dove:		0	0x581	5		PJ4		idivt
> 
> Yes, that agrees with my dove.

ok.

arnd@wuerfel:/tmp$ cat idiv.c 
unsigned int udiv(unsigned int a, unsigned int b)
{
        return a / b;
}

int sdiv(int a, int b)
{
        return a / b;
}
arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c -o idiv-arm.o
arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o   

idiv-arm.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <udiv>:
   0:   fbb0 f0f1       udiv    r0, r0, r1
   4:   4770            bx      lr
   6:   bf00            nop

00000008 <sdiv>:
   8:   fb90 f0f1       sdiv    r0, r0, r1
   c:   4770            bx      lr
   e:   bf00            nop
arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c -o idiv-thumb.o -mthumb
arnd@wuerfel:/tmp$ objdump -dr idiv-thumb.o 

idiv-thumb.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <udiv>:
   0:   fbb0 f0f1       udiv    r0, r0, r1
   4:   4770            bx      lr
   6:   bf00            nop

00000008 <sdiv>:
   8:   fb90 f0f1       sdiv    r0, r0, r1
   c:   4770            bx      lr
   e:   bf00            nop


	Arnd

[toc] | [prev] | [next] | [standalone]

#1274951

From	Måns Rullgård <mans@mansr.com>
Date	2015-11-22 21:50 +0100
Message-ID	<qxJKa-qg-15@gated-at.bofh.it>
In reply to	#1274943

Arnd Bergmann <arnd@arndb.de> writes:

> arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c -o idiv-arm.o
> arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o   
>
> idiv-arm.o:     file format elf32-littlearm
>
> Disassembly of section .text:
>
> 00000000 <udiv>:
>    0:   fbb0 f0f1       udiv    r0, r0, r1
>    4:   4770            bx      lr
>    6:   bf00            nop
>
> 00000008 <sdiv>:
>    8:   fb90 f0f1       sdiv    r0, r0, r1
>    c:   4770            bx      lr
>    e:   bf00            nop

Your compiler seems to default to thumb so you should add -marm.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274957

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-22 22:20 +0100
Message-ID	<qxKdc-Rx-9@gated-at.bofh.it>
In reply to	#1274951

[Multipart message — attachments visible in raw view] — view raw

On Sunday 22 November 2015 20:39:54 Måns Rullgård wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c -o idiv-arm.o
> > arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o   
> >
> > idiv-arm.o:     file format elf32-littlearm
> >
> > Disassembly of section .text:
> >
> > 00000000 <udiv>:
> >    0:   fbb0 f0f1       udiv    r0, r0, r1
> >    4:   4770            bx      lr
> >    6:   bf00            nop
> >
> > 00000008 <sdiv>:
> >    8:   fb90 f0f1       sdiv    r0, r0, r1
> >    c:   4770            bx      lr
> >    e:   bf00            nop
> 
> Your compiler seems to default to thumb so you should add -marm.
> 

Sorry about that.

	Arnd

arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c -o idiv-arm.o -marm
arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o 

idiv-arm.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <udiv>:
   0:   e730f110        udiv    r0, r0, r1
   4:   e12fff1e        bx      lr

00000008 <sdiv>:
   8:   e710f110        sdiv    r0, r0, r1
   c:   e12fff1e        bx      lr

[toc] | [prev] | [next] | [standalone]

#1275015 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Nicolas Pitre <nicolas.pitre@linaro.org>
Date	2015-11-23 03:40 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qxPcR-3ZO-1@gated-at.bofh.it>
In reply to	#1274934

On Sun, 22 Nov 2015, Arnd Bergmann wrote:

> I've also found some /proc/cpuinfo output to cross-reference SoCs
> to their core names.
> 
> 		variant	part	revision	name		features
> dove:		0	0x581	5		PJ4		idivt

I just managed to boot my dusty Dove DB and ran a quick test programon 
it. Its cpuinfo corresponds to the above.

$ cat m.c
#include <stdio.h>
int mydiv(int, int);
int main()
{
        printf("div test\n");
        printf("%d\n", mydiv(12345678, 37));
        return 0;
}
$ cat d.c
int mydiv(int x, int y)
{
        return x/y;
}
$ gcc -o test m.c d.c
$ ./test
div test
333666
$ gcc -o test m.c d.c -march=armv7ve -mthumb
$ ./test
div test
333666
$ gcc -o test m.c d.c -march=armv7ve -marm
$ ./test
div test
Illegal instruction (core dumped)
$


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275106

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-23 09:20 +0100
Message-ID	<qxUvV-7DO-17@gated-at.bofh.it>
In reply to	#1275015

On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote:
> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
> 
> > I've also found some /proc/cpuinfo output to cross-reference SoCs
> > to their core names.
> > 
> >               variant part    revision        name            features
> > dove:         0       0x581   5               PJ4             idivt
> 
> I just managed to boot my dusty Dove DB and ran a quick test programon 
> it. Its cpuinfo corresponds to the above.
> 
> $ cat m.c
> #include <stdio.h>
> int mydiv(int, int);
> int main()
> {
>         printf("div test\n");
>         printf("%d\n", mydiv(12345678, 37));
>         return 0;
> }
> $ cat d.c
> int mydiv(int x, int y)
> {
>         return x/y;
> }
> $ gcc -o test m.c d.c
> $ ./test
> div test
> 333666
> $ gcc -o test m.c d.c -march=armv7ve -mthumb
> $ ./test
> div test
> 333666
> $ gcc -o test m.c d.c -march=armv7ve -marm
> $ ./test
> div test
> Illegal instruction (core dumped)
> $

Ok, thanks a lot! So the reporting in /proc/cpuinfo clearly matches
the actual features, and we can just treat this as no LPAE / no IDIV
for kernel compilation, as nobody ever seems to use THUMB2_KERNEL
in practice.

PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
which leaves the question whether Scorpion or Krait do the same as
well, or whether they are outliers and need a special configuration.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275418 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Christopher Covington <cov@codeaurora.org>
Date	2015-11-23 15:20 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qy08i-2R4-15@gated-at.bofh.it>
In reply to	#1275106

On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote:
>> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
>>
>>> I've also found some /proc/cpuinfo output to cross-reference SoCs
>>> to their core names.
>>>
>>>               variant part    revision        name            features
>>> dove:         0       0x581   5               PJ4             idivt
>>
>> I just managed to boot my dusty Dove DB and ran a quick test programon 
>> it. Its cpuinfo corresponds to the above.
>>
>> $ cat m.c
>> #include <stdio.h>
>> int mydiv(int, int);
>> int main()
>> {
>>         printf("div test\n");
>>         printf("%d\n", mydiv(12345678, 37));
>>         return 0;
>> }
>> $ cat d.c
>> int mydiv(int x, int y)
>> {
>>         return x/y;
>> }
>> $ gcc -o test m.c d.c
>> $ ./test
>> div test
>> 333666
>> $ gcc -o test m.c d.c -march=armv7ve -mthumb
>> $ ./test
>> div test
>> 333666
>> $ gcc -o test m.c d.c -march=armv7ve -marm
>> $ ./test
>> div test
>> Illegal instruction (core dumped)
>> $
> 
> Ok, thanks a lot! So the reporting in /proc/cpuinfo clearly matches
> the actual features, and we can just treat this as no LPAE / no IDIV
> for kernel compilation, as nobody ever seems to use THUMB2_KERNEL
> in practice.
> 
> PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
> which leaves the question whether Scorpion or Krait do the same as
> well, or whether they are outliers and need a special configuration.

LPAE is only supported in the Krait 450.

http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more

I'm pretty sure idiv support came earlier, but I don't have the
specifics on hand.

Regards,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275490

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-23 16:40 +0100
Message-ID	<qy1nH-3Ia-1@gated-at.bofh.it>
In reply to	#1275418

On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote:
> >> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
> > 
> > Ok, thanks a lot! So the reporting in /proc/cpuinfo clearly matches
> > the actual features, and we can just treat this as no LPAE / no IDIV
> > for kernel compilation, as nobody ever seems to use THUMB2_KERNEL
> > in practice.
> > 
> > PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
> > which leaves the question whether Scorpion or Krait do the same as
> > well, or whether they are outliers and need a special configuration.
> 
> LPAE is only supported in the Krait 450.
> 
> http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> 
> I'm pretty sure idiv support came earlier, but I don't have the
> specifics on hand.

I have seen that article, but didn't trust it as a canonical
source of information here.

If you can confirm that it's right, that would mean that we
don't support LPAE on mach-qcom, as the only SoC with Krait 450
seems to be APQ8084, and mainline Linux doesn't run on that.

The ones we do support are MSM8x60 (Scorpion), MSM8960
(Krait-without-number),and MSM7874 (Krait 400). Do those all
support IDIV but not LPAE?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275833 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Stephen Boyd <sboyd@codeaurora.org>
Date	2015-11-23 21:40 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qy641-6NZ-5@gated-at.bofh.it>
In reply to	#1275490

On 11/23, Arnd Bergmann wrote:
> On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> > On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > > On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote:
> > >> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
> > > 
> > > Ok, thanks a lot! So the reporting in /proc/cpuinfo clearly matches
> > > the actual features, and we can just treat this as no LPAE / no IDIV
> > > for kernel compilation, as nobody ever seems to use THUMB2_KERNEL
> > > in practice.
> > > 
> > > PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
> > > which leaves the question whether Scorpion or Krait do the same as
> > > well, or whether they are outliers and need a special configuration.
> > 
> > LPAE is only supported in the Krait 450.
> > 
> > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> > 
> > I'm pretty sure idiv support came earlier, but I don't have the
> > specifics on hand.
> 
> I have seen that article, but didn't trust it as a canonical
> source of information here.
> 
> If you can confirm that it's right, that would mean that we
> don't support LPAE on mach-qcom, as the only SoC with Krait 450
> seems to be APQ8084, and mainline Linux doesn't run on that.

arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline
kernel. We support more than what's in the Kconfig language
under mach-qcom. And yes LPAE is supported by apq8084 (as is
IDIV). Here's the /proc/cpuinfo on that device.

# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0x06f
CPU revision    : 1

processor       : 1
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0x06f
CPU revision    : 1

processor       : 2
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0x06f
CPU revision    : 1

processor       : 3
model name      : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0x06f
CPU revision    : 1

Hardware        : Qualcomm (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

> 
> The ones we do support are MSM8x60 (Scorpion), MSM8960
> (Krait-without-number),and MSM7874 (Krait 400). Do those all
> support IDIV but not LPAE?
> 

Krait supports IDIV for all versions. Scorpion doesn't support
IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 

# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 13.50
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0x02d
CPU revision    : 2

processor       : 1
model name      : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 13.50
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0x02d
CPU revision    : 2

Hardware        : Qualcomm (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275866

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-23 22:30 +0100
Message-ID	<qy6Qq-7lC-21@gated-at.bofh.it>
In reply to	#1275833

On Monday 23 November 2015 12:38:47 Stephen Boyd wrote:
> On 11/23, Arnd Bergmann wrote:
> > On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> > > On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > > LPAE is only supported in the Krait 450.
> > > 
> > > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> > > 
> > > I'm pretty sure idiv support came earlier, but I don't have the
> > > specifics on hand.
> > 
> > I have seen that article, but didn't trust it as a canonical
> > source of information here.
> > 
> > If you can confirm that it's right, that would mean that we
> > don't support LPAE on mach-qcom, as the only SoC with Krait 450
> > seems to be APQ8084, and mainline Linux doesn't run on that.
> 
> arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline
> kernel. We support more than what's in the Kconfig language
> under mach-qcom.

Ok, cool. I'm sometimes confused by the model numbers, could you
do a separate patch to update the Kconfig help text?

> And yes LPAE is supported by apq8084 (as is
> IDIV). Here's the /proc/cpuinfo on that device.
> # cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 1 (v7l)
> BogoMIPS        : 38.40
> Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

Ok.

> > The ones we do support are MSM8x60 (Scorpion), MSM8960
> > (Krait-without-number),and MSM7874 (Krait 400). Do those all
> > support IDIV but not LPAE?
> > 
> 
> Krait supports IDIV for all versions. Scorpion doesn't support
> IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 
> 
> # cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 2 (v7l)
> BogoMIPS        : 13.50
> Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> CPU implementer : 0x51
> CPU architecture: 7
> CPU variant     : 0x0
> CPU part        : 0x02d
> CPU revision    : 2

Ok, that leaves just one missing puzzle piece: can you confirm that
no supported Krait variant other than Krait 450 / apq8084 has LPAE?

	Arnd 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275868 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Stephen Boyd <sboyd@codeaurora.org>
Date	2015-11-23 22:40 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qy705-7p3-1@gated-at.bofh.it>
In reply to	#1275866

On 11/23, Arnd Bergmann wrote:
> On Monday 23 November 2015 12:38:47 Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > > On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> > > > On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > > > LPAE is only supported in the Krait 450.
> > > > 
> > > > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> > > > 
> > > > I'm pretty sure idiv support came earlier, but I don't have the
> > > > specifics on hand.
> > > 
> > > I have seen that article, but didn't trust it as a canonical
> > > source of information here.
> > > 
> > > If you can confirm that it's right, that would mean that we
> > > don't support LPAE on mach-qcom, as the only SoC with Krait 450
> > > seems to be APQ8084, and mainline Linux doesn't run on that.
> > 
> > arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline
> > kernel. We support more than what's in the Kconfig language
> > under mach-qcom.
> 
> Ok, cool. I'm sometimes confused by the model numbers, could you
> do a separate patch to update the Kconfig help text?

What did you have in mind? I'm also confused by the model numbers
so I don't know how helpful I will be.

It would be nice to drop the ARCH_MSM* configs entirely. If we
could select the right timers from kconfig without using selects
then we could drop them. Or we could just select both types of
timers when building qcom platforms.

> 
> > > The ones we do support are MSM8x60 (Scorpion), MSM8960
> > > (Krait-without-number),and MSM7874 (Krait 400). Do those all
> > > support IDIV but not LPAE?
> > > 
> > 
> > Krait supports IDIV for all versions. Scorpion doesn't support
> > IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 
> > 
> > # cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 2 (v7l)
> > BogoMIPS        : 13.50
> > Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> > CPU implementer : 0x51
> > CPU architecture: 7
> > CPU variant     : 0x0
> > CPU part        : 0x02d
> > CPU revision    : 2
> 
> Ok, that leaves just one missing puzzle piece: can you confirm that
> no supported Krait variant other than Krait 450 / apq8084 has LPAE?
> 

Right, apq8084 is the only SoC with a Krait CPU that supports
LPAE.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275898

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-23 23:00 +0100
Message-ID	<qy7jr-7vZ-1@gated-at.bofh.it>
In reply to	#1275868

On Monday 23 November 2015 13:32:06 Stephen Boyd wrote:
> On 11/23, Arnd Bergmann wrote:
> > On Monday 23 November 2015 12:38:47 Stephen Boyd wrote:
> > > On 11/23, Arnd Bergmann wrote:
> > > > On Monday 23 November 2015 09:14:39 Christopher Covington wrote:
> > > > > On 11/23/2015 03:15 AM, Arnd Bergmann wrote:
> > > > > LPAE is only supported in the Krait 450.
> > > > > 
> > > > > http://www.anandtech.com/show/7537/qualcomms-snapdragon-805-25ghz-128bit-memory-interface-d3d11class-graphics-more
> > > > > 
> > > > > I'm pretty sure idiv support came earlier, but I don't have the
> > > > > specifics on hand.
> > > > 
> > > > I have seen that article, but didn't trust it as a canonical
> > > > source of information here.
> > > > 
> > > > If you can confirm that it's right, that would mean that we
> > > > don't support LPAE on mach-qcom, as the only SoC with Krait 450
> > > > seems to be APQ8084, and mainline Linux doesn't run on that.
> > > 
> > > arch/arm/boot/dts/qcom-apq8084.dtsi exists in the mainline
> > > kernel. We support more than what's in the Kconfig language
> > > under mach-qcom.
> > 
> > Ok, cool. I'm sometimes confused by the model numbers, could you
> > do a separate patch to update the Kconfig help text?
> 
> What did you have in mind? I'm also confused by the model numbers
> so I don't know how helpful I will be.
> 
> It would be nice to drop the ARCH_MSM* configs entirely. If we
> could select the right timers from kconfig without using selects
> then we could drop them. Or we could just select both types of
> timers when building qcom platforms.

Ok, dropping the specific Kconfig entries is actually an awesome
idea, as it completely solves the other problem as well, more on
that below.

In that case, don't worry about listing all the models, once
we stop listing a subset of them, the confusion is already
reduced by the fact that one has to look at the .dts files
so see which models we support, and I assume there will be
additional ones coming in for at least a few more years (before
you stop caring about 32-bit MSM and compatibles).

Regarding the timers:
HAVE_ARM_ARCH_TIMER is already user-selectable, so maybe something
like

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index b251013eef0a..bad6343c34d5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -324,8 +324,9 @@ config EM_TIMER_STI
 	  such as EMEV2 from former NEC Electronics.
 
 config CLKSRC_QCOM
-	bool "Qualcomm MSM timer" if COMPILE_TEST
+	bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
 	depends on ARM
+	default ARCH_QCOM
 	select CLKSRC_OF
 	help
 	  This enables the clocksource and the per CPU clockevent driver for the

would make both of them equally configurable and not clutter up
the Kconfig file when ARCH_QCOM is not selected. I've added
Daniel Lezcano to Cc, he probably has an opinion on this too.

> > > > The ones we do support are MSM8x60 (Scorpion), MSM8960
> > > > (Krait-without-number),and MSM7874 (Krait 400). Do those all
> > > > support IDIV but not LPAE?
> > > > 
> > > 
> > > Krait supports IDIV for all versions. Scorpion doesn't support
> > > IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 
> > > 
> > > # cat /proc/cpuinfo
> > > processor       : 0
> > > model name      : ARMv7 Processor rev 2 (v7l)
> > > BogoMIPS        : 13.50
> > > Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> > > CPU implementer : 0x51
> > > CPU architecture: 7
> > > CPU variant     : 0x0
> > > CPU part        : 0x02d
> > > CPU revision    : 2
> > 
> > Ok, that leaves just one missing puzzle piece: can you confirm that
> > no supported Krait variant other than Krait 450 / apq8084 has LPAE?
> > 
> 
> Right, apq8084 is the only SoC with a Krait CPU that supports
> LPAE.

Ok, thanks for the confirmation.

Summarizing what we've found, I think we can get away with just
introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
Most CPUs fall clearly into one category or the other, and then
we can allow LPAE to be selected for V7VE-only build but not
for plain V7, and we can unconditionally build the kernel with

arch-$(CONFIG_CPU_32v7VE)  = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15)

This works perfectly for Cortex-A5, -A8, -A9, -A12, -A15, -A17, Brahma-B15,
PJ4B-MP, Scorpion and Krait-450, which all clearly fall into one of
the two other categories.

The two exceptions that don't quite fit are still "good enough":

- PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
  in ARM mode. We don't support that with true multiplatform kernels
  because those opcodes work nowhere else, though with your proposed
  series we could easily do that for dynamic patching.

- Krait (pre-450) won't run kernels with LPAE disabled, but if we only
  have one global ARCH_QCOM option that can be enabled for both
  ARCH_MULTI_V7VE and ARCH_MULTI_V7, we still win: a mach-qcom
  kernel with only ARCH_MULTI_V7VE will use IDIV by default, and
  give you the option to enable LPAE. If you pick LPAE, it will
  still work fine on Krait-450 but not the older ones, and that is
  a user error. If you enable ARCH_MULTI_V7 / CPU_V7, you get neither
  LPAE nor IDIV, and the kernel will be able to run on both Scorpion
  and Krait, as long as you have the right drivers too.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275954 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

From	Stephen Boyd <sboyd@codeaurora.org>
Date	2015-11-24 00:20 +0100
Subject	Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Message-ID	<qy8yR-8vh-7@gated-at.bofh.it>
In reply to	#1275898

On 11/23, Arnd Bergmann wrote:
> On Monday 23 November 2015 13:32:06 Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > > On Monday 23 November 2015 12:38:47 Stephen Boyd wrote:
> > 
> > It would be nice to drop the ARCH_MSM* configs entirely. If we
> > could select the right timers from kconfig without using selects
> > then we could drop them. Or we could just select both types of
> > timers when building qcom platforms.
> 
> Ok, dropping the specific Kconfig entries is actually an awesome
> idea, as it completely solves the other problem as well, more on
> that below.
> 
> In that case, don't worry about listing all the models, once
> we stop listing a subset of them, the confusion is already
> reduced by the fact that one has to look at the .dts files
> so see which models we support, and I assume there will be
> additional ones coming in for at least a few more years (before
> you stop caring about 32-bit MSM and compatibles).
> 
> Regarding the timers:
> HAVE_ARM_ARCH_TIMER is already user-selectable, so maybe something
> like

> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index b251013eef0a..bad6343c34d5 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -324,8 +324,9 @@ config EM_TIMER_STI
>  	  such as EMEV2 from former NEC Electronics.
>  
>  config CLKSRC_QCOM
> -	bool "Qualcomm MSM timer" if COMPILE_TEST
> +	bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
>  	depends on ARM
> +	default ARCH_QCOM
>  	select CLKSRC_OF
>  	help
>  	  This enables the clocksource and the per CPU clockevent driver for the
> 
> would make both of them equally configurable and not clutter up
> the Kconfig file when ARCH_QCOM is not selected. I've added
> Daniel Lezcano to Cc, he probably has an opinion on this too.

Yeah I think that architected timers are an outlier. I recall
some words from John Stultz that platforms should select the
clocksources they use, but maybe things have changed. For this
kind of thing I wouldn't mind putting it in the defconfig though.
I'll put the patches on the list to get the discussion started.

> 
> > > > > The ones we do support are MSM8x60 (Scorpion), MSM8960
> > > > > (Krait-without-number),and MSM7874 (Krait 400). Do those all
> > > > > support IDIV but not LPAE?
> > > > > 
> > > > 
> > > > Krait supports IDIV for all versions. Scorpion doesn't support
> > > > IDIV or lpae. Here's the output of /proc/cpuinfo on that device. 
> > > > 
> > > > # cat /proc/cpuinfo
> > > > processor       : 0
> > > > model name      : ARMv7 Processor rev 2 (v7l)
> > > > BogoMIPS        : 13.50
> > > > Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> > > > CPU implementer : 0x51
> > > > CPU architecture: 7
> > > > CPU variant     : 0x0
> > > > CPU part        : 0x02d
> > > > CPU revision    : 2
> > > 
> > > Ok, that leaves just one missing puzzle piece: can you confirm that
> > > no supported Krait variant other than Krait 450 / apq8084 has LPAE?
> > > 
> > 
> > Right, apq8084 is the only SoC with a Krait CPU that supports
> > LPAE.
> 
> Ok, thanks for the confirmation.
> 
> Summarizing what we've found, I think we can get away with just
> introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
> Most CPUs fall clearly into one category or the other, and then
> we can allow LPAE to be selected for V7VE-only build but not
> for plain V7, and we can unconditionally build the kernel with
> 
> arch-$(CONFIG_CPU_32v7VE)  = -D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7ve,-march=armv7-a -mcpu=cortex-a15)
> 
> This works perfectly for Cortex-A5, -A8, -A9, -A12, -A15, -A17, Brahma-B15,
> PJ4B-MP, Scorpion and Krait-450, which all clearly fall into one of
> the two other categories.
> 
> The two exceptions that don't quite fit are still "good enough":
> 
> - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
>   in ARM mode. We don't support that with true multiplatform kernels
>   because those opcodes work nowhere else, though with your proposed
>   series we could easily do that for dynamic patching.

Do you have the information on these custom opcodes? I can work
that into the patches assuming the MIDR is different.

> 
> - Krait (pre-450) won't run kernels with LPAE disabled, but if we only
>   have one global ARCH_QCOM option that can be enabled for both
>   ARCH_MULTI_V7VE and ARCH_MULTI_V7, we still win: a mach-qcom
>   kernel with only ARCH_MULTI_V7VE will use IDIV by default, and
>   give you the option to enable LPAE. If you pick LPAE, it will
>   still work fine on Krait-450 but not the older ones, and that is
>   a user error. If you enable ARCH_MULTI_V7 / CPU_V7, you get neither
>   LPAE nor IDIV, and the kernel will be able to run on both Scorpion
>   and Krait, as long as you have the right drivers too.
> 

So if I have built mach-qcom with ARCH_MULTI_V7VE won't I get a
kernel that uses idiv instructions that could be run on Scorpion,
where the instruction doesn't exist? Or is that a user error
again like picking LPAE?

It seems fine to me to go ahead with this approach. Should I take
care of cooking up the patches? I can package this all up into a
series that adds the new CPU type, updates the affected
platforms, and layers the runtime patching on top when plain V7
is a selected CPU type.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276264

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-11-24 11:20 +0100
Message-ID	<qyiRA-6MT-1@gated-at.bofh.it>
In reply to	#1275954

On Monday 23 November 2015 15:13:52 Stephen Boyd wrote:
> On 11/23, Arnd Bergmann wrote:
> > On Monday 23 November 2015 13:32:06 Stephen Boyd wrote:
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index b251013eef0a..bad6343c34d5 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -324,8 +324,9 @@ config EM_TIMER_STI
> >  	  such as EMEV2 from former NEC Electronics.
> >  
> >  config CLKSRC_QCOM
> > -	bool "Qualcomm MSM timer" if COMPILE_TEST
> > +	bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
> >  	depends on ARM
> > +	default ARCH_QCOM
> >  	select CLKSRC_OF
> >  	help
> >  	  This enables the clocksource and the per CPU clockevent driver for the
> > 
> > would make both of them equally configurable and not clutter up
> > the Kconfig file when ARCH_QCOM is not selected. I've added
> > Daniel Lezcano to Cc, he probably has an opinion on this too.
> 
> Yeah I think that architected timers are an outlier. I recall
> some words from John Stultz that platforms should select the
> clocksources they use, but maybe things have changed. For this
> kind of thing I wouldn't mind putting it in the defconfig though.
> I'll put the patches on the list to get the discussion started.

Ok, thanks!
 
> > This works perfectly for Cortex-A5, -A8, -A9, -A12, -A15, -A17, Brahma-B15,
> > PJ4B-MP, Scorpion and Krait-450, which all clearly fall into one of
> > the two other categories.
> > 
> > The two exceptions that don't quite fit are still "good enough":
> > 
> > - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
> >   in ARM mode. We don't support that with true multiplatform kernels
> >   because those opcodes work nowhere else, though with your proposed
> >   series we could easily do that for dynamic patching.
> 
> Do you have the information on these custom opcodes? I can work
> that into the patches assuming the MIDR is different.

Thomas Petazzoni said this in a private mail:

| According to the datasheet, the PJ4B has integer signed and unsigned
| divide, similar to the sdiv and udiv ARM instructions. But the way to
| access it is by doing a MRC instruction.
|
|    MRC<cond> p6, 1, Rd , CRn , CRm, 4
|
|for PJ4B is the same as:
|
|    SDIV Rd , Rn, Rm
|
| on ARM cores.
|
|And:
|
|    MRC<cond> p6, 1, Rd , CRn , CRm, 0
|
|for PJ4B is the same as:
|
|    UDIV Rd , Rn, Rm
|
|on ARM cores.
|
|This is documented in the "Extended instructions" section of the
|PJ4B datasheet.

I assume what he meant was that this is true for both PJ4 and PJ4B
but not for PJ4B-MP, which has the normal udiv/sdiv instructions.

IOW, anything with CPU implementer 0x56 part 0x581 should use those,
while part 0x584 can use the sdiv/udiv that it reports correctly.

> > - Krait (pre-450) won't run kernels with LPAE disabled, but if we only
> >   have one global ARCH_QCOM option that can be enabled for both
> >   ARCH_MULTI_V7VE and ARCH_MULTI_V7, we still win: a mach-qcom
> >   kernel with only ARCH_MULTI_V7VE will use IDIV by default, and
> >   give you the option to enable LPAE. If you pick LPAE, it will
> >   still work fine on Krait-450 but not the older ones, and that is
> >   a user error. If you enable ARCH_MULTI_V7 / CPU_V7, you get neither
> >   LPAE nor IDIV, and the kernel will be able to run on both Scorpion
> >   and Krait, as long as you have the right drivers too.
> > 
> 
> So if I have built mach-qcom with ARCH_MULTI_V7VE won't I get a
> kernel that uses idiv instructions that could be run on Scorpion,
> where the instruction doesn't exist? Or is that a user error
> again like picking LPAE?

Right. If you want to run on Scorpion, you have to select ARCH_MULTI_V7.
If both are set, we should build with -march=armv7-a and not use
the idiv instructions.
 
> It seems fine to me to go ahead with this approach. Should I take
> care of cooking up the patches? I can package this all up into a
> series that adds the new CPU type, updates the affected
> platforms, and layers the runtime patching on top when plain V7
> is a selected CPU type.

That would be nice, yes.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276379

From	Måns Rullgård <mans@mansr.com>
Date	2015-11-24 13:20 +0100
Message-ID	<qykJI-7YL-33@gated-at.bofh.it>
In reply to	#1276264

Arnd Bergmann <arnd@arndb.de> writes:

> On Monday 23 November 2015 15:13:52 Stephen Boyd wrote:
>> On 11/23, Arnd Bergmann wrote:
>> > On Monday 23 November 2015 13:32:06 Stephen Boyd wrote:
>> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> > index b251013eef0a..bad6343c34d5 100644
>> > --- a/drivers/clocksource/Kconfig
>> > +++ b/drivers/clocksource/Kconfig
>> > @@ -324,8 +324,9 @@ config EM_TIMER_STI
>> >  	  such as EMEV2 from former NEC Electronics.
>> >  
>> >  config CLKSRC_QCOM
>> > -	bool "Qualcomm MSM timer" if COMPILE_TEST
>> > +	bool "Qualcomm MSM timer" if ARCH_QCOM || COMPILE_TEST
>> >  	depends on ARM
>> > +	default ARCH_QCOM
>> >  	select CLKSRC_OF
>> >  	help
>> >  	  This enables the clocksource and the per CPU clockevent driver for the
>> > 
>> > would make both of them equally configurable and not clutter up
>> > the Kconfig file when ARCH_QCOM is not selected. I've added
>> > Daniel Lezcano to Cc, he probably has an opinion on this too.
>> 
>> Yeah I think that architected timers are an outlier. I recall
>> some words from John Stultz that platforms should select the
>> clocksources they use, but maybe things have changed. For this
>> kind of thing I wouldn't mind putting it in the defconfig though.
>> I'll put the patches on the list to get the discussion started.
>
> Ok, thanks!
>
>> > This works perfectly for Cortex-A5, -A8, -A9, -A12, -A15, -A17, Brahma-B15,
>> > PJ4B-MP, Scorpion and Krait-450, which all clearly fall into one of
>> > the two other categories.
>> > 
>> > The two exceptions that don't quite fit are still "good enough":
>> > 
>> > - PJ4/PJ4B (not PJ4B-MP) has a different custom opcode for udiv and sdiv
>> >   in ARM mode. We don't support that with true multiplatform kernels
>> >   because those opcodes work nowhere else, though with your proposed
>> >   series we could easily do that for dynamic patching.
>> 
>> Do you have the information on these custom opcodes? I can work
>> that into the patches assuming the MIDR is different.
>
> Thomas Petazzoni said this in a private mail:
>
> | According to the datasheet, the PJ4B has integer signed and unsigned
> | divide, similar to the sdiv and udiv ARM instructions. But the way to
> | access it is by doing a MRC instruction.
> |
> |    MRC<cond> p6, 1, Rd , CRn , CRm, 4
> |
> |for PJ4B is the same as:
> |
> |    SDIV Rd , Rn, Rm
> |
> | on ARM cores.
> |
> |And:
> |
> |    MRC<cond> p6, 1, Rd , CRn , CRm, 0
> |
> |for PJ4B is the same as:
> |
> |    UDIV Rd , Rn, Rm
> |
> |on ARM cores.
> |
> |This is documented in the "Extended instructions" section of the
> |PJ4B datasheet.
>
> I assume what he meant was that this is true for both PJ4 and PJ4B
> but not for PJ4B-MP, which has the normal udiv/sdiv instructions.
>
> IOW, anything with CPU implementer 0x56 part 0x581 should use those,
> while part 0x584 can use the sdiv/udiv that it reports correctly.

Or we could simply ignore those and they'd be no worse off than they are
now.

-- 
Måns Rullgård
mans@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

[RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

Contents

#1274868

#1274927

#1274929

#1274932 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1274934

#1274937 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1274943

#1274951

#1274957

#1275015 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1275106

#1275418 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1275490

#1275833 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1275866

#1275868 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1275898

#1275954 — Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

#1276264

#1276379