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 t
On Tue, Feb 8, 2011 at 4:58 PM, Arnd Bergmann 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 += -march=ar
On Tue, Feb 8, 2011 at 4:55 PM, Russell King - ARM Linux
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 doesn't work
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 wh
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 nei
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 abs
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
On Tue, Feb 8, 2011 at 4:25 PM, 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 abstractio
On Tue, Feb 8, 2011 at 4:20 PM, Russell King - ARM Linux
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 supported.
>
> Yes we
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 3:42 PM, Arnd Bergmann 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 not
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.
T
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 fla
On Tue, Feb 8, 2011 at 3:15 PM, Arnd Bergmann 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 __LINUX_A
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 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
On Tue, Feb 8, 2011 at 2:54 PM, Santosh Shilimkar
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 -march= flags, an
limkar; linux-
> o...@vger.kernel.org; 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 al
On Tue, Feb 8, 2011 at 12:53 PM, Arnd Bergmann 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.
>>
>>
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
o...@vger.kernel.org; Jean 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 defini
> > 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 kerne
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.
> > >
> > > Do
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 t
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 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
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
---
-
27 matches
Mail list logo
