* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-18 10:00 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH, Dave Hansen,
apw, linux-kernel, Christoph Raisch, Badari Pulavarty, netdev,
tklein
In-Reply-To: <1203094538.8142.23.camel@nimitz.home.sr71.net>
switching to proper mail client...
Dave Hansen <haveblue@us.ibm.com> wrote on 15.02.2008 17:55:38:
> I've been thinking about that, and I don't think you really *need* to
> keep a comprehensive map like that.=20
>=20
> When the memory is in a particular configuration (range of memory
> present along with unique set of holes) you get a unique ehea_bmap
> configuration. =A0That layout is completely predictable.
>=20
> So, if at any time you want to figure out what the ehea_bmap address for
> a particular *Linux* virtual address is, you just need to pretend that
> you're creating the entire ehea_bmap, use the same algorithm and figure
> out host you would have placed things, and use that result.
>=20
> Now, that's going to be a slow, crappy linear search (but maybe not as
> slow as recreating the silly thing). =A0So, you might eventually run into
> some scalability problems with a lot of packets going around. =A0But, I'd
> be curious if you do in practice.
Up to 14 addresses translation per packet (sg_list) might be required on=20
the transmit side. On receive side it is only 1. Most packets require only=
=20
very few translations (1 or sometimes more) =A0translations. However,=20
with more then 700.000 packets per second this approach does not seem=20
reasonable from performance perspective when memory is fragmented as you
described.
>=20
> The other idea is that you create a mapping that is precisely 1:1 with
> kernel memory. =A0Let's say you have two sections present, 0 and 100. =A0=
You
> have a high_section_index of 100, and you vmalloc() a 100 entry array.
>=20
> You need to create a *CONTIGUOUS* ehea map? =A0Create one like this:
>=20
> EHEA_VADDR->Linux Section
> 0->0
> 1->0
> 2->0
> 3->0
> ...
> 100->100
>=20
> It's contiguous. =A0Each area points to a valid Linux memory address.
> It's also discernable in O(1) to what EHEA address a given Linux address
> is mapped. =A0You just have a couple of duplicate entries.=20
This has a serious issues with constraint I mentions in the previous mail:=
=20
"- MRs can have a maximum size of the memory available under linux"
The requirement is not met that the memory region must not be=20
larger then the available memory for that partition. The "create MR"=20
H_CALL will fails (we tried this and discussed with FW development)
Regards,
Jan-Bernd & Christoph
^ permalink raw reply
* EBC configuration for mmio
From: sunil dutt @ 2008-02-18 10:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
We are working on the MMIO interface and are struck up at sending the data
over the interface on PPC405EXr.The following are the configurations done by
us to use EBC Bank3.
EBC0_B3CR = 0x80018000 /*Base address 0x800 size 1MB Read/Write set */
EBC0_B3AP = 0x07840f80
We have configured GPIO pin 10 (PER_CS3) for the chip select.The following
is the configuration for the CS .
OSRL : 00aa54aa
TSRL : 00aa54aa
ISR1L: XX(Dont care)
Here are our observations while doing the data transfer.
1.When the data of one byte is sent continuously we have observed that the
second write blocks and the chip select is not triggered for the second
transfer.
2.When one byte is sent and immediately we read the data over the interface
the read blocks and we also see that chip select is not triggered for the
read.
3.The point 2 mentioned above is not consistent.We some times read the value
from the interface though the chip select is not triggered.
Please could you verify our configurations.Please let us know if there is
any thing additional to be done.
Thanks and Regards,
Sunil
--
View this message in context: http://www.nabble.com/EBC-configuration-for-mmio-tp15542516p15542516.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* mm section mismatch warnings for ps3
From: Geert Uytterhoeven @ 2008-02-18 12:14 UTC (permalink / raw)
To: Linux/PPC Development, Linux Kernel Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5015 bytes --]
When building current mainline for ps3_defconfig, I get the following
mm-related section mismatches:
| WARNING: mm/built-in.o(.text+0x25094): Section mismatch in reference from the function .sparse_add_one_section() to the function .meminit.text:.sparse_index_init()
| The function .sparse_add_one_section() references
| the function __meminit .sparse_index_init().
| This is often because .sparse_add_one_section lacks a __meminit
| annotation or the annotation of .sparse_index_init is wrong.
|
| WARNING: mm/built-in.o(.text+0x25128): Section mismatch in reference from the function .sparse_add_one_section() to the function .meminit.text:.sparse_init_one_section()
| The function .sparse_add_one_section() references
| the function __meminit .sparse_init_one_section().
| This is often because .sparse_add_one_section lacks a __meminit
| annotation or the annotation of .sparse_init_one_section is wrong.
|
| WARNING: mm/built-in.o(.text+0x2c5fc): Section mismatch in reference from the function .__add_zone() to the function .meminit.text:.init_currently_empty_zone()
| The function .__add_zone() references
| the function __meminit .init_currently_empty_zone().
| This is often because .__add_zone lacks a __meminit
| annotation or the annotation of .init_currently_empty_zone is wrong.
|
| WARNING: mm/built-in.o(.text+0x2c628): Section mismatch in reference from the function .__add_zone() to the function .meminit.text:.memmap_init_zone()
| The function .__add_zone() references
| the function __meminit .memmap_init_zone().
| This is often because .__add_zone lacks a __meminit
| annotation or the annotation of .memmap_init_zone is wrong.
|
| WARNING: vmlinux.o(.text+0x7360): Section mismatch in reference from the function .start_secondary_prolog() to the function .devinit.text:.start_secondary()
| The function .start_secondary_prolog() references
| the function __devinit .start_secondary().
| This is often because .start_secondary_prolog lacks a __devinit
| annotation or the annotation of .start_secondary is wrong.
|
| WARNING: vmlinux.o(.text+0x1dea0): Section mismatch in reference from the function .move_device_tree() to the function .init.text:.lmb_alloc_base()
| The function .move_device_tree() references
| the function __init .lmb_alloc_base().
| This is often because .move_device_tree lacks a __init
| annotation or the annotation of .lmb_alloc_base is wrong.
|
| WARNING: vmlinux.o(.text+0xabd7c): Section mismatch in reference from the function .sparse_add_one_section() to the function .meminit.text:.sparse_index_init()
| The function .sparse_add_one_section() references
| the function __meminit .sparse_index_init().
| This is often because .sparse_add_one_section lacks a __meminit
| annotation or the annotation of .sparse_index_init is wrong.
|
| WARNING: vmlinux.o(.text+0xabe10): Section mismatch in reference from the function .sparse_add_one_section() to the function .meminit.text:.sparse_init_one_section()
| The function .sparse_add_one_section() references
| the function __meminit .sparse_init_one_section().
| This is often because .sparse_add_one_section lacks a __meminit
| annotation or the annotation of .sparse_init_one_section is wrong.
|
| WARNING: vmlinux.o(.text+0xb3198): Section mismatch in reference from the function .add_memory() to the function .devinit.text:.arch_add_memory()
| The function .add_memory() references
| the function __devinit .arch_add_memory().
| This is often because .add_memory lacks a __devinit
| annotation or the annotation of .arch_add_memory is wrong.
|
| WARNING: vmlinux.o(.text+0xb32e4): Section mismatch in reference from the function .__add_zone() to the function .meminit.text:.init_currently_empty_zone()
| The function .__add_zone() references
| the function __meminit .init_currently_empty_zone().
| This is often because .__add_zone lacks a __meminit
| annotation or the annotation of .init_currently_empty_zone is wrong.
|
| WARNING: vmlinux.o(.text+0xb3310): Section mismatch in reference from the function .__add_zone() to the function .meminit.text:.memmap_init_zone()
| The function .__add_zone() references
| the function __meminit .memmap_init_zone().
| This is often because .__add_zone lacks a __meminit
| annotation or the annotation of .memmap_init_zone is wrong.
(there are a few more regarding ps3_register_repository_device(), but these
cannot happen as only storage devices can be added later)
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
* How to describe FPGA-based devices in the device tree ?
From: Laurent Pinchart @ 2008-02-18 12:43 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]
Hi everybody,
I'm (at last) trying to move from ARCH=ppc to ARCH=powerpc. After reading
Documentation/powerpc/booting-without-of.txt and various device trees in
arch/powerpc/boot/dts, I still don't know how to express some devices in the
device tree.
The target board has several devices on the processor local bus, as described
in the following device tree fragment.
localbus@f0010100 {
compatible = "fsl,mpc8260-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <f0010100 60>;
ranges = <0 0 40000000 01000000
2 0 f2000000 00100000
3 0 f3000000 00100000
4 0 f4000000 00100000>;
flash@0,0 {
compatible = "cfi-flash";
reg = <0 0 01000000>;
bank-width = <2>;
};
nvram@2,0 {
compatible = "mtd-ram";
reg = <2 0 00100000>;
bank-width = <2>;
};
bcsr@3,0 {
device_type = "board-control";
reg = <3 0 00000020>;
};
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. 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.
Should I put IP core nodes as children of the FPGA node ? 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, I don't see how I could translate offsets in the
FPGA into an address at the localbus scope.
Could anyone advice me regarding how to properly describe my hardware in the
device tree ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: "make ARCH=ppc defconfig" fails looking for common_defconfig
From: Josh Boyer @ 2008-02-18 12:43 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux PPC Mailing List
In-Reply-To: <alpine.LFD.1.00.0802180430100.10518@localhost.localdomain>
On Mon, 18 Feb 2008 04:32:24 -0500 (EST)
"Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
>
> (AIUI, the entire ppc/ architecture is going away, yes? which means
> i probably shouldn't care about any errors within. is that correct?
> even so, build errors should probably still be avoided for now.)
Yes, it's going away. There's really no longer support for anything
"common" in it now anyway. CHRP, POWER3 and POWER4 have been removed.
So have 83xx and 85xx.
Just let it go.
josh
^ permalink raw reply
* Re: [Patch 2/2] powerpc: i2c-isa: add access check to legacy ioports
From: Jean Delvare @ 2008-02-18 13:31 UTC (permalink / raw)
To: Christian Krafft; +Cc: parabelboi, linuxppc-dev, linux-kernel
In-Reply-To: <20080213183701.254391cc@de.ibm.com>
Hi Christian,
On Wed, 13 Feb 2008 18:37:01 +0100, Christian Krafft wrote:
> when probing i2c-pca-isa writes to legacy ioports, which crashes the kernel
> if there is no device at that port.
> This patch adds a check_legacy_ioport call, so probe failes gracefully
> and thus prevents the oops.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
>
> Index: linux.git/drivers/i2c/busses/i2c-pca-isa.c
> ===================================================================
> --- linux.git.orig/drivers/i2c/busses/i2c-pca-isa.c
> +++ linux.git/drivers/i2c/busses/i2c-pca-isa.c
> @@ -125,6 +125,13 @@ static int __devinit pca_isa_probe(struc
>
> dev_info(dev, "i/o base %#08lx. irq %d\n", base, irq);
>
> +#ifdef CONFIG_PPC_MERGE
> + if (check_legacy_ioport(base)) {
> + dev_err(dev, "I/O address %#08lx is not available\n", base);
> + goto out;
> + }
> +#endif
> +
> if (!request_region(base, IO_SIZE, "i2c-pca-isa")) {
> dev_err(dev, "I/O address %#08lx is in use\n", base);
> goto out;
>
I can apply this, no problem. That being said, you might alternatively
just exclude this driver from PPC. It's for a rare device with no known
user, the driver is unmaintained and will hopefully be replaced soon by
a platform driver which will not probe random ports at load time.
--
Jean Delvare
^ permalink raw reply
* 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
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