* [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Zhang Wei @ 2007-06-12 9:02 UTC (permalink / raw)
To: mporter; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11816389393593-git-send-email-wei.zhang@freescale.com>
Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 41 ++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index b49ce16..359c899 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1729,6 +1729,47 @@ platforms are moved over to use the flattened-device-tree model.
More devices will be defined as this spec matures.
+ k) RapidIO
+
+ Required properties:
+
+ - device_type : Should be "rapidio"
+ - compatible : Should be "fsl,rapidio-v0.0" or "fsl,rapidio-v1.0"
+ and so on. The version number is got from IP Block Revision
+ Register of RapidIO controller.
+ - #address-cells : Address representation for "rapidio" devices.
+ This field represents the number of cells needed to represent
+ the RapidIO address of the registers. For supporting more than
+ 36-bits RapidIO address, this field should be <2>.
+ See 1) above for more details on defining #address-cells.
+ - reg : Offset and length of the register set for the device
+ - ranges : Should be defined as specified in 1) to describe the
+ translation of addresses for memory mapped RapidIO memory
+ space.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have. For this sector, interrupts order should be
+ <err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
+ msg2_tx_irq msg2_rx_irq ... msgN_tx_irq msgN_rx_irq>.
+
+ Example:
+
+ srio@c0000{
+ device_type = "rapidio";
+ compatible = "fsl,rapidio-v1.0";
+ #address-cells = <2>;
+ reg = <c0000 20000>;
+ ranges = <0 0 c0000000 20000000>;
+ interrupt-parent = <&mpic>;
+ /* err_irq bell_outb_irq bell_inb_irq msg1_tx_irq msg1_rx_irq
+ msg2_tx_irq msg2_rx_irq */
+ interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
+ };
+
VII - Specifying interrupt information for devices
===================================================
--
1.5.1
^ permalink raw reply related
* Re: [patch 02/10] powerpc: Move CONFIG_PPC64 into CPU selection
From: Arnd Bergmann @ 2007-06-12 8:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <18030.15937.699275.958545@cargo.ozlabs.ibm.com>
On Tuesday 12 June 2007, Paul Mackerras wrote:
> > Currently, PPC64 is a top level configuration option in
> > arch/powerpc/Kconfig, which is somewhat unconventional.
>=20
> It makes a lot of sense to me to have 32 vs. 64 bits as a high level
> binary selector that conditions the things that follow. =A0I don't think
> it makes sense to push it down into the CPU selection menu.
Can you eleborate, other than stating the exact opposite of what
my comment said?
I don't mind removing this patch from the series, but I'd like to
understand the reason. I've always thought of the top-level option
as a temporary ugly hack that should eventually go away ;-)
Other than subjective feelings, my reasons for this patch were:
* No other architecture I have seen uses bool options in the top-level
menu, so it would be more consistant to move it to the cpu type
selection menu.
* we have six (depending on how you count) PPC CPU families
supported by Linux (4xx, 6xx, 8xx, e200, e500, ppc64), each
of them incompatible with the others, meaning that you can run
common user space but not a common kernel. Having the list in
as the first Kconfig choice seems logical to me, because
all other options more or less depend on these.
* The only major difference between ppc64 and the others is the
object format of the kernel binary. My impression when playing
with the cpu selection menu was that we have a lot more stuff
depending on 6xx than on ppc64.
* Given the choice between the equivalent
> config PPC64
> bool
>
> choice
> depends on !PPC64
> config 4xx
> config 6xx
> config 8xx
> config E200
> config E500
> endchoice
and
> choice
> config PPC64
> config 4xx
> config 6xx
> config 8xx
> config E200
> config E500
> endchoice
I find the latter easier to understand regarding further options
depending on each of them in the individual platforms, e.g. each
of the platforms/foo/Kconfig files depends on exactly one of these
six options.=20
Arnd <><
^ permalink raw reply
* Re: [patch 06/10] powerpc: multiplatformize embedded6xx Kconfig
From: Arnd Bergmann @ 2007-06-12 7:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <F72846CE-5742-4413-A2EB-AC1B4080048E@kernel.crashing.org>
On Tuesday 12 June 2007, Kumar Gala wrote:
> > -config EMBEDDED6xx
> > -=A0=A0=A0=A0=A0bool "Embedded 6xx/7xx/7xxx-based board"
> > -=A0=A0=A0=A0=A0depends on PPC32 && (BROKEN||BROKEN_ON_SMP)
> > -
>=20
> Do we know why this was marked BROKEN?
I don't know. As far as I can tell, (BROKEN||BROKEN_ON_SMP) is the
same as simply BROKEN_ON_SMP, which makes the option only show
up when SMP is disabled.
My patch doesn't change that behaviour, I just moved the dependency
down to the individual boards.
Arnd <><
^ permalink raw reply
* Re: [patch 01/10] powerpc: split out CPU specific options into a new Kconfig file
From: Arnd Bergmann @ 2007-06-12 7:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, paulus
In-Reply-To: <20070612140214.1a7dfd9d.sfr@canb.auug.org.au>
On Tuesday 12 June 2007, Stephen Rothwell wrote:
> On Tue, 12 Jun 2007 01:28:25 +0200 arnd@arndb.de wrote:
> >
> > -config VIRT_CPU_ACCOUNTING
> > -=A0=A0=A0=A0=A0bool "Deterministic task and CPU time accounting"
>=20
> I am not sure that this belongs with all the rest.
It's selected by arch/powerpc/platforms/embedded6xx/Kconfig.
How about moving it to arch/powerpc/platforms/Kconfig?
Arnd <><
^ permalink raw reply
* Re: [patch 02/10] powerpc: Move CONFIG_PPC64 into CPU selection
From: Paul Mackerras @ 2007-06-12 6:33 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev
In-Reply-To: <20070611233353.734704855@arndb.de>
arnd@arndb.de writes:
> Currently, PPC64 is a top level configuration option in
> arch/powerpc/Kconfig, which is somewhat unconventional.
It makes a lot of sense to me to have 32 vs. 64 bits as a high level
binary selector that conditions the things that follow. I don't think
it makes sense to push it down into the CPU selection menu.
Paul.
^ permalink raw reply
* RE: [PATCH 5/6]: 82xx: Add the support of Wind River SBC PowerQUICCII 82xx
From: Mark Zhan @ 2007-06-12 6:03 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890D2AA5B@zch01exm26.fsl.freescale.net>
Hi Li Yang,
On Mon, 2007-06-11 at 21:51 +0800, Li Yang-r58472 wrote:
> Shouldn't these come from device tree too?
>
> Moreover, you can no longer use the hard coded IRQ numbers. They need
> to be mapped to virtual irq, and the driver needs to use the virtual irq
> number.
>
Actually this is a fake interrupt. Please see my code comment:
/*
* For SBCPQ2 board, the interrupt of M48T59 RTC chip
* will generate a machine check exception. We use a
* fake irq to give the platform machine_check_exception() hook
* a chance to call the driver ISR. If IRQ_HANDLED is returned,
* then we will survive from the machine check exception.
*/
> I don't believe the following are necessary. New MTD mapping should be
> defined in device tree.
>
Oh, here I just want to document the memory mapping for this board. I
think, even we already have devtree, it is a good idea that we always
document the H/W setting in platform header file, which will definitely
make life easier.
> > +/*
> > + * Wind River SBC PowerQUICCII 82xx Physical Memory Map (CS0 for
> > OnBoard Flash)
> > + *
......
>
> Use < &interrupt-controller > as interrupt-parent instead.
>
Got it.
> - Leo
Thanks
Mark Zhan
^ permalink raw reply
* Re: [patch 06/10] powerpc: multiplatformize embedded6xx Kconfig
From: Kumar Gala @ 2007-06-12 5:59 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070611233354.289486461@arndb.de>
On Jun 11, 2007, at 6:28 PM, arnd@arndb.de wrote:
> The existing embedded 6xx platforms will happily coexist
> with each other in a single kernel if you let them.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Index: linux-2.6/arch/powerpc/platforms/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/Kconfig
> +++ linux-2.6/arch/powerpc/platforms/Kconfig
> @@ -12,10 +12,6 @@ config PPC_MULTIPLATFORM
> RS/6000 machine, an Apple machine, or a PReP, CHRP,
> Maple or Cell-based machine.
>
> -config EMBEDDED6xx
> - bool "Embedded 6xx/7xx/7xxx-based board"
> - depends on PPC32 && (BROKEN||BROKEN_ON_SMP)
> -
Do we know why this was marked BROKEN?
- k
^ permalink raw reply
* Re: [patch 00/18] PS3 patches for 2.6.23
From: Benjamin Herrenschmidt @ 2007-06-12 5:03 UTC (permalink / raw)
To: Milton Miller; +Cc: Geert Uytterhoeven, ppcdev
In-Reply-To: <71e5ae7f85657e4ab5bfbc809cab9c60@bga.com>
On Mon, 2007-06-11 at 02:08 -0500, Milton Miller wrote:
> (Or disable the ps3 system bus during the merge of the series).
Considering that
- It breaks only ps3
- ps3, as of today, doesn't quite work anyway without those patches
I'd be tempted to say bisect doesn't matter. If you're bisecting
something else, then just disable ps3 support.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Gibson @ 2007-06-12 4:44 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, David Woodhouse, Milton Miller, linux-mtd
In-Reply-To: <18fbfbaf113ab76b602d279848d9b405@kernel.crashing.org>
On Thu, Jun 07, 2007 at 05:55:44PM +0200, Segher Boessenkool wrote:
> > Any representation of flash devices in the device-tree should ideally
> > have 'bus width' and 'interleave' properties to contain this
> > information.
> >
> > The 'bus width' cannot necessarily be inferred, especially where a
> > given
> > bus can be configured to allow multiple sizes of access. It's purely a
> > function of how the flash chips are wired up. That's why we actually
> > call it 'bank width', not 'bus width' in the Linux code.
>
> Ah, "bank width" as in "bus width" per chip select. I see.
>
> So I think the best thing to have would be
>
> compatible "cfi-flash"
> bank-width like you said
> device-width width of a single flash device
> reg complete address range of this thing
>
> and then the Linux OF CFI flash code / MTD code just keeps
> on probing devices from that address range until it has it
> filled.
>
> Sounds good / comments / anything I missed?
Looks pretty sensible to me. Presumably the compatible property could
also have more specific entries for the particular chip type.
Of course, Ebony has flash which is JEDEC rather than CFI probed, so I
have an interest in a binding for that, too.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Gibson @ 2007-06-12 4:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <7878cf1aec340b976b90b86b9e83bf18@kernel.crashing.org>
On Thu, Jun 07, 2007 at 03:30:46PM +0200, Segher Boessenkool wrote:
> > Whatever Segher says, I think it's fine to have the partition
> > information here.
>
> It's nonsense to have it *inside that device node*. I
> understand if you want to express it elsewhere.
>
> > It may not be hardware information, but it is
> > (often) firmware information;
>
> Only part of it is. The rest should *not* be dictated
> by the firmware; for example, if a new OS image for
> the device needs different flash partition sizes, you
> would have to reflash the firmware! Obviously less than
> ideal, and we can't have that kind of stuff in a more-
> or-less generic device tree binding.
>
> > there are plenty precedents for things
> > like this in the device tree and it doesn't get in the way of any real
> > hardware information.
>
> There is plenty of precedent for putting stuff that
> is not configuration info for some OS in the device
> tree, yes -- like describing the flash region used
> by firmware code (as a subnode of the flash node,
> perhaps). A "generic" (i.e., specific to the current
> implementation of linux-mtd) partition map is no such
> thing.
So, what you're suggesting is a subnode for each described partition?
Seems an awfully verbose way of going about it, and I don't see what
it buys us over the partitions/partition-names pair of properties.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] dtc: parse NOP in dtb input
From: David Gibson @ 2007-06-12 4:31 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, jdl
In-Reply-To: <311814492916b8b45674.846930886.miltonm@bga.com>
On Sat, Jun 09, 2007 at 11:21:31PM -0500, Milton Miller wrote:
> Version 16 and later of the flat device tree format allow NOPs
> to be placed in the tree. When processing dtb input, dtc must
> recognise them.
>
> Previously it would produce the error message
> FATAL ERROR: Invalid opcode word 00000004 in device tree blob
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> ---
>
> I was trying to look at the output of convert_flattree_inplace
> when I found this. ftdump.c was able to process the input,
> producing // [NOP] comments when encountered.
Oops, we didn't parse NOPs already. That's a bit of an oversight.
[snip]
> @@ -774,6 +775,13 @@ static struct node *unflatten_tree(struc
> die("Premature OF_DT_END in device tree blob\n");
> break;
>
> + case OF_DT_NOP:
> + if (flags & FTF_NOPS)
> + break;
> +
> + die("OF_DT_NOP in device tree blob\n");
> + break;
> +
Actually, I think we should accept the NOPs (with at most a warning)
on all DTB versions. They may not have been defined for the early
versions, but they're not ambiguous.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 06/10] powerpc: multiplatformize embedded6xx Kconfig
From: Stephen Rothwell @ 2007-06-12 4:16 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070612141509.4c4f6cc8.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
On Tue, 12 Jun 2007 14:15:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > config LINKSTATION
> > bool "Linkstation / Kurobox(HG) from Buffalo"
> > + depends on EMBEDDED6xx
> > + depends on (BROKEN || BROKEN_ON_SMP)
>
> Would this be a separate fix?
No, I should have read further above, sorry.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 06/10] powerpc: multiplatformize embedded6xx Kconfig
From: Stephen Rothwell @ 2007-06-12 4:15 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070611233354.289486461@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
On Tue, 12 Jun 2007 01:28:30 +0200 arnd@arndb.de wrote:
>
> The existing embedded 6xx platforms will happily coexist
> with each other in a single kernel if you let them.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/Kconfig
> +++ linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
> @@ -1,9 +1,10 @@
> -choice
> - prompt "Machine Type"
> - depends on EMBEDDED6xx
> +config EMBEDDED6xx
> + bool "Embedded 6xx"
>
> config LINKSTATION
> bool "Linkstation / Kurobox(HG) from Buffalo"
> + depends on EMBEDDED6xx
> + depends on (BROKEN || BROKEN_ON_SMP)
Would this be a separate fix?
> select MPIC
> select FSL_SOC
> select PPC_UDBG_16550 if SERIAL_8250
> @@ -17,6 +18,8 @@ config LINKSTATION
>
> config MPC7448HPC2
> bool "Freescale MPC7448HPC2(Taiga)"
> + depends on EMBEDDED6xx
> + depends on (BROKEN || BROKEN_ON_SMP)
And this?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 04/10] powerpc: rename add_bridge to avoid namespace clashes
From: Stephen Rothwell @ 2007-06-12 4:11 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070611233354.006513064@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
On Tue, 12 Jun 2007 01:28:28 +0200 arnd@arndb.de wrote:
>
> Many platforms currently define their own add_bridge function, some
> of them globally. This breaks some multiplatform configurations.
> Prefixing each of these functions with the platform name avoids
> this problem.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Index: linux-2.6/arch/powerpc/platforms/82xx/mpc82xx_ads.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/82xx/mpc82xx_ads.c
> +++ linux-2.6/arch/powerpc/platforms/82xx/mpc82xx_ads.c
> @@ -49,7 +49,7 @@
> #include <linux/fs_enet_pd.h>
>
> #include <sysdev/fsl_soc.h>
> -#include <../sysdev/cpm2_pic.h>
> +#include <../../sysdev/cpm2_pic.h>
This is a separate fix and so should be a separate patch. You might also
consider putting that include file in include/asm-powerpc...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 01/10] powerpc: split out CPU specific options into a new Kconfig file
From: Stephen Rothwell @ 2007-06-12 4:02 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070611233353.602822721@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]
On Tue, 12 Jun 2007 01:28:25 +0200 arnd@arndb.de wrote:
>
> -config VIRT_CPU_ACCOUNTING
> - bool "Deterministic task and CPU time accounting"
I am not sure that this belongs with all the rest.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: opb_ethernet driver
From: David Gibson @ 2007-06-12 3:45 UTC (permalink / raw)
To: xu chen; +Cc: linuxppc-dev
In-Reply-To: <22250.22723.qm@web92006.mail.cnb.yahoo.com>
On Mon, Jun 11, 2007 at 10:37:55AM +0800, xu chen wrote:
> Hello.
> I'm porting an opb_ethernet driver to my ml403 board now, using the 2.6.17 kernel. I know the ethernet support 3 mode: No DMA, simple DMA, scatter gather DMA, when I use the No DMA mode, we can write the skb into the FIFO, but can't ping other PCs in the network. When I use the simple DMA mode, at the time of ping, in the driver, we should initialize the DMA channel, but when transfering the skb, the DMA returns a "DMA bus time out" signal.
> Now I'm worry about it. Who had encountered the problem before? I think I need some help.
What's an opb_ethernet?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Michael Ellerman @ 2007-06-12 2:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <a2b3134aaf411c43fabdb6bba233f91a@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
On Fri, 2007-06-08 at 22:16 +0200, Segher Boessenkool wrote:
> > If you do
> >
> > for_each_compatible_node(node, NULL, "foo") {
> > do_something(node);
> > }
> >
> > then the reference count is held just as long as the do_something()
> > function is run,
>
> Yeah. so (like we discussed on irc) the of_node_get() in
> the code under discussion should really be done inside the
> axon_msi_setup_one() function.
Yep.
> > and if you do
> >
> > for_each_compatible_node(node, NULL, "foo")
> > if (conditional_func(node))
> > break;
> >
> > then the node variable will have the reference count.
>
> Yes. This is bad form though, "for_each" means for
> _each_, open coding the loop would be clearer IMHO.
No. That just means more places people can get the refcounting wrong.
If in doubt, just do:
for_each_compatible_node(node, NULL, "foo") {
..
}
...
of_node_put(node);
And then you're free to do whatever inside the loop, including breaking
out.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Michael Ellerman @ 2007-06-12 2:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <e098552c6ae6fa48212a951ec644b80f@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
On Fri, 2007-06-08 at 22:06 +0200, Segher Boessenkool wrote:
> >> That wasn't my question though?
> >
> > Sorry, I misread this. The of_node_get is done because we keep
> > a reference to the device node in the axon_msic struct. There is
> > no module_exit function in the driver that could clean up the
> > axon_msic, so we must never have an of_node_put as far as I
> > understand.
>
> >>>>>> + if (axon_msi_setup_one(of_node_get(node)) == 0)
> >>>>>> + found++;
>
> What if axon_msi_setup_one() returns an error? Sounds
> to me like the get() should be inside that function no
> matter what?
It drops the ref if there's an error.
> If the reference counting isn't obvious, it is obviously
> wrong ;-)
But if it is obvious it may well be unobviously wrong, which is
better? ;)
I'll rework it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* unsubscribe
From: Alexander Baldeck @ 2007-06-12 1:14 UTC (permalink / raw)
To: linuxppc-dev
^ permalink raw reply
* PATCH improve worst case module load times
From: Brian Behlendorf @ 2007-06-12 1:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
Recently I ran in to an apparently well known ppc/ppc64 issue regarding slow
module load times which I see was posted to lkml back on '05.
http://lkml.org/lkml/2005/9/28/180
In my environment I'm forced to live with a few very large kernel modules
and frequent reboots so this was become a bit of an issue. I took a look at
the root cause and put together a patch to address the issue. The proposed
patch resolves the problem by removing the order(n^2) algorithm and replaces
it with an order(n) chained hash.
It works well for me but I'm not a powerpc guru so I'd appreciate a review
of the patch. I thought about posting it to lkml but after I learned there
was a ppc dev list this seemed like the right place to post.
--
Thanks,
Brian Behlendorf
behlendorf1@llnl.gov
[-- Attachment #2: powerpc-reloc.diff --]
[-- Type: text/x-diff, Size: 11546 bytes --]
Author: Brian Behlendorf <behlendorf1@llnl.gov>, LLNL
Date: Mon Jun 11 2007
For ppc and ppc64 replace the O(N^2) algorithm used to calculate unique
relocations with a O(N) chained hash. The only significant downside to
the new algorithm is that is requires at least one memory allocation.
Allocation size is limited to a single page and the kernel is given every
opportunity to satisfy the request. In the unlikely event of a memory
allocation failure the module will fail to load and -ENOMEM will be
returned up the stack.
The performance improvement on my embedded ppc dev system was dramatic.
Without the patch it took 35 seconds to load the desired module stack
which contained a few worst case modules with a large number of
relocatable symbols. With the patch the time dropped to less than 1
second.
While I didn't do any extensive testing the small module case may be
slightly impacted due to the addition of the page alloc. If this is
a concern the patch could be reworked to choose either the O(N^2) or
O(N) algorithm based on the number of symbols. This would give us
the best of both worlds.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
--- arch/powerpc/kernel/module_64.c.orig 2007-06-11 11:13:23.877345417 -0700
+++ arch/powerpc/kernel/module_64.c 2007-06-11 14:22:23.287707424 -0700
@@ -77,30 +77,15 @@
0x4e, 0x80, 0x04, 0x20 /* bctr */
} };
-/* Count how many different 24-bit relocations (different symbol,
- different addend) */
-static unsigned int count_relocs(const Elf64_Rela *rela, unsigned int num)
-{
- unsigned int i, j, ret = 0;
-
- /* FIXME: Only count external ones --RR */
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
- for (i = 0; i < num; i++) {
- /* Only count 24-bit relocs, others don't need stubs */
- if (ELF64_R_TYPE(rela[i].r_info) != R_PPC_REL24)
- continue;
- for (j = 0; j < i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (rela[i].r_info == rela[j].r_info
- && rela[i].r_addend == rela[j].r_addend)
- break;
- }
- if (j == i) ret++;
- }
- return ret;
-}
+#define HASH_RELOC_NEXT (PAGE_SIZE / sizeof(Elf64_Rela *) - 1)
+
+struct hash_reloc {
+ /* Page full of Elf64_Rela pointers; increasing the hash depth is
+ * accomplished by chaining pages of the ptr element in the page. */
+ Elf64_Rela **r_page;
+ int r_depth;
+ int r_duplicate;
+};
void *module_alloc(unsigned long size)
{
@@ -118,12 +103,112 @@
table entries. */
}
+/* Hash function for unique relocations */
+static unsigned hash_reloc_key(const Elf64_Rela *r)
+{
+ return ((ELF64_R_SYM(r->r_info) + r->r_addend) % HASH_RELOC_NEXT);
+}
+
+/* Hash insert can return -errno or number of inserted elements,
+ * duplicate elements will not be inserted in the hash and return 0. */
+static long hash_reloc_insert(struct hash_reloc *hash,
+ Elf64_Rela *r1, unsigned key)
+{
+ Elf64_Rela **p1 = hash->r_page, **p2 = NULL;
+ unsigned i = 0;
+
+ while (p1 && p1[key]) {
+
+ /* Check for duplicates */
+ if ((r1->r_info == p1[key]->r_info) &&
+ (r1->r_addend == p1[key]->r_addend)) {
+ hash->r_duplicate++;
+ return 0;
+ }
+
+ p2 = p1;
+ p1 = (Elf64_Rela **)p2[HASH_RELOC_NEXT];
+ i++;
+ }
+
+ if (i >= hash->r_depth) {
+ p1 = (Elf64_Rela **)get_zeroed_page(GFP_KERNEL);
+ if (!p1) {
+ printk("Unable to allocate memory for module\n");
+ return -ENOMEM;
+ }
+
+ hash->r_depth++;
+ p2[HASH_RELOC_NEXT] = (Elf64_Rela *)p1;
+ }
+
+ p1[key] = r1;
+ return 1;
+}
+
+static long hash_reloc_init(struct hash_reloc *hash)
+{
+ if (!(hash->r_page = (Elf64_Rela **)get_zeroed_page(GFP_KERNEL))) {
+ printk("Unable to allocate memory for module\n");
+ return -ENOMEM;
+ }
+
+ hash->r_depth = 1;
+ hash->r_duplicate = 0;
+ return 0;
+}
+
+static void hash_reloc_cleanup(struct hash_reloc *hash)
+{
+ Elf64_Rela **p1, **p2;
+
+ p1 = hash->r_page;
+ while (p1) {
+ p2 = (Elf64_Rela **)p1[HASH_RELOC_NEXT];
+ free_page((unsigned long)p1);
+ p1 = p2;
+ }
+}
+
+/* Count how many unique 24-bit relocations (different symbol and addend) */
+static long count_relocs(const Elf64_Rela *rela, unsigned int num)
+{
+ struct hash_reloc hash;
+ Elf64_Rela *r;
+ long rc, ret = 0;
+ unsigned i, key;
+
+ hash_reloc_init(&hash);
+
+ /* Use a chained hash with a uniform key for an order(N) algorithm */
+ for (i = 0; i < num; i++) {
+ r = (Elf64_Rela *)&rela[i];
+ key = hash_reloc_key(r);
+
+ /* Only count 24-bit relocs, others don't need stubs */
+ if (ELF64_R_TYPE(r->r_info) != R_PPC_REL24)
+ continue;
+
+ if ((rc = hash_reloc_insert(&hash, r, key)) < 0) {
+ ret = rc;
+ break;
+ }
+
+ ret += rc;
+ }
+
+ DEBUGP("Symbols %d, duplicates %d, depth %d\n",
+ num, hash.r_duplicate, hash.r_depth);
+ hash_reloc_cleanup(&hash);
+ return ret;
+}
+
/* Get size of potential trampolines required. */
-static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
- const Elf64_Shdr *sechdrs)
+static long get_stubs_size(const Elf64_Ehdr *hdr,
+ const Elf64_Shdr *sechdrs)
{
/* One extra reloc so it's always 0-funcaddr terminated */
- unsigned long relocs = 1;
+ long rc, ret = sizeof(struct ppc64_stub_entry);
unsigned i;
/* Every relocated section... */
@@ -133,14 +218,17 @@
DEBUGP("Ptr: %p. Number: %lu\n",
(void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size / sizeof(Elf64_Rela));
- relocs += count_relocs((void *)sechdrs[i].sh_addr,
- sechdrs[i].sh_size
- / sizeof(Elf64_Rela));
+ rc = count_relocs((void *)sechdrs[i].sh_addr,
+ sechdrs[i].sh_size /
+ sizeof(Elf64_Rela));
+ if (rc < 0)
+ return rc;
+
+ ret += (rc * sizeof(struct ppc64_stub_entry));
}
}
- DEBUGP("Looks like a total of %lu stubs, max\n", relocs);
- return relocs * sizeof(struct ppc64_stub_entry);
+ return ret;
}
static void dedotify_versions(struct modversion_info *vers,
@@ -172,7 +260,8 @@
char *secstrings,
struct module *me)
{
- unsigned int i;
+ unsigned i;
+ long rc;
/* Find .toc and .stubs sections, symtab and strtab */
for (i = 1; i < hdr->e_shnum; i++) {
@@ -209,7 +298,10 @@
me->arch.toc_section = me->arch.stubs_section;
/* Override the stubs size */
- sechdrs[me->arch.stubs_section].sh_size = get_stubs_size(hdr, sechdrs);
+ if ((rc = get_stubs_size(hdr, sechdrs)) < 0)
+ return rc;
+
+ sechdrs[me->arch.stubs_section].sh_size = rc;
return 0;
}
--- arch/powerpc/kernel/module_32.c.orig 2007-06-11 13:24:52.440788813 -0700
+++ arch/powerpc/kernel/module_32.c 2007-06-11 14:13:07.998973232 -0700
@@ -35,6 +35,16 @@
LIST_HEAD(module_bug_list);
+#define HASH_RELOC_NEXT (PAGE_SIZE / sizeof(Elf32_Rela *) - 1)
+
+struct hash_reloc {
+ /* Page full of Elf32_Rela pointers; increasing the hash depth is
+ * accomplished by chaining pages of the ptr element in the page. */
+ Elf32_Rela **r_page;
+ int r_depth;
+ int r_duplicate;
+};
+
void *module_alloc(unsigned long size)
{
if (size == 0)
@@ -50,36 +60,109 @@
table entries. */
}
-/* Count how many different relocations (different symbol, different
- addend) */
-static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
+/* Hash function for unique relocations */
+static unsigned hash_reloc_key(const Elf32_Rela *r)
+{
+ return ((ELF32_R_SYM(r->r_info) + r->r_addend) % HASH_RELOC_NEXT);
+}
+
+/* Hash insert can return -errno or number of inserted elements,
+ * duplicate elements will not be inserted in the hash and return 0. */
+static long hash_reloc_insert(struct hash_reloc *hash,
+ Elf32_Rela *r1, unsigned key)
+{
+ Elf32_Rela **p1 = hash->r_page, **p2 = NULL;
+ unsigned i = 0;
+
+ while (p1 && p1[key]) {
+
+ /* Check for duplicates */
+ if (ELF32_R_SYM(r1->r_info) == ELF32_R_SYM(p1[key]->r_info) &&
+ r1->r_addend == p1[key]->r_addend) {
+ hash->r_duplicate++;
+ return 0;
+ }
+
+ p2 = p1;
+ p1 = (Elf32_Rela **)p2[HASH_RELOC_NEXT];
+ i++;
+ }
+
+ if (i >= hash->r_depth) {
+ p1 = (Elf32_Rela **)get_zeroed_page(GFP_KERNEL);
+ if (!p1) {
+ printk("Unable to allocate memory for module\n");
+ return -ENOMEM;
+ }
+
+ hash->r_depth++;
+ p2[HASH_RELOC_NEXT] = (Elf32_Rela *)p1;
+ }
+
+ p1[key] = r1;
+ return 1;
+}
+
+static long hash_reloc_init(struct hash_reloc *hash)
{
- unsigned int i, j, ret = 0;
+ if (!(hash->r_page = (Elf32_Rela **)get_zeroed_page(GFP_KERNEL))) {
+ printk("Unable to allocate memory for module\n");
+ return -ENOMEM;
+ }
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
+ hash->r_depth = 1;
+ hash->r_duplicate = 0;
+ return 0;
+}
+
+static void hash_reloc_cleanup(struct hash_reloc *hash)
+{
+ Elf32_Rela **p1, **p2;
+
+ p1 = hash->r_page;
+ while (p1) {
+ p2 = (Elf32_Rela **)p1[HASH_RELOC_NEXT];
+ free_page((unsigned long)p1);
+ p1 = p2;
+ }
+}
+
+/* Count how many unique relocations (different symbol and addend) */
+static long count_relocs(const Elf32_Rela *rela, unsigned int num)
+{
+ struct hash_reloc hash;
+ Elf32_Rela *r;
+ long rc, ret = 0;
+ unsigned i, key;
+
+ hash_reloc_init(&hash);
+
+ /* Use a chained hash with a uniform key for an order(N) algorithm */
for (i = 0; i < num; i++) {
- for (j = 0; j < i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (ELF32_R_SYM(rela[i].r_info)
- == ELF32_R_SYM(rela[j].r_info)
- && rela[i].r_addend == rela[j].r_addend)
- break;
+ r = (Elf32_Rela *)&rela[i];
+ key = hash_reloc_key(r);
+ if ((rc = hash_reloc_insert(&hash, r, key)) < 0) {
+ ret = rc;
+ break;
}
- if (j == i) ret++;
+
+ ret += rc;
}
+
+ DEBUGP("Symbols %d, duplicates %d, depth %d\n",
+ num, hash.r_duplicate, hash.r_depth);
+ hash_reloc_cleanup(&hash);
return ret;
}
/* Get the potential trampolines size required of the init and
non-init sections */
-static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
+static long get_plt_size(const Elf32_Ehdr *hdr,
const Elf32_Shdr *sechdrs,
const char *secstrings,
int is_init)
{
- unsigned long ret = 0;
+ long rc, ret = 0;
unsigned i;
/* Everything marked ALLOC (this includes the exported
@@ -100,11 +183,13 @@
DEBUGP("Ptr: %p. Number: %u\n",
(void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela));
- ret += count_relocs((void *)hdr
- + sechdrs[i].sh_offset,
- sechdrs[i].sh_size
- / sizeof(Elf32_Rela))
- * sizeof(struct ppc_plt_entry);
+ rc = count_relocs((void *)hdr + sechdrs[i].sh_offset,
+ sechdrs[i].sh_size /
+ sizeof(Elf32_Rela));
+ if (rc < 0)
+ return rc;
+
+ ret += (rc * sizeof(struct ppc_plt_entry));
}
}
@@ -116,7 +201,8 @@
char *secstrings,
struct module *me)
{
- unsigned int i;
+ unsigned i;
+ long rc;
/* Find .plt and .init.plt sections */
for (i = 0; i < hdr->e_shnum; i++) {
@@ -131,10 +217,15 @@
}
/* Override their sizes */
- sechdrs[me->arch.core_plt_section].sh_size
- = get_plt_size(hdr, sechdrs, secstrings, 0);
- sechdrs[me->arch.init_plt_section].sh_size
- = get_plt_size(hdr, sechdrs, secstrings, 1);
+ if ((rc = get_plt_size(hdr, sechdrs, secstrings, 0)) < 0)
+ return rc;
+
+ sechdrs[me->arch.core_plt_section].sh_size = rc;
+
+ if ((rc = get_plt_size(hdr, sechdrs, secstrings, 1)) < 0)
+ return rc;
+
+ sechdrs[me->arch.init_plt_section].sh_size = rc;
return 0;
}
^ permalink raw reply
* [patch 08/10] powerpc: multiplatformize 85xx Kconfig
From: arnd @ 2007-06-11 23:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070611232824.489103547@arndb.de>
The various e500 platforms can be built in a single kernel,
as long as a small conflict in the header files is resolved.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/85xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/85xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/85xx/Kconfig
@@ -1,28 +1,27 @@
-choice
- prompt "Machine Type"
- depends on PPC_85xx
- default MPC8540_ADS
-
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
+ depends on PPC_85xx
select DEFAULT_UIMAGE
help
This option enables support for the MPC 8540 ADS board
config MPC8560_ADS
bool "Freescale MPC8560 ADS"
+ depends on PPC_85xx
select DEFAULT_UIMAGE
help
This option enables support for the MPC 8560 ADS board
config MPC85xx_CDS
bool "Freescale MPC85xx CDS"
+ depends on PPC_85xx
select DEFAULT_UIMAGE
help
This option enables support for the MPC85xx CDS board
config MPC85xx_MDS
bool "Freescale MPC85xx MDS"
+ depends on PPC_85xx
select DEFAULT_UIMAGE
# select QUICC_ENGINE
help
@@ -30,12 +29,11 @@ config MPC85xx_MDS
config MPC8544_DS
bool "Freescale MPC8544 DS"
+ depends on PPC_85xx
select DEFAULT_UIMAGE
help
This option enables support for the MPC8544 DS board
-endchoice
-
config MPC8540
bool
select PPC_UDBG_16550
Index: linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_ads.h
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/85xx/mpc85xx_ads.h
+++ linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_ads.h
@@ -29,14 +29,14 @@
#define MPC85xx_CPM_OFFSET (0x80000)
#define CPM_MAP_ADDR (get_immrbase() + MPC85xx_CPM_OFFSET)
-#define CPM_IRQ_OFFSET 60
+#define MPC85xxADS_CPM_IRQ_OFFSET 60
-#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
-#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC1 ((uint)0x28+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC2 ((uint)0x29+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC3 ((uint)0x2a+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
+#define SIU_INT_SMC1 ((uint)0x04+MPC85xxADS_CPM_IRQ_OFFSET)
+#define SIU_INT_SMC2 ((uint)0x05+MPC85xxADS_CPM_IRQ_OFFSET)
+#define SIU_INT_SCC1 ((uint)0x28+MPC85xxADS_CPM_IRQ_OFFSET)
+#define SIU_INT_SCC2 ((uint)0x29+MPC85xxADS_CPM_IRQ_OFFSET)
+#define SIU_INT_SCC3 ((uint)0x2a+MPC85xxADS_CPM_IRQ_OFFSET)
+#define SIU_INT_SCC4 ((uint)0x2b+MPC85xxADS_CPM_IRQ_OFFSET)
/* FCC1 Clock Source Configuration. These can be
* redefined in the board specific file.
Index: linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.h
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/85xx/mpc85xx_cds.h
+++ linux-2.6/arch/powerpc/platforms/85xx/mpc85xx_cds.h
@@ -36,7 +36,7 @@
#define PIRQ1A MPC85xx_IRQ_EXT11
#define NR_8259_INTS 16
-#define CPM_IRQ_OFFSET NR_8259_INTS
+#define MPC85xxCDS_CPM_IRQ_OFFSET NR_8259_INTS
#define MPC85xx_OPENPIC_IRQ_OFFSET 80
--
^ permalink raw reply
* [patch 07/10] powerpc: multiplatformize 52xx configuration
From: arnd @ 2007-06-11 23:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070611232824.489103547@arndb.de>
Efika and Lite5200 can both coexist with other 6xx compatible
configurations, so change the Kconfig allow selecting both
at the same time.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/52xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/52xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/52xx/Kconfig
@@ -1,11 +1,26 @@
config PPC_MPC52xx
- bool
+ bool "Freescale 52xx"
select FSL_SOC
+
+config PPC_EFIKA
+ bool "bPlan Efika 5k2. MPC5200B based computer"
+ depends on PPC_MULTIPLATFORM && PPC32
+ depends on PPC_MPC52xx
+ select PPC_RTAS
+ select RTAS_PROC
+ select PPC_NATIVE
+ default n
+
+config PPC_LITE5200
+ bool "Freescale Lite5200 Eval Board"
+ depends on PPC_MULTIPLATFORM && PPC32
+ depends on PPC_MPC52xx
+ select PPC_MPC5200
default n
config PPC_MPC5200
bool
- select PPC_MPC52xx
+ depends on PPC_MPC52xx
default n
config PPC_MPC5200_BUGFIX
@@ -18,19 +33,4 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
-config PPC_EFIKA
- bool "bPlan Efika 5k2. MPC5200B based computer"
- depends on PPC_MULTIPLATFORM && PPC32
- select PPC_RTAS
- select RTAS_PROC
- select PPC_MPC52xx
- select PPC_NATIVE
- default n
-
-config PPC_LITE5200
- bool "Freescale Lite5200 Eval Board"
- depends on PPC_MULTIPLATFORM && PPC32
- select PPC_MPC5200
- default n
-
--
^ permalink raw reply
* [patch 06/10] powerpc: multiplatformize embedded6xx Kconfig
From: arnd @ 2007-06-11 23:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070611232824.489103547@arndb.de>
The existing embedded 6xx platforms will happily coexist
with each other in a single kernel if you let them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Index: linux-2.6/arch/powerpc/platforms/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/Kconfig
+++ linux-2.6/arch/powerpc/platforms/Kconfig
@@ -12,10 +12,6 @@ config PPC_MULTIPLATFORM
RS/6000 machine, an Apple machine, or a PReP, CHRP,
Maple or Cell-based machine.
-config EMBEDDED6xx
- bool "Embedded 6xx/7xx/7xxx-based board"
- depends on PPC32 && (BROKEN||BROKEN_ON_SMP)
-
config APUS
bool "Amiga-APUS"
depends on PPC32 && BROKEN
@@ -33,7 +29,6 @@ config CLASSIC32
source "arch/powerpc/platforms/pseries/Kconfig"
source "arch/powerpc/platforms/iseries/Kconfig"
source "arch/powerpc/platforms/chrp/Kconfig"
-source "arch/powerpc/platforms/52xx/Kconfig"
source "arch/powerpc/platforms/powermac/Kconfig"
source "arch/powerpc/platforms/prep/Kconfig"
source "arch/powerpc/platforms/maple/Kconfig"
@@ -42,6 +37,7 @@ source "arch/powerpc/platforms/celleb/Kc
source "arch/powerpc/platforms/ps3/Kconfig"
source "arch/powerpc/platforms/cell/Kconfig"
source "arch/powerpc/platforms/8xx/Kconfig"
+source "arch/powerpc/platforms/52xx/Kconfig"
source "arch/powerpc/platforms/82xx/Kconfig"
source "arch/powerpc/platforms/83xx/Kconfig"
source "arch/powerpc/platforms/85xx/Kconfig"
Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -1,9 +1,10 @@
-choice
- prompt "Machine Type"
- depends on EMBEDDED6xx
+config EMBEDDED6xx
+ bool "Embedded 6xx"
config LINKSTATION
bool "Linkstation / Kurobox(HG) from Buffalo"
+ depends on EMBEDDED6xx
+ depends on (BROKEN || BROKEN_ON_SMP)
select MPIC
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
@@ -17,6 +18,8 @@ config LINKSTATION
config MPC7448HPC2
bool "Freescale MPC7448HPC2(Taiga)"
+ depends on EMBEDDED6xx
+ depends on (BROKEN || BROKEN_ON_SMP)
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
@@ -26,6 +29,7 @@ config MPC7448HPC2
config PPC_HOLLY
bool "PPC750GX/CL with TSI10x bridge (Hickory/Holly)"
+ depends on EMBEDDED6xx
select TSI108_BRIDGE
select PPC_UDBG_16550
help
@@ -34,12 +38,12 @@ config PPC_HOLLY
config PPC_PRPMC2800
bool "Motorola-PrPMC2800"
+ depends on EMBEDDED6xx
select MV64X60
select NOT_COHERENT_CACHE
select WANT_DEVICE_TREE
help
This option enables support for the Motorola PrPMC2800 board
-endchoice
config TSI108_BRIDGE
bool
--
^ permalink raw reply
* [patch 10/10] powerpc: autoselect optimal -mcpu= flag by platform
From: arnd @ 2007-06-11 23:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070611232824.489103547@arndb.de>
We can choose the -mcpu= gcc flags for compiling the kernel
based on the platform that we build for. In case of multiplatform
kernels, this chooses a setting for a common subset.
When using a platform type that can use different CPUs, a
new option CONFIG_PPC_CPU_SELECTION can be enabled to select
more specifically which CPUs the kernel will be able to
run on.
This replaces the CONFIG_POWER4_ONLY option with an much more
generic approach.
Also, when CONFIG_PPC_CPU_SELECTION is set, it is now possible
to select a CPU to tune for by means of the -mtune= option.
I tried to be very careful when coding the specific rules into
the Kconfig language, but it would be good to have a few
people sanity-checking them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/4xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/4xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/4xx/Kconfig
@@ -87,6 +87,7 @@ endmenu
# 40x specific CPU modules, selected based on the board above.
config NP405H
bool
+ select CPU_405
#depends on ASH
# OAK doesn't exist but wanted to keep this around for any future 403GCX boards
@@ -94,6 +95,7 @@ config 403GCX
bool
#depends on OAK
select IBM405_ERR51
+ select CPU_403
config 405GP
bool
@@ -102,19 +104,23 @@ config 405GP
config 405EP
bool
+ select CPU_405
config 405GPR
bool
+ select CPU_405
config VIRTEX_II_PRO
bool
select IBM405_ERR77
select IBM405_ERR51
+ select CPU_405
config STB03xxx
bool
select IBM405_ERR77
select IBM405_ERR51
+ select CPU_405
# 40x errata/workaround config symbols, selected by the CPU models above
@@ -168,20 +174,25 @@ config 440EP
bool
select PPC_FPU
select IBM440EP_ERR42
+ select CPU_440
config 440GP
bool
select IBM_NEW_EMAC_ZMII
+ select CPU_440
config 440GX
bool
+ select CPU_440
config 440SP
bool
+ select CPU_440
config 440A
bool
depends on 440GX
+ select CPU_440
default y
# 44x errata/workaround config symbols, selected by the CPU models above
Index: linux-2.6/arch/powerpc/platforms/52xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/52xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/52xx/Kconfig
@@ -1,6 +1,7 @@
config PPC_MPC52xx
bool "Freescale 52xx"
select FSL_SOC
+ depends on 6xx
config PPC_EFIKA
bool "bPlan Efika 5k2. MPC5200B based computer"
@@ -9,6 +10,7 @@ config PPC_EFIKA
select PPC_RTAS
select RTAS_PROC
select PPC_NATIVE
+ select CPU_603e
default n
config PPC_LITE5200
@@ -16,6 +18,7 @@ config PPC_LITE5200
depends on PPC_MULTIPLATFORM && PPC32
depends on PPC_MPC52xx
select PPC_MPC5200
+ select CPU_603e
default n
config PPC_MPC5200
Index: linux-2.6/arch/powerpc/platforms/82xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/82xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/82xx/Kconfig
@@ -1,6 +1,7 @@
config PPC_82xx
bool "Freescale 82xx"
depends on PPC_MULTIPLATFORM && 6xx
+ select CPU_603e
config MPC82xx_ADS
bool "Freescale MPC82xx ADS"
Index: linux-2.6/arch/powerpc/platforms/83xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/83xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/83xx/Kconfig
@@ -4,6 +4,7 @@ config PPC_83xx
select FSL_SOC
select 83xx
select WANT_DEVICE_TREE
+ select CPU_603e
config MPC8313_RDB
bool "Freescale MPC8313 RDB"
Index: linux-2.6/arch/powerpc/platforms/86xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/86xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/86xx/Kconfig
@@ -4,6 +4,7 @@ config PPC_86xx
select FSL_SOC
select FSL_PCIE
select ALTIVEC
+ select CPU_74xx
help
The Freescale E600 SoCs have 74xx cores.
Index: linux-2.6/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/Kconfig.cputype
+++ linux-2.6/arch/powerpc/platforms/Kconfig.cputype
@@ -45,9 +45,232 @@ config E200
endchoice
-config POWER4_ONLY
- bool "Optimize for POWER4"
+config PPC_CPU_SELECTION
+ bool "Advanced CPU selection"
+
+config CPU_DEFAULT
+ bool "Don't specify -mcpu= to gcc" if PPC_CPU_SELECTION
+
+config CPU_RS64
+ bool "RS64" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES || PPC_ISERIES
+
+config CPU_POWER3
+ bool "IBM Power3" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES || PPC_ISERIES
+
+config CPU_POWER4
+ bool "IBM Power4" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES || PPC_ISERIES
+
+config CPU_POWER5
+ bool "IBM Power5" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+
+config CPU_POWER6
+ bool "IBM Power6" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+ select ALTIVEC
+
+config CPU_970
+ bool "IBM PowerPC 970 (G5)" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+ select ALTIVEC
+
+config CPU_CELL
+ bool "Sony/Toshiba/IBM Cell Broadband Engine" if PPC_CPU_SELECTION
depends on PPC64
+ select ALTIVEC
+
+config CPU_PA6T
+ bool "PA Semi PA6T-1682M" if PPC_CPU_SELECTION
+ depends on PPC64
+ select ALTIVEC
+
+config CPU_601
+ bool "PowerPC 601 (G1)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default y if PPC_CHRP || PPC_PREP
+
+config CPU_603e
+ bool "PowerPC 603e, 604, 604e, 52xx, 82xx, 83xx (G2)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default y if PPC_CHRP || PPC_PREP || PPC_PMAC
+
+config CPU_7xx
+ bool "PowerPC 740/750 (G3)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default y if PPC_PMAC
+
+config CPU_74xx
+ bool "PowerPC 74xx, 86xx (G4)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default y if PPC_PMAC
+ select ALTIVEC
+
+config CPU_403
+ bool "AMCC 403" if PPC_CPU_SELECTION
+ depends on 40x
+
+config CPU_405
+ bool "AMCC 405" if PPC_CPU_SELECTION
+ depends on 40x
+
+config CPU_440
+ bool "AMCC 440" if PPC_CPU_SELECTION
+ depends on 44x
+
+choice
+ prompt "Tune for processor type" if PPC_CPU_SELECTION
+ default TUNE_POWER4 if PPC64
+ default TUNE_DEFAULT
+
+config TUNE_DEFAULT
+ bool "Don't specify -mtune= to gcc"
+
+config TUNE_RS64
+ bool "RS64"
+ depends on CPU_RS64
+
+config TUNE_POWER3
+ bool "IBM Power3"
+ depends on CPU_POWER3
+
+config TUNE_POWER4
+ bool "IBM Power4"
+ depends on CPU_POWER4
+
+config TUNE_POWER5
+ bool "IBM Power5"
+ depends on CPU_POWER5
+
+config TUNE_POWER6
+ bool "IBM Power6"
+ depends on CPU_POWER6
+
+config TUNE_970
+ bool "IBM PowerPC 970 (G5)"
+ depends on CPU_970
+
+config TUNE_CELL
+ bool "Sony/Toshiba/IBM Cell Broadband Engine"
+ depends on CPU_CELL
+
+config TUNE_PA6T
+ bool "PA Semi PA6T-1682M"
+ depends on CPU_PA6T
+
+config TUNE_601
+ bool "PowerPC 601 (G1)"
+ depends on CPU_601
+
+config TUNE_603e
+ bool "PowerPC 603e, 604, 604e, 52xx, 82xx, 83xx (G2)"
+ depends on CPU_603e
+
+config TUNE_7xx
+ bool "PowerPC 740/750 (G3)"
+ depends on CPU_7xx
+
+config TUNE_74xx
+ bool "PowerPC 74xx, 86xx (G4)"
+ depends on CPU_74xx
+
+config TUNE_821
+ bool "Freescale MPC821"
+ depends on 8xx
+
+config TUNE_823
+ bool "Freescale MPC823"
+ depends on 8xx
+
+config TUNE_860
+ bool "Freescale MPC860"
+ depends on 8xx
+
+config TUNE_403
+ bool "AMCC 403"
+ depends on CPU_403
+
+config TUNE_405
+ bool "AMCC 405"
+ depends on CPU_405
+
+config TUNE_440
+ bool "AMCC 440"
+ depends on CPU_440
+
+config TUNE_8540
+ bool "Freescale MPC8540"
+ depends on PPC_85xx
+
+config TUNE_E200
+ bool "Freescale e200"
+ depends on E200
+
+endchoice
+
+config PPC_MCPU
+ string
+ default "" if CPU_DEFAULT
+ default "-mcpu=powerpc64" if CPU_POWER3 || CPU_RS64
+ default "-mcpu=power4" if (CPU_POWER5 || CPU_POWER6) && (CPU_970 || CPU_CELL || CPU_PA6T)
+ default "-mcpu=power4" if CPU_POWER4
+ default "-mcpu=power5" if CPU_POWER5
+ default "-mcpu=power6" if CPU_POWER6
+ default "-mcpu=970" if CPU_970
+ default "-mcpu=cell" if CPU_CELL
+ default "-mcpu=pa6t" if CPU_PA6T
+ default "-mcpu=powerpc64" if PPC64
+ default "-mcpu=powerpc" if CPU_601 && (CPU_603e || CPU_7xx || CPU_74xx)
+ default "-mcpu=601" if CPU_601
+ default "-mcpu=603e" if CPU_603e
+ default "-mcpu=750" if CPU_7xx
+ default "-mcpu=7450" if CPU_74xx
+ default "-mcpu=powerpc" if (CPU_403 && CPU_405)
+ default "-mcpu=powerpc" if (CPU_403 || CPU_405) && CPU_440
+ default "-mcpu=403" if CPU_403
+ default "-mcpu=405" if CPU_405
+ default "-mcpu=440" if CPU_440
+ default "-mcpu=860" if PPC_8xx
+ default "-mcpu=8540" if PPC_85xx
+ default "-mcpu=e200" if E200
+ default "-mcpu=powerpc"
+
+config PPC_MTUNE
+ string
+ default "" if TUNE_DEFAULT
+ default "-mtune=power3" if TUNE_POWER3
+ default "-mtune=rs64a" if TUNE_RS64
+ default "-mtune=power4" if TUNE_POWER4
+ default "-mtune=power5" if TUNE_POWER5
+ default "-mtune=power6" if TUNE_POWER6
+ default "-mtune=970" if TUNE_970
+ default "-mtune=cell" if TUNE_CELL
+ default "-mtune=pa6t" if TUNE_PA6T
+ default "-mtune=601" if TUNE_601
+ default "-mtune=603e" if TUNE_603e
+ default "-mtune=750" if TUNE_7xx
+ default "-mtune=7450" if TUNE_74xx
+ default "-mtune=403" if TUNE_403
+ default "-mtune=405" if TUNE_405
+ default "-mtune=440" if TUNE_440
+ default "-mtune=821" if TUNE_821
+ default "-mtune=823" if TUNE_823
+ default "-mtune=860" if TUNE_860
+ default "-mtune=8540" if TUNE_8540
+ default "-mtune=e200" if TUNE_E200
+ default "-mtune=power4" if PPC64
+
+config POWER4_ONLY
+ def_bool y
+ depends on PPC64 && !CPU_POWER3 && !CPU_RS64
default n
---help---
Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
Index: linux-2.6/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux-2.6/arch/powerpc/platforms/cell/Kconfig
@@ -20,6 +20,7 @@ config PPC_IBM_CELL_BLADE
select MMIO_NVRAM
select PPC_UDBG_16550
select UDBG_RTAS_CONSOLE
+ select CPU_CELL
menu "Cell Broadband Engine options"
depends on PPC_CELL
Index: linux-2.6/arch/powerpc/platforms/celleb/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/celleb/Kconfig
+++ linux-2.6/arch/powerpc/platforms/celleb/Kconfig
@@ -2,6 +2,7 @@ config PPC_CELLEB
bool "Toshiba's Cell Reference Set 'Celleb' Architecture"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
+ select CPU_CELL
select PPC_OF_PLATFORM_PCI
select HAS_TXX9_SERIAL
select PPC_UDBG_BEAT
Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -1,5 +1,6 @@
config EMBEDDED6xx
bool "Embedded 6xx"
+ depends on 6xx
config LINKSTATION
bool "Linkstation / Kurobox(HG) from Buffalo"
@@ -9,6 +10,7 @@ config LINKSTATION
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
select DEFAULT_UIMAGE
+ select CPU_603e
help
Select LINKSTATION if configuring for one of PPC- (MPC8241)
based NAS systems from Buffalo Technology. So far only
@@ -23,6 +25,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+ select CPU_74xx
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
@@ -32,6 +35,7 @@ config PPC_HOLLY
depends on EMBEDDED6xx
select TSI108_BRIDGE
select PPC_UDBG_16550
+ select CPU_7xx
help
Select PPC_HOLLY if configuring for an IBM 750GX/CL Eval
Board with TSI108/9 bridge (Hickory/Holly)
@@ -42,6 +46,7 @@ config PPC_PRPMC2800
select MV64X60
select NOT_COHERENT_CACHE
select WANT_DEVICE_TREE
+ select CPU_74xx
help
This option enables support for the Motorola PrPMC2800 board
Index: linux-2.6/arch/powerpc/platforms/maple/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/maple/Kconfig
+++ linux-2.6/arch/powerpc/platforms/maple/Kconfig
@@ -11,6 +11,7 @@ config PPC_MAPLE
select PPC_RTAS
select MMIO_NVRAM
select ATA_NONSTANDARD if ATA
+ select CPU_970
default n
help
This option enables support for the Maple 970FX Evaluation Board.
Index: linux-2.6/arch/powerpc/platforms/pasemi/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pasemi/Kconfig
+++ linux-2.6/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,6 +5,7 @@ config PPC_PASEMI
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
+ select CPU_PA6T
help
This option enables support for PA Semi's PWRficient line
of SoC processors, including PA6T-1682M
Index: linux-2.6/arch/powerpc/platforms/powermac/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/Kconfig
+++ linux-2.6/arch/powerpc/platforms/powermac/Kconfig
@@ -15,6 +15,7 @@ config PPC_PMAC64
select MPIC_U3_HT_IRQS
select GENERIC_TBSYNC
select PPC_970_NAP
+ select CPU_970
default y
Index: linux-2.6/arch/powerpc/platforms/ps3/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/ps3/Kconfig
+++ linux-2.6/arch/powerpc/platforms/ps3/Kconfig
@@ -2,6 +2,7 @@ config PPC_PS3
bool "Sony PS3 (incomplete)"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
+ select CPU_CELL
select USB_ARCH_HAS_OHCI
select USB_OHCI_LITTLE_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO
Index: linux-2.6/arch/powerpc/Makefile
===================================================================
--- linux-2.6.orig/arch/powerpc/Makefile
+++ linux-2.6/arch/powerpc/Makefile
@@ -78,24 +78,23 @@ LINUXINCLUDE += $(LINUXINCLUDE-y)
CHECKFLAGS += -m$(SZ) -D__powerpc__ -D__powerpc$(SZ)__
+OPTFLAGS := $(call cc-option,$(CONFIG_PPC_MCPU)) $(call cc-option,$(CONFIG_PPC_MTUNE))
+
+# compilers older than 4.0.0 can only set -maltivec in 64 bit mode
+# when compiling for 970
ifeq ($(CONFIG_PPC64),y)
GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y"; fi)
-
ifeq ($(CONFIG_POWER4_ONLY),y)
ifeq ($(CONFIG_ALTIVEC),y)
ifeq ($(GCC_BROKEN_VEC),y)
- CFLAGS += $(call cc-option,-mcpu=970)
-else
- CFLAGS += $(call cc-option,-mcpu=power4)
+ OPTFLAGS := $(call cc-option,-mcpu=970) $(call cc-option,$(CONFIG_PPC_MTUNE))
endif
-else
- CFLAGS += $(call cc-option,-mcpu=power4)
endif
-else
- CFLAGS += $(call cc-option,-mtune=power4)
endif
endif
+CFLAGS += $(OPTFLAGS)
+
# No AltiVec instruction when building kernel
CFLAGS += $(call cc-option,-mno-altivec)
@@ -107,10 +106,6 @@ CFLAGS += $(call cc-option,-funit-at-a-t
# often slow when they are implemented at all
CFLAGS += -mno-string
-ifeq ($(CONFIG_6xx),y)
-CFLAGS += -mcpu=powerpc
-endif
-
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
Index: linux-2.6/arch/powerpc/platforms/apus/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/apus/Kconfig
+++ linux-2.6/arch/powerpc/platforms/apus/Kconfig
@@ -1,6 +1,7 @@
config APUS
bool "Amiga-APUS"
depends on PPC32 && BROKEN
+ select CPU_603e
help
Select APUS if configuring for a PowerUP Amiga.
More information is available at:
--
^ permalink raw reply
* [patch 01/10] powerpc: split out CPU specific options into a new Kconfig file
From: arnd @ 2007-06-11 23:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070611232824.489103547@arndb.de>
A lot of the options in arch/powerpc/Kconfig deal with the CPU menu,
and my next patches add more to them. Moving them to a new
arch/powerpc/platforms/Kconfig.cputype file makes it easier to
follow.
There are no functional changes in here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/Kconfig
+++ linux-2.6/arch/powerpc/Kconfig
@@ -4,12 +4,7 @@
mainmenu "Linux/PowerPC Kernel Configuration"
-config PPC64
- bool "64-bit kernel"
- default n
- help
- This option selects whether a 32-bit or a 64-bit kernel
- will be built.
+source "arch/powerpc/platforms/Kconfig.cputype"
config PPC_PM_NEEDS_RTC_LIB
bool
@@ -132,123 +127,6 @@ config PPC64_SWSUSP
depends on PPC64 && (BROKEN || (PPC_PMAC64 && EXPERIMENTAL))
default y
-menu "Processor support"
-choice
- prompt "Processor Type"
- depends on PPC32
- default 6xx
-
-config CLASSIC32
- bool "52xx/6xx/7xx/74xx"
- select PPC_FPU
- select 6xx
- help
- There are four families of PowerPC chips supported. The more common
- types (601, 603, 604, 740, 750, 7400), the Motorola embedded
- versions (821, 823, 850, 855, 860, 52xx, 82xx, 83xx), the AMCC
- embedded versions (403 and 405) and the high end 64 bit Power
- processors (POWER 3, POWER4, and IBM PPC970 also known as G5).
-
- This option is the catch-all for 6xx types, including some of the
- embedded versions. Unless there is see an option for the specific
- chip family you are using, you want this option.
-
- You do not want this if you are building a kernel for a 64 bit
- IBM RS/6000 or an Apple G5, choose 6xx.
-
- If unsure, select this option
-
- Note that the kernel runs in 32-bit mode even on 64-bit chips.
-
-config PPC_82xx
- bool "Freescale 82xx"
- select 6xx
- select PPC_FPU
-
-config PPC_83xx
- bool "Freescale 83xx"
- select 6xx
- select FSL_SOC
- select 83xx
- select PPC_FPU
- select WANT_DEVICE_TREE
-
-config PPC_85xx
- bool "Freescale 85xx"
- select E500
- select FSL_SOC
- select 85xx
- select WANT_DEVICE_TREE
-
-config PPC_86xx
- bool "Freescale 86xx"
- select 6xx
- select FSL_SOC
- select FSL_PCIE
- select PPC_FPU
- select ALTIVEC
- help
- The Freescale E600 SoCs have 74xx cores.
-
-config PPC_8xx
- bool "Freescale 8xx"
- select FSL_SOC
- select 8xx
-
-config 40x
- bool "AMCC 40x"
- select PPC_DCR_NATIVE
-
-config 44x
- bool "AMCC 44x"
- select PPC_DCR_NATIVE
- select WANT_DEVICE_TREE
-
-config E200
- bool "Freescale e200"
-
-endchoice
-
-config POWER4_ONLY
- bool "Optimize for POWER4"
- depends on PPC64
- default n
- ---help---
- Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
- The resulting binary will not work on POWER3 or RS64 processors
- when compiled with binutils 2.15 or later.
-
-config POWER3
- bool
- depends on PPC64
- default y if !POWER4_ONLY
-
-config POWER4
- depends on PPC64
- def_bool y
-
-config 6xx
- bool
-
-# this is temp to handle compat with arch=ppc
-config 8xx
- bool
-
-# this is temp to handle compat with arch=ppc
-config 83xx
- bool
-
-# this is temp to handle compat with arch=ppc
-config 85xx
- bool
-
-config E500
- bool
-
-config PPC_FPU
- bool
- default y if PPC64
-
config PPC_DCR_NATIVE
bool
default n
@@ -267,134 +145,6 @@ config PPC_OF_PLATFORM_PCI
depends on PPC64 # not supported on 32 bits yet
default n
-config 4xx
- bool
- depends on 40x || 44x
- default y
-
-config BOOKE
- bool
- depends on E200 || E500 || 44x
- default y
-
-config FSL_BOOKE
- bool
- depends on E200 || E500
- default y
-
-config PTE_64BIT
- bool
- depends on 44x || E500
- default y if 44x
- default y if E500 && PHYS_64BIT
-
-config PHYS_64BIT
- bool 'Large physical address support' if E500
- depends on 44x || E500
- select RESOURCES_64BIT
- default y if 44x
- ---help---
- This option enables kernel support for larger than 32-bit physical
- addresses. This features is not be available on all e500 cores.
-
- If in doubt, say N here.
-
-config ALTIVEC
- bool "AltiVec Support"
- depends on CLASSIC32 || POWER4
- ---help---
- This option enables kernel support for the Altivec extensions to the
- PowerPC processor. The kernel currently supports saving and restoring
- altivec registers, and turning on the 'altivec enable' bit so user
- processes can execute altivec instructions.
-
- This option is only usefully if you have a processor that supports
- altivec (G4, otherwise known as 74xx series), but does not have
- any affect on a non-altivec cpu (it does, however add code to the
- kernel).
-
- If in doubt, say Y here.
-
-config SPE
- bool "SPE Support"
- depends on E200 || E500
- default y
- ---help---
- This option enables kernel support for the Signal Processing
- Extensions (SPE) to the PowerPC processor. The kernel currently
- supports saving and restoring SPE registers, and turning on the
- 'spe enable' bit so user processes can execute SPE instructions.
-
- This option is only useful if you have a processor that supports
- SPE (e500, otherwise known as 85xx series), but does not have any
- effect on a non-spe cpu (it does, however add code to the kernel).
-
- If in doubt, say Y here.
-
-config PPC_STD_MMU
- bool
- depends on 6xx || POWER3 || POWER4 || PPC64
- default y
-
-config PPC_STD_MMU_32
- def_bool y
- depends on PPC_STD_MMU && PPC32
-
-config PPC_MM_SLICES
- bool
- default y if HUGETLB_PAGE
- default n
-
-config VIRT_CPU_ACCOUNTING
- bool "Deterministic task and CPU time accounting"
- depends on PPC64
- default y
- help
- Select this option to enable more accurate task and CPU time
- accounting. This is done by reading a CPU counter on each
- kernel entry and exit and on transitions within the kernel
- between system, softirq and hardirq state, so there is a
- small performance impact. This also enables accounting of
- stolen time on logically-partitioned systems running on
- IBM POWER5-based machines.
-
- If in doubt, say Y here.
-
-config SMP
- depends on PPC_STD_MMU
- bool "Symmetric multi-processing support"
- ---help---
- This enables support for systems with more than one CPU. If you have
- a system with only one CPU, say N. If you have a system with more
- than one CPU, say Y. Note that the kernel does not currently
- support SMP machines with 603/603e/603ev or PPC750 ("G3") processors
- since they have inadequate hardware support for multiprocessor
- operation.
-
- If you say N here, the kernel will run on single and multiprocessor
- machines, but will use only one CPU of a multiprocessor machine. If
- you say Y here, the kernel will run on single-processor machines.
- On a single-processor machine, the kernel will run faster if you say
- N here.
-
- If you don't know what to do here, say N.
-
-config NR_CPUS
- int "Maximum number of CPUs (2-128)"
- range 2 128
- depends on SMP
- default "32" if PPC64
- default "4"
-
-config NOT_COHERENT_CACHE
- bool
- depends on 4xx || 8xx || E200
- default y
-
-config CONFIG_CHECK_CACHE_COHERENCY
- bool
-endmenu
-
source "init/Kconfig"
source "arch/powerpc/platforms/Kconfig"
Index: linux-2.6/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- /dev/null
+++ linux-2.6/arch/powerpc/platforms/Kconfig.cputype
@@ -0,0 +1,252 @@
+config PPC64
+ bool "64-bit kernel"
+ default n
+ help
+ This option selects whether a 32-bit or a 64-bit kernel
+ will be built.
+
+menu "Processor support"
+choice
+ prompt "Processor Type"
+ depends on PPC32
+ default 6xx
+
+config CLASSIC32
+ bool "52xx/6xx/7xx/74xx"
+ select PPC_FPU
+ select 6xx
+ help
+ There are four families of PowerPC chips supported. The more common
+ types (601, 603, 604, 740, 750, 7400), the Motorola embedded
+ versions (821, 823, 850, 855, 860, 52xx, 82xx, 83xx), the AMCC
+ embedded versions (403 and 405) and the high end 64 bit Power
+ processors (POWER 3, POWER4, and IBM PPC970 also known as G5).
+
+ This option is the catch-all for 6xx types, including some of the
+ embedded versions. Unless there is see an option for the specific
+ chip family you are using, you want this option.
+
+ You do not want this if you are building a kernel for a 64 bit
+ IBM RS/6000 or an Apple G5, choose 6xx.
+
+ If unsure, select this option
+
+ Note that the kernel runs in 32-bit mode even on 64-bit chips.
+
+config PPC_82xx
+ bool "Freescale 82xx"
+ select 6xx
+ select PPC_FPU
+
+config PPC_83xx
+ bool "Freescale 83xx"
+ select 6xx
+ select FSL_SOC
+ select 83xx
+ select PPC_FPU
+ select WANT_DEVICE_TREE
+
+config PPC_85xx
+ bool "Freescale 85xx"
+ select E500
+ select FSL_SOC
+ select 85xx
+ select WANT_DEVICE_TREE
+
+config PPC_86xx
+ bool "Freescale 86xx"
+ select 6xx
+ select FSL_SOC
+ select FSL_PCIE
+ select PPC_FPU
+ select ALTIVEC
+ help
+ The Freescale E600 SoCs have 74xx cores.
+
+config PPC_8xx
+ bool "Freescale 8xx"
+ select FSL_SOC
+ select 8xx
+
+config 40x
+ bool "AMCC 40x"
+ select PPC_DCR_NATIVE
+
+config 44x
+ bool "AMCC 44x"
+ select PPC_DCR_NATIVE
+ select WANT_DEVICE_TREE
+
+config E200
+ bool "Freescale e200"
+
+endchoice
+
+config POWER4_ONLY
+ bool "Optimize for POWER4"
+ depends on PPC64
+ default n
+ ---help---
+ Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
+ The resulting binary will not work on POWER3 or RS64 processors
+ when compiled with binutils 2.15 or later.
+
+config POWER3
+ bool
+ depends on PPC64
+ default y if !POWER4_ONLY
+
+config POWER4
+ depends on PPC64
+ def_bool y
+
+config 6xx
+ bool
+
+# this is temp to handle compat with arch=ppc
+config 8xx
+ bool
+
+# this is temp to handle compat with arch=ppc
+config 83xx
+ bool
+
+# this is temp to handle compat with arch=ppc
+config 85xx
+ bool
+
+config E500
+ bool
+
+config PPC_FPU
+ bool
+ default y if PPC64
+
+config 4xx
+ bool
+ depends on 40x || 44x
+ default y
+
+config BOOKE
+ bool
+ depends on E200 || E500 || 44x
+ default y
+
+config FSL_BOOKE
+ bool
+ depends on E200 || E500
+ default y
+
+config PTE_64BIT
+ bool
+ depends on 44x || E500
+ default y if 44x
+ default y if E500 && PHYS_64BIT
+
+config PHYS_64BIT
+ bool 'Large physical address support' if E500
+ depends on 44x || E500
+ select RESOURCES_64BIT
+ default y if 44x
+ ---help---
+ This option enables kernel support for larger than 32-bit physical
+ addresses. This features is not be available on all e500 cores.
+
+ If in doubt, say N here.
+
+config ALTIVEC
+ bool "AltiVec Support"
+ depends on CLASSIC32 || POWER4
+ ---help---
+ This option enables kernel support for the Altivec extensions to the
+ PowerPC processor. The kernel currently supports saving and restoring
+ altivec registers, and turning on the 'altivec enable' bit so user
+ processes can execute altivec instructions.
+
+ This option is only usefully if you have a processor that supports
+ altivec (G4, otherwise known as 74xx series), but does not have
+ any affect on a non-altivec cpu (it does, however add code to the
+ kernel).
+
+ If in doubt, say Y here.
+
+config SPE
+ bool "SPE Support"
+ depends on E200 || E500
+ default y
+ ---help---
+ This option enables kernel support for the Signal Processing
+ Extensions (SPE) to the PowerPC processor. The kernel currently
+ supports saving and restoring SPE registers, and turning on the
+ 'spe enable' bit so user processes can execute SPE instructions.
+
+ This option is only useful if you have a processor that supports
+ SPE (e500, otherwise known as 85xx series), but does not have any
+ effect on a non-spe cpu (it does, however add code to the kernel).
+
+ If in doubt, say Y here.
+
+config PPC_STD_MMU
+ bool
+ depends on 6xx || POWER3 || POWER4 || PPC64
+ default y
+
+config PPC_STD_MMU_32
+ def_bool y
+ depends on PPC_STD_MMU && PPC32
+
+config PPC_MM_SLICES
+ bool
+ default y if HUGETLB_PAGE
+ default n
+
+config VIRT_CPU_ACCOUNTING
+ bool "Deterministic task and CPU time accounting"
+ depends on PPC64
+ default y
+ help
+ Select this option to enable more accurate task and CPU time
+ accounting. This is done by reading a CPU counter on each
+ kernel entry and exit and on transitions within the kernel
+ between system, softirq and hardirq state, so there is a
+ small performance impact. This also enables accounting of
+ stolen time on logically-partitioned systems running on
+ IBM POWER5-based machines.
+
+ If in doubt, say Y here.
+
+config SMP
+ depends on PPC_STD_MMU
+ bool "Symmetric multi-processing support"
+ ---help---
+ This enables support for systems with more than one CPU. If you have
+ a system with only one CPU, say N. If you have a system with more
+ than one CPU, say Y. Note that the kernel does not currently
+ support SMP machines with 603/603e/603ev or PPC750 ("G3") processors
+ since they have inadequate hardware support for multiprocessor
+ operation.
+
+ If you say N here, the kernel will run on single and multiprocessor
+ machines, but will use only one CPU of a multiprocessor machine. If
+ you say Y here, the kernel will run on single-processor machines.
+ On a single-processor machine, the kernel will run faster if you say
+ N here.
+
+ If you don't know what to do here, say N.
+
+config NR_CPUS
+ int "Maximum number of CPUs (2-128)"
+ range 2 128
+ depends on SMP
+ default "32" if PPC64
+ default "4"
+
+config NOT_COHERENT_CACHE
+ bool
+ depends on 4xx || 8xx || E200
+ default y
+
+config CONFIG_CHECK_CACHE_COHERENCY
+ bool
+
+endmenu
--
^ 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