On Tuesday 08 February 2011, Dave Martin wrote:
I have a (possibly silly) question ... are the definitions in
arm/system.h intended to be fully generic, or not? Some features
suggest an attempt at genericness, but not everything there is
generic. Maybe I have misconstrued the purpose of this
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6, wfi() is not defined. If needed, some CPU-
specific wfi() will have to be defined elsewhere.
Signed-off-by: Dave Martin
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6, wfi() is not defined. If needed, some CPU-
specific wfi() will have
On Tue, Feb 08, 2011 at 11:08:08AM +, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op instead of wfi() is probably bad, so for older
processors than v6,
On Tue, Feb 08, 2011 at 01:11:51PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
Doing a no-op
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
[...]
On Tue, Feb 08, 2011 at 01:11:51PM +0100, Arnd Bergmann wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so
Pihet
Subject: Re: [PATCH v2] ARM: Define wfi() macro for v6 processors
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
For v6, wfi is architected as a defined MCR instruction, so
use that definition.
[...]
On Tue, Feb 08, 2011 at 01:11:51PM +0100, Arnd Bergmann wrote:
I
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so removing them seems like a good strategy to avoid people from
using them incorrectly.
That's because they've only just been added. See the massive
On Tue, Feb 8, 2011 at 12:53 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
I don't see any users of the sev/wfe/wfi macros in the current kernel,
so removing them seems like a good strategy to avoid people from
using them incorrectly.
; Jean Pihet
Subject: Re: [PATCH v2] ARM: Define wfi() macro for v6 processors
[]
For (2), I think the best approach is to use the actual wfi
instruction and build the affected files with the appropriate -
march=
flag (omap already does that) - since those CPU-specific files
should
On Tue, Feb 8, 2011 at 2:54 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Dave,
-Original Message-
From: Dave Martin [mailto:dave.mar...@linaro.org]
[...]
I don't like the practice of pre-assembling bits of code with .long,
in order to allow a file to be built with wrong
On Tuesday 08 February 2011, Dave Martin wrote:
I guess there are two problems we're trying to solve here:
1) a lowest-common denominator implementation of things like wfi(),
for use in common code. This must be based on __LINUX_ARM_ARCH__
(which IIUC gives the lowest arch supported by all
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code from that file
could ever get run on other processors. I'm not so sure of the answer
to that..., but perhaps someone else has a better
On Tue, Feb 8, 2011 at 3:15 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
I guess there are two problems we're trying to solve here:
1) a lowest-common denominator implementation of things like wfi(),
for use in common code. This must be based on
On Tuesday 08 February 2011, Dave Martin wrote:
Why not have macros for these cases? (Which kinda brings the
discussion full-circle...)
My immediate concern is that too often, the Thumb-2 case will be
handled incorrectly or not at all ... and the kernel will silently
build without flagging
On Tue, Feb 08, 2011 at 02:45:51PM +, Dave Martin wrote:
If support for a v6K processor is included, we have no way to know
from preprocessor definitions whether a plain v6 processor is also to
be supported.
Yes we do. See the v6 patches I've recently posted to various mailing
lists.
On Tue, Feb 8, 2011 at 3:42 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
Why not have macros for these cases? (Which kinda brings the
discussion full-circle...)
My immediate concern is that too often, the Thumb-2 case will be
handled incorrectly or
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same kind of abstraction that we have for a number of other things
like cache management in
On Tue, Feb 8, 2011 at 4:20 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 08, 2011 at 02:45:51PM +, Dave Martin wrote:
If support for a v6K processor is included, we have no way to know
from preprocessor definitions whether a plain v6 processor is also to
be
On Tue, Feb 8, 2011 at 4:25 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code from that file
could ever get run on other processors. I'm not so sure
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither form, right? I think to do that, it needs the
same kind of
On Tue, Feb 08, 2011 at 05:47:18PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that doesn't work if you build a combined v5/v6/v7 kernel, because
v5 supports neither
On Tuesday 08 February 2011 17:32:29 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o+= -march=armv7-a
Whether it's safe to do it depends on whether code
On Tue, Feb 8, 2011 at 4:55 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 08, 2011 at 05:47:18PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
But that
On Tue, Feb 8, 2011 at 4:58 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 08 February 2011 17:32:29 Russell King - ARM Linux wrote:
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
On Tuesday 08 February 2011, Dave Martin wrote:
CFLAGS_cpu_specific_object.o +=
27 matches
Mail list logo
