* linux-next: ide pmac.c fix
From: Stephen Rothwell @ 2008-02-18 13:53 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: ppc-dev, linux-next
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
Hi Bart,
the current linux-next produces this error for a pmac32 powerpc build:
drivers/ide/ppc/pmac.c:1094: error: conversion to non-scalar type requested
drivers/ide/ppc/pmac.c:1232: error: conversion to non-scalar type requested
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Adrian Bunk @ 2008-02-18 13:56 UTC (permalink / raw)
To: Michael Ellerman
Cc: Roel Kluin, lkml, cbe-oss-dev, linuxppc-dev, Willy Tarreau,
Arjan van de Ven
In-Reply-To: <1203249003.6718.24.camel@concordia>
On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
>...
> > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > than the coder in general. Same for most other architectures.
> >
> > unlikely() creates bigger code as well.
> >
> > Now... we're talking about your super duper hotpath function here right?
> > One where you care about 0.5 cycle speed improvement? (less on modern
> > systems ;)
>
> The first patch was to platforms/ps3 code, which runs on the Cell, in
> particular the PPE ... which is not an x86 :)
>
> eg:
>
> [michael@schoenaich ~]$ cat branch.c
> #include <stdio.h>
> int main(void)
> {
> int i, j;
>
> for (i = 0, j = 0; i < 1000000000; i++)
> if (i % 4 == 0)
> j++;
>
> printf("j = %d\n", j);
> return 0;
> }
> [michael@schoenaich ~]$ ppu-gcc -Wall -O3 -o branch branch.c
> [michael@schoenaich ~]$ time ./branch
> real 0m5.172s
>
> [michael@schoenaich ~]$ cat branch.c
> ..
> for (i = 0, j = 0; i < 1000000000; i++)
> if (__builtin_expect(i % 4 == 0, 0))
> j++;
> ..
> [michael@schoenaich ~]$ ppu-gcc -Wall -O3 -o branch branch.c
> [michael@schoenaich ~]$ time ./branch
> real 0m3.762s
>
>
> Which looks as though unlikely() is helping. Admittedly we don't have a
> lot of kernel code that looks like that, but at least unlikely is doing
> what we want it to.
This means it generates faster code with a current gcc for your platform.
But a future gcc might e.g. replace the whole loop with a division
(gcc SVN head (that will soon become gcc 4.3) already does
transformations like replacing loops with divisions [1]).
And your __builtin_expect() then might have unwanted effects on gcc.
Or the kernel code changes much but the likely/unlikely stays unchanged
although it becomes wrong.
If it is a real hotpath in the kernel where you have _measurable_
performance advantages from using likely/unlikely it's usage might be
justified, but otherwise it shouldn't be used.
> cheers
cu
Adrian
[1] e.g. the while() loop in timespec_add_ns() in include/linux/time.h
gets replaced by a division and a modulo (whether this
transformation is correct in this specific case is a different
question, but that's the level of code transformation gcc already
does today)
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Geert Uytterhoeven @ 2008-02-18 14:01 UTC (permalink / raw)
To: Adrian Bunk
Cc: Roel Kluin, lkml, cbe-oss-dev, linuxppc-dev, Willy Tarreau,
Arjan van de Ven
In-Reply-To: <20080218135609.GD21080@cs181133002.pp.htv.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2637 bytes --]
On Mon, 18 Feb 2008, Adrian Bunk wrote:
> On Sun, Feb 17, 2008 at 10:50:03PM +1100, Michael Ellerman wrote:
> > On Sat, 2008-02-16 at 10:39 -0800, Arjan van de Ven wrote:
> >...
> > > for mordern (last 10 years) x86 cpus... the cpu branchpredictor is better
> > > than the coder in general. Same for most other architectures.
> > >
> > > unlikely() creates bigger code as well.
> > >
> > > Now... we're talking about your super duper hotpath function here right?
> > > One where you care about 0.5 cycle speed improvement? (less on modern
> > > systems ;)
> >
> > The first patch was to platforms/ps3 code, which runs on the Cell, in
> > particular the PPE ... which is not an x86 :)
> >
> > eg:
> >
> > [michael@schoenaich ~]$ cat branch.c
> > #include <stdio.h>
> > int main(void)
> > {
> > int i, j;
> >
> > for (i = 0, j = 0; i < 1000000000; i++)
> > if (i % 4 == 0)
> > j++;
> >
> > printf("j = %d\n", j);
> > return 0;
> > }
> > [michael@schoenaich ~]$ ppu-gcc -Wall -O3 -o branch branch.c
> > [michael@schoenaich ~]$ time ./branch
> > real 0m5.172s
> >
> > [michael@schoenaich ~]$ cat branch.c
> > ..
> > for (i = 0, j = 0; i < 1000000000; i++)
> > if (__builtin_expect(i % 4 == 0, 0))
> > j++;
> > ..
> > [michael@schoenaich ~]$ ppu-gcc -Wall -O3 -o branch branch.c
> > [michael@schoenaich ~]$ time ./branch
> > real 0m3.762s
> >
> >
> > Which looks as though unlikely() is helping. Admittedly we don't have a
> > lot of kernel code that looks like that, but at least unlikely is doing
> > what we want it to.
>
> This means it generates faster code with a current gcc for your platform.
>
> But a future gcc might e.g. replace the whole loop with a division
> (gcc SVN head (that will soon become gcc 4.3) already does
> transformations like replacing loops with divisions [1]).
Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(),
if it doesn't live up to its promise?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH] next-20080218 build failure at pmac_ide_macio_attach ()
From: Kamalesh Babulal @ 2008-02-18 14:01 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-ide, sfr, linuxppc-dev
Hi,
The next-20080218 kernel build fails on the powerpc(s)
drivers/ide/ppc/pmac.c: In function ‘pmac_ide_macio_attach’:
drivers/ide/ppc/pmac.c:1094: error: conversion to non-scalar type requested
drivers/ide/ppc/pmac.c: In function ‘pmac_ide_pci_attach’:
drivers/ide/ppc/pmac.c:1232: error: conversion to non-scalar type requested
make[3]: *** [drivers/ide/ppc/pmac.o] Error 1
make[2]: *** [drivers/ide/ppc] Error 2
make[1]: *** [drivers/ide] Error 2
make: *** [drivers] Error 2
I Have tested this patch for build failure only.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
---
--- linux-2.6.25-rc1/drivers/ide/ppc/pmac.c 2008-02-18 18:41:48.000000000 +0530
+++ linux-2.6.25-rc1/drivers/ide/ppc/~pmac.c 2008-02-18 19:20:37.000000000 +0530
@@ -1091,7 +1091,7 @@ pmac_ide_macio_attach(struct macio_dev *
int irq, rc;
hw_regs_t hw;
- pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
+ pmif = (struct pmac_ide_hwif*)kzalloc(sizeof(*pmif), GFP_KERNEL);
if (pmif == NULL)
return -ENOMEM;
@@ -1229,7 +1229,7 @@ pmac_ide_pci_attach(struct pci_dev *pdev
return -ENODEV;
}
- pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
+ pmif = (struct pmac_ide_hwif*)kzalloc(sizeof(*pmif), GFP_KERNEL);
if (pmif == NULL)
return -ENOMEM;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Does anyone have a simple UIO driver that uses an interrupt handler?
From: Hans-Jürgen Koch @ 2008-02-18 13:09 UTC (permalink / raw)
To: ndroogh; +Cc: linuxppc-embedded
In-Reply-To: <47B8BF83.2070907@cadlink.com>
Am Sun, 17 Feb 2008 18:13:07 -0500
schrieb Nick Droogh <ndroogh@cadlink.com>:
> Hi everyone,
Hi Nick,
>
> I am looking for a driver example for a user space driver utilizing
> an interrupt handler. I am having trouble registering a handler in
> my driver attempt and would like to see an example of a working UIO
> driver.
Did you have a look at uio-howto in Documentation/DocBook/ in the
kernel sources? Just do a "make htmldocs", and you get the UIO howto in
html format in its own subdirectory.
You don't have to "register" the userspace part of an UIO driver. You
simply open /dev/uio0, mmap() your device's memory, and wait for
interrupts using a blocking read() or select() on /dev/uio0.
If you want to do it properly, you should use sysfs to find the right
UIO device (there could be others...) and the size of the memory to
map. Have a look at the sources of lsuio to see how this is done:
http://www.osadl.org/projects/downloads/UIO/user/
You find the userspace part of the uio_cif driver there, too.
If you still got problems after reading this, feel free to ask me. Note
that I'm not subscribed to linuxppc-embedded. The preferred list for
UIO questions is LKML. If you don't want to subscribe to LKML, you can
also ask me by private mail. You should ask detailed questions, ideally
accompanied by a piece of your code that shows the problem.
Thanks,
Hans
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Adrian Bunk @ 2008-02-18 14:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Roel Kluin, lkml, cbe-oss-dev, linuxppc-dev, Willy Tarreau,
Arjan van de Ven
In-Reply-To: <Pine.LNX.4.64.0802181500410.13406@vixen.sonytel.be>
On Mon, Feb 18, 2008 at 03:01:35PM +0100, Geert Uytterhoeven wrote:
> On Mon, 18 Feb 2008, Adrian Bunk wrote:
> >
> > This means it generates faster code with a current gcc for your platform.
> >
> > But a future gcc might e.g. replace the whole loop with a division
> > (gcc SVN head (that will soon become gcc 4.3) already does
> > transformations like replacing loops with divisions [1]).
>
> Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(),
> if it doesn't live up to its promise?
That's a different issue.
My point here is that we do not know how the latest gcc available in the
year 2010 might transform this code, and how a likely/unlikely placed
there might influence gcc's optimizations then.
If this is in hotpath code with a measurable speedup when using
likely/unlikely with a current gcc then it's worth it.
But otherwise it brings no real advantage today and the longterm effects
are not predictable.
> With kind regards,
>
> Geert Uytterhoeven
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] next-20080218 build failure at pmac_ide_macio_attach ()
From: Andreas Schwab @ 2008-02-18 14:17 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linux-ide, sfr, linux-kernel, linuxppc-dev
In-Reply-To: <20080218140159.GA31310@linux.vnet.ibm.com>
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> writes:
> --- linux-2.6.25-rc1/drivers/ide/ppc/pmac.c 2008-02-18 18:41:48.000000000 +0530
> +++ linux-2.6.25-rc1/drivers/ide/ppc/~pmac.c 2008-02-18 19:20:37.000000000 +0530
> @@ -1091,7 +1091,7 @@ pmac_ide_macio_attach(struct macio_dev *
> int irq, rc;
> hw_regs_t hw;
>
> - pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
> + pmif = (struct pmac_ide_hwif*)kzalloc(sizeof(*pmif), GFP_KERNEL);
Just remove the cast.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: libfdt: More tests of NOP handling behaviour
From: Jon Loeliger @ 2008-02-18 14:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080218050925.GH29975@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> In light of the recently discovered bug with NOP handling, this adds
> some more testcases for NOP handling. Specifically, it adds a helper
> program which will add a NOP tag after every existing tag in a dtb,
> and runs the standard battery of tests over trees mangled in this way.
>
> For now, this does not add a NOP at the very beginning of the
> structure block. This causes problems for libfdt at present, because
> we assume in many places that the root node's BEGIN_NODE tag is at
> offset 0. I'm still contemplating what to do about this (with one
> option being simply to declare such dtbs invalid).
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
BTW, declaring DTBs with BEGIN_NODES not at offset 0
as invalid seems like a fine choice to me.
jdl
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: David Howells @ 2008-02-18 14:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Adrian Bunk, Roel Kluin, lkml, Willy Tarreau, linuxppc-dev,
cbe-oss-dev, Arjan van de Ven
In-Reply-To: <Pine.LNX.4.64.0802181500410.13406@vixen.sonytel.be>
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> Hence shouldn't we ask the gcc people what's the purpose of
> __builtin_expect(), if it doesn't live up to its promise?
__builtin_expect() is useful on FRV where you _have_ to give each branch and
conditional branch instruction a measure of probability whether the branch
will be taken.
David
^ permalink raw reply
* Re: libfdt: Trivial cleanup for CHECK_HEADER)
From: Jon Loeliger @ 2008-02-18 14:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080218070631.GI29975@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently the CHECK_HEADER() macro is defined local to fdt_ro.c.
> However, there are a handful of functions (fdt_move, rw_check_header,
> fdt_open_into) from other files which could also use it (currently
> they open-code something more-or-less identical). Therefore, this
> patch moves CHECK_HEADER() to libfdt_internal.h and uses it in those
> places.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: libfdt: Remove no longer used code from fdt_node_offset_by_compatible()
From: Jon Loeliger @ 2008-02-18 14:29 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080218070904.GJ29975@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Since fdt_node_offset_by_compatible() was converted to the new
> fdt_next_node() iterator, a chunk of initialization code became
> redundant, but was not removed by oversight. This patch cleans it up.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Andi Kleen @ 2008-02-18 14:39 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Roel Kluin, lkml, cbe-oss-dev, linuxppc-dev, Willy Tarreau
In-Reply-To: <20080216094226.1e8eede1@laptopd505.fenrus.org>
Arjan van de Ven <arjan@infradead.org> writes:
> you have more faith in the authors knowledge of how his code actually behaves than I think is warranted :)
iirc there was a mm patch some time ago to keep track of the actual unlikely
values at runtime and it showed indeed some wrong ones. But the
far majority of them are probably correct.
> Or faith in that he knows what "unlikely" means.
> I should write docs about this; but unlikely() means:
> 1) It happens less than 0.01% of the cases.
> 2) The compiler couldn't have figured this out by itself
> (NULL pointer checks are compiler done already, same for some other conditions)
> 3) It's a hot codepath where shaving 0.5 cycles (less even on x86) matters
> (and the author is ok with taking a 500 cycles hit if he's wrong)
One more thing unlikely() does is to move the unlikely code out of line.
So it should conserve some icache in critical functions, which might
well be worth some more cycles (don't have numbers though).
But overall I agree with you that unlikely is in most cases a bad
idea (and I submitted the original patch introducing it originally @). That is because
it is often used in situations where gcc's default branch prediction
heuristics do would make exactly the same decision
if (unlikely(x == NULL))
is simply totally useless because gcc already assumes all x == NULL
tests are unlikely. I appended some of the builtin heuristics from
a recent gcc source so people can see them.
Note in particular the last predictors; assuming branch ending
with goto, including call, causing early function return or
returning negative constant are not taken. Just these alone
are likely 95+% of the unlikelies in the kernel.
-Andi
/* Use number of loop iterations determined by # of iterations
analysis to set probability. We don't want to use Dempster-Shaffer
theory here, as the predictions is exact. */
DEF_PREDICTOR (PRED_LOOP_ITERATIONS, "loop iterations", PROB_ALWAYS,
PRED_FLAG_FIRST_MATCH)
/* Hints dropped by user via __builtin_expect feature. */
DEF_PREDICTOR (PRED_BUILTIN_EXPECT, "__builtin_expect", PROB_VERY_LIKELY,
PRED_FLAG_FIRST_MATCH)
/* Use number of loop iterations guessed by the contents of the loop. */
DEF_PREDICTOR (PRED_LOOP_ITERATIONS_GUESSED, "guessed loop iterations",
PROB_ALWAYS, PRED_FLAG_FIRST_MATCH)
/* Branch containing goto is probably not taken. */
DEF_PREDICTOR (PRED_CONTINUE, "continue", HITRATE (56), 0)
/* Branch to basic block containing call marked by noreturn attribute. */
DEF_PREDICTOR (PRED_NORETURN, "noreturn call", HITRATE (99),
PRED_FLAG_FIRST_MATCH)
/* Branch to basic block containing call marked by cold function attribute. */
DEF_PREDICTOR (PRED_COLD_FUNCTION, "cold function call", HITRATE (99),
PRED_FLAG_FIRST_MATCH)
/* Loopback edge is taken. */
DEF_PREDICTOR (PRED_LOOP_BRANCH, "loop branch", HITRATE (86),
PRED_FLAG_FIRST_MATCH)
/* Edge causing loop to terminate is probably not taken. */
DEF_PREDICTOR (PRED_LOOP_EXIT, "loop exit", HITRATE (91),
PRED_FLAG_FIRST_MATCH)
/* Pointers are usually not NULL. */
DEF_PREDICTOR (PRED_POINTER, "pointer", HITRATE (85), 0)
DEF_PREDICTOR (PRED_TREE_POINTER, "pointer (on trees)", HITRATE (85), 0)
/* NE is probable, EQ not etc... */
DEF_PREDICTOR (PRED_OPCODE_POSITIVE, "opcode values positive", HITRATE (79), 0)
DEF_PREDICTOR (PRED_OPCODE_NONEQUAL, "opcode values nonequal", HITRATE (71), 0)
DEF_PREDICTOR (PRED_FPOPCODE, "fp_opcode", HITRATE (90), 0)
DEF_PREDICTOR (PRED_TREE_OPCODE_POSITIVE, "opcode values positive (on trees)", HITRATE (70), 0)
DEF_PREDICTOR (PRED_TREE_OPCODE_NONEQUAL, "opcode values nonequal (on trees)", HITRATE (69), 0)
DEF_PREDICTOR (PRED_TREE_FPOPCODE, "fp_opcode (on trees)", HITRATE (90), 0)
/* Branch guarding call is probably taken. */
DEF_PREDICTOR (PRED_CALL, "call", HITRATE (69), 0)
/* Branch causing function to terminate is probably not taken. */
DEF_PREDICTOR (PRED_TREE_EARLY_RETURN, "early return (on trees)", HITRATE (54), 0)
/* Branch containing goto is probably not taken. */
DEF_PREDICTOR (PRED_GOTO, "goto", HITRATE (70), 0)
/* Branch guarding call is probably taken. */
DEF_PREDICTOR (PRED_CALL, "call", HITRATE (69), 0)
/* Branch causing function to terminate is probably not taken. */
DEF_PREDICTOR (PRED_TREE_EARLY_RETURN, "early return (on trees)", HITRATE (54), 0)
/* Branch containing goto is probably not taken. */
DEF_PREDICTOR (PRED_GOTO, "goto", HITRATE (70), 0)
/* Branch ending with return constant is probably not taken. */
DEF_PREDICTOR (PRED_CONST_RETURN, "const return", HITRATE (67), 0)
/* Branch ending with return negative constant is probably not taken. */
DEF_PREDICTOR (PRED_NEGATIVE_RETURN, "negative return", HITRATE (96), 0)
/* Branch ending with return; is probably not taken */
DEF_PREDICTOR (PRED_NULL_RETURN, "null return", HITRATE (96), 0)
/* Branches to a mudflap bounds check are extremely unlikely. */
DEF_PREDICTOR (PRED_MUDFLAP, "mudflap check", PROB_VERY_LIKELY, 0)
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Roel Kluin @ 2008-02-18 14:59 UTC (permalink / raw)
To: David Howells
Cc: Adrian Bunk, lkml, cbe-oss-dev, linuxppc-dev, Geert Uytterhoeven,
Willy Tarreau, Arjan van de Ven
In-Reply-To: <12131.1203344830@redhat.com>
David Howells wrote:
> Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
>> Hence shouldn't we ask the gcc people what's the purpose of
>> __builtin_expect(), if it doesn't live up to its promise?
>
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch instruction a measure of probability whether the branch
> will be taken.
>
> David
I was wondering whether some of the uses of likely illustrated below are
incorrect or not useful.
x = likely(X) || Y
for ( ... ; likely(...); ... )
while ( likely(X) )
if ( unlikely(X) &&/|| likely(Y) )
if ( X &&/|| unlikely(Y) )
return likely(X);
return likely(X) ? a : b;
^ permalink raw reply
* Re: APU FPU in Virtex ppc405
From: A. Nolson @ 2008-02-18 15:09 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <loom.20080217T072721-349@post.gmane.org>
Hi Thomas,
I am still very interested in this. It would be really good if you can
post what you have so far. Did you also have to patch gcc also? Is there
any penalty in performance when compiling with -fshort-double?
/Albert
Thomas Werne wrote:
> A. Nolson <alohanono <at> gmail.com> writes:
>
>
>> I have been checking and it seems that the APU FPU patches will give
>> some headaches now, so I will probably wait until they merge them with
>> the official GCC release. In any case, it seems that the FPU restricts
>> the PowerPC and bus frequencies to a max of 200/100.
>>
>> Anyway, thanks for the info. I will try to keep track of this in case of
>> an update.
>>
>>
>
> Hi -
>
> You can get the FPU to work with the 2.6.24rc3 Linux (I got it to work just
> yesterday). There are a couple of small changes you have to make to kernel
> config files and to one of the .h files, plus you need to compile with the
> -fshort-double flag to convert all doubles into floats. Let me know if you're
> still interested and I can post details and/or patches.
>
> Thomas
>
> --
> Thomas Werne
> NASA Jet Propulsion Laboratory
>
> All personal and professional opinions presented herein are my
> own and do not, in any way, represent the opinion or policy of JPL.
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: Build failure on treeboot-walnut.c
From: maxime louvel @ 2008-02-18 15:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
Kumar Gala wrote:
> $ make V=1
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/uImage powerpc-unknown-linux-gnu-gcc -m32
>- Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef
>- Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float
-pipe
>- fomit-frame-pointer -fno-builtin -fPIC -nostdinc -isystem
> /_TOOLS_/.dist0/gnu-
gcc-4.0.2-binutils-2.16.1-glibc-2.3.6-e300c2-powerpc-unknown-linux-gnu/i686-
pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/4.0.2/include -
Iarch/powerpc/boot -I/temp/kumar.484/arch/powerpc/boot -mcpu=405 -c -o
> arch/powerpc/boot/treeboot-walnut.o arch/powerpc/boot/treeboot-walnut.c
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at
> /tmp/crosstool/crosstool-0.42/build/powerpc-unknown-linux-gnu/gcc-
4.0.2_e300-enabled-glibc-2.3.6/binutils-2.16.1-complete/gas/config/tc-ppc.c
> line 1314 in ppc_setup_opcodes
> Please report this bug.
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make: *** [uImage] Error 2
>
>ARCH=ppc64? WTF? I specifically said ARCH=powerpc on the make command
line.
I have got the exact same problem.
Has the problem been sovled ?
I am trying to compile a 2.6.24 kernel (vanilla + some board specific stuff)
with a vanilla gcc-4.1.2 with the flag -msoft-float.
cheers,
Maxime
--
Maxime Louvel
0044 7964 5555 80
43 Allen road
Whitemore reans
WV60AW Wolverhampton
United Kingdom
[-- Attachment #2: Type: text/html, Size: 1657 bytes --]
^ permalink raw reply
* Re: Linker error: no init_fcc_ioports
From: Scott Wood @ 2008-02-18 15:58 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AAC0@xmb-sjc-212.amer.cisco.com>
On Fri, Feb 15, 2008 at 06:05:36PM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi
> Our platform is based on mpc8541cds, I am using Linux 2.6.24 from
> powerpc git tree.
> I tried to compile the kernel to include the fcc Ethernet controller and
> I got the following
> linker errors:
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
>
> arch/powerpc/sysdev/built-in.o: In function `fs_enet_of_init':
> arch/powerpc/sysdev/fsl_soc.c:853: undefined reference to
> `init_fcc_ioports'
> arch/powerpc/sysdev/fsl_soc.c:853: undefined reference to
> `init_fcc_ioports'
You need to select PPC_CPM_NEW_BINDING from your board's kconfig entry
(and make sure you comply with the new CPM bindings, and that all pins
are set up by firmware or platform code).
-Scott
^ permalink raw reply
* Re: Sequoia NAND - others missing?
From: Steve Heflin @ 2008-02-18 16:18 UTC (permalink / raw)
To: Linuxppc-embedded
Looking at the "arch/ppc/platforms/4xx/sequoia.c" from 2.6.14
MontaVista, I also see ECC error handling, a Serial RTC device, UART4
to UART11. It doesn't look like those are supported in the current
"arch/powerpc/platforms/44x/sequoia" ?
Regarding the nftd NAND driver, I see a device table hookup in
"arch/powerpc/platforms/44x/warp-nand.c". Am I right in saying that
file is a perfect template from which to generate sequoia-nand.c ?
thanks,
Steve
At 03:56 PM 2/17/2008, you wrote:
>On Sun, 17 Feb 2008 10:27:22 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > Are there other devices (beside the NAND Flash Controller) that exist
> > on the AMCC-440EPx chip and are not supported by the current
> > Linux-2.6.25 ARCH=powerpc?
>
>i2c, GPIO, the security stuff (if your version has that), and GPT.
>Thought GPT has never really been supported in any kernel that I
>remember.
>
>Patches for i2c and GPIO are floating around somewhere I think. Just
>need to get them polished up and device-tree compliant.
>
>josh
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH-RESEND] next-20080218 build failure at pmac_ide_macio_attach ()
From: Kamalesh Babulal @ 2008-02-18 17:06 UTC (permalink / raw)
To: Andreas Schwab
Cc: sfr, linux-ide, linux-kernel, Kamalesh Babulal, linuxppc-dev
In-Reply-To: <jeodae4acy.fsf@sykes.suse.de>
On Mon, Feb 18, 2008 at 03:17:49PM +0100, Andreas Schwab wrote:
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> writes:
>
.
.
<snip>
> Just remove the cast.
>
> Andreas.
Resending the patch after making the changes Andreas said.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Andreas Schwab <schwab@suse.de>
--
--- linux-2.6.25-rc1/drivers/ide/ppc/pmac.c 2008-02-18 22:24:49.000000000 +0530
+++ linux-2.6.25-rc1/drivers/ide/ppc/~pmac.c 2008-02-18 22:25:10.000000000 +0530
@@ -1091,7 +1091,7 @@ pmac_ide_macio_attach(struct macio_dev *
int irq, rc;
hw_regs_t hw;
- pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
+ pmif = kzalloc(sizeof(*pmif), GFP_KERNEL);
if (pmif == NULL)
return -ENOMEM;
@@ -1229,7 +1229,7 @@ pmac_ide_pci_attach(struct pci_dev *pdev
return -ENODEV;
}
- pmif = (struct pmac_ide_hwif)kzalloc(sizeof(*pmif), GFP_KERNEL);
+ pmif = kzalloc(sizeof(*pmif), GFP_KERNEL);
if (pmif == NULL)
return -ENOMEM;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Anton Vorontsov @ 2008-02-18 17:37 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: linux-fbdev-devel, adaplas, Krzysztof Helt, linux-kernel,
linuxppc-dev, Geert Uytterhoeven, Andrew Morton
In-Reply-To: <19805.1203355811@turing-police.cc.vt.edu>
On Mon, Feb 18, 2008 at 12:30:11PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> > I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> > Both resolve endianess at driver level. Actually, both handle it by setting special
> > bits so the graphics chip itself reorder bytes to transform foreign endianess.
> > I understand that this patch is for chips which cannot reorder bytes by themselves.
>
> Does anybody know of such a chip that's actually available in the wild?
LE Fujitsu mb86277 (MINT) on the BE MPC8360E.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: How to describe FPGA-based devices in the device tree ?
From: Scott Wood @ 2008-02-18 17:47 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200802181343.54989.laurentp@cse-semaphore.com>
On Mon, Feb 18, 2008 at 01:43:52PM +0100, Laurent Pinchart wrote:
> bcsr@3,0 {
> device_type = "board-control";
> reg = <3 0 00000020>;
> };
No device_type. Needs a compatible.
>
> fpga@4,0 {
> reg = <4 0 00010000>;
> };
> };
>
> The fourth device is a FPGA that contains several IP cores such as an
> interrupt controller and a SD/MMC host controller. If I understand things
> correctly, each IP core should have its own node in the device tree to allow
> proper binding with device drivers.
Correct.
> As booting-without-of.txt describes the localbus node ranges as
> corresponding to a single chipselect and covering the entire chipselect
> access window, I can't have nodes for each IP core as children of the
> localbus node.
That does not follow. The ranges entry has to cover the whole chipselect,
but there's no one-to-one correspondence between nodes and ranges entries.
There's nothing wrong with doing this:
fpga@4,0 {
compatible = "foo,bar";
reg = <4 0 00010000>;
};
fpga@4,10000 {
compatible = "foo,baz";
reg = <4 00010000 00010000>;
};
fpga@4,20000 {
compatible = "foo,blah";
reg = <4 00020000 00010000>;
};
> Should I put IP core nodes as children of the FPGA node ?
You could do that as well.
> If so, how do I map addresses at the FPGA level ? A ranges property in the
> FPGA node would let me map addresses in the FPGA scope to the localbus
> scope. However, as the localbus scope use the chipselect number as its
> first address cell and 0 as its second address cell,
The second cell is the address within the chipselect. If it were always
zero, it wouldn't be there at all.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Valdis.Kletnieks @ 2008-02-18 18:11 UTC (permalink / raw)
To: David Howells
Cc: Adrian Bunk, Roel Kluin, lkml, Willy Tarreau, linuxppc-dev,
Geert Uytterhoeven, cbe-oss-dev, Arjan van de Ven
In-Reply-To: <12131.1203344830@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
> __builtin_expect() is useful on FRV where you _have_ to give each branch and
> conditional branch instruction a measure of probability whether the branch
> will be taken.
What does gcc do the 99.998% of the time we don't have likely/unlikely coded?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* arch_initcall time
From: Sean MacLennan @ 2008-02-18 18:28 UTC (permalink / raw)
To: LinuxPPC-dev
I need to call i2c_register_board_info for the new i2c style ad7414
driver. This needs to be called at arch initcall time. Currently I just
do this:
static int __init warp_arch_init(void)
{
i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
return 0;
}
arch_initcall(warp_arch_init);
It works, but is there a "better" place to put this? None of the other
powerpc platforms make this call and I want to get it right, so that
others don't blindly follow my example ;)
I kept the name vague rather than specific in case more drivers need to
be setup this way in the future.
Cheers,
Sean
^ permalink raw reply
* Re: How to describe FPGA-based devices in the device tree ?
From: Grant Likely @ 2008-02-18 18:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080218174701.GA3835@loki.buserror.net>
On Feb 18, 2008 10:47 AM, Scott Wood <scottwood@freescale.com> wrote:
> On Mon, Feb 18, 2008 at 01:43:52PM +0100, Laurent Pinchart wrote:
> > Should I put IP core nodes as children of the FPGA node ?
>
> You could do that as well.
I'd recommend doing that, then your subnodes are isolated from changes
to the bus attachment (chipselect). (really an insignificant point,
but I think it is a more logical layout).
So, something like this:
fpga@4,0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 4 0 00100000>;
/* breakdown of 'ranges' fields: */
/* "0": start address of internal range */
/* "4 0": start address of external range (chip select 4, address 0) */
/* "00100000: size of range */
iocore@0 {
compatible = "foo,bar";
reg = <0 00010000>;
};
iocore@10000 {
compatible = "foo,bar";
reg = <10000 00010000>;
};
iocore@20000 {
compatible = "foo,bar";
reg = <20000 00010000>;
};
};
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: arch_initcall time
From: Grant Likely @ 2008-02-18 18:31 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47B9CE4D.1020303@pikatech.com>
On Feb 18, 2008 11:28 AM, Sean MacLennan <smaclennan@pikatech.com> wrote:
> I need to call i2c_register_board_info for the new i2c style ad7414
> driver. This needs to be called at arch initcall time. Currently I just
> do this:
>
> static int __init warp_arch_init(void)
> {
> i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
> return 0;
> }
> arch_initcall(warp_arch_init);
Yes, this is the right thing to do, but use machine_arch_initcall()
instead so that it doesn't get called if it is not your board.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
From: Valdis.Kletnieks @ 2008-02-18 17:30 UTC (permalink / raw)
To: Krzysztof Helt
Cc: linux-fbdev-devel, adaplas, linux-kernel, linuxppc-dev,
Geert Uytterhoeven, Andrew Morton
In-Reply-To: <20080218081847.e9e65f2f.krzysztof.h1@poczta.fm>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said:
> I know two fb drivers which use endianess information (pm2fb and s3c2410fb).
> Both resolve endianess at driver level. Actually, both handle it by setting special
> bits so the graphics chip itself reorder bytes to transform foreign endianess.
> I understand that this patch is for chips which cannot reorder bytes by themselves.
Does anybody know of such a chip that's actually available in the wild? Or are
we writing drivers for speculative possible chips?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox