* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 1:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
On Fri, 25 Jan 2008 10:55:25 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
> Just a reminder that the plan is to remove arch/ppc this summer (June
> 2008). The following boards still existing over in arch/ppc. Some of
> them have been ported over to arch/powerpc. If you care about one of
> these boards and its not ported speak up (it helps if you have access
> to the board). Also, if you know a given board is free to die of
> bitrot let us know so we know not to worry about it:
> 4xx:
> BAMBOO
Ported (mostly)
> CPCI405
Doubt this will be ported.
> EBONY
Ported (mostly)
> EP405
Ported (mostly)
> BUBINGA
> LUAN
No idea on these.
> YUCCA
Yucca was what again? 440spe?
> OCOTEA
This one will be ported soon. I have an ocotea now.
> REDWOOD_5
> REDWOOD_6
Don't have either of these.
> SYCAMORE
I think Mathias was working on a 405gpr port somewhere.
> TAISHAN
> WALNUT
Ported (mostly)
> XILINX_ML300
> XILINX_ML403
Grant should have these in decent shape.
josh
^ permalink raw reply
* Re: [RFC][PATCH] remove section mappinng
From: Paul Mackerras @ 2008-01-26 1:24 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linux-mm, linuxppc-dev, anton
In-Reply-To: <1201277105.26929.36.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty writes:
> Here is the code I cooked up, it seems to be working fine.
> But I have concerns where I need your help.
>
> In order to invalidate htab entries, we need to find the "slot".
> But I can only find the hpte group. Is it okay to invalidate the
> first entry in the group ? Do I need to invalidate the entire group ?
You do need to find the correct slot. (I suppose you could invalidate
the entire group, but that would be pretty gross.)
Note that in the CONFIG_DEBUG_PAGEALLOC case we use 4k pages and keep
a map of the slot numbers in linear_map_hash_slots[]. But in that
case I assume that the generic code would have already unmapped all
the pages of the LMB that you're trying to hot-unplug.
In the non-DEBUG_PAGEALLOC case on a System p machine, the hash table
will be big enough that the linear mapping entries should always be in
slot 0. So just invalidating slot 0 would probably work in practice,
but it seems pretty fragile. We might want to use your new
htab_remove_mapping() function on a bare-metal system with a smaller
hash table in future, for instance.
Have a look at pSeries_lpar_hpte_updateboltedpp. It calls
pSeries_lpar_hpte_find to find the slot for a bolted HPTE. You could
do something similar. In fact maybe the best approach is to do a
pSeries_lpar_hpte_remove_bolted() and not try to solve the more
general problem.
Paul.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Roland Dreier @ 2008-01-26 1:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <20080125192150.4cde6fac@zod.rchland.ibm.com>
> > YUCCA
>
> Yucca was what again? 440spe?
Yes, it was the first 440SPe eval board; since replaced by Katmai.
I have a Yucca and can at least test thing; if no one else gets to it,
I may try to port it to arch/powerpc for 2.6.26.
^ permalink raw reply
* [PATCH] POWERPC: Convert all 86xx DTS files to /dts-v1/ format.
From: Jon Loeliger @ 2008-01-25 22:31 UTC (permalink / raw)
To: linuxppc-dev
Also fixed a few minor indent problems as well.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 227 +++++++++++-----------
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 333 ++++++++++++++++----------------
2 files changed, 281 insertions(+), 279 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index d98715c..16c947b 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -8,6 +8,7 @@
* by the Free Software Foundation.
*/
+/dts-v1/;
/ {
model = "MPC8610HPCD";
@@ -29,11 +30,11 @@
PowerPC,8610@0 {
device_type = "cpu";
reg = <0>;
- d-cache-line-size = <d# 32>; // bytes
- i-cache-line-size = <d# 32>; // bytes
- d-cache-size = <8000>; // L1, 32K
- i-cache-size = <8000>; // L1, 32K
- timebase-frequency = <0>; // 33 MHz, from uboot
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>; // L1
+ i-cache-size = <32768>; // L1
+ timebase-frequency = <0>; // From uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
};
@@ -41,7 +42,7 @@
memory {
device_type = "memory";
- reg = <00000000 20000000>; // 512M at 0x0
+ reg = <0x00000000 0x20000000>; // 512M at 0x0
};
soc@e0000000 {
@@ -50,8 +51,8 @@
#interrupt-cells = <2>;
device_type = "soc";
compatible = "fsl,mpc8610-immr", "simple-bus";
- ranges = <0 e0000000 00100000>;
- reg = <e0000000 1000>;
+ ranges = <0x0 0xe0000000 0x00100000>;
+ reg = <0xe0000000 0x1000>;
bus-frequency = <0>;
i2c@3000 {
@@ -59,17 +60,17 @@
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
- reg = <3000 100>;
- interrupts = <2b 2>;
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
- cs4270:codec@4f {
+ cs4270:codec@4f {
compatible = "cirrus,cs4270";
- reg = <4f>;
+ reg = <0x4f>;
/* MCLK source is a stand-alone oscillator */
- clock-frequency = <bb8000>;
- };
+ clock-frequency = <12288000>;
+ };
};
i2c@3100 {
@@ -77,8 +78,8 @@
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
- reg = <3100 100>;
- interrupts = <2b 2>;
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
@@ -87,9 +88,9 @@
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
- reg = <4500 100>;
+ reg = <0x4500 0x100>;
clock-frequency = <0>;
- interrupts = <2a 2>;
+ interrupts = <42 2>;
interrupt-parent = <&mpic>;
};
@@ -97,9 +98,9 @@
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
- reg = <4600 100>;
+ reg = <0x4600 0x100>;
clock-frequency = <0>;
- interrupts = <1c 2>;
+ interrupts = <28 2>;
interrupt-parent = <&mpic>;
};
@@ -108,7 +109,7 @@
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
- reg = <40000 40000>;
+ reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
@@ -116,16 +117,16 @@
global-utilities@e0000 {
compatible = "fsl,mpc8610-guts";
- reg = <e0000 1000>;
+ reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
i2s@16000 {
compatible = "fsl,mpc8610-ssi";
cell-index = <0>;
- reg = <16000 100>;
+ reg = <0x16000 0x100>;
interrupt-parent = <&mpic>;
- interrupts = <3e 2>;
+ interrupts = <62 2>;
fsl,mode = "i2s-slave";
codec-handle = <&cs4270>;
};
@@ -133,94 +134,94 @@
ssi@16100 {
compatible = "fsl,mpc8610-ssi";
cell-index = <1>;
- reg = <16100 100>;
+ reg = <0x16100 0x100>;
interrupt-parent = <&mpic>;
- interrupts = <3f 2>;
+ interrupts = <63 2>;
};
- dma@21300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,mpc8610-dma", "fsl,eloplus-dma";
- cell-index = <0>;
- reg = <21300 4>; /* DMA general status register */
- ranges = <0 21100 200>;
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8610-dma", "fsl,eloplus-dma";
+ cell-index = <0>;
+ reg = <0x21300 0x4>; /* DMA general status register */
+ ranges = <0x0 0x21100 0x200>;
- dma-channel@0 {
+ dma-channel@0 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,eloplus-dma-channel";
cell-index = <0>;
- reg = <0 80>;
+ reg = <0x0 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <14 2>;
- };
- dma-channel@1 {
+ interrupts = <20 2>;
+ };
+ dma-channel@1 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,eloplus-dma-channel";
cell-index = <1>;
- reg = <80 80>;
+ reg = <0x80 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <15 2>;
- };
- dma-channel@2 {
+ interrupts = <21 2>;
+ };
+ dma-channel@2 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,eloplus-dma-channel";
cell-index = <2>;
- reg = <100 80>;
+ reg = <0x100 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <16 2>;
- };
- dma-channel@3 {
+ interrupts = <22 2>;
+ };
+ dma-channel@3 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,eloplus-dma-channel";
cell-index = <3>;
- reg = <180 80>;
+ reg = <0x180 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <17 2>;
- };
- };
+ interrupts = <23 2>;
+ };
+ };
- dma@c300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
- cell-index = <1>;
- reg = <c300 4>; /* DMA general status register */
- ranges = <0 c100 200>;
+ dma@c300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
+ cell-index = <1>;
+ reg = <0xc300 0x4>; /* DMA general status register */
+ ranges = <0x0 0xc100 0x200>;
- dma-channel@0 {
+ dma-channel@0 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
cell-index = <0>;
- reg = <0 80>;
+ reg = <0x0 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <3c 2>;
- };
- dma-channel@1 {
+ interrupts = <60 2>;
+ };
+ dma-channel@1 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
cell-index = <1>;
- reg = <80 80>;
+ reg = <0x80 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <3d 2>;
- };
- dma-channel@2 {
+ interrupts = <61 2>;
+ };
+ dma-channel@2 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
cell-index = <2>;
- reg = <100 80>;
+ reg = <0x100 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <3e 2>;
- };
- dma-channel@3 {
+ interrupts = <62 2>;
+ };
+ dma-channel@3 {
compatible = "fsl,mpc8610-dma-channel",
"fsl,mpc8540-dma-channel";
cell-index = <3>;
- reg = <180 80>;
+ reg = <0x180 0x80>;
interrupt-parent = <&mpic>;
- interrupts = <3f 2>;
- };
- };
+ interrupts = <63 2>;
+ };
+ };
};
@@ -231,26 +232,26 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <e0008000 1000>;
+ reg = <0xe0008000 0x1000>;
bus-range = <0 0>;
- ranges = <02000000 0 80000000 80000000 0 10000000
- 01000000 0 00000000 e1000000 0 00100000>;
- clock-frequency = <1fca055>;
+ ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe1000000 0x0 0x00100000>;
+ clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
- interrupts = <18 2>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupts = <24 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 */
- 8800 0 0 1 &mpic 4 1
- 8800 0 0 2 &mpic 5 1
- 8800 0 0 3 &mpic 6 1
- 8800 0 0 4 &mpic 7 1
+ 0x8800 0 0 1 &mpic 4 1
+ 0x8800 0 0 2 &mpic 5 1
+ 0x8800 0 0 3 &mpic 6 1
+ 0x8800 0 0 4 &mpic 7 1
/* IDSEL 0x12 */
- 9000 0 0 1 &mpic 5 1
- 9000 0 0 2 &mpic 6 1
- 9000 0 0 3 &mpic 7 1
- 9000 0 0 4 &mpic 4 1
+ 0x9000 0 0 1 &mpic 5 1
+ 0x9000 0 0 2 &mpic 6 1
+ 0x9000 0 0 3 &mpic 7 1
+ 0x9000 0 0 4 &mpic 4 1
>;
};
@@ -261,28 +262,28 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <e000a000 1000>;
+ reg = <0xe000a000 0x1000>;
bus-range = <1 3>;
- ranges = <02000000 0 a0000000 a0000000 0 10000000
- 01000000 0 00000000 e3000000 0 00100000>;
- clock-frequency = <1fca055>;
+ ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe3000000 0x0 0x00100000>;
+ clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
- interrupts = <1a 2>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupts = <26 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 0x1b */
- d800 0 0 1 &mpic 2 1
+ 0xd800 0 0 1 &mpic 2 1
/* IDSEL 0x1c*/
- e000 0 0 1 &mpic 1 1
- e000 0 0 2 &mpic 1 1
- e000 0 0 3 &mpic 1 1
- e000 0 0 4 &mpic 1 1
+ 0xe000 0 0 1 &mpic 1 1
+ 0xe000 0 0 2 &mpic 1 1
+ 0xe000 0 0 3 &mpic 1 1
+ 0xe000 0 0 4 &mpic 1 1
/* IDSEL 0x1f */
- f800 0 0 1 &mpic 3 0
- f800 0 0 2 &mpic 0 1
+ 0xf800 0 0 1 &mpic 3 0
+ 0xf800 0 0 2 &mpic 0 1
>;
pcie@0 {
@@ -290,22 +291,22 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <02000000 0 a0000000
- 02000000 0 a0000000
- 0 10000000
- 01000000 0 00000000
- 01000000 0 00000000
- 0 00100000>;
+ ranges = <0x02000000 0x0 0xa0000000
+ 0x02000000 0x0 0xa0000000
+ 0x0 0x10000000
+ 0x01000000 0x0 0x00000000
+ 0x01000000 0x0 0x00000000
+ 0x0 0x00100000>;
uli1575@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
- ranges = <02000000 0 a0000000
- 02000000 0 a0000000
- 0 10000000
- 01000000 0 00000000
- 01000000 0 00000000
- 0 00100000>;
+ ranges = <0x02000000 0x0 0xa0000000
+ 0x02000000 0x0 0xa0000000
+ 0x0 0x10000000
+ 0x01000000 0x0 0x00000000
+ 0x01000000 0x0 0x00000000
+ 0x0 0x00100000>;
};
};
};
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 556a9ca..79385bc 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -9,6 +9,7 @@
* option) any later version.
*/
+/dts-v1/;
/ {
model = "MPC8641HPCN";
@@ -34,22 +35,22 @@
PowerPC,8641@0 {
device_type = "cpu";
reg = <0>;
- d-cache-line-size = <20>; // 32 bytes
- i-cache-line-size = <20>; // 32 bytes
- d-cache-size = <8000>; // L1, 32K
- i-cache-size = <8000>; // L1, 32K
- timebase-frequency = <0>; // 33 MHz, from uboot
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>; // L1
+ i-cache-size = <32768>; // L1
+ timebase-frequency = <0>; // From uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
};
PowerPC,8641@1 {
device_type = "cpu";
reg = <1>;
- d-cache-line-size = <20>; // 32 bytes
- i-cache-line-size = <20>; // 32 bytes
- d-cache-size = <8000>; // L1, 32K
- i-cache-size = <8000>; // L1, 32K
- timebase-frequency = <0>; // 33 MHz, from uboot
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <32768>;
+ i-cache-size = <32768>;
+ timebase-frequency = <0>; // From uboot
bus-frequency = <0>; // From uboot
clock-frequency = <0>; // From uboot
};
@@ -57,45 +58,45 @@
memory {
device_type = "memory";
- reg = <00000000 40000000>; // 1G at 0x0
+ reg = <0x00000000 0x40000000>; // 1G at 0x0
};
localbus@f8005000 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "fsl,mpc8641-localbus", "simple-bus";
- reg = <f8005000 1000>;
- interrupts = <13 2>;
+ reg = <0xf8005000 0x1000>;
+ interrupts = <19 2>;
interrupt-parent = <&mpic>;
- ranges = <0 0 ff800000 00800000
- 1 0 fe000000 01000000
- 2 0 f8200000 00100000
- 3 0 f8100000 00100000>;
+ ranges = <0 0 0xff800000 0x00800000
+ 1 0 0xfe000000 0x01000000
+ 2 0 0xf8200000 0x00100000
+ 3 0 0xf8100000 0x00100000>;
flash@0,0 {
compatible = "cfi-flash";
- reg = <0 0 00800000>;
+ reg = <0 0 0x00800000>;
bank-width = <2>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "kernel";
- reg = <00000000 00300000>;
+ reg = <0x00000000 0x00300000>;
};
partition@300000 {
label = "firmware b";
- reg = <00300000 00100000>;
+ reg = <0x00300000 0x00100000>;
read-only;
};
partition@400000 {
label = "fs";
- reg = <00400000 00300000>;
+ reg = <0x00400000 0x00300000>;
};
partition@700000 {
label = "firmware a";
- reg = <00700000 00100000>;
+ reg = <0x00700000 0x00100000>;
read-only;
};
};
@@ -106,8 +107,8 @@
#size-cells = <1>;
device_type = "soc";
compatible = "simple-bus";
- ranges = <00000000 f8000000 00100000>;
- reg = <f8000000 00001000>; // CCSRBAR
+ ranges = <0x00000000 0xf8000000 0x00100000>;
+ reg = <0xf8000000 0x00001000>; // CCSRBAR
bus-frequency = <0>;
i2c@3000 {
@@ -115,8 +116,8 @@
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
- reg = <3000 100>;
- interrupts = <2b 2>;
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
@@ -126,8 +127,8 @@
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
- reg = <3100 100>;
- interrupts = <2b 2>;
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
@@ -136,29 +137,29 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
- reg = <24520 20>;
+ reg = <0x24520 0x20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
- interrupts = <a 1>;
+ interrupts = <10 1>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
- interrupts = <a 1>;
+ interrupts = <10 1>;
reg = <1>;
device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&mpic>;
- interrupts = <a 1>;
+ interrupts = <10 1>;
reg = <2>;
device_type = "ethernet-phy";
};
phy3: ethernet-phy@3 {
interrupt-parent = <&mpic>;
- interrupts = <a 1>;
+ interrupts = <10 1>;
reg = <3>;
device_type = "ethernet-phy";
};
@@ -169,9 +170,9 @@
device_type = "network";
model = "TSEC";
compatible = "gianfar";
- reg = <24000 1000>;
+ reg = <0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <1d 2 1e 2 22 2>;
+ interrupts = <29 2 30 2 34 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
phy-connection-type = "rgmii-id";
@@ -182,9 +183,9 @@
device_type = "network";
model = "TSEC";
compatible = "gianfar";
- reg = <25000 1000>;
+ reg = <0x25000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <23 2 24 2 28 2>;
+ interrupts = <35 2 36 2 40 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
@@ -195,9 +196,9 @@
device_type = "network";
model = "TSEC";
compatible = "gianfar";
- reg = <26000 1000>;
+ reg = <0x26000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <1F 2 20 2 21 2>;
+ interrupts = <31 2 32 2 33 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy2>;
phy-connection-type = "rgmii-id";
@@ -208,9 +209,9 @@
device_type = "network";
model = "TSEC";
compatible = "gianfar";
- reg = <27000 1000>;
+ reg = <0x27000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <25 2 26 2 27 2>;
+ interrupts = <37 2 38 2 39 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy3>;
phy-connection-type = "rgmii-id";
@@ -220,9 +221,9 @@
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
- reg = <4500 100>;
+ reg = <0x4500 0x100>;
clock-frequency = <0>;
- interrupts = <2a 2>;
+ interrupts = <42 2>;
interrupt-parent = <&mpic>;
};
@@ -230,9 +231,9 @@
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
- reg = <4600 100>;
+ reg = <0x4600 0x100>;
clock-frequency = <0>;
- interrupts = <1c 2>;
+ interrupts = <28 2>;
interrupt-parent = <&mpic>;
};
@@ -241,7 +242,7 @@
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
- reg = <40000 40000>;
+ reg = <0x40000 0x40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
@@ -249,7 +250,7 @@
global-utilities@e0000 {
compatible = "fsl,mpc8641-guts";
- reg = <e0000 1000>;
+ reg = <0xe0000 0x1000>;
fsl,has-rstcr;
};
};
@@ -261,127 +262,127 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <f8008000 1000>;
- bus-range = <0 ff>;
- ranges = <02000000 0 80000000 80000000 0 20000000
- 01000000 0 00000000 e2000000 0 00100000>;
- clock-frequency = <1fca055>;
+ reg = <0xf8008000 0x1000>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x20000000
+ 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
- interrupts = <18 2>;
- interrupt-map-mask = <ff00 0 0 7>;
+ interrupts = <24 2>;
+ interrupt-map-mask = <0xff00 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 func 0 - PCI slot 1 */
- 8800 0 0 1 &mpic 2 1
- 8800 0 0 2 &mpic 3 1
- 8800 0 0 3 &mpic 4 1
- 8800 0 0 4 &mpic 1 1
+ 0x8800 0 0 1 &mpic 2 1
+ 0x8800 0 0 2 &mpic 3 1
+ 0x8800 0 0 3 &mpic 4 1
+ 0x8800 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 1 - PCI slot 1 */
- 8900 0 0 1 &mpic 2 1
- 8900 0 0 2 &mpic 3 1
- 8900 0 0 3 &mpic 4 1
- 8900 0 0 4 &mpic 1 1
+ 0x8900 0 0 1 &mpic 2 1
+ 0x8900 0 0 2 &mpic 3 1
+ 0x8900 0 0 3 &mpic 4 1
+ 0x8900 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 2 - PCI slot 1 */
- 8a00 0 0 1 &mpic 2 1
- 8a00 0 0 2 &mpic 3 1
- 8a00 0 0 3 &mpic 4 1
- 8a00 0 0 4 &mpic 1 1
+ 0x8a00 0 0 1 &mpic 2 1
+ 0x8a00 0 0 2 &mpic 3 1
+ 0x8a00 0 0 3 &mpic 4 1
+ 0x8a00 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 3 - PCI slot 1 */
- 8b00 0 0 1 &mpic 2 1
- 8b00 0 0 2 &mpic 3 1
- 8b00 0 0 3 &mpic 4 1
- 8b00 0 0 4 &mpic 1 1
+ 0x8b00 0 0 1 &mpic 2 1
+ 0x8b00 0 0 2 &mpic 3 1
+ 0x8b00 0 0 3 &mpic 4 1
+ 0x8b00 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 4 - PCI slot 1 */
- 8c00 0 0 1 &mpic 2 1
- 8c00 0 0 2 &mpic 3 1
- 8c00 0 0 3 &mpic 4 1
- 8c00 0 0 4 &mpic 1 1
+ 0x8c00 0 0 1 &mpic 2 1
+ 0x8c00 0 0 2 &mpic 3 1
+ 0x8c00 0 0 3 &mpic 4 1
+ 0x8c00 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 5 - PCI slot 1 */
- 8d00 0 0 1 &mpic 2 1
- 8d00 0 0 2 &mpic 3 1
- 8d00 0 0 3 &mpic 4 1
- 8d00 0 0 4 &mpic 1 1
+ 0x8d00 0 0 1 &mpic 2 1
+ 0x8d00 0 0 2 &mpic 3 1
+ 0x8d00 0 0 3 &mpic 4 1
+ 0x8d00 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 6 - PCI slot 1 */
- 8e00 0 0 1 &mpic 2 1
- 8e00 0 0 2 &mpic 3 1
- 8e00 0 0 3 &mpic 4 1
- 8e00 0 0 4 &mpic 1 1
+ 0x8e00 0 0 1 &mpic 2 1
+ 0x8e00 0 0 2 &mpic 3 1
+ 0x8e00 0 0 3 &mpic 4 1
+ 0x8e00 0 0 4 &mpic 1 1
/* IDSEL 0x11 func 7 - PCI slot 1 */
- 8f00 0 0 1 &mpic 2 1
- 8f00 0 0 2 &mpic 3 1
- 8f00 0 0 3 &mpic 4 1
- 8f00 0 0 4 &mpic 1 1
+ 0x8f00 0 0 1 &mpic 2 1
+ 0x8f00 0 0 2 &mpic 3 1
+ 0x8f00 0 0 3 &mpic 4 1
+ 0x8f00 0 0 4 &mpic 1 1
/* IDSEL 0x12 func 0 - PCI slot 2 */
- 9000 0 0 1 &mpic 3 1
- 9000 0 0 2 &mpic 4 1
- 9000 0 0 3 &mpic 1 1
- 9000 0 0 4 &mpic 2 1
+ 0x9000 0 0 1 &mpic 3 1
+ 0x9000 0 0 2 &mpic 4 1
+ 0x9000 0 0 3 &mpic 1 1
+ 0x9000 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 1 - PCI slot 2 */
- 9100 0 0 1 &mpic 3 1
- 9100 0 0 2 &mpic 4 1
- 9100 0 0 3 &mpic 1 1
- 9100 0 0 4 &mpic 2 1
+ 0x9100 0 0 1 &mpic 3 1
+ 0x9100 0 0 2 &mpic 4 1
+ 0x9100 0 0 3 &mpic 1 1
+ 0x9100 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 2 - PCI slot 2 */
- 9200 0 0 1 &mpic 3 1
- 9200 0 0 2 &mpic 4 1
- 9200 0 0 3 &mpic 1 1
- 9200 0 0 4 &mpic 2 1
+ 0x9200 0 0 1 &mpic 3 1
+ 0x9200 0 0 2 &mpic 4 1
+ 0x9200 0 0 3 &mpic 1 1
+ 0x9200 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 3 - PCI slot 2 */
- 9300 0 0 1 &mpic 3 1
- 9300 0 0 2 &mpic 4 1
- 9300 0 0 3 &mpic 1 1
- 9300 0 0 4 &mpic 2 1
+ 0x9300 0 0 1 &mpic 3 1
+ 0x9300 0 0 2 &mpic 4 1
+ 0x9300 0 0 3 &mpic 1 1
+ 0x9300 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 4 - PCI slot 2 */
- 9400 0 0 1 &mpic 3 1
- 9400 0 0 2 &mpic 4 1
- 9400 0 0 3 &mpic 1 1
- 9400 0 0 4 &mpic 2 1
+ 0x9400 0 0 1 &mpic 3 1
+ 0x9400 0 0 2 &mpic 4 1
+ 0x9400 0 0 3 &mpic 1 1
+ 0x9400 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 5 - PCI slot 2 */
- 9500 0 0 1 &mpic 3 1
- 9500 0 0 2 &mpic 4 1
- 9500 0 0 3 &mpic 1 1
- 9500 0 0 4 &mpic 2 1
+ 0x9500 0 0 1 &mpic 3 1
+ 0x9500 0 0 2 &mpic 4 1
+ 0x9500 0 0 3 &mpic 1 1
+ 0x9500 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 6 - PCI slot 2 */
- 9600 0 0 1 &mpic 3 1
- 9600 0 0 2 &mpic 4 1
- 9600 0 0 3 &mpic 1 1
- 9600 0 0 4 &mpic 2 1
+ 0x9600 0 0 1 &mpic 3 1
+ 0x9600 0 0 2 &mpic 4 1
+ 0x9600 0 0 3 &mpic 1 1
+ 0x9600 0 0 4 &mpic 2 1
/* IDSEL 0x12 func 7 - PCI slot 2 */
- 9700 0 0 1 &mpic 3 1
- 9700 0 0 2 &mpic 4 1
- 9700 0 0 3 &mpic 1 1
- 9700 0 0 4 &mpic 2 1
+ 0x9700 0 0 1 &mpic 3 1
+ 0x9700 0 0 2 &mpic 4 1
+ 0x9700 0 0 3 &mpic 1 1
+ 0x9700 0 0 4 &mpic 2 1
// IDSEL 0x1c USB
- e000 0 0 1 &i8259 c 2
- e100 0 0 2 &i8259 9 2
- e200 0 0 3 &i8259 a 2
- e300 0 0 4 &i8259 b 2
+ 0xe000 0 0 1 &i8259 12 2
+ 0xe100 0 0 2 &i8259 9 2
+ 0xe200 0 0 3 &i8259 10 2
+ 0xe300 0 0 4 &i8259 112
// IDSEL 0x1d Audio
- e800 0 0 1 &i8259 6 2
+ 0xe800 0 0 1 &i8259 6 2
// IDSEL 0x1e Legacy
- f000 0 0 1 &i8259 7 2
- f100 0 0 1 &i8259 7 2
+ 0xf000 0 0 1 &i8259 7 2
+ 0xf100 0 0 1 &i8259 7 2
// IDSEL 0x1f IDE/SATA
- f800 0 0 1 &i8259 e 2
- f900 0 0 1 &i8259 5 2
+ 0xf800 0 0 1 &i8259 14 2
+ 0xf900 0 0 1 &i8259 5 2
>;
pcie@0 {
@@ -389,37 +390,37 @@
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <02000000 0 80000000
- 02000000 0 80000000
- 0 20000000
+ ranges = <0x02000000 0x0 0x80000000
+ 0x02000000 0x0 0x80000000
+ 0x0 0x20000000
- 01000000 0 00000000
- 01000000 0 00000000
- 0 00100000>;
+ 0x01000000 0x0 0x00000000
+ 0x01000000 0x0 0x00000000
+ 0x0 0x00100000>;
uli1575@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
- ranges = <02000000 0 80000000
- 02000000 0 80000000
- 0 20000000
- 01000000 0 00000000
- 01000000 0 00000000
- 0 00100000>;
+ ranges = <0x02000000 0x0 0x80000000
+ 0x02000000 0x0 0x80000000
+ 0x0 0x20000000
+ 0x01000000 0x0 0x00000000
+ 0x01000000 0x0 0x00000000
+ 0x0 0x00100000>;
isa@1e {
device_type = "isa";
#interrupt-cells = <2>;
#size-cells = <1>;
#address-cells = <2>;
- reg = <f000 0 0 0 0>;
- ranges = <1 0 01000000 0 0
- 00001000>;
+ reg = <0xf000 0 0 0 0>;
+ ranges = <1 0 0x01000000 0 0
+ 0x00001000>;
interrupt-parent = <&i8259>;
i8259: interrupt-controller@20 {
- reg = <1 20 2
- 1 a0 2
- 1 4d0 2>;
+ reg = <1 0x20 2
+ 1 0xa0 2
+ 1 0x4d0 2>;
interrupt-controller;
device_type = "interrupt-controller";
#address-cells = <0>;
@@ -432,8 +433,8 @@
i8042@60 {
#size-cells = <0>;
#address-cells = <1>;
- reg = <1 60 1 1 64 1>;
- interrupts = <1 3 c 3>;
+ reg = <1 0x60 1 1 0x64 1>;
+ interrupts = <1 3 12 3>;
interrupt-parent =
<&i8259>;
@@ -451,11 +452,11 @@
rtc@70 {
compatible =
"pnpPNP,b00";
- reg = <1 70 2>;
+ reg = <1 0x70 2>;
};
gpio@400 {
- reg = <1 400 80>;
+ reg = <1 0x400 0x80>;
};
};
};
@@ -470,33 +471,33 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <f8009000 1000>;
- bus-range = <0 ff>;
- ranges = <02000000 0 a0000000 a0000000 0 20000000
- 01000000 0 00000000 e3000000 0 00100000>;
- clock-frequency = <1fca055>;
+ reg = <0xf8009000 0x1000>;
+ bus-range = <0 0xff>;
+ ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
+ 0x01000000 0x0 0x00000000 0xe3000000 0x0 0x00100000>;
+ clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
- interrupts = <19 2>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupts = <25 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
- 0000 0 0 1 &mpic 4 1
- 0000 0 0 2 &mpic 5 1
- 0000 0 0 3 &mpic 6 1
- 0000 0 0 4 &mpic 7 1
+ 0x0000 0 0 1 &mpic 4 1
+ 0x0000 0 0 2 &mpic 5 1
+ 0x0000 0 0 3 &mpic 6 1
+ 0x0000 0 0 4 &mpic 7 1
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
- ranges = <02000000 0 a0000000
- 02000000 0 a0000000
- 0 20000000
+ ranges = <0x02000000 0x0 0xa0000000
+ 0x02000000 0x0 0xa0000000
+ 0x0 0x20000000
- 01000000 0 00000000
- 01000000 0 00000000
- 0 00100000>;
+ 0x01000000 0x0 0x00000000
+ 0x01000000 0x0 0x00000000
+ 0x0 0x00100000>;
};
};
};
--
1.5.2.1.126.g6abd0
^ permalink raw reply related
* [PATCH] POWERPC: Convert StorCenter DTS file to /dts-v1/ format.
From: Jon Loeliger @ 2008-01-25 22:36 UTC (permalink / raw)
To: ppcdev
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/boot/dts/storcenter.dts | 73 +++++++++++++++++----------------
1 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/boot/dts/storcenter.dts b/arch/powerpc/boot/dts/storcenter.dts
index 6aa1d69..2204874 100644
--- a/arch/powerpc/boot/dts/storcenter.dts
+++ b/arch/powerpc/boot/dts/storcenter.dts
@@ -11,6 +11,8 @@
* warranty of any kind, whether express or implied.
*/
+/dts-v1/;
+
/ {
model = "StorCenter";
compatible = "storcenter";
@@ -30,19 +32,19 @@
PowerPC,8241@0 {
device_type = "cpu";
reg = <0>;
- clock-frequency = <d# 200000000>; /* Hz */
- timebase-frequency = <d# 25000000>; /* Hz */
+ clock-frequency = <200000000>;
+ timebase-frequency = <25000000>;
bus-frequency = <0>; /* from bootwrapper */
- i-cache-line-size = <d# 32>; /* bytes */
- d-cache-line-size = <d# 32>; /* bytes */
- i-cache-size = <4000>;
- d-cache-size = <4000>;
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <16384>;
+ d-cache-size = <16384>;
};
};
memory {
device_type = "memory";
- reg = <00000000 04000000>; /* 64MB @ 0x0 */
+ reg = <0x00000000 0x04000000>; /* 64MB @ 0x0 */
};
soc@fc000000 {
@@ -51,15 +53,15 @@
device_type = "soc";
compatible = "fsl,mpc8241", "mpc10x";
store-gathering = <0>; /* 0 == off, !0 == on */
- ranges = <0 fc000000 100000>;
- reg = <fc000000 100000>; /* EUMB */
+ ranges = <0x0 0xfc000000 0x100000>;
+ reg = <0xfc000000 0x100000>; /* EUMB */
bus-frequency = <0>; /* fixed by loader */
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl-i2c";
- reg = <3000 100>;
+ reg = <0x3000 0x100>;
interrupts = <5 2>;
interrupt-parent = <&mpic>;
@@ -73,9 +75,9 @@
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
- reg = <4500 20>;
- clock-frequency = <d# 97553800>; /* Hz */
- current-speed = <d# 115200>;
+ reg = <0x4500 0x20>;
+ clock-frequency = <97553800>; /* Hz */
+ current-speed = <115200>;
interrupts = <9 2>;
interrupt-parent = <&mpic>;
};
@@ -84,10 +86,10 @@
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
- reg = <4600 20>;
- clock-frequency = <d# 97553800>; /* Hz */
- current-speed = <d# 9600>;
- interrupts = <a 2>;
+ reg = <0x4600 0x20>;
+ clock-frequency = <97553800>; /* Hz */
+ current-speed = <9600>;
+ interrupts = <10 2>;
interrupt-parent = <&mpic>;
};
@@ -96,7 +98,7 @@
device_type = "open-pic";
compatible = "chrp,open-pic";
interrupt-controller;
- reg = <40000 40000>;
+ reg = <0x40000 0x40000>;
};
};
@@ -107,28 +109,29 @@
#interrupt-cells = <1>;
device_type = "pci";
compatible = "mpc10x-pci";
- reg = <fe800000 1000>;
- ranges = <01000000 0 0 fe000000 0 00c00000
- 02000000 0 80000000 80000000 0 70000000>;
- bus-range = <0 ff>;
- clock-frequency = <d# 97553800>; /* Hz */
+ reg = <0xfe800000 0x1000>;
+ ranges = <0x01000000 0x0 0x0 0xfe000000 0x0 0x00c00000
+ 0x02000000 0x0 0x80000000 0x80000000 0x0 0x70000000>;
+ bus-range = <0 0xff>;
+ clock-frequency = <97553800>;
interrupt-parent = <&mpic>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <
/* IDSEL 13 - IDE */
- 6800 0 0 1 &mpic 0 1
- 6800 0 0 2 &mpic 0 1
- 6800 0 0 3 &mpic 0 1
+ 0x6800 0 0 1 &mpic 0 1
+ 0x6800 0 0 2 &mpic 0 1
+ 0x6800 0 0 3 &mpic 0 1
+ 0x6800 0 0 4 &mpic 0 1
/* IDSEL 14 - USB */
- 7000 0 0 1 &mpic 0 1
- 7000 0 0 2 &mpic 0 1
- 7000 0 0 3 &mpic 0 1
- 7000 0 0 4 &mpic 0 1
+ 0x7000 0 0 1 &mpic 0 1
+ 0x7000 0 0 2 &mpic 0 1
+ 0x7000 0 0 3 &mpic 0 1
+ 0x7000 0 0 4 &mpic 0 1
/* IDSEL 15 - ETH */
- 7800 0 0 1 &mpic 0 1
- 7800 0 0 2 &mpic 0 1
- 7800 0 0 3 &mpic 0 1
- 7800 0 0 4 &mpic 0 1
+ 0x7800 0 0 1 &mpic 0 1
+ 0x7800 0 0 2 &mpic 0 1
+ 0x7800 0 0 3 &mpic 0 1
+ 0x7800 0 0 4 &mpic 0 1
>;
};
--
1.5.2.1.126.g6abd0
^ permalink raw reply related
* [PATCH] 5200 dts: add default address and size cells to soc node.
From: Paul Gortmaker @ 2008-01-25 20:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
The various 5200 dts files don't have values specified for the soc
node, which in turn results in a warning from the processing of
every child node (roughly 40 warnings per file). This explicitly
sets the default values and gets rid of all the warnings.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/cm5200.dts | 2 ++
arch/powerpc/boot/dts/lite5200.dts | 2 ++
arch/powerpc/boot/dts/lite5200b.dts | 2 ++
arch/powerpc/boot/dts/motionpro.dts | 2 ++
arch/powerpc/boot/dts/tqm5200.dts | 2 ++
5 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 9295083..2b88a58 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -45,6 +45,8 @@
};
soc5200@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
model = "fsl,mpc5200b";
compatible = "fsl,mpc5200b";
revision = ""; // from bootloader
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index e1d6f44..7de3d21 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -46,6 +46,8 @@
};
soc5200@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
model = "fsl,mpc5200";
compatible = "mpc5200";
revision = ""; // from bootloader
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 3e06f58..dd2c4fd 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -46,6 +46,8 @@
};
soc5200@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
model = "fsl,mpc5200b";
compatible = "mpc5200";
revision = ""; // from bootloader
diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
index d8c316a..ee30805 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -45,6 +45,8 @@
};
soc5200@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
model = "fsl,mpc5200b";
compatible = "fsl,mpc5200b";
revision = ""; // from bootloader
diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
index 5017cec..58c9799 100644
--- a/arch/powerpc/boot/dts/tqm5200.dts
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -45,6 +45,8 @@
};
soc5200@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
model = "fsl,mpc5200";
compatible = "fsl,mpc5200";
revision = ""; // from bootloader
--
1.5.4.rc4.gcab31
^ permalink raw reply related
* Re: [PATCH] create modalias file in sysfs for bus vio
From: Olaf Hering @ 2008-01-25 17:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080123010505.d812129e.sfr@canb.auug.org.au>
On Wed, Jan 23, Stephen Rothwell wrote:
> It would be nice if we could factor out the "vio:T%sS%s" string as it is
> also used in vio_hotplug().
What exactly do you have in mind?
Creating a tempstring seems to make things more complicated.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 2:20 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <adahch1jruv.fsf@cisco.com>
On Fri, 25 Jan 2008 17:30:32 -0800
Roland Dreier <rdreier@cisco.com> wrote:
> > > YUCCA
> >
> > Yucca was what again? 440spe?
>
> Yes, it was the first 440SPe eval board; since replaced by Katmai.
>
> I have a Yucca and can at least test thing; if no one else gets to it,
> I may try to port it to arch/powerpc for 2.6.26.
Hm. Katmai is already in-tree. Theoretically I should be able to get
the HW docs and do a new DTS and have it mostly "just work". Perhaps
I'll give that a shot and have you give it a quick spin.
josh
^ permalink raw reply
* SET_NETDEV_DEV -> 83xx HDLC Driver??
From: Russell McGuire @ 2008-01-26 2:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1.1201309203.24413.linuxppc-embedded@ozlabs.org>
All,
I am partly done porting a combination of the 83xx ATM driver and dscc4 HDLC
driver into a 83xx HDLC driver.
However, encounter a call I don't truly understand.
SET_NETDEV_DEV(dev, pointer_to_some_handle);
I can see plenty of examples of this registering some kind of PCI device
handle, however in this case I am not using a PCI device. So what should the
pointer be? Or can this call be ignored, and if so what are the
consequences?
I see the some of the Freescale Ethernet devices don't use this call.
Anyway, can somebody shed some light on if I am going to need this, or a way
to get it to work, without creating a PCI device?
-Russ
^ permalink raw reply
* Re: [PATCH 3/3] Cell IOMMU static mapping support
From: Olof Johansson @ 2008-01-26 2:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <9ce4678eef9e50908969eb1ef8470e307f3076ff.1201257905.git.michael@ellerman.id.au>
On Fri, Jan 25, 2008 at 09:45:07PM +1100, Michael Ellerman wrote:
> Citing "release early release often", I'm posting this now as a mega-patch
> to get people looking at it. I'll try to split it up and make it look a
> little prettier before submitting it.
>
> The intent of this patch is to setup (on certain machines) a "static" IOMMU
> mapping of all of memory, to reduce the overhead of the IOMMU. If anyone has
> a better name than "static" I'm all ears.
>
> So instead of having an IOMMU window that we use to temporarily map things
> in and out of DMA'able space, at boot we create a 1:1 mapping for all of
> memory. This obviously only works for devices that can do 64-bit DMA.
I don't get it. Why not disable the iommu instead?
-Olof
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Grant Likely @ 2008-01-26 3:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Jon Loeliger, linuxppc-embedded
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
On 1/25/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> Just a reminder that the plan is to remove arch/ppc this summer (June
> 2008).
I strongly recommend that we delay removal by about a month...
somewhere around July 23-26... so we can have a great big "ding, dong,
arch/ppc is dead" party at OLS.
:-D
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] qe/muram dts: Explicitly set address-cells and size cells for muram
From: Paul Gortmaker @ 2008-01-25 19:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
Currently there are several dts that don't specify address or size
cells for the muram. This causes dtc to use default values, one of
which is an address-cells of two, and this breaks the parsing of the
muram ranges, which is assuming an address-cells of one. For example:
Warning (reg_format): "reg" property in
/qe@e0100000/muram@10000/data-only@0 has invalid length
(8 bytes) (#address-cells == 2, #size-cells == 1)
Explicitly setting the address and size cells gets it parsed properly
and gets rid of the four dtc warnings.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/mpc832x_mds.dts | 2 ++
arch/powerpc/boot/dts/mpc832x_rdb.dts | 2 ++
arch/powerpc/boot/dts/mpc836x_mds.dts | 4 +++-
arch/powerpc/boot/dts/mpc8568mds.dts | 4 +++-
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 6902524..ec3ca83 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -213,6 +213,8 @@
bus-frequency = <BCD3D80>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 00004000>;
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 10ff7aa..9251997 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -173,6 +173,8 @@
bus-frequency = <BCD3D80>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 00004000>;
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 2181d2c..10b5d6d 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -214,10 +214,12 @@
bus-frequency = <179A7B00>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 0000c000>;
- data-only@0{
+ data-only@0 {
reg = <0 c000>;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5818a7c..78d4b83 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -291,10 +291,12 @@
bus-frequency = <179A7B00>;
muram@10000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "muram";
ranges = <0 00010000 0000c000>;
- data-only@0{
+ data-only@0 {
reg = <0 c000>;
};
};
--
1.5.4.rc4.gcab31
^ permalink raw reply related
* Re: [PATCH] 5200 dts: add default address and size cells to soc node.
From: Grant Likely @ 2008-01-26 3:17 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1201293200-32031-1-git-send-email-paul.gortmaker@windriver.com>
On 1/25/08, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> The various 5200 dts files don't have values specified for the soc
> node, which in turn results in a warning from the processing of
> every child node (roughly 40 warnings per file). This explicitly
> sets the default values and gets rid of all the warnings.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks!
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Josh Boyer @ 2008-01-26 3:22 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list, Jon Loeliger, linuxppc-embedded
In-Reply-To: <fa686aa40801251907x710f1916y1fa8d8ac6913aae@mail.gmail.com>
On Fri, 25 Jan 2008 20:07:57 -0700
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 1/25/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> > Just a reminder that the plan is to remove arch/ppc this summer (June
> > 2008).
>
> I strongly recommend that we delay removal by about a month...
> somewhere around July 23-26... so we can have a great big "ding, dong,
> arch/ppc is dead" party at OLS.
Ironically, that is where the original June date came from. Segher
suggested doing it at OLS, which for some reason we all thought was in
June.
But this is Linux. We never do anything on time, so I'm sure it'll
work out ;)
josh
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Olof Johansson @ 2008-01-26 3:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <1201245134-4876-63-git-send-email-gregkh@suse.de>
On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> Dynamically create the kset instead of declaring it statically. We also
> rename devices_subsys to devices_kset to catch all users of the
> variable.
Guess what, you broke powerpc again!
olof@quad:~/work/linux/k.org $ git grep devices_subsys
arch/powerpc/kernel/vio.c:extern struct kset devices_subsys; /* needed for vio_find_name() */
arch/powerpc/kernel/vio.c: found = kset_find_obj(&devices_subsys, kobj_name);
Obviously causes build failues, even of ppc64_defconfig.
(I can unfortunately not boot test, since I lack hardware that uses vio)
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 19a5656..ee752ab 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -37,7 +37,7 @@
#include <asm/iseries/hv_call_xm.h>
#include <asm/iseries/iommu.h>
-extern struct kset devices_subsys; /* needed for vio_find_name() */
+extern struct kset *devices_kset; /* needed for vio_find_name() */
static struct bus_type vio_bus_type;
@@ -369,7 +369,7 @@ static struct vio_dev *vio_find_name(const char *kobj_name)
{
struct kobject *found;
- found = kset_find_obj(&devices_subsys, kobj_name);
+ found = kset_find_obj(devices_kset, kobj_name);
if (!found)
return NULL;
^ permalink raw reply related
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 4:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=,
linuxppc-dev
In-Reply-To: <1201251000.6341.108.camel@lappy>
On Fri, Jan 25, 2008 at 09:50:00AM +0100, Peter Zijlstra wrote:
>
> On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > Here, I do the test of running 4 times the repro-case provided by Michel
> > > > with nice 19 and a dd eating CPU with nice 0.
> > > >
> > > > Without this option, I get the dd at 100% and the nice 19 shells down
> > > > below it with whatever is left of the CPUs.
> > > >
> > > > With this option, dd gets about 50% of one CPU and the niced processes
> > > > still get most of the time.
Ben,
I presume you had CONFIG_FAIR_USER_SCHED turned on too? Also were the
dd process and the niced processes running under different user ids? If
so, that is expected behavior, that we divide CPU equally among
users first and then among the processes within each user.
> > > FYI. This is a 4 way G5 (ppc64)
> >
> > I also tested responsiveness of X running with or without that option
> > and with niced CPU eaters in the background (still 4 of them, one per
> > CPU), and I can confirm Michel observations, it gets very sluggish
> > (maybe not -as- bad as his but still pretty annoying) with the fair
> > group scheduler enabled.
When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
enabled, X will be given higher priority for running on CPU when compared to
other niced tasks. When the above options are turned on, X (running
under root uid) would be given lesser priority to run when compared to other
niced tasks running user different uids. Hence I expect some drop in
interactivity-experience with FAIR_GROUP_SCHED on.
Can you pls let me know if any of these makes a difference:
1. Run niced tasks as root. This would bring X and niced tasks in the
same "scheduler group" domain, which would give X much more CPU power
when compared to niced tasks.
2. Keep the niced tasks running under a non-root uid, but increase root users
cpu share.
# echo 8192 > /sys/kernel/uids/0/cpu_share
This should bump up root user's priority for running on CPU and also
give a better desktop experience.
> > Here, X is running with nice=0
>
> Curious, sounds like an issue with the group load balancer, vatsa, any
> ideas?
The group scheduler's SMP-load balance in 2.6.24 is not the best it
could be. sched-devel has a better load balancer, which I am presuming
will go into 2.6.25 soon.
In this case, I suspect that's not the issue. If X and the niced processes are
running under different uids, this (niced processes getting more cpu power) is
on expected lines. Will wait for Ben to confirm this.
--
Regards,
vatsa
^ permalink raw reply
* Please pull for-2.6.25 branch of pasemi.git
From: Olof Johansson @ 2008-01-26 4:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
to receive the following updates:
arch/powerpc/kernel/smp.c | 49 +++++++++++++++++++++++++++++++++-------------
1 file changed, 36 insertions(+), 13 deletions(-)
Olof Johansson (2):
[POWERPC] smp_call_function_map should be static
[POWERPC] Make smp_send_stop() handle panic and xmon reboot
Those two patches are marked as "awaiting upstream" in patchwork, but
I didn't see them in powerpc.git for-2.6.25.
-Olof
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-26 4:13 UTC (permalink / raw)
To: vatsa; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, Michel Dänzer
In-Reply-To: <20080126040734.GA21365@linux.vnet.ibm.com>
On Sat, 2008-01-26 at 09:37 +0530, Srivatsa Vaddagiri wrote:
>
> Ben,
> I presume you had CONFIG_FAIR_USER_SCHED turned on too?
Yes. It seems to be automatically turned on whenever FAIR_GROUP is
turned on. Considering how bad the behaviour is for a standard desktop
configuration, I'd be tempted to say to change it to default n.
> Also were the
> dd process and the niced processes running under different user ids? If
> so, that is expected behavior, that we divide CPU equally among
> users first and then among the processes within each user.
They were different users and that behaviour seems to be a very stupid
default behaviour for a desktop machine. Take this situation:
- X running as root
- User apps running as "user"
- Background crap (indexing daemons etc...) running as their own user
or nobody
Unless you can get some kind of grouping based on user sessions
including suid binaries, X etc... I think this shouldn't default y in
Kconfig.
Not that it seems that Michel reported far worse behaviour than what I
saw, including pretty hickup'ish X behaviour even without the fair group
scheduler compared to 2.6.23. It might be because he's running X niced
to -1 (I leave X at 0 and let the scheduler deal with it in general)
though.
> When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
> enabled, X will be given higher priority for running on CPU when compared to
> other niced tasks. When the above options are turned on, X (running
> under root uid) would be given lesser priority to run when compared to other
> niced tasks running user different uids. Hence I expect some drop in
> interactivity-experience with FAIR_GROUP_SCHED on.
>
> Can you pls let me know if any of these makes a difference:
>
> 1. Run niced tasks as root. This would bring X and niced tasks in the
> same "scheduler group" domain, which would give X much more CPU power
> when compared to niced tasks.
I'll dbl check. My tests where indeed done with different users.
> 2. Keep the niced tasks running under a non-root uid, but increase root users
> cpu share.
> # echo 8192 > /sys/kernel/uids/0/cpu_share
>
> This should bump up root user's priority for running on CPU and also
> give a better desktop experience.
Allright, that's something that might need to be set by default by the
kernel ... as it will take some time to have knowledge of those knobs to
percolate to distros. Too bad you can't do the opposite by default for
"nobody" as there's no standard uid for it.
> The group scheduler's SMP-load balance in 2.6.24 is not the best it
> could be. sched-devel has a better load balancer, which I am presuming
> will go into 2.6.25 soon.
>
> In this case, I suspect that's not the issue. If X and the niced processes are
> running under different uids, this (niced processes getting more cpu power) is
> on expected lines. Will wait for Ben to confirm this.
I would suggest turning the fair group scheduler to default n in stable
for now.
Cheers,
Ben.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Roland Dreier @ 2008-01-26 4:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <20080125202034.43556262@zod.rchland.ibm.com>
> Hm. Katmai is already in-tree. Theoretically I should be able to get
> the HW docs and do a new DTS and have it mostly "just work". Perhaps
> I'll give that a shot and have you give it a quick spin.
Yep, should be pretty easy. A while back I built a Katmai kernel in
arch/ppc based on the Yucca support and the differences were pretty
trivial -- as I recall, the Katmai has compact flash support that the
Yucca doesn't have, and the Yucca has a simple little FPGA with a few
registers that controls power to the PCI slots.
- R.
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <1201320834.6815.160.camel@pasglop>
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.
If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.
Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default,
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.
That way all tasks belong to same group by default unless admin explicitly
creates groups and moves around tasks between them. This will be good for
desktop user who may choose to keep all tasks in one group by default, but also
giving him/her the flexibility of exploiting fair-group scheduler by creating
custom task groups and adjusting their cpu shares (for ex: kernel compile group
or multi-media group). If someone still needs the fair-user scheduler (as
provided by CONFIG_FAIR_USER_SCHED), they can still get it with
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around
tasks into different task group based on userid.
Ingo/Peter, what do you think?
> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
>
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
>
> - X running as root
> - User apps running as "user"
> - Background crap (indexing daemons etc...) running as their own user
> or nobody
>
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.
yes, see above.
> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.
Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.
Michel,
You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?
> > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > cpu share.
> > # echo 8192 > /sys/kernel/uids/0/cpu_share
> >
> > This should bump up root user's priority for running on CPU and also
> > give a better desktop experience.
>
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
>
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> >
> > In this case, I suspect that's not the issue. If X and the niced processes are
> > running under different uids, this (niced processes getting more cpu power) is
> > on expected lines. Will wait for Ben to confirm this.
>
> I would suggest turning the fair group scheduler to default n in stable
> for now.
I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?
Reference:
1. http://article.gmane.org/gmane.linux.kernel/553267
--
Regards,
vatsa
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Srivatsa Vaddagiri @ 2008-01-26 5:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <1201320834.6815.160.camel@pasglop>
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.
If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.
Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default,
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.
That way all tasks belong to same group by default unless admin explicitly
creates groups and moves around tasks between them. This will be good for
desktop user who may choose to keep all tasks in one group by default, but also
giving him/her the flexibility of exploiting fair-group scheduler by creating
custom task groups and adjusting their cpu shares (for ex: kernel compile group
or multi-media group). If someone still needs the fair-user scheduler (as
provided by CONFIG_FAIR_USER_SCHED), they can still get it with
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around
tasks into different task group based on userid.
Ingo/Peter, what do you think?
> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
>
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
>
> - X running as root
> - User apps running as "user"
> - Background crap (indexing daemons etc...) running as their own user
> or nobody
>
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.
yes, see above.
> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.
Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.
Michel,
You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?
> > 2. Keep the niced tasks running under a non-root uid, but increase root users
> > cpu share.
> > # echo 8192 > /sys/kernel/uids/0/cpu_share
> >
> > This should bump up root user's priority for running on CPU and also
> > give a better desktop experience.
>
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
>
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> >
> > In this case, I suspect that's not the issue. If X and the niced processes are
> > running under different uids, this (niced processes getting more cpu power) is
> > on expected lines. Will wait for Ben to confirm this.
>
> I would suggest turning the fair group scheduler to default n in stable
> for now.
I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?
Reference:
1. http://article.gmane.org/gmane.linux.kernel/553267
--
Regards,
vatsa
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-26 5:15 UTC (permalink / raw)
To: vatsa
Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
In-Reply-To: <20080126050637.GA14177@linux.vnet.ibm.com>
> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
>
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.
It depends as X can end up starving it's own clients, especially with a
compositing manager or other fancy window manager...
> Michel,
> You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> was the cause for this bad behavior. Do you see behavior change (from good->bad)
> immediately after applying that patch during your bisect process?
Also Michel, double check your .config in both cases.
> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?
I'm going to give that a try but unfortunately, it will have to wait
until I'm back from LCA in a bit more than a week.
Ben.
^ permalink raw reply
* Re: [PATCH 063/196] kset: convert /sys/devices to use kset_create
From: Greg KH @ 2008-01-26 5:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Kay Sievers, torvalds, linux-kernel
In-Reply-To: <20080126034055.GA28786@lixom.net>
On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote:
> On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> > Dynamically create the kset instead of declaring it statically. We also
> > rename devices_subsys to devices_kset to catch all users of the
> > variable.
>
> Guess what, you broke powerpc again!
I did this ON PURPOSE!!!
The linux-kernel archives hold the details, and I was told by the PPC64
IBM people that they would fix this properly for 2.6.25, and not to hold
back on my changes. This has been known for many months now.
> olof@quad:~/work/linux/k.org $ git grep devices_subsys
> arch/powerpc/kernel/vio.c:extern struct kset devices_subsys; /* needed for vio_find_name() */
> arch/powerpc/kernel/vio.c: found = kset_find_obj(&devices_subsys, kobj_name);
>
> Obviously causes build failues, even of ppc64_defconfig.
>
> (I can unfortunately not boot test, since I lack hardware that uses vio)
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 19a5656..ee752ab 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -37,7 +37,7 @@
> #include <asm/iseries/hv_call_xm.h>
> #include <asm/iseries/iommu.h>
>
> -extern struct kset devices_subsys; /* needed for vio_find_name() */
> +extern struct kset *devices_kset; /* needed for vio_find_name() */
No, this just papers over the real problem here. For some reason, the
vio code thinks it is acceptable to walk the whole device tree and match
by a name and just assume that they got the correct device. You call
this "enterprise grade"? :)
You need to just put your device on a real bus, and then just walk the
bus. That's the ONLY way you can guarantee the proper name will return
what you want, and you get the pointer that you really think you are
getting.
There is a reason that devices_kset is not exported, don't make me go
and have to name it something like:
devices_kset_dont_touch_this_or_gregkh_will_make_fun_of_you
Or I'll just mush 3 files in the driver core together and keep the
symbol from being accessible at all.
So no, I'm going to leave the build broken for this code, because that
is what it really is.
Please fix it correctly.
thanks,
greg k-h
^ permalink raw reply
* [PATCH]warp.c
From: Sean MacLennan @ 2008-01-26 5:39 UTC (permalink / raw)
To: linuxppc-dev
While merging, I found a small bug that I forgot to send. I add an
offset to a value twice.
It is much easier to diff if it doesn't show the entire file as new.
Cheers,
Sean MacLennan
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 8f01563..da5b7b7 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -137,7 +137,7 @@ static int __init pika_dtm_start(void)
}
of_node_put(np);
- fpga = ioremap(res.start + 0x20, 4);
+ fpga = ioremap(res.start, 0x24);
if (fpga == NULL)
return -ENOENT;
^ permalink raw reply related
* i2c-ibm_iic.c fix
From: Sean MacLennan @ 2008-01-26 5:44 UTC (permalink / raw)
To: linuxppc-dev
If anybody is following this patch it needs to be updated. It was
recommended that the device_type be removed from the dts files. But the
table matches the type, so I changed the table to only match the
compatibility. I can give people a full blown patch if they want it. But
basically the table should look like follows:
static const struct of_device_id ibm_iic_match[] =
{
{ .compatible = "ibm,iic-405ex", },
{ .compatible = "ibm,iic-405gp", },
{ .compatible = "ibm,iic-440gp", },
{ .compatible = "ibm,iic-440gpx", },
{ .compatible = "ibm,iic-440grx", },
{}
};
Cheers,
Sean
^ 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