* [PATCH 0/9] 83xx DTS fixes and v1 conversions
From: Paul Gortmaker @ 2008-01-28 7:27 UTC (permalink / raw)
To: linuxppc-dev
This series incorporates my earlier qe/muram fix before converting
the existing mpc83xx DTS files to v1 format. I've also redone the
mpc834x_mds with the IRQs as decimal as per Kumar's comments and
re-included that too. I've kept each board as a separate commit
in case one of them conflicts with what someone else is working on.
Boards covered are: 8349mds, 8349mitx, 8349mitx-gp, 836x_mds,
8323_mds, 8323_rdb, and the 8313_rdb. Plus a small tweak to the
sbc8349 (it was already v1 -- but IRQs were in hex.)
I've fed all the files to DTC before and after to ensure the
output is the same after the conversion.
I'm not aware of any explicit rules for what is hex vs decimal.
I've tried to keep things that are usually discussed in decimal
as decimal quantities (i.e. cache size, IRQ, counts, indicies)
and all other data that you'd normally expect in hex (addresses,
IRQ flags, masks) as hex -- including prefixing 0x on values from
zero to 10 where it tends to make rows of numbers (e.g. ranges)
align for better readability, even though it isn't required.
Paul.
^ permalink raw reply
* [PATCH 1/9] qe/muram dts: Explicitly set address-cells and size cells for muram
From: Paul Gortmaker @ 2008-01-28 7:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
In-Reply-To: <1201505279-25847-1-git-send-email-paul.gortmaker@windriver.com>
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/mpc836x_mds.dts | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
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>;
};
};
--
1.5.4.rc4.gcab31
^ permalink raw reply related
* [PATCH 2/9] mpc834x_mds: Convert device tree source to dts-v1
From: Paul Gortmaker @ 2008-01-28 7:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
In-Reply-To: <a050480a21aef92854805e9bee517c0d65d5bd59.1201503958.git.paul.gortmaker@windriver.com>
Move mpc834x_mds device tree source forward to dts-v1 format. Nothing
too complex in this one, so it boils down to just adding a bunch of 0x
in the right places and converting clock speeds to decimal.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/mpc834x_mds.dts | 254 +++++++++++++++++----------------
1 files changed, 128 insertions(+), 126 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 4120e92..537a77c 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -9,6 +9,8 @@
* option) any later version.
*/
+/dts-v1/;
+
/ {
model = "MPC8349EMDS";
compatible = "MPC8349EMDS", "MPC834xMDS", "MPC83xxMDS";
@@ -31,10 +33,10 @@
PowerPC,8349@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
+ d-cache-line-size = <32>; // 32 bytes
+ i-cache-line-size = <32>; // 32 bytes
+ d-cache-size = <32768>; // L1, 32K
+ i-cache-size = <32768>; // L1, 32K
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
@@ -43,26 +45,26 @@
memory {
device_type = "memory";
- reg = <00000000 10000000>; // 256MB at 0
+ reg = <0x00000000 0x10000000>; // 256MB at 0
};
bcsr@e2400000 {
device_type = "board-control";
- reg = <e2400000 8000>;
+ reg = <0xe2400000 0x8000>;
};
soc8349@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
- ranges = <0 e0000000 00100000>;
- reg = <e0000000 00000200>;
+ ranges = <0x0 0xe0000000 0x00100000>;
+ reg = <0xe0000000 0x00000200>;
bus-frequency = <0>;
wdt@200 {
device_type = "watchdog";
compatible = "mpc83xx_wdt";
- reg = <200 100>;
+ reg = <0x200 0x100>;
};
i2c@3000 {
@@ -70,14 +72,14 @@
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
- reg = <3000 100>;
- interrupts = <e 8>;
- interrupt-parent = < &ipic >;
+ reg = <0x3000 0x100>;
+ interrupts = <14 0x8>;
+ interrupt-parent = <&ipic>;
dfsrr;
rtc@68 {
compatible = "dallas,ds1374";
- reg = <68>;
+ reg = <0x68>;
};
};
@@ -86,41 +88,41 @@
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
- reg = <3100 100>;
- interrupts = <f 8>;
- interrupt-parent = < &ipic >;
+ reg = <0x3100 0x100>;
+ interrupts = <15 0x8>;
+ interrupt-parent = <&ipic>;
dfsrr;
};
spi@7000 {
device_type = "spi";
compatible = "fsl_spi";
- reg = <7000 1000>;
- interrupts = <10 8>;
- interrupt-parent = < &ipic >;
+ reg = <0x7000 0x1000>;
+ interrupts = <16 0x8>;
+ interrupt-parent = <&ipic>;
mode = "cpu";
};
- /* phy type (ULPI or SERIAL) are only types supportted for MPH */
+ /* phy type (ULPI or SERIAL) are only types supported for MPH */
/* port = 0 or 1 */
usb@22000 {
compatible = "fsl-usb2-mph";
- reg = <22000 1000>;
+ reg = <0x22000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
- interrupt-parent = < &ipic >;
- interrupts = <27 8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <39 0x8>;
phy_type = "ulpi";
port1;
};
/* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */
usb@23000 {
compatible = "fsl-usb2-dr";
- reg = <23000 1000>;
+ reg = <0x23000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
- interrupt-parent = < &ipic >;
- interrupts = <26 8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <38 0x8>;
dr_mode = "otg";
phy_type = "ulpi";
};
@@ -129,18 +131,18 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
- reg = <24520 20>;
+ reg = <0x24520 0x20>;
phy0: ethernet-phy@0 {
- interrupt-parent = < &ipic >;
- interrupts = <11 8>;
- reg = <0>;
+ interrupt-parent = <&ipic>;
+ interrupts = <17 0x8>;
+ reg = <0x0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
- interrupt-parent = < &ipic >;
- interrupts = <12 8>;
- reg = <1>;
+ interrupt-parent = <&ipic>;
+ interrupts = <18 0x8>;
+ reg = <0x1>;
device_type = "ethernet-phy";
};
};
@@ -150,11 +152,11 @@
device_type = "network";
model = "TSEC";
compatible = "gianfar";
- reg = <24000 1000>;
+ reg = <0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <20 8 21 8 22 8>;
- interrupt-parent = < &ipic >;
- phy-handle = < &phy0 >;
+ interrupts = <32 0x8 33 0x8 34 0x8>;
+ interrupt-parent = <&ipic>;
+ phy-handle = <&phy0>;
linux,network-index = <0>;
};
@@ -163,11 +165,11 @@
device_type = "network";
model = "TSEC";
compatible = "gianfar";
- reg = <25000 1000>;
+ reg = <0x25000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <23 8 24 8 25 8>;
- interrupt-parent = < &ipic >;
- phy-handle = < &phy1 >;
+ interrupts = <35 0x8 36 0x8 37 0x8>;
+ interrupt-parent = <&ipic>;
+ phy-handle = <&phy1>;
linux,network-index = <1>;
};
@@ -175,20 +177,20 @@
cell-index = <0>;
device_type = "serial";
compatible = "ns16550";
- reg = <4500 100>;
+ reg = <0x4500 0x100>;
clock-frequency = <0>;
- interrupts = <9 8>;
- interrupt-parent = < &ipic >;
+ interrupts = <9 0x8>;
+ interrupt-parent = <&ipic>;
};
serial1: serial@4600 {
cell-index = <1>;
device_type = "serial";
compatible = "ns16550";
- reg = <4600 100>;
+ reg = <0x4600 0x100>;
clock-frequency = <0>;
- interrupts = <a 8>;
- interrupt-parent = < &ipic >;
+ interrupts = <10 0x8>;
+ interrupt-parent = <&ipic>;
};
/* May need to remove if on a part without crypto engine */
@@ -196,15 +198,15 @@
device_type = "crypto";
model = "SEC2";
compatible = "talitos";
- reg = <30000 10000>;
- interrupts = <b 8>;
- interrupt-parent = < &ipic >;
+ reg = <0x30000 0x10000>;
+ interrupts = <11 0x8>;
+ interrupt-parent = <&ipic>;
num-channels = <4>;
- channel-fifo-len = <18>;
- exec-units-mask = <0000007e>;
+ channel-fifo-len = <0x18>;
+ exec-units-mask = <0x0000007e>;
/* desc mask is for rev2.0,
* we need runtime fixup for >2.0 */
- descriptor-types-mask = <01010ebf>;
+ descriptor-types-mask = <0x01010ebf>;
};
/* IPIC
@@ -217,129 +219,129 @@
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
- reg = <700 100>;
+ reg = <0x700 0x100>;
device_type = "ipic";
};
};
pci0: pci@e0008500 {
cell-index = <1>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x11 */
- 8800 0 0 1 &ipic 14 8
- 8800 0 0 2 &ipic 15 8
- 8800 0 0 3 &ipic 16 8
- 8800 0 0 4 &ipic 17 8
+ 0x8800 0x0 0x0 0x1 &ipic 20 0x8
+ 0x8800 0x0 0x0 0x2 &ipic 21 0x8
+ 0x8800 0x0 0x0 0x3 &ipic 22 0x8
+ 0x8800 0x0 0x0 0x4 &ipic 23 0x8
/* IDSEL 0x12 */
- 9000 0 0 1 &ipic 16 8
- 9000 0 0 2 &ipic 17 8
- 9000 0 0 3 &ipic 14 8
- 9000 0 0 4 &ipic 15 8
+ 0x9000 0x0 0x0 0x1 &ipic 22 0x8
+ 0x9000 0x0 0x0 0x2 &ipic 23 0x8
+ 0x9000 0x0 0x0 0x3 &ipic 20 0x8
+ 0x9000 0x0 0x0 0x4 &ipic 21 0x8
/* IDSEL 0x13 */
- 9800 0 0 1 &ipic 17 8
- 9800 0 0 2 &ipic 14 8
- 9800 0 0 3 &ipic 15 8
- 9800 0 0 4 &ipic 16 8
+ 0x9800 0x0 0x0 0x1 &ipic 23 0x8
+ 0x9800 0x0 0x0 0x2 &ipic 20 0x8
+ 0x9800 0x0 0x0 0x3 &ipic 21 0x8
+ 0x9800 0x0 0x0 0x4 &ipic 22 0x8
/* IDSEL 0x15 */
- a800 0 0 1 &ipic 14 8
- a800 0 0 2 &ipic 15 8
- a800 0 0 3 &ipic 16 8
- a800 0 0 4 &ipic 17 8
+ 0xa800 0x0 0x0 0x1 &ipic 20 0x8
+ 0xa800 0x0 0x0 0x2 &ipic 21 0x8
+ 0xa800 0x0 0x0 0x3 &ipic 22 0x8
+ 0xa800 0x0 0x0 0x4 &ipic 23 0x8
/* IDSEL 0x16 */
- b000 0 0 1 &ipic 17 8
- b000 0 0 2 &ipic 14 8
- b000 0 0 3 &ipic 15 8
- b000 0 0 4 &ipic 16 8
+ 0xb000 0x0 0x0 0x1 &ipic 23 0x8
+ 0xb000 0x0 0x0 0x2 &ipic 20 0x8
+ 0xb000 0x0 0x0 0x3 &ipic 21 0x8
+ 0xb000 0x0 0x0 0x4 &ipic 22 0x8
/* IDSEL 0x17 */
- b800 0 0 1 &ipic 16 8
- b800 0 0 2 &ipic 17 8
- b800 0 0 3 &ipic 14 8
- b800 0 0 4 &ipic 15 8
+ 0xb800 0x0 0x0 0x1 &ipic 22 0x8
+ 0xb800 0x0 0x0 0x2 &ipic 23 0x8
+ 0xb800 0x0 0x0 0x3 &ipic 20 0x8
+ 0xb800 0x0 0x0 0x4 &ipic 21 0x8
/* IDSEL 0x18 */
- c000 0 0 1 &ipic 15 8
- c000 0 0 2 &ipic 16 8
- c000 0 0 3 &ipic 17 8
- c000 0 0 4 &ipic 14 8>;
- interrupt-parent = < &ipic >;
- interrupts = <42 8>;
+ 0xc000 0x0 0x0 0x1 &ipic 21 0x8
+ 0xc000 0x0 0x0 0x2 &ipic 22 0x8
+ 0xc000 0x0 0x0 0x3 &ipic 23 0x8
+ 0xc000 0x0 0x0 0x4 &ipic 20 0x8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <0x42 0x8>;
bus-range = <0 0>;
- ranges = <02000000 0 90000000 90000000 0 10000000
- 42000000 0 80000000 80000000 0 10000000
- 01000000 0 00000000 e2000000 0 00100000>;
- clock-frequency = <3f940aa>;
+ ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000
+ 0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>;
+ clock-frequency = <66666666>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <e0008500 100>;
+ reg = <0xe0008500 0x100>;
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
pci1: pci@e0008600 {
cell-index = <2>;
- interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x11 */
- 8800 0 0 1 &ipic 14 8
- 8800 0 0 2 &ipic 15 8
- 8800 0 0 3 &ipic 16 8
- 8800 0 0 4 &ipic 17 8
+ 0x8800 0x0 0x0 0x1 &ipic 20 0x8
+ 0x8800 0x0 0x0 0x2 &ipic 21 0x8
+ 0x8800 0x0 0x0 0x3 &ipic 22 0x8
+ 0x8800 0x0 0x0 0x4 &ipic 23 0x8
/* IDSEL 0x12 */
- 9000 0 0 1 &ipic 16 8
- 9000 0 0 2 &ipic 17 8
- 9000 0 0 3 &ipic 14 8
- 9000 0 0 4 &ipic 15 8
+ 0x9000 0x0 0x0 0x1 &ipic 22 0x8
+ 0x9000 0x0 0x0 0x2 &ipic 23 0x8
+ 0x9000 0x0 0x0 0x3 &ipic 20 0x8
+ 0x9000 0x0 0x0 0x4 &ipic 21 0x8
/* IDSEL 0x13 */
- 9800 0 0 1 &ipic 17 8
- 9800 0 0 2 &ipic 14 8
- 9800 0 0 3 &ipic 15 8
- 9800 0 0 4 &ipic 16 8
+ 0x9800 0x0 0x0 0x1 &ipic 23 0x8
+ 0x9800 0x0 0x0 0x2 &ipic 20 0x8
+ 0x9800 0x0 0x0 0x3 &ipic 21 0x8
+ 0x9800 0x0 0x0 0x4 &ipic 22 0x8
/* IDSEL 0x15 */
- a800 0 0 1 &ipic 14 8
- a800 0 0 2 &ipic 15 8
- a800 0 0 3 &ipic 16 8
- a800 0 0 4 &ipic 17 8
+ 0xa800 0x0 0x0 0x1 &ipic 20 0x8
+ 0xa800 0x0 0x0 0x2 &ipic 21 0x8
+ 0xa800 0x0 0x0 0x3 &ipic 22 0x8
+ 0xa800 0x0 0x0 0x4 &ipic 23 0x8
/* IDSEL 0x16 */
- b000 0 0 1 &ipic 17 8
- b000 0 0 2 &ipic 14 8
- b000 0 0 3 &ipic 15 8
- b000 0 0 4 &ipic 16 8
+ 0xb000 0x0 0x0 0x1 &ipic 23 0x8
+ 0xb000 0x0 0x0 0x2 &ipic 20 0x8
+ 0xb000 0x0 0x0 0x3 &ipic 21 0x8
+ 0xb000 0x0 0x0 0x4 &ipic 22 0x8
/* IDSEL 0x17 */
- b800 0 0 1 &ipic 16 8
- b800 0 0 2 &ipic 17 8
- b800 0 0 3 &ipic 14 8
- b800 0 0 4 &ipic 15 8
+ 0xb800 0x0 0x0 0x1 &ipic 22 0x8
+ 0xb800 0x0 0x0 0x2 &ipic 23 0x8
+ 0xb800 0x0 0x0 0x3 &ipic 20 0x8
+ 0xb800 0x0 0x0 0x4 &ipic 21 0x8
/* IDSEL 0x18 */
- c000 0 0 1 &ipic 15 8
- c000 0 0 2 &ipic 16 8
- c000 0 0 3 &ipic 17 8
- c000 0 0 4 &ipic 14 8>;
- interrupt-parent = < &ipic >;
- interrupts = <42 8>;
+ 0xc000 0x0 0x0 0x1 &ipic 21 0x8
+ 0xc000 0x0 0x0 0x2 &ipic 22 0x8
+ 0xc000 0x0 0x0 0x3 &ipic 23 0x8
+ 0xc000 0x0 0x0 0x4 &ipic 20 0x8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <66 0x8>;
bus-range = <0 0>;
- ranges = <02000000 0 b0000000 b0000000 0 10000000
- 42000000 0 a0000000 a0000000 0 10000000
- 01000000 0 00000000 e2100000 0 00100000>;
- clock-frequency = <3f940aa>;
+ ranges = <0x02000000 0x0 0xb0000000 0xb0000000 0x0 0x10000000
+ 0x42000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2100000 0x0 0x00100000>;
+ clock-frequency = <66666666>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <e0008600 100>;
+ reg = <0xe0008600 0x100>;
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
--
1.5.4.rc4.gcab31
^ permalink raw reply related
* xsysace.c driver oops on reboot (PPC405 on Virtex-II pro)
From: Jean-Samuel Chenard @ 2008-01-28 5:55 UTC (permalink / raw)
To: linuxppc-embedded
SGksCgpJIGFtIHVzaW5nIGEgWGlsaW54IE1MLTMxMCBib2FyZCBhbmQgYSBCRUUyIGRldmVsb3Bt
ZW50IHN5c3RlbSBhbmQKYm90aCBjb25maWd1cmF0aW9ucyBzaG93IHRoZSBzYW1lIHByb2JsZW0u
ICBJIHVzZSB0aGUgU3lzdGVtIEFDRSBJUApjb3JlIChvcGJfc3lzYWNlIHZlcnNpb24gMS4wMC5j
IG9uIEVESzkuMS4wMmkpLiAgSWYgSSBjb21waWxlIG15Cmtlcm5lbCAyLjYuMjQtcmMzIChJIHVz
ZSBhIHZlcnkgcmVjZW50IHB1bGwgZnJvbSBnaXQuc2VjcmV0bGFiLmNhKQp3aXRoIHRoZSAib2xk
IFN5c3RlbSBBQ0UiIGRyaXZlciBmcm9tIFhpbGlueCwgSSBjYW4gaXNzdWUgdGhlIHJlYm9vdApj
b21tYW5kIG9uIGJ1c3lib3ggYW5kIEkgZ2V0IGEgcHJvcGVyIHJlYm9vdC4KCklmIEkgY29tcGls
ZSBteSBrZXJuZWwgd2l0aCB0aGUgbmV3IFN5c3RlbUFDRSBkcml2ZXIKKGRyaXZlcnMvYmxvY2sv
eHN5c2FjZS5jKSwgdGhlIGRyaXZlciB3b3JrcyBncmVhdCBhbmQgSSBjYW4gcmVhZC93cml0ZQp0
byB0aGUgQ29tcGFjdEZsYXNoIGNhcmQgd2l0aG91dCBwcm9ibGVtcy4gICBIb3dldmVyLCB3aGVu
IEkgaXNzdWUgdGhlCnJlYm9vdCBjb21tYW5kLCBJIGdldCBhIGtlcm5lbCBvb3BzLiAgU3RyYW5n
ZWx5LCB0aGUgb29wcyBkb2VzIG5vdApoYXBwZW4gd2hlbiBJIGRvIGEgc2h1dGRvd24gY29tbWFu
ZCAoa2VybmVsIGhhbHQpLiAgSSBmdXJ0aGVyCmludmVzdGlnYXRlZCB0aGUgaXNzdWUgYnkgYnVp
bGRpbmcgYSBSQU0gZmlsZXN5c3RlbSBhbmQgYnVpbGRpbmcgYm90aApzeXN0ZW0gQUNFIGRyaXZl
cnMgYXMgbG9hZGFibGUgbW9kdWxlcy4KCklmIEkgZG9uJ3QgbG9hZCBhbnkgc3lzdGVtQUNFIG1v
ZHVsZSBhbmQgY2FsbCByZWJvb3QgPT4gSSBnZXQgdGhlIG9vcHMgbWVzc2FnZS4KSWYgSSBsb2Fk
IHRoZSBuZXcgc3lzdGVtQUNFIG1vZHVsZSBhbmQgY2FsbCByZWJvb3QgPT4gSSBnZXQgdGhlIG9v
cHMgbWVzc2FnZS4KSWYgSSBsb2FkIHRoZSAiT2xkIFN5c3RlbUFjZSIgbW9kdWxlIGFuZCBjYWxs
IHJlYm9vdCA9PiBUaGUgcHJvY2Vzc29yCnJlYm9vdHMgcHJvcGVybHkgLSBHT09ECklmIEkgbG9h
ZCB0aGUgIk9sZCBTeXN0ZW1BY2UiIG1vZHVsZSwgdW5sb2FkIGl0IGFuZCB0aGVuIGNhbGwgcmVi
b290Cj0+IEkgZ2V0IHRoZSBvb3BzIG1lc3NhZ2UKClNvIHRoZXJlIGlzIHNvbWUgY29kZSB0aGF0
IGdldHMgY2FsbGVkIHdpdGggdGhlIE9sZCBTeXN0ZW1BQ0UgZHJpdmVyCndoaWNoIG1ha2VzIGl0
IGhhbmRsZSB0aGUgcmVib290IGNvcnJlY3RseSB0aGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcKZnJv
bSB0aGUgbmV3IHN5c3RlbUFDRSBkcml2ZXIuICBUaGUgaGFyZHdhcmUgSVAgbWF5IGJlIG1pc2Jl
aGF2aW5nCmxpa2Ugc2VuZGluZyBhbiBpbnRlcnJ1cHQgb3Igc29tZXRoaW5nIGxpa2UgdGhhdCBh
dCBzb21lIHBvaW50IHdoZW4KdGhlIHByb2Nlc3NvciBpcyBnb2luZyBmb3IgcmVib290IGFuZCB1
bmFibGUgdG8gaGFuZGxlIGl0LiAgVGhlIFhpbGlueAoob2xkKSBkcml2ZXIgc2VlbXMgdG8gcGx1
ZyB1cCB0aGlzIHByb2JsZW0gc29tZWhvdy4uLgoKTm90ZSB0aGF0IEkgZGlkIGhhdmUgdG8gdHdl
YWsgdGhlIG5ldyBzeXN0ZW1BQ0UgZHJpdmVyIHNsaWdodGx5IHRvCm1ha2UgaXQgd29yayBvbiB0
aGUgTUwtMzEwIChiZWNhdXNlIG9mIHRoZSA4LWJpdCBidXMgb2YgdGhlClN5c3RlbUFDRSk6CkBA
IC0xMTI2LDcgKzExMjYsNyBAQCBzdGF0aWMgdm9pZCBfX2RldmV4aXQgYWNlX2ZyZWUoc3RydWN0
IGRldmljZSAqZGV2KQogc3RhdGljIGludCBfX2RldmluaXQgYWNlX3Byb2JlKHN0cnVjdCBwbGF0
Zm9ybV9kZXZpY2UgKmRldikKIHsKICAgICAgICB1bnNpZ25lZCBsb25nIHBoeXNhZGRyID0gMDsK
LSAgICAgICBpbnQgYnVzX3dpZHRoID0gQUNFX0JVU19XSURUSF8xNjsgLyogRklYTUU6IHNob3Vs
ZCBub3QgYmUgaGFyZCBjb2RlZCAqLworICAgICAgIGludCBidXNfd2lkdGggPSBBQ0VfQlVTX1dJ
RFRIXzg7IC8qIEZJWE1FOiBzaG91bGQgbm90IGJlIGhhcmQgY29kZWQgKi8KICAgICAgICBpbnQg
aWQgPSBkZXYtPmlkOwogICAgICAgIGludCBpcnEgPSBOT19JUlE7CgpIZXJlIGlzIGFuIG9vcHMg
dHJhY2UgdGhhdCBJIGdvdCB3aGVuIEkgZG9uJ3QgbG9hZCBhbnkgc3lzdGVtQUNFCmRyaXZlciAo
SSBzaG93IGEgZmV3IG9mIHRoZSBsYXN0IGNvbnNvbGUgbWVzc2FnZXMgYmVmb3JlIHRoZSBvb3Bz
KS4gIEkKZ290IHRoaXMgbWVzc2FnZSBmcm9tIG15IE1MLTMxMCBib2FyZCwgYnV0IHRoZSBzYW1l
IGhhcHBlbnMgb24gdGhlCkJFRTI6Cj09ClRoZSBzeXN0ZW0gaXMgZ29pbmcgZG93biBOT1chClNl
bmRpbmcgU0lHVEVSTSB0byBhbGwgcHJvY2Vzc2VzClJlcXVlc3Rpbmcgc3lzdGVtIHJlYm9vdApb
ICAgMjUuODYyNDQwXSBSZXN0YXJ0aW5nIHN5c3RlbS4KWyAgIDI1Ljjvv71bICAgMjUuODY2NDY3
XSBPb3BzOiBFeGNlcHRpb24gaW4ga2VybmVsIG1vZGUsIHNpZzogOCBbIzFdClsgICAyNS44NzAz
ODJdIE5JUDogYzdkMjFlMDAgTFI6IGM3ZDIxZGYwIENUUjogMDAwMDAwMDEKWyAgIDI1Ljg3NTMx
Ml0gUkVHUzogYzdkMjFkNDAgVFJBUDogMjAwMWRmMCAgIE5vdCB0YWludGVkCigyLjYuMjQtcmMz
LWpzYy1zZWNsYWItTkVUV09SSy1nNTk1NThkYzEtZGlydHkpClsgICAyNS44ODQ2MzBdIE1TUjog
YzAwZTg3M2MgPEVFLElSLERSPiAgQ1I6IDAwMDAwMDEwICBYRVI6IDAwMTIwMGQyClsgICAyNS44
OTA2ODRdIFRBU0sgPSBjN2MzN2JhMFsxNDldICdsaW51eHJjJyBUSFJFQUQ6IGM3ZDIwMDAwClsg
ICAyNS44OTYwMzRdIEdQUjAwOiAzYzMwM2U1YiAyMDIwMjAzMiAzNTJlMzgzNiAzMjM0MzQzMCA1
ZDIwMDBhMApjMDBmNTg1OCAwMDAwMDcwMCA3ZmI3OGYwYwpbICAgMjUuOTA0MzI3XSBHUFIwODog
MDAwMDAwMDAgZmVlMWRlYWQgMjgxMjE5NjkgMDAwMDAwMDAgYzdkMjFkZjAKYzAwMWYxNTAgMDdm
ZmRkYTggMDAwMDAwMDAKWyAgIDI1LjkxMjYyMF0gR1BSMTY6IDAwMDAwMDAxIDAwMDAwMDAwIGMw
MTkwMDAwIGMwM2NmY2ZjIGMwMDBiNTRjCjAwMDAwY2IyIDAwMDAwMDAwIDAwMDAwMDAwClsgICAy
NS45MjA5MTRdIEdQUjI0OiAwMDAwMDAwMCBmZmZmZmZmZiAwMDAwMDAwMCAwMDAyZDAzMCAwMDAw
MDAwMQpjMDAyZGM1NCBjN2QyMWU4NCBjN2QyMWU2MApbICAgMjUuOTI5MzgxXSBOSVAgW2M3ZDIx
ZTAwXSAweGM3ZDIxZTAwClsgICAyNS45MzMwMDldIExSIFtjN2QyMWRmMF0gMHhjN2QyMWRmMApb
ICAgMjUuOTM2NTUwXSBDYWxsIFRyYWNlOgpbICAgMjUuOTM4OTcxXSBJbnN0cnVjdGlvbiBkdW1w
OgpbICAgMjUuOTQxOTA4XSBYWFhYWFhYWCBYWFhYWFhYWCBYWFhYWFhYWCBYWFhYWFhYWCBYWFhY
WFhYWCBYWFhYWFhYWApYWFhYWFhYWCBYWFhYWFhYWApbICAgMjUuOTQ5NTk1XSBYWFhYWFhYWCBY
WFhYWFhYWCBYWFhYWFhYWCBYWFhYWFhYWCBYWFhYWFhYWCBYWFhYWFhYWApYWFhYWFhYWCBYWFhY
WFhYWAo9PQoKTm90ZSB0aGF0IEkgaGF2ZSBlbmFibGVkIENPTkZJR19ERUJVR19CVUdWRVJCT1NF
LCBDT05GSUdfREVCVUdfSU5GTwphbmQgQ09ORklHX0RFQlVHX0tFUk5FTC4gIEhvd2V2ZXIsIHRo
b3NlIGFkZHJlc3NlcyBnaXZlbiBhdCBOSVAgZG9uJ3QKc2VlbSB0byBtYXRjaCBhbnl0aGluZyBp
biBteSBrZXJuZWwgbWVtb3J5IG1hcC4KCkkgYW0gYSBiaXQgZ3JlZW4gdG8gZW1iZWRkZWQgbGlu
dXggYW5kIGVzcGVjaWFsbHkgdGhlIGRlYnVnZ2luZyBvZgprZXJuZWwgZXJyb3JzLi4uICBEaWQg
YW55IG90aGVyIE1MLTMxMCB1c2VycyBlbmNvdW50ZXIgdGhpcyBwcm9ibGVtCmJlZm9yZSA/CgpU
aGUgZWFzeSBmaXggaXMganVzdCB0byB1c2UgdGhlIG9sZCBkcml2ZXIgZnJvbSBYaWxpbngsIGJ1
dCB0aGUgbmV3CmRyaXZlciBzZWVtcyBmYXN0ZXIgYW5kIGlzIG5vdyBwYXJ0IG9mIHRoZSBtYWlu
bGluZSB0cmVlLi4uCgpMZXQgbWUga25vdyBpZiB5b3Uga25vdyBzb21lIHRyaWNrcyBvbiBob3cg
SSBjb3VsZCBkZWJ1ZyB0aGlzIHByb2JsZW0uCiBOb3RlIHRoYXQgYXQgdGhpcyB0aW1lLCBJIGRv
bid0IGhhdmUgYSBkZWJ1Z2dpbmcgY2FibGUgZm9yIG15IE1MLTMxMCwKc28gSSByZWx5IG9uIHBy
aW50aW5nIGZvciBkZWJ1Z2dpbmcuCgpUaGFua3MsCgpKZWFuLVNhbXVlbAotLSAKSW50ZWdyYXRl
ZCBNaWNyb3N5c3RlbXMgTGFib3JhdG9yeQpNY0dpbGwgVW5pdmVyc2l0eSwgTW9udHLDqWFsLCBR
QywgQ0FOQURBCldlYiBQYWdlOiBodHRwOi8vY2hhb3MuZWNlLm1jZ2lsbC5jYQo=
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Benjamin Herrenschmidt @ 2008-01-28 4:25 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar, vatsa, Peter Zijlstra
In-Reply-To: <1201450409.1931.23.camel@thor.sulgenrain.local>
On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:
>
> > Do you see behavior change (from good->bad) immediately after
> applying that patch
> > during your bisect process?
>
> Yes, confirmed by trying that commit and its parent again.
Just to be paranoid... can you try with a different gcc version in case
something gets miscompiled ?
Ben.
^ permalink raw reply
* Re: Load Kernel 2.6 using U-boot on ML403
From: Yedu Jathavedan @ 2008-01-28 4:25 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40801271313y4370ac3dmd4460d79362f10c4@mail.gmail.com>
>
> Looking at your bootlog, it doesn't look like you've got the systemace
> driver built into the kernel.
>
>
Grant,
Yes, the systemace was not built into the kernel. It is successfully
booting the kernel now.
Trying to bring up the Ethernet interface. Any pointers?
Thank you,
Yedu
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Steve Heflin @ 2008-01-28 3:37 UTC (permalink / raw)
To: Josh Boyer, linuxppc-embedded
In-Reply-To: <20080127200044.148982a6@zod.rchland.ibm.com>
At 09:00 PM 1/27/2008, Josh wrote:
>On Sun, 27 Jan 2008 18:37:22 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > Hello!
> >
> > Yes! I'm looking at 2.6.23.14 as I thought that was the newest
> > version. I completely missed seeing the 2.6.24 kit, thank you so much!!
>
>FYI, 2.6.24 is considered fairly old relatively speaking. With so much
>activity going on for the embedded boards for arch/powerpc, you're sort
>of missing out if you aren't running from the latest git trees.
>
>Yes, I realize how ridiculous it sounds to say a kernel that was just
>released 3 days ago is old, but that's reality.
>
>josh
Hey Josh, thank you so much for the pointer to the git trees. I've
been using Linus' kernel.org tree, as that's where I was pointed to
by the powerpc web site about 2 months ago. I sure do appreciate your
updated pointer to the git tree, I will now locate it and stay tuned
and participate.
steve
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Josh Boyer @ 2008-01-28 2:00 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080127233751.A6F9EDDDF0@ozlabs.org>
On Sun, 27 Jan 2008 18:37:22 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> Hello!
>
> Yes! I'm looking at 2.6.23.14 as I thought that was the newest
> version. I completely missed seeing the 2.6.24 kit, thank you so much!!
FYI, 2.6.24 is considered fairly old relatively speaking. With so much
activity going on for the embedded boards for arch/powerpc, you're sort
of missing out if you aren't running from the latest git trees.
Yes, I realize how ridiculous it sounds to say a kernel that was just
released 3 days ago is old, but that's reality.
josh
^ permalink raw reply
* PATCH[1/1] 8xx: Add clock-frequency to .dts brg entries
From: Bryan O'Donoghue @ 2008-01-28 1:53 UTC (permalink / raw)
To: linuxppc-dev, scottwood
cpm_uart_core has a dependency on fsl,cpm-brg/clock-frequency, this
means that a .dts that uses the cpm uart driver needs to supply a
clock-frequency entry for get_brgfreq to return a meaningful number.
Included is a patchset which adds the correct brgclk to the adder port -
@ 50Mhz and also adds an entry for mpc885ads - which I've noticed is
missing a clock-frequency entry.
Without an entry for clock-frequency in the .dts you'd get -1 as the
return value brgclk !
Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
---
diff --git a/arch/powerpc/boot/dts/adder875-redboot.dts
b/arch/powerpc/boot/dts/adder875-redboot.dts
index 7c25d96..975f3d4 100644
--- a/arch/powerpc/boot/dts/adder875-redboot.dts
+++ b/arch/powerpc/boot/dts/adder875-redboot.dts
@@ -149,6 +149,7 @@
compatible = "fsl,mpc875-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0x2faf080>;
reg = <0x9f0 0x10>;
};
diff --git a/arch/powerpc/boot/dts/adder875-uboot.dts
b/arch/powerpc/boot/dts/adder875-uboot.dts
index 605202f..18d6dd6 100644
--- a/arch/powerpc/boot/dts/adder875-uboot.dts
+++ b/arch/powerpc/boot/dts/adder875-uboot.dts
@@ -148,6 +148,7 @@
compatible = "fsl,mpc875-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0x2faf080>;
reg = <0x9f0 0x10>;
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 8848e63..f2a437b 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -166,6 +166,7 @@
compatible = "fsl,mpc885-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
+ clock-frequency = <0>;
reg = <9f0 10>;
};
^ permalink raw reply related
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Steve Heflin @ 2008-01-27 23:37 UTC (permalink / raw)
To: Olof Johansson, linuxppc-embedded
In-Reply-To: <20080127233923.GA5550@lixom.net>
Hello!
Yes! I'm looking at 2.6.23.14 as I thought that was the newest
version. I completely missed seeing the 2.6.24 kit, thank you so much!!
- Steve
At 06:39 PM 1/27/2008, you wrote:
>Hi,
>
>On Sun, Jan 27, 2008 at 06:05:06PM -0500, Steve Heflin wrote:
> > The Sequoia board (AMCC-440EPx processor) is missing from the new
> > arch/powerpc. The Sequoia board is also missing from arch/ppc , but
> > there is support for integrated devices on the AMCC part inside
> > arch/ppc that needs to be incorporated into arch/powerpc. In
> > addition, there needs to be a "sequoia.c" file added to the
> > arch/powerpc/44x directory. I have a good start on the missing
> > pieces and a test platform, is this contribution desired?
>
>2.6.24 already has sequoia support in arch/powerpc. Are you looking at
>an older tree?
>
>olof@quad:~/work/linux/k.org $ head arch/powerpc/platforms/44x/sequoia.c
>/*
> * Sequoia board specific routines
> *
> * Valentine Barshak <vbarshak@ru.mvista.com>
> * Copyright 2007 MontaVista Software Inc.
> *
> * Based on the Bamboo code by
> * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> * Copyright 2007 IBM Corporation
> *
>...
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Olof Johansson @ 2008-01-27 23:39 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080127231214.1F50ADDDE9@ozlabs.org>
Hi,
On Sun, Jan 27, 2008 at 06:05:06PM -0500, Steve Heflin wrote:
> The Sequoia board (AMCC-440EPx processor) is missing from the new
> arch/powerpc. The Sequoia board is also missing from arch/ppc , but
> there is support for integrated devices on the AMCC part inside
> arch/ppc that needs to be incorporated into arch/powerpc. In
> addition, there needs to be a "sequoia.c" file added to the
> arch/powerpc/44x directory. I have a good start on the missing
> pieces and a test platform, is this contribution desired?
2.6.24 already has sequoia support in arch/powerpc. Are you looking at
an older tree?
olof@quad:~/work/linux/k.org $ head arch/powerpc/platforms/44x/sequoia.c
/*
* Sequoia board specific routines
*
* Valentine Barshak <vbarshak@ru.mvista.com>
* Copyright 2007 MontaVista Software Inc.
*
* Based on the Bamboo code by
* Josh Boyer <jwboyer@linux.vnet.ibm.com>
* Copyright 2007 IBM Corporation
*
...
^ permalink raw reply
* Re: Reminder: removal of arch/ppc - (Sequoia)
From: Steve Heflin @ 2008-01-27 23:05 UTC (permalink / raw)
To: linuxppc-embedded
The Sequoia board (AMCC-440EPx processor) is missing from the new
arch/powerpc. The Sequoia board is also missing from arch/ppc , but
there is support for integrated devices on the AMCC part inside
arch/ppc that needs to be incorporated into arch/powerpc. In
addition, there needs to be a "sequoia.c" file added to the
arch/powerpc/44x directory. I have a good start on the missing
pieces and a test platform, is this contribution desired?
- Steve Heflin
New Age Micro
CEO & Software Engineer
At 11:55 AM 1/25/2008, you 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:
>
> PREP
> PQ2ADS
> TQM8260
> CPCI690
> EV64260
> CHESTNUT
> LOPEC
> KATANA
> HDPU
> MVME5100
> PAL4
> POWERPMC250
> PPLUS
> PRPMC750
> PRPMC800
> RADSTONE_PPC7D
> SANDPOINT
> SBC82xx
> SPRUCE
> LITE5200
> EV64360
> MPC86XADS
> MPC885ADS
> ADS8272
>
>4xx:
> BAMBOO
> CPCI405
> EBONY
> EP405
> BUBINGA
> LUAN
> YUCCA
> OCOTEA
> REDWOOD_5
> REDWOOD_6
> SYCAMORE
> TAISHAN
> WALNUT
> XILINX_ML300
> XILINX_ML403
>
>- k
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Anton Vorontsov @ 2008-01-27 21:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <fa686aa40801271259k5fd3340bg1b7f29da774be85b@mail.gmail.com>
On Sun, Jan 27, 2008 at 01:59:51PM -0700, Grant Likely wrote:
a> On 1/27/08, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> > On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> > > Hi Anton,
> > >
> > > > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > > > +{
> > > > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > > > + struct port_regs *regs = mm_gc->regs;
> > > > + u32 pin_mask;
> > > > + u32 tmp_val;
> > > > +
> > > > + /* calculate pin location */
> > > > + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > > > +
> > > > + tmp_val = in_be32(®s->cpdata);
> > > > +
> > > > + if (val == 0)
> > > > + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> > > > + else
> > > > + out_be32(®s->cpdata, pin_mask | tmp_val);
> > > > +}
> > >
> > > I see a possible problem with this (and in the corresponding call in CPM1, as well):
> > >
> > > if there is a pin configured as open drain, you might accidently switch this pin to 0
> > > while switching a different pin, if an external device is pulling the pin to 0.
> >
> > Unfortunately I can't think out any workaround for this, except
> > implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
> > start using it in the drivers that might care about this issue. Though,
> > looking into i2c-gpio.c I don't clearly see were we can insert these
> > locks, there should be "start/end transaction" handlers or something,
> > but it seems that it's in the bitbanging code, not in the i2c-gpio
> > driver..
> >
> > Actually, I see this as a hardware limitation. For example, on ARMs
> > PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
> > not all-in-one data register.
>
> I've run into this exact issue on other GPIO hardware too. It's not
> uncommon behaviour in GPIO hardware.
>
> The solution is to not depend on the hardware to remember what the
> output pin values should be. Add a shadow register in the driver
> private data. Set the pin state for each output pin in the shadow
> register and then write that value to the hardware. That way input
> state doesn't interfere with the output values.
Great idea, much thanks. Would be easy to implement also.
> Also, you do still need spinlocks around the manipulation of the
> shared registers; otherwise you'll have very hard to debug race
> conditions. Probably one spin lock per bank.
With GPIO LIB we already have per bank spinlock, so it isn't
a problem.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: Grant Likely @ 2008-01-27 21:15 UTC (permalink / raw)
To: Ricardo Severo; +Cc: linuxppc-embedded
In-Reply-To: <479CAF56.30306@gmail.com>
On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> Hi all,
>
> I am working with a Xilinx Virtex II Pro evaluation board, wich has two
> PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> My question is how the initial execution (the one who uncompresses the
> kernel image) transfers the processor to the kernel itself. I've looked
> in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> position?
Post your output log please.
If your getting a message that the kernel is uncompressing, but you
don't have any output beyond that then most likely your console is not
setup correctly. If you've got a debugger, look at memory at the
__log_buf location to see if there are any boot logs there.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Load Kernel 2.6 using U-boot on ML403
From: Grant Likely @ 2008-01-27 21:13 UTC (permalink / raw)
To: Yedu Jathavedan; +Cc: linuxppc-embedded
In-Reply-To: <20080126231047.y3lm7epb0gw4cog8@webmail.cecs.pdx.edu>
On 1/27/08, Yedu Jathavedan <yeduj@ece.pdx.edu> wrote:
>
> 1)Downloaded(sourceforge.net) & compiled the U-boot 1.1.6 files to get
> u-boot, u-boot.srec & u-boot.bin (I didn't find ml403 board config for the
> uboot. So used ml300_config).
U-boot 1.1.6 is ancient. The u-boot project has moved off of
sourceforge to denx.de
> After this, I tried to convert the u-boot (README says that this is an ELF
> file) into an ace file. But, it gave me the error saying unable to read elf
> file. Is it because ML403 board is not supported or is it possible that the
> u-boot image that I created is corrupted?
I don't know; but personally I don't weld u-boot into an ace file. I
use a 1st stage bootloader to load the u-boot image off the cf card
(but unfortunately I'm not able to post that loader at this time).
Try again with a recent u-boot version.
> 2) Since generating ace files failed, I tried to search the net for an
> u-boot ace file that could run on ML403 & found it at
> http://88.191.24.164/docenligne/projets/samba/2006/linux-embarque-sur-ml-403/u-boot-ml403.ace/view
>
> I copied this ace file (u-boot-ml403.ace) along with the kernel 2.6 image
> (uImage) onto my CF card & booted the board. After loading the kernel, it
> fails to read the correct root device. I tried changing the "bootargs" env
> variable root = /dev/xsysace/disc0/part2 rw to root = /dev/xsysace2 rw &
> root = /dev/xsda2 rw.
>
> But, it failed in both cases. (There was a previous post on Problem2 a year
> ago & he solved it by giving root =/dev/xsysace2)
Looking at your bootlog, it doesn't look like you've got the systemace
driver built into the kernel.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Grant Likely @ 2008-01-27 20:59 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <20080127160818.GA25859@zarina>
On 1/27/08, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> > Hi Anton,
> >
> > > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > > +{
> > > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > > + struct port_regs *regs = mm_gc->regs;
> > > + u32 pin_mask;
> > > + u32 tmp_val;
> > > +
> > > + /* calculate pin location */
> > > + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > > +
> > > + tmp_val = in_be32(®s->cpdata);
> > > +
> > > + if (val == 0)
> > > + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> > > + else
> > > + out_be32(®s->cpdata, pin_mask | tmp_val);
> > > +}
> >
> > I see a possible problem with this (and in the corresponding call in CPM1, as well):
> >
> > if there is a pin configured as open drain, you might accidently switch this pin to 0
> > while switching a different pin, if an external device is pulling the pin to 0.
>
> Unfortunately I can't think out any workaround for this, except
> implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
> start using it in the drivers that might care about this issue. Though,
> looking into i2c-gpio.c I don't clearly see were we can insert these
> locks, there should be "start/end transaction" handlers or something,
> but it seems that it's in the bitbanging code, not in the i2c-gpio
> driver..
>
> Actually, I see this as a hardware limitation. For example, on ARMs
> PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
> not all-in-one data register.
I've run into this exact issue on other GPIO hardware too. It's not
uncommon behaviour in GPIO hardware.
The solution is to not depend on the hardware to remember what the
output pin values should be. Add a shadow register in the driver
private data. Set the pin state for each output pin in the shadow
register and then write that value to the hardware. That way input
state doesn't interfere with the output values.
Also, you do still need spinlocks around the manipulation of the
shared registers; otherwise you'll have very hard to debug race
conditions. Probably one spin lock per bank.
Here's what I did for a Xilinx GPIO block driver (but ignore the fact
that I'm not using driver private data so only one GPIO block can be
supported; that will be fixed before I post this driver)
+void gpio_set_value(unsigned gpio, int value)
+{
+ unsigned long flags;
+
+ if (!gpio_regs)
+ return;
+
+ spin_lock_irqsave(&gpio_spinlock, flags);
+ if (value)
+ gpio_output_state |= 1<<gpio;
+ else
+ gpio_output_state &= ~(1<<gpio);
+ out_be32(gpio_regs, gpio_output_state);
+ spin_unlock_irqrestore(&gpio_spinlock, flags);
+}
+EXPORT_SYMBOL_GPL(gpio_set_value);
Cheers,
g.
>
> --
> Anton Vorontsov
> email: cbou@mail.ru
> backup email: ya-cbou@yandex.ru
> irc://irc.freenode.net/bd2
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC (Take 2)
From: Nish Aravamudan @ 2008-01-27 20:22 UTC (permalink / raw)
To: balbir, Paul Mackerras, linuxppc-dev, LKML; +Cc: Mel Gorman
In-Reply-To: <20080127150147.GA10914@balbir.in.ibm.com>
On 1/27/08, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> * Paul Mackerras <paulus@samba.org> [2008-01-27 22:55:43]:
>
> > Balbir Singh writes:
> >
> > > Here's a better and more complete fix for the problem. Could you
> > > please see if it works for you? I tested it on a real NUMA box and it
> > > seemed to work fine there.
> >
> > There are a couple of other changes in behaviour that your patch
> > introduces, and I'd like to understand them better before taking the
> > patch. First, with your patch we don't set nodes online if they end
> > up having no memory in them because of the memory limit, whereas
> > previously we did. Secondly, in the case where we don't have NUMA
> > information, we now set node 0 online after adding each LMB, whereas
> > previously we only set it online once.
> >
> > If in fact these changes are benign, then your patch description
> > should mention them and explain why they are benign.
> >
>
> Yes, they are. I'll try and justify the changes with a good detailed
> changelog. If people prefer it, I can hide fake NUMA nodes under a
> config option, so that it does not come enabled by default.
Sigh, there already *is* a fake NUMA config option: CONFIG_NUMA_EMU.
"CONFIG_NUMA_EMU:
Enable NUMA emulation. A flat machine will be split
into virtual nodes when booted with "numa=fake=N", where N is the
number of nodes. This is only useful for debugging."
I have to assume your patch is implementing the same feature for
powerpc (really just extending the x86_64 one), and thus should share
the config option.
Any chance you can just make some of that code common? Maybe as a
follow-on patch. I expect that some of Mel's (added to Cc) work to
allow NUMA to be set on x86 more easily will flow quite simply into
adding fake NUMA support there as well. So moving the code to a common
place (at least the parsing) makes sense.
I also feel like you want to be able to online memoryless nodes --
that's where we've been hitting a number of bugs lately in the VM. I
can't tell from Paul's comment if your patch prevents that from being
faked or not.
Thanks,
Nish
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Geoff Levand @ 2008-01-27 20:01 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Andrew Morton,
Linux Frame Buffer Device Development,
Cell Broadband Engine OSS Development, Antonino Daplas
In-Reply-To: <Pine.LNX.4.64.0801271215120.10514@vixen.sonytel.be>
On 01/27/2008 03:15 AM, Geert Uytterhoeven wrote:
> On Sun, 27 Jan 2008, Andrew Morton wrote:
>> > On Sun, 27 Jan 2008 10:44:40 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>> > I posted these patches before, about 2 months ago. Unfortunately I didn't CC
>> > you at that time, so they slipped under your radar.
>> > But the patches did receive public testing even before that, when they entered
>> > Geoff's ps3-linux.git tree.
>>
>> Should that git tree be in the -mm lineup?
>
> That may be a good idea! Geoff?
Sounds good.
ps3-linux.git is used by a lot of active PS3 developers, so
already gets some good testing on PS3, but I think if we get
the stable patches into -mm, then we will get more testing on
non-PS3 platforms, which is something I think we need.
As a start, I'll work toward getting patches from ps3-stable
into -mm. I think it is too late now for the 2.6.25 patches,
so the 'for 2.6.26' ones. To make this work, we (PS3
maintainers) need to get our patches moved from ps3-wip to
ps3-stable in a timely manner. As of late, it seems patches
have lingered in ps3-wip too long.
-Geoff
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: Jon Smirl @ 2008-01-27 19:21 UTC (permalink / raw)
To: David Brownell; +Cc: Jean Delvare, linuxppc-dev, Linux I2C
In-Reply-To: <200801271040.20248.david-b@pacbell.net>
On 1/27/08, David Brownell <david-b@pacbell.net> wrote:
> General comment: if you're going to index arrays by enum
> values, it's best to initialize them that way too. Else
> you're expecting a particular optional policy for how the
> enums get grown...
Even better is the way the m41t80 driver does it. Can we get the base
patch set in first and then do driver clean up in later patches?
>
> - Dave
>
>
> On Monday 21 January 2008, Jean Delvare wrote:
> > --- linux-2.6.24-rc8.orig/drivers/rtc/rtc-ds1307.c 2008-01-20 17:26:58.000000000 +0100
> > +++ linux-2.6.24-rc8/drivers/rtc/rtc-ds1307.c 2008-01-20 19:03:48.000000000 +0100
> > @@ -102,42 +102,36 @@ struct chip_desc {
> > char name[9];
> > unsigned nvram56:1;
> > unsigned alarm:1;
> > - enum ds_type type;
> > };
> >
> > static const struct chip_desc chips[] = { {
> > .name = "ds1307",
> > - .type = ds_1307,
> > .nvram56 = 1,
> > }, {
>
> So tables like this would become
>
> [ds1307] = { ... },
> [ds1337] = { ... },
>
> > .name = "ds1337",
> > - .type = ds_1337,
> > .alarm = 1,
> > }, {
> > .name = "ds1338",
> > - .type = ds_1338,
> > .nvram56 = 1,
> > }, {
> > .name = "ds1339",
> > - .type = ds_1339,
> > .alarm = 1,
> > }, {
> > .name = "ds1340",
> > - .type = ds_1340,
> > }, {
> > .name = "m41t00",
> > - .type = m41t00,
> > }, };
> >
> > -static inline const struct chip_desc *find_chip(const char *s)
> > -{
> > - unsigned i;
> > -
> > - for (i = 0; i < ARRAY_SIZE(chips); i++)
> > - if (strnicmp(s, chips[i].name, sizeof chips[i].name) == 0)
> > - return &chips[i];
> > - return NULL;
> > -}
> > +static const struct i2c_device_id ds1307_id[] = {
> > + { "ds1307", ds_1307 },
> > + { "ds1337", ds_1337 },
> > + { "ds1338", ds_1338 },
> > + { "ds1339", ds_1339 },
> > + { "ds1340", ds_1340 },
> > + { "m41t00", m41t00 },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(i2c, ds1307_id);
> >
> > static int ds1307_get_time(struct device *dev, struct rtc_time *t)
> > {
> > @@ -335,12 +329,7 @@ static int __devinit ds1307_probe(struct
> > const struct chip_desc *chip;
> > struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> >
> > - chip = find_chip(client->name);
> > - if (!chip) {
> > - dev_err(&client->dev, "unknown chip type '%s'\n",
> > - client->name);
> > - return -ENODEV;
> > - }
> > + chip = &chips[id->driver_data];
>
> ... and that would *ensure* such lines always work right,
> no matter how the enum values grow.
>
> >
> > if (!i2c_check_functionality(adapter,
> > I2C_FUNC_I2C | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 2/3] i2c: Convert all new-style drivers to use module aliasing
From: David Brownell @ 2008-01-27 18:40 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Linux I2C
In-Reply-To: <20080121114139.3aaa111a@hyperion.delvare>
General comment: if you're going to index arrays by enum
values, it's best to initialize them that way too. Else
you're expecting a particular optional policy for how the
enums get grown...
- Dave
On Monday 21 January 2008, Jean Delvare wrote:
> --- linux-2.6.24-rc8.orig/drivers/rtc/rtc-ds1307.c 2008-01-20 17:26:58.000000000 +0100
> +++ linux-2.6.24-rc8/drivers/rtc/rtc-ds1307.c 2008-01-20 19:03:48.000000000 +0100
> @@ -102,42 +102,36 @@ struct chip_desc {
> char name[9];
> unsigned nvram56:1;
> unsigned alarm:1;
> - enum ds_type type;
> };
>
> static const struct chip_desc chips[] = { {
> .name = "ds1307",
> - .type = ds_1307,
> .nvram56 = 1,
> }, {
So tables like this would become
[ds1307] = { ... },
[ds1337] = { ... },
> .name = "ds1337",
> - .type = ds_1337,
> .alarm = 1,
> }, {
> .name = "ds1338",
> - .type = ds_1338,
> .nvram56 = 1,
> }, {
> .name = "ds1339",
> - .type = ds_1339,
> .alarm = 1,
> }, {
> .name = "ds1340",
> - .type = ds_1340,
> }, {
> .name = "m41t00",
> - .type = m41t00,
> }, };
>
> -static inline const struct chip_desc *find_chip(const char *s)
> -{
> - unsigned i;
> -
> - for (i = 0; i < ARRAY_SIZE(chips); i++)
> - if (strnicmp(s, chips[i].name, sizeof chips[i].name) == 0)
> - return &chips[i];
> - return NULL;
> -}
> +static const struct i2c_device_id ds1307_id[] = {
> + { "ds1307", ds_1307 },
> + { "ds1337", ds_1337 },
> + { "ds1338", ds_1338 },
> + { "ds1339", ds_1339 },
> + { "ds1340", ds_1340 },
> + { "m41t00", m41t00 },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, ds1307_id);
>
> static int ds1307_get_time(struct device *dev, struct rtc_time *t)
> {
> @@ -335,12 +329,7 @@ static int __devinit ds1307_probe(struct
> const struct chip_desc *chip;
> struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
>
> - chip = find_chip(client->name);
> - if (!chip) {
> - dev_err(&client->dev, "unknown chip type '%s'\n",
> - client->name);
> - return -ENODEV;
> - }
> + chip = &chips[id->driver_data];
... and that would *ensure* such lines always work right,
no matter how the enum values grow.
>
> if (!i2c_check_functionality(adapter,
> I2C_FUNC_I2C | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: David Baird @ 2008-01-27 18:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <479CAF56.30306@gmail.com>
On Jan 27, 2008 9:20 AM, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> Hi all,
>
> I am working with a Xilinx Virtex II Pro evaluation board, wich has two
> PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> My question is how the initial execution (the one who uncompresses the
> kernel image) transfers the processor to the kernel itself. I've looked
> in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> position?
>
> Thanks,
It should branch to the beginning of arch/ppc/kernel/head_4xx.S, which
I think was 0x0.
Some things to check are:
- Comment/remove the weak embed_config in arch/ppc/boot/simple/misc-embedded.c
- Did you use ttyUL0 or ttyS0 as your console?
If that fails, you can use XMD to set a breakpoint at 0x0 and then
read the memory to see if it matches up with an objdump of vmlinux.
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] QE: implement GPIO LIB API
From: Anton Vorontsov @ 2008-01-27 16:08 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, Arnd Bergmann, David Gibson
In-Reply-To: <479C8A34.2000701@scram.de>
On Sun, Jan 27, 2008 at 02:42:12PM +0100, Jochen Friedrich wrote:
> Hi Anton,
>
> > +static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> > +{
> > + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> > + struct port_regs *regs = mm_gc->regs;
> > + u32 pin_mask;
> > + u32 tmp_val;
> > +
> > + /* calculate pin location */
> > + pin_mask = (u32) (1 << (NUM_OF_PINS - 1 - gpio));
> > +
> > + tmp_val = in_be32(®s->cpdata);
> > +
> > + if (val == 0)
> > + out_be32(®s->cpdata, ~pin_mask & tmp_val);
> > + else
> > + out_be32(®s->cpdata, pin_mask | tmp_val);
> > +}
>
> I see a possible problem with this (and in the corresponding call in CPM1, as well):
>
> if there is a pin configured as open drain, you might accidently switch this pin to 0
> while switching a different pin, if an external device is pulling the pin to 0.
Unfortunately I can't think out any workaround for this, except
implementing generic gpio_bank_{,un}lock(gpio_pin_on_the_bank), and
start using it in the drivers that might care about this issue. Though,
looking into i2c-gpio.c I don't clearly see were we can insert these
locks, there should be "start/end transaction" handlers or something,
but it seems that it's in the bitbanging code, not in the i2c-gpio
driver..
Actually, I see this as a hardware limitation. For example, on ARMs
PXA2xx, there are separate, per bank, read/set/clear GPIO registers,
not all-in-one data register.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Linux boot on a ppc 405
From: Ricardo Severo @ 2008-01-27 16:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am working with a Xilinx Virtex II Pro evaluation board, wich has two
PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
Until now I've manged to make it uncompress the kernel, but it doesn't boot.
My question is how the initial execution (the one who uncompresses the
kernel image) transfers the processor to the kernel itself. I've looked
in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
0x0 after uncompressing, is it right? The kernel is uncompressed at that
position?
Thanks,
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: [patch 00/11] ps3av/3fb patches for 2.6.25
From: Jon Loeliger @ 2008-01-27 16:15 UTC (permalink / raw)
To: Josh Boyer
Cc: Linux Frame Buffer Device Development, Antonino Daplas,
Linux/PPC Development, Geert Uytterhoeven, Andrew Morton, Cell,
Development
In-Reply-To: <20080127074230.00adf79d@zod.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
>
> There are lots of powerpc sub-trees. Kumar's, Geoff's, mine, Olof's,
> Grant's, Vitaly's are just the ones I can think of the top of my head.
>
> Shouldn't we just ask Paul to sync up more often rather than have
> Andrew track X number of trees that eventually all merge into Paul's
> anyway?
I think that is an excellent notion.
jdl
^ permalink raw reply
* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
From: Michel Dänzer @ 2008-01-27 16:13 UTC (permalink / raw)
To: vatsa; +Cc: Ingo Molnar, Peter Zijlstra, linuxppc-dev
In-Reply-To: <20080126050757.GB14177@linux.vnet.ibm.com>
On Sat, 2008-01-26 at 10:39 +0530, Srivatsa Vaddagiri wrote:
> On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
>
> > > 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.
Note that in my test case, the niced infinite loop constantly burns
significantly more than 50% of the cycles; X and its clients never need
more than 20% (high estimate) each to move windows smoothly. So even
under the premise above, it should be possible to have smooth
interaction with X while there is a CPU hog in another group, shouldn't
it?
> > 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.
FWIW, -1 or 0 for X doesn't seem to make any difference for this
problem.
(I've had X at -1 because a long time ago, when it was at 0 some 3D
games could starve it to the point that their input would be delayed)
> Michel,
> You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> was the cause for this bad behavior.
Well, it may not be the cause, but that's where the hickups with
CONFIG_FAIR_USER_SCHED disabled first manifest themselves, yes.
> Do you see behavior change (from good->bad) immediately after applying that patch
> during your bisect process?
Yes, confirmed by trying that commit and its parent again.
> > > 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.
Running the niced CPU hog as root or my user instead of as nobody didn't
seem to make a difference, maybe because the X session requires
interaction between processes having different uids, and disturbing
either is sufficient.
> > > 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.
I didn't try 8192, but bumping the shares of root and my user up to 4096
didn't seem to help much if at all. Decreasing the share of the user
running the niced CPU hog to 1 resulted in more or less the same
behaviour as with CONFIG_FAIR_USER_SCHED disabled.
> > > 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.
FWIW, the scheduler changes merged after 2.6.24 don't seem to help at
all for my test:
With CONFIG_FAIR_USER_SCHED enabled, X still becomes unusable.
With CONFIG_FAIR_USER_SCHED disabled, X remains mostly usable, but there
are still hickups that weren't there with 2.6.23. (BTW, the hickups seem
related to top running in the terminal window I'm trying to move;
without top running, there are no hickups when moving the window. With
2.6.23, there are no hickups even with top running)
Note that my test case is an exaggerated example constructed from worse
(than with 2.6.23) interactive behaviour I've been seeing with my
day-to-day X session. This isn't just a theoretical problem.
> > > 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?
Seems to be the same as with CONFIG_FAIR_GROUP_SCHED disabled
completely.
In summary, there are two separate problems with similar symptoms, which
had me confused at times:
* With CONFIG_FAIR_USER_SCHED disabled, there are severe
interactivity hickups with a niced CPU hog and top running. This
started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8.
* With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
unusable with a niced CPU hog, with or without top running. I
don't know when this started, possibly when this option was
first introduced.
I don't personally care too much about the latter problem - I can live
well without that option. But it would be nice if the former problem
could be fixed (and the default changed from CONFIG_FAIR_USER_SCHED to
CONFIG_FAIR_CGROUP_SCHED) in 2.6.24.x.
FWIW, the patch below (which reverts commit
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8) restores 2.6.24 interactivity
to the same level as 2.6.23 here with CONFIG_FAIR_USER_SCHED disabled
(my previous report to the contrary was with CONFIG_FAIR_USER_SCHED
enabled because I didn't yet realize the difference it makes), but I
don't know if that's the real fix.
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
struct task_struct *curr = rq->curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = &curr->se, *pse = &p->se;
- unsigned long gran;
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se->load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, &se->load);
- if (pse->vruntime + gran < se->vruntime)
+ if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
resched_task(curr);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
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