* [PATCH][v2] powerpc/85xx: Create dts for each core in CAMP mode for P2020RDB
From: Poonam Aggrwal @ 2009-09-19 17:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Poonam Aggrwal
This patch creates the dts files for each core and splits the devices between
the two cores for P2020RDB.
core0 has memory, L2, i2c, spi, dma1, usb, eth0, eth1, crypto, global-util, pci0
core1 has L2, dma2, eth0, pci1, msi.
MPIC is shared between two cores but each core will protect its
interrupts from other core by using "protected-sources" of mpic.
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
---
- based on http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
- branch->next
- Removed interrupt properties for serial ports to make them work in polling mode.
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 363 +++++++++++++++++++++++++
arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 184 +++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 10 +-
3 files changed, 556 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts b/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
new file mode 100644
index 0000000..0fe93d0
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
@@ -0,0 +1,363 @@
+/*
+ * P2020 RDB Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts file allows core0 to have memory, l2, i2c, spi, gpio, dma1, usb,
+ * eth1, eth2, sdhc, crypto, global-util, pci0.
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = "fsl,P2020";
+ compatible = "fsl,P2020RDB", "fsl,MPC85XXRDB-CAMP";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ serial0 = &serial0;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P2020@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p2020-immr", "simple-bus";
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,p2020-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,p2020-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ };
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ rtc@68 {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ };
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ };
+
+ spi@7000 {
+ cell-index = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,espi";
+ reg = <0x7000 0x1000>;
+ interrupts = <59 0x2>;
+ interrupt-parent = <&mpic>;
+ mode = "cpu";
+
+ fsl_m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,espi-flash";
+ reg = <0>;
+ linux,modalias = "fsl_m25p80";
+ modal = "s25sl128b";
+ spi-max-frequency = <50000000>;
+ mode = <0>;
+
+ partition@0 {
+ /* 512KB for u-boot Bootloader Image */
+ reg = <0x0 0x00080000>;
+ label = "SPI (RO) U-Boot Image";
+ read-only;
+ };
+
+ partition@80000 {
+ /* 512KB for DTB Image */
+ reg = <0x00080000 0x00080000>;
+ label = "SPI (RO) DTB Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 4MB for Linux Kernel Image */
+ reg = <0x00100000 0x00400000>;
+ label = "SPI (RO) Linux Kernel Image";
+ read-only;
+ };
+
+ partition@500000 {
+ /* 4MB for Compressed RFS Image */
+ reg = <0x00500000 0x00400000>;
+ label = "SPI (RO) Compressed RFS Image";
+ read-only;
+ };
+
+ partition@900000 {
+ /* 7MB for JFFS2 based RFS */
+ reg = <0x00900000 0x00700000>;
+ label = "SPI (RW) JFFS2 RFS";
+ };
+ };
+ };
+
+ gpio: gpio-controller@f000 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8572-gpio";
+ reg = <0xf000 0x100>;
+ interrupts = <47 0x2>;
+ interrupt-parent = <&mpic>;
+ gpio-controller;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p2020-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2,512K
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma";
+ reg = <0x21300 0x4>;
+ ranges = <0x0 0x21100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <20 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <21 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <22 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <23 2>;
+ };
+ };
+
+ usb@22000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-usb2-dr";
+ reg = <0x22000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <28 0x2>;
+ phy_type = "ulpi";
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x24520 0x20>;
+
+ phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <3 1>;
+ reg = <0x0>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <3 1>;
+ reg = <0x1>;
+ };
+ };
+
+ mdio@25520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x26520 0x20>;
+
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet1: ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <1>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x25000 0x1000>;
+ ranges = <0x0 0x25000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <35 2 36 2 40 2>;
+ interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi0>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "sgmii";
+
+ };
+
+ enet2: ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <2>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x26000 0x1000>;
+ ranges = <0x0 0x26000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <31 2 32 2 33 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ sdhci@2e000 {
+ compatible = "fsl,p2020-esdhc", "fsl,esdhc";
+ reg = <0x2e000 0x1000>;
+ interrupts = <72 0x2>;
+ interrupt-parent = <&mpic>;
+ /* Filled in by U-Boot */
+ clock-frequency = <0>;
+ };
+
+ crypto@30000 {
+ compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
+ "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
+ reg = <0x30000 0x10000>;
+ interrupts = <45 2 58 2>;
+ interrupt-parent = <&mpic>;
+ fsl,num-channels = <4>;
+ fsl,channel-fifo-len = <24>;
+ fsl,exec-units-mask = <0xbfe>;
+ fsl,descriptor-types-mask = <0x3ab0ebf>;
+ };
+
+ mpic: pic@40000 {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ protected-sources = <
+ 42 76 77 78 79 /* serial1 , dma2 */
+ 29 30 34 26 /* enet0, pci1 */
+ 0xe0 0xe1 0xe2 0xe3 /* msi */
+ 0xe4 0xe5 0xe6 0xe7
+ >;
+ };
+
+ global-utilities@e0000 {
+ compatible = "fsl,p2020-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+ };
+
+ pci0: pcie@ffe09000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0 0xffe09000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc30000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <25 2>;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/p2020rdb_camp_core1.dts b/arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
new file mode 100644
index 0000000..e95a512
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
@@ -0,0 +1,184 @@
+/*
+ * P2020 RDB Core1 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts allows core1 to have l2, dma2, eth0, pci1, msi.
+ *
+ * Please note to add "-b 1" for core1's dts compiling.
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = "fsl,P2020";
+ compatible = "fsl,P2020RDB", "fsl,MPC85XXRDB-CAMP";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 = &enet0;
+ serial0 = &serial0;
+ pci1 = &pci1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P2020@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p2020-immr", "simple-bus";
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ bus-frequency = <0>; // Filled out by uboot.
+
+ serial0: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ };
+
+ dma@c300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma";
+ reg = <0xc300 0x4>;
+ ranges = <0x0 0xc100 0x200>;
+ cell-index = <1>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <76 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <77 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <78 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <79 2>;
+ };
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p2020-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2,512K
+ interrupt-parent = <&mpic>;
+ };
+
+
+ enet0: ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x24000 0x1000>;
+ ranges = <0x0 0x24000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <29 2 30 2 34 2>;
+ interrupt-parent = <&mpic>;
+ fixed-link = <1 1 1000 0 0>;
+ phy-connection-type = "rgmii-id";
+
+ };
+
+ mpic: pic@40000 {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ protected-sources = <
+ 17 18 43 42 59 47 /*ecm, mem, i2c, serial0, spi,gpio */
+ 16 20 21 22 23 28 /* L2, dma1, USB */
+ 03 35 36 40 31 32 33 /* mdio, enet1, enet2 */
+ 72 45 58 25 /* sdhci, crypto , pci */
+ >;
+ };
+
+ msi@41600 {
+ compatible = "fsl,p2020-msi", "fsl,mpic-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe0 0
+ 0xe1 0
+ 0xe2 0
+ 0xe3 0
+ 0xe4 0
+ 0xe5 0
+ 0xe6 0
+ 0xe7 0>;
+ interrupt-parent = <&mpic>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0 0xffe0a000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <26 2>;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0xc0000000
+ 0x2000000 0x0 0xc0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index c8468de..d173164 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -44,6 +44,7 @@ void __init mpc85xx_rdb_pic_init(void)
struct mpic *mpic;
struct resource r;
struct device_node *np;
+ unsigned long root = of_get_flat_dt_root();
np = of_find_node_by_type(NULL, "open-pic");
if (np == NULL) {
@@ -57,11 +58,18 @@ void __init mpc85xx_rdb_pic_init(void)
return;
}
- mpic = mpic_alloc(np, r.start,
+ if (of_flat_dt_is_compatible(root, "fsl,85XXRDB-CAMP")) {
+ mpic = mpic_alloc(np, r.start,
+ MPIC_PRIMARY |
+ MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS,
+ 0, 256, " OpenPIC ");
+ } else {
+ mpic = mpic_alloc(np, r.start,
MPIC_PRIMARY | MPIC_WANTS_RESET |
MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
MPIC_SINGLE_DEST_CPU,
0, 256, " OpenPIC ");
+ }
BUG_ON(mpic == NULL);
of_node_put(np);
--
1.5.6.5
^ permalink raw reply related
* Re: FPGA access over PCI-E on MPC8536
From: Leon Woestenberg @ 2009-09-19 18:31 UTC (permalink / raw)
To: Felix Radensky, Greg KH, Greg KH; +Cc: linuxppc-dev
In-Reply-To: <4AB1B84F.8080606@embedded-sol.com>
Hello Felix,
On Thu, Sep 17, 2009 at 6:17 AM, Felix Radensky <felix@embedded-sol.com> wrote:
> On my custom MPC8536 based board running 2.6.31 kernel
> FPGA is connected via x2 PCI-E lane. FPGA is identified
> during PCI scan and is visible via lspci.
>
I committed a PCI Express device driver for an Altera FPGA (chaining
DMA reference) design upstream that resides in the upstream Linux
kernel at drivers/staging/altpciechdma/
It can act as a reference for the generic part of your design.
Regards,
--
Leon
^ permalink raw reply
* [PATCH] sbc8548: fixup of PCI-e related DTS fields
From: Paul Gortmaker @ 2009-09-21 0:49 UTC (permalink / raw)
To: linuxppc-dev
The PCI-e addressing was originally patterned of the MPC8548CDS
which has PCI1, PCI2, and PCI-e. Since this board only has
PCI1 and PCI-e, it makes more sense to be similar to the MPC8568MDS
board. This does that by cutting the PCI/PCI-e I/O sizes from
16MB to 8MB and pulling the PCI-e I/O range back to 0xe280_0000
(the hole where PCI2 I/O would have been).
This also fixes a typo where an extra zero made an 8MB range a 128MB
range, removes the hole left by PCI2 from the aliases, and sets the
clocks to match the oscillators that are actually on the board.
With accompanying u-boot updates, PCI-e has been validated with
both a sky2 card (1148:9e00) and an e1000 card (8086:108b).
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/sbc8548.dts | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index 9eefe00..a5bb015 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -26,8 +26,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
- /* pci1 doesn't have a corresponding physical connector */
- pci2 = &pci2;
+ pci1 = &pci1;
};
cpus {
@@ -381,7 +380,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00800000>;
- clock-frequency = <66666666>;
+ clock-frequency = <66000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -390,7 +389,7 @@
device_type = "pci";
};
- pci2: pcie@e000a000 {
+ pci1: pcie@e000a000 {
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
@@ -403,9 +402,9 @@
interrupt-parent = <&mpic>;
interrupts = <0x1a 0x2>;
bus-range = <0x0 0xff>;
- ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
- 0x01000000 0x0 0x00000000 0xe3000000 0x0 0x08000000>;
- clock-frequency = <33333333>;
+ ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2800000 0x0 0x08000000>;
+ clock-frequency = <33000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -419,11 +418,11 @@
device_type = "pci";
ranges = <0x02000000 0x0 0xa0000000
0x02000000 0x0 0xa0000000
- 0x0 0x20000000
+ 0x0 0x10000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
- 0x0 0x08000000>;
+ 0x0 0x0800000>;
};
};
};
--
1.6.4.1
^ permalink raw reply related
* Re: PPC_4xx synopsy USB driver
From: Stefan Roese @ 2009-09-21 5:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cote, Sylvain
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01FA07D04F37@ATLMBX.verint.corp.verintsystems.com>
Hi Sylvain,
On Friday 18 September 2009 17:50:24 Cote, Sylvain wrote:
> USB gadget support --> y
> Maximum VBUS power usage = 500
> Synopsys DWC OTG controller
> Synopsys DWC OTG internal DMA mode --> y
> USB gadget --> M
> gadget zero --> M
> Ethernet Gadget --> M
> RNDIS support --> y
>
> Any help will be appreciated
Looks good so far. I suspect that the only thing missing for your 405EX custom
board is the following line in the arch/powerpc/sysdev/Makefile:
obj-$(CONFIG_KILAUEA) += amcc-usbotg.o
to enable the device-tree to platform-device driver wrapper for the USB-OTG
resources.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: rename get_dma_direct_offset get_dma_offset
From: Benjamin Herrenschmidt @ 2009-09-21 5:19 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1251930200-4796-1-git-send-email-beckyb@kernel.crashing.org>
On Wed, 2009-09-02 at 17:23 -0500, Becky Bruce wrote:
> #ifdef CONFIG_NOT_COHERENT_CACHE
> /*
> @@ -90,6 +89,14 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
> dev->archdata.dma_ops = ops;
> }
>
> +static inline unsigned long get_dma_offset(struct device *dev)
> +{
> + if (dev)
> + return (unsigned long)dev->archdata.dma_data;
> +
> + return PCI_DRAM_OFFSET;
> +}
My main objection here is that this makes it look "too" generic ... it
only works for direct and swiotlb, not iommu. Maybe not a big deal but
I think at least there should be a comment explaining what it is and
when it can be used in the header.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Change archdata dma_data to a union
From: Benjamin Herrenschmidt @ 2009-09-21 5:21 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1251930200-4796-2-git-send-email-beckyb@kernel.crashing.org>
On Wed, 2009-09-02 at 17:23 -0500, Becky Bruce wrote:
> Sometimes this is used to hold a simple offset, and sometimes
> it is used to hold a pointer. This patch changes it to a union containing
> void * and dma_addr_t. get/set accessors are also provided, because it was
> getting a bit ugly to get to the actual data.
Looks good, but please respin the two patches with the comment I
suggested added :-)
Cheers,
Ben.
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/device.h | 11 ++++++++++-
> arch/powerpc/include/asm/dma-mapping.h | 10 ++++++++--
> arch/powerpc/include/asm/iommu.h | 10 ++++++++++
> arch/powerpc/kernel/dma-iommu.c | 16 ++++++++--------
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/powerpc/kernel/vio.c | 2 +-
> arch/powerpc/platforms/cell/beat_iommu.c | 2 +-
> arch/powerpc/platforms/cell/iommu.c | 9 +++------
> arch/powerpc/platforms/iseries/iommu.c | 2 +-
> arch/powerpc/platforms/pasemi/iommu.c | 2 +-
> arch/powerpc/platforms/pseries/iommu.c | 8 ++++----
> arch/powerpc/sysdev/dart_iommu.c | 2 +-
> 12 files changed, 49 insertions(+), 27 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
> index 67fcd7f..07ca8b5 100644
> --- a/arch/powerpc/include/asm/device.h
> +++ b/arch/powerpc/include/asm/device.h
> @@ -15,7 +15,16 @@ struct dev_archdata {
>
> /* DMA operations on that device */
> struct dma_map_ops *dma_ops;
> - void *dma_data;
> +
> + /*
> + * When an iommu is in use, dma_data is used as a ptr to the base of the
> + * iommu_table. Otherwise, it is a simple numerical offset.
> + */
> + union {
> + dma_addr_t dma_offset;
> + void *iommu_table_base;
> + } dma_data;
> +
> #ifdef CONFIG_SWIOTLB
> dma_addr_t max_direct_dma_addr;
> #endif
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index eef4db1..e9f4fe9 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -89,14 +89,20 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
> dev->archdata.dma_ops = ops;
> }
>
> -static inline unsigned long get_dma_offset(struct device *dev)
> +static inline dma_addr_t get_dma_offset(struct device *dev)
> {
> if (dev)
> - return (unsigned long)dev->archdata.dma_data;
> + return dev->archdata.dma_data.dma_offset;
>
> return PCI_DRAM_OFFSET;
> }
>
> +static inline void set_dma_offset(struct device *dev, dma_addr_t off)
> +{
> + if (dev)
> + dev->archdata.dma_data.dma_offset = off;
> +}
> +
> /* this will be removed soon */
> #define flush_write_buffers()
>
> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
> index 7464c0d..edfc980 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -70,6 +70,16 @@ struct iommu_table {
>
> struct scatterlist;
>
> +static inline void set_iommu_table_base(struct device *dev, void *base)
> +{
> + dev->archdata.dma_data.iommu_table_base = base;
> +}
> +
> +static inline void *get_iommu_table_base(struct device *dev)
> +{
> + return dev->archdata.dma_data.iommu_table_base;
> +}
> +
> /* Frees table for an individual device node */
> extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index 87ddb3f..37771a5 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -18,7 +18,7 @@
> static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> - return iommu_alloc_coherent(dev, dev->archdata.dma_data, size,
> + return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
> dma_handle, device_to_mask(dev), flag,
> dev_to_node(dev));
> }
> @@ -26,7 +26,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
> static void dma_iommu_free_coherent(struct device *dev, size_t size,
> void *vaddr, dma_addr_t dma_handle)
> {
> - iommu_free_coherent(dev->archdata.dma_data, size, vaddr, dma_handle);
> + iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
> }
>
> /* Creates TCEs for a user provided buffer. The user buffer must be
> @@ -39,8 +39,8 @@ static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
> enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - return iommu_map_page(dev, dev->archdata.dma_data, page, offset, size,
> - device_to_mask(dev), direction, attrs);
> + return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
> + size, device_to_mask(dev), direction, attrs);
> }
>
>
> @@ -48,7 +48,7 @@ static void dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
> size_t size, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - iommu_unmap_page(dev->archdata.dma_data, dma_handle, size, direction,
> + iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
> attrs);
> }
>
> @@ -57,7 +57,7 @@ static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
> int nelems, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - return iommu_map_sg(dev, dev->archdata.dma_data, sglist, nelems,
> + return iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
> device_to_mask(dev), direction, attrs);
> }
>
> @@ -65,14 +65,14 @@ static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,
> int nelems, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - iommu_unmap_sg(dev->archdata.dma_data, sglist, nelems, direction,
> + iommu_unmap_sg(get_iommu_table_base(dev), sglist, nelems, direction,
> attrs);
> }
>
> /* We support DMA to/from any memory page via the iommu */
> static int dma_iommu_dma_supported(struct device *dev, u64 mask)
> {
> - struct iommu_table *tbl = dev->archdata.dma_data;
> + struct iommu_table *tbl = get_iommu_table_base(dev);
>
> if (!tbl || tbl->it_offset > mask) {
> printk(KERN_INFO
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index e9f4840..bb8209e 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1117,7 +1117,7 @@ void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
>
> /* Hook up default DMA ops */
> sd->dma_ops = pci_dma_ops;
> - sd->dma_data = (void *)PCI_DRAM_OFFSET;
> + set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
>
> /* Additional platform DMA/iommu setup */
> if (ppc_md.pci_dma_dev_setup)
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index bc7b41e..8d9275f 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1233,7 +1233,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
> vio_cmo_set_dma_ops(viodev);
> else
> viodev->dev.archdata.dma_ops = &dma_iommu_ops;
> - viodev->dev.archdata.dma_data = vio_build_iommu_table(viodev);
> + set_iommu_table_base(&viodev->dev, vio_build_iommu_table(viodev));
> set_dev_node(&viodev->dev, of_node_to_nid(of_node));
>
> /* init generic 'struct device' fields: */
> diff --git a/arch/powerpc/platforms/cell/beat_iommu.c b/arch/powerpc/platforms/cell/beat_iommu.c
> index 93b0efd..39d361c 100644
> --- a/arch/powerpc/platforms/cell/beat_iommu.c
> +++ b/arch/powerpc/platforms/cell/beat_iommu.c
> @@ -77,7 +77,7 @@ static void __init celleb_init_direct_mapping(void)
> static void celleb_dma_dev_setup(struct device *dev)
> {
> dev->archdata.dma_ops = get_pci_dma_ops();
> - dev->archdata.dma_data = (void *)celleb_dma_direct_offset;
> + set_dma_offset(dev, celleb_dma_direct_offset);
> }
>
> static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index 416db17..ca5bfdf 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -657,15 +657,13 @@ static void cell_dma_dev_setup_fixed(struct device *dev);
>
> static void cell_dma_dev_setup(struct device *dev)
> {
> - struct dev_archdata *archdata = &dev->archdata;
> -
> /* Order is important here, these are not mutually exclusive */
> if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
> cell_dma_dev_setup_fixed(dev);
> else if (get_pci_dma_ops() == &dma_iommu_ops)
> - archdata->dma_data = cell_get_iommu_table(dev);
> + set_iommu_table_base(dev, cell_get_iommu_table(dev));
> else if (get_pci_dma_ops() == &dma_direct_ops)
> - archdata->dma_data = (void *)cell_dma_direct_offset;
> + set_dma_offset(dev, cell_dma_direct_offset);
> else
> BUG();
> }
> @@ -973,11 +971,10 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
>
> static void cell_dma_dev_setup_fixed(struct device *dev)
> {
> - struct dev_archdata *archdata = &dev->archdata;
> u64 addr;
>
> addr = cell_iommu_get_fixed_address(dev) + dma_iommu_fixed_base;
> - archdata->dma_data = (void *)addr;
> + set_dma_offset(dev, addr);
>
> dev_dbg(dev, "iommu: fixed addr = %llx\n", addr);
> }
> diff --git a/arch/powerpc/platforms/iseries/iommu.c b/arch/powerpc/platforms/iseries/iommu.c
> index 6c1e101..9d53cb4 100644
> --- a/arch/powerpc/platforms/iseries/iommu.c
> +++ b/arch/powerpc/platforms/iseries/iommu.c
> @@ -193,7 +193,7 @@ static void pci_dma_dev_setup_iseries(struct pci_dev *pdev)
> pdn->iommu_table = iommu_init_table(tbl, -1);
> else
> kfree(tbl);
> - pdev->dev.archdata.dma_data = pdn->iommu_table;
> + set_iommu_table_base(&pdev->dev, pdn->iommu_table);
> }
> #else
> #define pci_dma_dev_setup_iseries NULL
> diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
> index a0ff03a..7b1d608 100644
> --- a/arch/powerpc/platforms/pasemi/iommu.c
> +++ b/arch/powerpc/platforms/pasemi/iommu.c
> @@ -189,7 +189,7 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
> }
> #endif
>
> - dev->dev.archdata.dma_data = &iommu_table_iobmap;
> + set_iommu_table_base(&dev->dev, &iommu_table_iobmap);
> }
>
> static void pci_dma_bus_setup_null(struct pci_bus *b) { }
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 661c8e0..1a0000a 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -482,7 +482,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
> phb->node);
> iommu_table_setparms(phb, dn, tbl);
> PCI_DN(dn)->iommu_table = iommu_init_table(tbl, phb->node);
> - dev->dev.archdata.dma_data = PCI_DN(dn)->iommu_table;
> + set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> return;
> }
>
> @@ -494,7 +494,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
> dn = dn->parent;
>
> if (dn && PCI_DN(dn))
> - dev->dev.archdata.dma_data = PCI_DN(dn)->iommu_table;
> + set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> else
> printk(KERN_WARNING "iommu: Device %s has no iommu table\n",
> pci_name(dev));
> @@ -538,7 +538,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> */
> if (dma_window == NULL || pdn->parent == NULL) {
> pr_debug(" no dma window for device, linking to parent\n");
> - dev->dev.archdata.dma_data = PCI_DN(pdn)->iommu_table;
> + set_iommu_table_base(&dev->dev, PCI_DN(pdn)->iommu_table);
> return;
> }
>
> @@ -554,7 +554,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> pr_debug(" found DMA window, table: %p\n", pci->iommu_table);
> }
>
> - dev->dev.archdata.dma_data = pci->iommu_table;
> + set_iommu_table_base(&dev->dev, pci->iommu_table);
> }
> #else /* CONFIG_PCI */
> #define pci_dma_bus_setup_pSeries NULL
> diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
> index 89639ec..ae3c4db 100644
> --- a/arch/powerpc/sysdev/dart_iommu.c
> +++ b/arch/powerpc/sysdev/dart_iommu.c
> @@ -297,7 +297,7 @@ static void pci_dma_dev_setup_dart(struct pci_dev *dev)
> /* We only have one iommu table on the mac for now, which makes
> * things simple. Setup all PCI devices to point to this table
> */
> - dev->dev.archdata.dma_data = &iommu_table_dart;
> + set_iommu_table_base(&dev->dev, &iommu_table_dart);
> }
>
> static void pci_dma_bus_setup_dart(struct pci_bus *bus)
^ permalink raw reply
* 2.6.31-git10 : perf counters build failure on powerpc
From: Sachin Sant @ 2009-09-21 5:21 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Ingo Molnar, Paul Mackerras
Latest 31 git(2.6.31-git10 : ebc79c4f8da0f92efa968e0328f32334a2ce80cf)
fails to build on powerpc with following error
arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
cc1: warnings being treated as errors
arch/powerpc/kernel/perf_counter.c:1165: error: initialization makes integer from pointer without a cast
arch/powerpc/kernel/perf_counter.c:1173: error: too few arguments to function 'perf_counter_overflow'
make[1]: *** [arch/powerpc/kernel/perf_counter.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Paul Mackerras @ 2009-09-21 6:44 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra; +Cc: Markus Metzger, linux-kernel, linuxppc-dev
Commit 5622f295 ("x86, perf_counter, bts: Optimize BTS overflow
handling") removed the regs field from struct perf_sample_data and
added a regs parameter to perf_counter_overflow(). This breaks the
build on powerpc as reported by Sachin Sant:
arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
cc1: warnings being treated as errors
arch/powerpc/kernel/perf_counter.c:1165: error: initialization makes integer from pointer without a cast
arch/powerpc/kernel/perf_counter.c:1173: error: too few arguments to function 'perf_counter_overflow'
make[1]: *** [arch/powerpc/kernel/perf_counter.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
This adjusts arch/powerpc/kernel/perf_counter.c to correspond with the
new struct perf_sample_data and perf_counter_overflow().
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
I missed this problem when the "x86, perf_counter, bts: Optimize BTS
overflow handling" patch was posted because the headline made it seem
entirely x86-specific, and the changes to struct perf_sample_data and
perf_counter_overflow() were not mentioned in the changelog.
Markus, please take care in future to mention it in the changelog if
your patches touch definitions used by other architectures. If you
could go so far as to use grep a bit more and fix up other
architectures' callsites for the things you're changing, that would be
very much appreciated. Thanks.
diff --git a/arch/powerpc/kernel/perf_counter.c b/arch/powerpc/kernel/perf_counter.c
index 7ceefaf..5ccf9bc 100644
--- a/arch/powerpc/kernel/perf_counter.c
+++ b/arch/powerpc/kernel/perf_counter.c
@@ -1162,7 +1162,6 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
*/
if (record) {
struct perf_sample_data data = {
- .regs = regs,
.addr = 0,
.period = counter->hw.last_period,
};
@@ -1170,7 +1169,7 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
if (counter->attr.sample_type & PERF_SAMPLE_ADDR)
perf_get_data_addr(regs, &data.addr);
- if (perf_counter_overflow(counter, nmi, &data)) {
+ if (perf_counter_overflow(counter, nmi, &data, regs)) {
/*
* Interrupts are coming too fast - throttle them
* by setting the counter to 0, so it will be
^ permalink raw reply related
* RE: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Metzger, Markus T @ 2009-09-21 7:12 UTC (permalink / raw)
To: Paul Mackerras, Ingo Molnar, Peter Zijlstra, davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <19127.8400.376239.586120@drongo.ozlabs.ibm.com>
>-----Original Message-----
>From: Paul Mackerras [mailto:paulus@samba.org]
>Sent: Monday, September 21, 2009 8:45 AM
>Markus, please take care in future to mention it in the changelog if
>your patches touch definitions used by other architectures. If you
>could go so far as to use grep a bit more and fix up other
>architectures' callsites for the things you're changing, that would be
>very much appreciated. Thanks.
I'm sorry I missed that.
There's one more place in arch/sparc/.
The below patch should fix it, but I have no means to test it.
Index: b/arch/sparc/kernel/perf_counter.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- a/arch/sparc/kernel/perf_counter.c
+++ b/arch/sparc/kernel/perf_counter.c
@@ -493,7 +493,6 @@ static int __kprobes perf_counter_nmi_ha
=20
regs =3D args->regs;
=20
- data.regs =3D regs;
data.addr =3D 0;
=20
cpuc =3D &__get_cpu_var(cpu_hw_counters);
@@ -513,7 +512,7 @@ static int __kprobes perf_counter_nmi_ha
if (!sparc_perf_counter_set_period(counter, hwc, idx))
continue;
=20
- if (perf_counter_overflow(counter, 1, &data))
+ if (perf_counter_overflow(counter, 1, &data, regs))
sparc_pmu_disable_counter(hwc, idx);
}
thanks and regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Ingo Molnar @ 2009-09-21 7:30 UTC (permalink / raw)
To: Metzger, Markus T, David S. Miller
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77EC69BA5E0@irsmsx504.ger.corp.intel.com>
* Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> >-----Original Message-----
> >From: Paul Mackerras [mailto:paulus@samba.org]
> >Sent: Monday, September 21, 2009 8:45 AM
>
>
> >Markus, please take care in future to mention it in the changelog if
> >your patches touch definitions used by other architectures. If you
> >could go so far as to use grep a bit more and fix up other
> >architectures' callsites for the things you're changing, that would be
> >very much appreciated. Thanks.
>
> I'm sorry I missed that.
>
> There's one more place in arch/sparc/.
> The below patch should fix it, but I have no means to test it.
You also missed a third thing:
+static inline int
+perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
+ unsigned int size, int nmi, int sample) { }
an 'int' function returning void ...
Plus all the !PERF_COUNTERS branch of empty inlines is pointless - these
facilities are used by perfcounters code only. I fixed that too.
>
> Index: b/arch/sparc/kernel/perf_counter.c
> ===================================================================
> --- a/arch/sparc/kernel/perf_counter.c
> +++ b/arch/sparc/kernel/perf_counter.c
> @@ -493,7 +493,6 @@ static int __kprobes perf_counter_nmi_ha
>
> regs = args->regs;
>
> - data.regs = regs;
> data.addr = 0;
>
> cpuc = &__get_cpu_var(cpu_hw_counters);
> @@ -513,7 +512,7 @@ static int __kprobes perf_counter_nmi_ha
> if (!sparc_perf_counter_set_period(counter, hwc, idx))
> continue;
>
> - if (perf_counter_overflow(counter, 1, &data))
> + if (perf_counter_overflow(counter, 1, &data, regs))
> sparc_pmu_disable_counter(hwc, idx);
> }
Looks correct to me and i've also done a Sparc cross build with the fix
in place and it builds fine besides the unrelated build error pasted
below. I've added it to the other fix and if David acks it will send it
to Linus later today.
Thanks,
Ingo
/home/mingo/tip/drivers/video/console/vgacon.c: In function 'vgacon_startup':
/home/mingo/tip/drivers/video/console/vgacon.c:516: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:517: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:518: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:519: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:520: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:520: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:521: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:522: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:525: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:526: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:527: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:527: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:528: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:529: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:532: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:533: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c: In function 'vgacon_do_font_op':
/home/mingo/tip/drivers/video/console/vgacon.c:1126: error: implicit declaration of function 'vga_writeb'
/home/mingo/tip/drivers/video/console/vgacon.c:1129: error: implicit declaration of function 'vga_readb'
make[4]: *** [drivers/video/console/vgacon.o] Error 1
make[3]: *** [drivers/video/console] Error 2
make[2]: *** [drivers/video] Error 2
make[2]: *** Waiting for unfinished jobs....
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Heiko Carstens @ 2009-09-21 7:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org, Metzger, Markus T,
linuxppc-dev@ozlabs.org, Paul Mackerras, David S. Miller
In-Reply-To: <20090921073043.GB24467@elte.hu>
On Mon, Sep 21, 2009 at 09:30:43AM +0200, Ingo Molnar wrote:
>
> * Metzger, Markus T <markus.t.metzger@intel.com> wrote:
>
> > >-----Original Message-----
> > >From: Paul Mackerras [mailto:paulus@samba.org]
> > >Sent: Monday, September 21, 2009 8:45 AM
> >
> >
> > >Markus, please take care in future to mention it in the changelog if
> > >your patches touch definitions used by other architectures. If you
> > >could go so far as to use grep a bit more and fix up other
> > >architectures' callsites for the things you're changing, that would be
> > >very much appreciated. Thanks.
> >
> > I'm sorry I missed that.
> >
> > There's one more place in arch/sparc/.
> > The below patch should fix it, but I have no means to test it.
>
> You also missed a third thing:
>
> +static inline int
> +perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
> + unsigned int size, int nmi, int sample) { }
>
> an 'int' function returning void ...
>
> Plus all the !PERF_COUNTERS branch of empty inlines is pointless - these
> facilities are used by perfcounters code only. I fixed that too.
Hi Ingo,
did you fix all of these warnings for !PERF_COUNTERS?
include/linux/perf_counter.h: In function 'perf_output_begin':
include/linux/perf_counter.h:854: warning: no return statement in function returning non-void
include/linux/perf_counter.h: At top level:
include/linux/perf_counter.h:863: warning: 'struct perf_sample_data' declared inside parameter list
include/linux/perf_counter.h:863: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/perf_counter.h:868: warning: 'struct perf_sample_data' declared inside parameter list
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Ingo Molnar @ 2009-09-21 7:45 UTC (permalink / raw)
To: Heiko Carstens
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org, Metzger, Markus T,
linuxppc-dev@ozlabs.org, Paul Mackerras, David S. Miller
In-Reply-To: <20090921073848.GA4649@osiris.boeblingen.de.ibm.com>
* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Mon, Sep 21, 2009 at 09:30:43AM +0200, Ingo Molnar wrote:
> >
> > * Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> >
> > > >-----Original Message-----
> > > >From: Paul Mackerras [mailto:paulus@samba.org]
> > > >Sent: Monday, September 21, 2009 8:45 AM
> > >
> > >
> > > >Markus, please take care in future to mention it in the changelog if
> > > >your patches touch definitions used by other architectures. If you
> > > >could go so far as to use grep a bit more and fix up other
> > > >architectures' callsites for the things you're changing, that would be
> > > >very much appreciated. Thanks.
> > >
> > > I'm sorry I missed that.
> > >
> > > There's one more place in arch/sparc/.
> > > The below patch should fix it, but I have no means to test it.
> >
> > You also missed a third thing:
> >
> > +static inline int
> > +perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
> > + unsigned int size, int nmi, int sample) { }
> >
> > an 'int' function returning void ...
> >
> > Plus all the !PERF_COUNTERS branch of empty inlines is pointless - these
> > facilities are used by perfcounters code only. I fixed that too.
>
> Hi Ingo,
>
> did you fix all of these warnings for !PERF_COUNTERS?
>
> include/linux/perf_counter.h: In function 'perf_output_begin':
> include/linux/perf_counter.h:854: warning: no return statement in function returning non-void
> include/linux/perf_counter.h: At top level:
> include/linux/perf_counter.h:863: warning: 'struct perf_sample_data' declared inside parameter list
> include/linux/perf_counter.h:863: warning: its scope is only this definition or declaration, which is probably not what you want
> include/linux/perf_counter.h:868: warning: 'struct perf_sample_data' declared inside parameter list
Yes. The full commit is below.
Ingo
---------------->
>From cd74c86bdf705f824d494a2bbda393d1d562b40a Mon Sep 17 00:00:00 2001
From: Paul Mackerras <paulus@samba.org>
Date: Mon, 21 Sep 2009 16:44:32 +1000
Subject: [PATCH] perf_counter, powerpc, sparc: Fix compilation after perf_counter_overflow() change
Commit 5622f295 ("x86, perf_counter, bts: Optimize BTS overflow
handling") removed the regs field from struct perf_sample_data and
added a regs parameter to perf_counter_overflow(). This breaks the
build on powerpc (and Sparc) as reported by Sachin Sant:
arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
This adjusts arch/powerpc/kernel/perf_counter.c to correspond with the
new struct perf_sample_data and perf_counter_overflow().
[ v2: also fix Sparc, Markus Metzger <markus.t.metzger@intel.com> ]
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: Markus Metzger <markus.t.metzger@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <19127.8400.376239.586120@drongo.ozlabs.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/kernel/perf_counter.c | 3 +--
arch/sparc/kernel/perf_counter.c | 3 +--
include/linux/perf_counter.h | 17 -----------------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/perf_counter.c b/arch/powerpc/kernel/perf_counter.c
index 7ceefaf..5ccf9bc 100644
--- a/arch/powerpc/kernel/perf_counter.c
+++ b/arch/powerpc/kernel/perf_counter.c
@@ -1162,7 +1162,6 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
*/
if (record) {
struct perf_sample_data data = {
- .regs = regs,
.addr = 0,
.period = counter->hw.last_period,
};
@@ -1170,7 +1169,7 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
if (counter->attr.sample_type & PERF_SAMPLE_ADDR)
perf_get_data_addr(regs, &data.addr);
- if (perf_counter_overflow(counter, nmi, &data)) {
+ if (perf_counter_overflow(counter, nmi, &data, regs)) {
/*
* Interrupts are coming too fast - throttle them
* by setting the counter to 0, so it will be
diff --git a/arch/sparc/kernel/perf_counter.c b/arch/sparc/kernel/perf_counter.c
index 09de403..b1265ce 100644
--- a/arch/sparc/kernel/perf_counter.c
+++ b/arch/sparc/kernel/perf_counter.c
@@ -493,7 +493,6 @@ static int __kprobes perf_counter_nmi_handler(struct notifier_block *self,
regs = args->regs;
- data.regs = regs;
data.addr = 0;
cpuc = &__get_cpu_var(cpu_hw_counters);
@@ -513,7 +512,7 @@ static int __kprobes perf_counter_nmi_handler(struct notifier_block *self,
if (!sparc_perf_counter_set_period(counter, hwc, idx))
continue;
- if (perf_counter_overflow(counter, 1, &data))
+ if (perf_counter_overflow(counter, 1, &data, regs))
sparc_pmu_disable_counter(hwc, idx);
}
diff --git a/include/linux/perf_counter.h b/include/linux/perf_counter.h
index bd34100..740caad 100644
--- a/include/linux/perf_counter.h
+++ b/include/linux/perf_counter.h
@@ -849,23 +849,6 @@ static inline void perf_counter_comm(struct task_struct *tsk) { }
static inline void perf_counter_fork(struct task_struct *tsk) { }
static inline void perf_counter_init(void) { }
-static inline int
-perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
- unsigned int size, int nmi, int sample) { }
-static inline void perf_output_end(struct perf_output_handle *handle) { }
-static inline void
-perf_output_copy(struct perf_output_handle *handle,
- const void *buf, unsigned int len) { }
-static inline void
-perf_output_sample(struct perf_output_handle *handle,
- struct perf_event_header *header,
- struct perf_sample_data *data,
- struct perf_counter *counter) { }
-static inline void
-perf_prepare_sample(struct perf_event_header *header,
- struct perf_sample_data *data,
- struct perf_counter *counter,
- struct pt_regs *regs) { }
#endif
#define perf_output_put(handle, x) \
^ permalink raw reply related
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Ingo Molnar @ 2009-09-21 7:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Peter Zijlstra, linux-kernel, Markus Metzger, linuxppc-dev
In-Reply-To: <19127.8400.376239.586120@drongo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Commit 5622f295 ("x86, perf_counter, bts: Optimize BTS overflow
> handling") removed the regs field from struct perf_sample_data and
> added a regs parameter to perf_counter_overflow(). This breaks the
> build on powerpc as reported by Sachin Sant:
>
> arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
> arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
> cc1: warnings being treated as errors
> arch/powerpc/kernel/perf_counter.c:1165: error: initialization makes integer from pointer without a cast
> arch/powerpc/kernel/perf_counter.c:1173: error: too few arguments to function 'perf_counter_overflow'
> make[1]: *** [arch/powerpc/kernel/perf_counter.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
>
> This adjusts arch/powerpc/kernel/perf_counter.c to correspond with the
> new struct perf_sample_data and perf_counter_overflow().
>
> Reported-by: Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Applied, thanks Paul.
> ---
>
> I missed this problem when the "x86, perf_counter, bts: Optimize BTS
> overflow handling" patch was posted because the headline made it seem
> entirely x86-specific, and the changes to struct perf_sample_data and
> perf_counter_overflow() were not mentioned in the changelog.
>
> Markus, please take care in future to mention it in the changelog if
> your patches touch definitions used by other architectures. If you
> could go so far as to use grep a bit more and fix up other
> architectures' callsites for the things you're changing, that would be
> very much appreciated. Thanks.
Yes, that should be done in general - still, nothing beats actual
testing.
Paul, you might also want to test the perfcounter bits of -tip on
PowerPC a bit more frequently - this patch was there for 5 days before i
sent it to Linus.
Cross-builds didnt catch it as perfcounters isnt enabled by default in
any of the powerpc defconfigs:
phoenix:~/linux/linux> grep -w CONFIG_PERF_COUNTERS arch/powerpc/configs/*
arch/powerpc/configs/adder875_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/c2k_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/ep8248e_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/ep88xc_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/linkstation_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mgcoge_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mgsuvd_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc7448_hpc2_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc8272_ads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc83xx_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc85xx_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc85xx_smp_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc866_ads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc86xx_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc885_ads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/pq2fads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/prpmc2800_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/ps3_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/storcenter_defconfig:# CONFIG_PERF_COUNTERS is not set
There's not that many PowerPC users so all extra testing help would be
much welcome. Also, enabling them in the powerpc defconfigs would be
helpful as well.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] sbc8548: fixup of PCI-e related DTS fields
From: Segher Boessenkool @ 2009-09-21 9:34 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1253494142-26821-1-git-send-email-paul.gortmaker@windriver.com>
> - 0x0 0x08000000>;
> + 0x0 0x0800000>;
You might want to write that as 0x00800000, otherwise people
will think it says 128M still :-)
Segher
^ permalink raw reply
* Re: Linux booting issue on powerpc 440x5
From: Benjamin Herrenschmidt @ 2009-09-21 9:52 UTC (permalink / raw)
To: Sumesh Kaana; +Cc: linuxppc-dev
In-Reply-To: <BLU124-W15B59AFF88DB52C03BD481B4E00@phx.gbl>
On Fri, 2009-09-18 at 09:31 +0000, Sumesh Kaana wrote:
>
>
> Hi,
>
>
> I am trying to boot linux kernel (2.6.30) on PPC440x5 processor in a
> custom built board. I am using simple ppc platform.
>
>
> I have a small bootloader which will only copy the
> simpleImage.myboard.bin to 0x400000 location of my SRAM from the
> flash.
>
>
> SRAM is only 16MB and bootloader creates one and only TLB of 16MB
>
The 440 kernel is meant to be run from memory physical address 0 in main
memory. It's not capable of relocating itself there, so I wouldn't be
surprised that this is the source of your problem.
Ben.
> I am getting "Kernel access of bad area, sig: 11 [#1]" while kernel is
> booting.
>
>
> kernel crashes in different places, for different compilation
>
>
> Bellow given are 2 dumps of kernel crash
>
>
> In DUMP1, in back trace, execution flow is shown like,
>
>
> Start_kernel() --> sort_main_extable() --> sort_extable(). and sort
> extable calls some functions whose name is not mentioned.
>
>
> Why is it not able to get the name of the function.?
>
>
> i went through the 'objdump' of the kernel, I don't know whether it
> can help me somehow, it looked like this
>
>
> --
> c018c730: 48 00 71 9d bl c01938cc <sort_main_extable>
> c018c734: 48 00 3e 3d bl c0190570 <trap_init>
> --
> c01938e8: 4b f7 10 f1 bl c01049d8 <sort_extable>
> c01938ec: 80 01 00 14 lwz r0,20(r1)
> --
> c01049fc: 48 00 8d 99 bl c010d794 <sort>
> c0104a00: 80 01 00 14 lwz r0,20(r1)
> --
> c016b99c: 42 6f 6f 74 bc+ 18,4*cr3+so,c0172910
> <kallsyms_token_index+0x7400>
> --
>
>
> Could this be problem with "kallsyms"..? Because sort_extable() calls
> sort() which is an exported function defined in linux-2.6.30\lib
> \sort.c
>
>
> when i checked 'objdump' of the kernel, i could see the usage of a
> preserved opcode of ppc440x5 (code: eciwx).
>
>
> I tried compiling the kernel with "kallsyms" disabled, that also did
> not work.
>
>
> In DUMP2, backtrace is not able to identify the name of 'caller' of
> unflatten_device_tree(). The caller is mentioned as "[00000000]
> (null)"
>
>
> Could this be a stack problem, like stack pointer getting corrupted.?
>
>
> At last, could this be a hardware problem(expecting to be memory
> problem)..?
>
>
> Can you tell me if i am missing something.?
>
>
> thanks,
> Shyju. N
>
>
>
>
> -------------------------DUMP 1------------------------------------
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> bootmemarch: exit
> <7>Top of RAM: 0x1000000, Total RAM: 0x1000000
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00001000
> Normal 0x00001000 -> 0x00001000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00001000
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists in Zone order, mobility grouping off. Total pages:
> 4064
> Kernel command line: console=ttyS0 root=/dev/ram
> Unable to handle kernel paging request for data at address 0x00021000
> Faulting instruction address: 0xc010a7c4
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT PowerPC 44x Platform
> Modules linked in:
> NIP: c010a7c4 LR: c010dc50 CTR: 00000000
> REGS: c01bfeb0 TRAP: 0300 Not tainted (2.6.30)
> MSR: 00021000 <ME,CE> CR: 24000044 XER: 00000000
> DEAR: 00021000, ESR: 00000000
> TASK = c01a94b8[0] 'swapper' THREAD: c01be000
> GPR00: 00001180 c01bff60 c01a94b8 00021000 00000025 00000008 c0104968
> 00000000
> GPR08: 2f72616d c0110000 c0155938 c01a0000 22000024 00000000 fffff104
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 fffffff8 000008b8 c010d758
> c0104968
> GPR24: 00001198 00001190 c018a001 c01c5498 000008c0 00001188 00021000
> c01c42f0
> NIP [c010a7c4] strchr+0x0/0x3c
> LR [c010dc50] match_token+0x138/0x228
> Call Trace:
> [c01bff60] [c016b99c] 0xc016b99c (unreliable)
> [c01bffa0] [c0104a00] sort_extable+0x28/0x38
> [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30
> [c01bffc0] [c018c734] start_kernel+0x140/0x288
> [c01bfff0] [c0000200] skpinv+0x190/0x1cc
> Instruction dump:
> 7ca903a6 88040000 38a5ffff 38840001 2f800000 98090000 39290001
> 419e0010
> 4200ffe4 98a90000 4e800020 4e800020 <88030000> 5484063e 7f802000
> 4d9e0020
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> Call Trace:
> [c01bfd90] [c0005d5c] show_stack+0x4c/0x16c (unreliable)
> [c01bfdd0] [c002f17c] panic+0xa0/0x168
> [c01bfe20] [c0032eb8] do_exit+0x61c/0x638
> [c01bfe60] [c000b60c] kernel_bad_stack+0x0/0x4c
> [c01bfe90] [c000f310] bad_page_fault+0x90/0xd8
> [c01bfea0] [c000e184] handle_page_fault+0x7c/0x80
> [c01bff60] [c016b99c] 0xc016b99c
> [c01bffa0] [c0104a00] sort_extable+0x28/0x38
> [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30
> [c01bffc0] [c018c734] start_kernel+0x140/0x288
> [c01bfff0] [c0000200] skpinv+0x190/0x1cc
> Rebooting in 180 seconds..
> -------------------------------------------------------------------
>
>
> -------------------------DUMP 2------------------------------------
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> <1>Unable to handle kernel paging request for data at address
> 0x40ee8053
> Faulting instruction address: 0xc018ff44
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT PowerPC 44x Platform
> Modules linked in:
> NIP: c018ff44 LR: c018ff20 CTR: 00000000
> REGS: c01bfe10 TRAP: 0300 Not tainted (2.6.30)
> MSR: 00021000 <ME,CE> CR: 44088024 XER: 00000000
> DEAR: 40ee8053, ESR: 00800000
> TASK = c01a94b8[0] 'swapper' THREAD: c01be000
> GPR00: c0ffea58 c01bfec0 c01a94b8 c0ffea6e c04eb3aa 00000003 c0ffea74
> 00000000
> GPR08: 00000000 40ee802f c04eb3a0 c01bfec8 24082022 00000000 fffff104
> 00000000
> GPR16: 00000000 c016cfe8 c016cfd8 c0170cbc c01bfec8 c0ffea24 c04eb3a4
> c04eb3a0
> GPR24: 00000008 c01bff8c c04eb33c c0ffea2c 00000007 c01bff88 c0ffe984
> c0ffea6d
> NIP [c018ff44] unflatten_dt_node+0x158/0x520
> LR [c018ff20] unflatten_dt_node+0x134/0x520
> Call Trace:
> [c01bff20] [c019023c] unflatten_dt_node+0x450/0x520
> [c01bff80] [c01903b4] unflatten_device_tree+0xa8/0x13c
> [c01bffb0] [00000000] (null)
> Instruction dump:
> 7f85e378 7ec4b378 4be81b55 81390000 381b002c 93690000 90190000
> 4192001c
> 813e0028 93db001c 2f890000 419e03b4 <93690024> 937e0028 387b0034
> 3abb0014
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> Call Trace:
> [c01bfcf0] [c0005d5c] show_stack+0x4c/0x16c (unreliable)
> [c01bfd30] [c002f17c] panic+0xa0/0x168
> [c01bfd80] [c0032eb8] do_exit+0x61c/0x638
> [c01bfdc0] [c000b60c] kernel_bad_stack+0x0/0x4c
> [c01bfdf0] [c000f310] bad_page_fault+0x90/0xd8
> [c01bfe00] [c000e184] handle_page_fault+0x7c/0x80
> [c01bfec0] [00000000] (null)
> [c01bff20] [c019023c] unflatten_dt_node+0x450/0x520
> [c01bff80] [c01903b4] unflatten_device_tree+0xa8/0x13c
> [c01bffb0] [00000000] (null)
> -------------------------------------------------------------------
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> Let us find your next place for you! Need a place to rent, buy or
> share?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] USB: Add support for Xilinx USB host controller
From: Benjamin Herrenschmidt @ 2009-09-21 10:23 UTC (permalink / raw)
To: Julie Zhu; +Cc: linux-usb, gregkh, juliez, linuxppc-dev, john.linn
In-Reply-To: <20090915221050.0DA0F2C005E@mail34-va3.bigfish.com>
On Tue, 2009-09-15 at 16:10 -0600, Julie Zhu wrote:
> Add bus glue driver for Xilinx USB host controller. The controller can be
> configured as HS only or HS/FS hybrid. The driver uses the device tree file
> to configure the driver according to the setting in the hardware system.
>
> This driver has been tested with usbtest using the NET2280 PCI card.
>
> Signed-off-by: Julie Zhu <julie.zhu@xilinx.com>
Hi !
First, this is a very clean piece of code, thanks.
Just a few minor nits:
> static int ehci_xilinx_port_handed_over(struct usb_hcd *hcd, int portnum)
> +{
> + dev_warn(hcd->self.controller, "port %d cannot be enabled\n", portnum);
> + if (hcd->has_tt) {
> + dev_warn(hcd->self.controller,
> + "Maybe you have connected an LS device?\n");
> +
> + dev_warn(hcd->self.controller,
> + "We do not support LS devices\n");
> + } else {
> + dev_warn(hcd->self.controller,
> + "Maybe your device is not an HS device?\n");
> + dev_warn(hcd->self.controller,
> + "The USB host controller does not support FS or "
> + "LS devices\n");
> + dev_warn(hcd->self.controller,
> + "You can reconfigure the host controller to have "
> + "FS support\n");
> + }
> +
> + return 0;
> +}
I'm not sure the final users would know what "FS", "LS" or "HS" mean
here, it might be worth being a -tad- more verbose :-)
.../...
> +
> +/**
> + * ehci_hcd_xilinx_of_remove - shutdown hcd and release resources
> + * @op: pointer to of_device structure that is to be removed
> + *
> + * Remove the hcd structure, and release resources that has been requested
> + * during probe.
> + */
> +static int ehci_hcd_xilinx_of_remove(struct of_device *op)
> +{
> + struct usb_hcd *hcd = dev_get_drvdata(&op->dev);
> + dev_set_drvdata(&op->dev, NULL);
> +
> + dev_dbg(&op->dev, "stopping XILINX-OF USB Controller\n");
> +
> + usb_remove_hcd(hcd);
> +
> + iounmap(hcd->regs);
> + irq_dispose_mapping(hcd->irq);
You don't need to dispose of the irq mapping, and in fact, it could be
harmful if the interrupt is shared, as we don't refcount the mapping
users. Just remove the line above. The mapping doesn't really use
resources (well, it depends on your PIC but even then, it's minor) so
it's better, once a HW IRQ number has been associated to a linux IRQ
number, to keep that association for the lifetime of the kernel.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Paul Mackerras @ 2009-09-21 11:19 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Peter Zijlstra, linux-kernel, Markus Metzger, linuxppc-dev
In-Reply-To: <20090921071127.GA24467@elte.hu>
Ingo Molnar writes:
> Paul, you might also want to test the perfcounter bits of -tip on
> PowerPC a bit more frequently - this patch was there for 5 days before i
> sent it to Linus.
Yes, I'll try to do that in future.
I hope I didn't come across as blaming anyone for anything - that
wasn't my intention at all.
> Cross-builds didnt catch it as perfcounters isnt enabled by default in
> any of the powerpc defconfigs:
I'll get that fixed too.
Paul.
^ permalink raw reply
* RE: PPC_4xx synopsy USB driver
From: Cote, Sylvain @ 2009-09-21 13:44 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <200909210713.29238.sr@denx.de>
Hi Stefan,
On Friday 18 September 2009 17:50:24 Cote, Sylvain wrote:
> USB gadget support --> y
> Maximum VBUS power usage =3D 500
> Synopsys DWC OTG controller
> Synopsys DWC OTG internal DMA mode --> y
> USB gadget --> M
> gadget zero --> M
> Ethernet Gadget --> M
> RNDIS support --> y
>=20
> Any help will be appreciated
> Looks good so far. I suspect that the only thing missing for your 405EX=20
> custom=20
> board is the following line in the arch/powerpc/sysdev/Makefile:
> obj-$(CONFIG_KILAUEA) +=3D amcc-usbotg.o
I have created a new platform (platform using 405ex). I have missed this o=
ne for my new platform. Do you know if there is a compilation switch that =
could be more generic (like CONFIG_40x) for the usbotg?
> to enable the device-tree to platform-device driver wrapper for the USB-
> OTG=20
> resources.
Thanks you,
Your help has been appreciated.
Sylvain
This electronic message may contain proprietary and confidential informat=
ion of Verint Systems Inc., its affiliates and/or subsidiaries.
The information is intended to be for the use of the individual(s) or
entity(ies) named above. If you are not the intended recipient (or autho=
rized to receive this e-mail for the intended recipient), you may not use=
, copy, disclose or distribute to anyone this message or any information =
contained in this message. If you have received this electronic message =
in error, please notify us by replying to this e-mail.
=0D
^ permalink raw reply
* Re: [PATCH] USB: Add support for Xilinx USB host controller
From: Grant Likely @ 2009-09-21 14:14 UTC (permalink / raw)
To: Julie Zhu; +Cc: linux-usb, gregkh, juliez, linuxppc-dev, john.linn
In-Reply-To: <20090915221050.0DA0F2C005E@mail34-va3.bigfish.com>
On Tue, Sep 15, 2009 at 3:10 PM, Julie Zhu <julie.zhu@xilinx.com> wrote:
> Add bus glue driver for Xilinx USB host controller. The controller can be
> configured as HS only or HS/FS hybrid. The driver uses the device tree fi=
le
> to configure the driver according to the setting in the hardware system.
>
> This driver has been tested with usbtest using the NET2280 PCI card.
>
> Signed-off-by: Julie Zhu <julie.zhu@xilinx.com>
As Ben said, this is nice tight code. Two comments below.
> +/**
> + * ehci_xilinx_port_handed_over - hand the port out if failed to enable =
it
> + * @hcd: =A0 =A0 =A0 Pointer to the usb_hcd device to which the host con=
troller bound
> + * @portnum:Port number to which the device is attached.
> + *
> + * This function is used as a place to tell the user that the Xilinx USB=
host
> + * controller does support LS devices. And in an HS only configuration, =
it
> + * does not support FS devices neither. It is hoped that this can help a
s/neither/either
[...]
> +static struct of_device_id ehci_hcd_xilinx_of_match[] =3D {
> + =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .compatible =3D "usb-ehci",
> + =A0 =A0 =A0 },
This looks wrong. Since this driver only works with Xilinx USB controllers=
,
it should be binding against "xlnx,xps-usb-host-1.00.a", and the meaning of
that binding needs to be documented in Documentation/powerpc/dts-bindings.
Having this driver bind against the generic "usb-ehci" will cause conflicts
with the ehci-ppc-of driver.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PPC_4xx synopsy USB driver
From: Stefan Roese @ 2009-09-21 14:24 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01FA07D05186@ATLMBX.verint.corp.verintsystems.com>
On Monday 21 September 2009 15:44:30 Cote, Sylvain wrote:
> > Looks good so far. I suspect that the only thing missing for your 405EX
> > custom
> > board is the following line in the arch/powerpc/sysdev/Makefile:
> >
> > obj-$(CONFIG_KILAUEA) += amcc-usbotg.o
>
> I have created a new platform (platform using 405ex). I have missed this
> one for my new platform. Do you know if there is a compilation switch
> that could be more generic (like CONFIG_40x) for the usbotg?
Yes, it would probably make sense to just use
obj-$(CONFIG_USB_DWC_OTG) += amcc-usbotg.o
here. I'll change this soon.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH] sbc8548: fixup of PCI-e related DTS fields
From: Paul Gortmaker @ 2009-09-21 14:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8549256E-05F8-4990-866F-EB73C048E462@kernel.crashing.org>
The PCI-e addressing was originally patterned of the MPC8548CDS
which has PCI1, PCI2, and PCI-e. Since this board only has
PCI1 and PCI-e, it makes more sense to be similar to the MPC8568MDS
board. This does that by cutting the PCI/PCI-e I/O sizes from
16MB to 8MB and pulling the PCI-e I/O range back to 0xe280_0000
(the hole where PCI2 I/O would have been).
This also fixes a typo where an extra zero made an 8MB range a 128MB
range, removes the hole left by PCI2 from the aliases, and sets the
clocks to match the oscillators that are actually on the board.
With accompanying u-boot updates, PCI-e has been validated with
both a sky2 card (1148:9e00) and an e1000 card (8086:108b).
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
v2: cosmetic; fix leading zeros on 0x00800000 for better readability
arch/powerpc/boot/dts/sbc8548.dts | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index 9eefe00..94a3322 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -26,8 +26,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
- /* pci1 doesn't have a corresponding physical connector */
- pci2 = &pci2;
+ pci1 = &pci1;
};
cpus {
@@ -381,7 +380,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00800000>;
- clock-frequency = <66666666>;
+ clock-frequency = <66000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -390,7 +389,7 @@
device_type = "pci";
};
- pci2: pcie@e000a000 {
+ pci1: pcie@e000a000 {
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
@@ -403,9 +402,9 @@
interrupt-parent = <&mpic>;
interrupts = <0x1a 0x2>;
bus-range = <0x0 0xff>;
- ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
- 0x01000000 0x0 0x00000000 0xe3000000 0x0 0x08000000>;
- clock-frequency = <33333333>;
+ ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2800000 0x0 0x08000000>;
+ clock-frequency = <33000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -419,11 +418,11 @@
device_type = "pci";
ranges = <0x02000000 0x0 0xa0000000
0x02000000 0x0 0xa0000000
- 0x0 0x20000000
+ 0x0 0x10000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
- 0x0 0x08000000>;
+ 0x0 0x00800000>;
};
};
};
--
1.6.4.1
^ permalink raw reply related
* Re: [PATCH] USB: Add support for Xilinx USB host controller
From: Grant Likely @ 2009-09-21 14:46 UTC (permalink / raw)
To: Julie Zhu; +Cc: linux-usb, gregkh, linuxppc-dev, John Linn
In-Reply-To: <20090921144131.1C1A31078051@mail56-sin.bigfish.com>
On Mon, Sep 21, 2009 at 7:41 AM, Julie Zhu <julie.zhu@xilinx.com> wrote:
> I have changed the compatible to "xlnx,xps-usb-host-1.00.a", thanks for catching this.
>
> Where should I put the binding for Xilinx USB host controller? usb-ehci.txt or xilinx.txt?
Probably xilinx.txt.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [LTP] mmapstress03 weirdness? (fwd)
From: Geert Uytterhoeven @ 2009-09-21 13:40 UTC (permalink / raw)
To: Linux/PPC Development, Linux Kernel Development; +Cc: Linux Test Project
---------- Forwarded message ----------
Date: Wed, 16 Sep 2009 18:37:12 +0200 (CEST)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To: Linux Test Project <Ltp-list@lists.sourceforge.net>
Subject: [LTP] mmapstress03 weirdness?
On ppc64, with 32-bit userland, I get:
| Running tests.......
| <<<test_start>>>
| tag=mmapstress03 stime=1253117251
| cmdline="mmapstress03"
| contacts=""
| analysis=exit
| <<<test_output>>>
| incrementing stop
| : errno = 0: really large mmap didn't fail
| mmapstress03 1 TFAIL : Test failed
^^^^^^^^^^^^^^^^^^^^^
| <<<execution_status>>>
| initiation_status="ok"
| duration=0 termination_type=exited termination_id=0 corefile=no
| cutime=0 cstime=0
| <<<test_end>>>
| INFO: ltp-pan reported all tests PASS
^^^^
The core part of this test is:
/* Ask for a ridiculously large mmap region at a high address */
if (mmap((caddr_t)(1UL << (POINTER_SIZE - 1)) - pagesize,
(size_t)((1UL << (POINTER_SIZE - 1)) - pagesize),
PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED|MAP_SHARED, 0, 0)
!= (caddr_t)-1)
{
ERROR("really large mmap didn't fail");
anyfail();
}
if (errno != ENOMEM && errno != EINVAL) {
ERROR("really large mmap didn't set errno = ENOMEM nor EINVAL");
anyfail();
}
With 32-bit userland, this boils down to:
| mmap addr 0x7fff0000 size 0x7fff0000
| mmap returned 0x7fff0000
i.e. mmap() succeeds, but (1) the test expects it to fail, so the test returns
TFAIL, but (2) ltp-pan still reports that the tests passed?
In addition, sometimes mmapstress03 fails due to SEGV. I created a small test
program that just does the above mmap(), and depending on the distro and what
else I print later it crashes with a SEGV, too. Probably this happens because
the mmap() did succeed, and corrupted some existing mappings, cfr. the notes
for MAP_FIXED:
MAP_FIXED
Don’t interpret addr as a hint: place the mapping at exactly
that address. addr must be a multiple of the page size. If the
memory region specified by addr and len overlaps pages of any
existing mapping(s), then the overlapped part of the existing
mapping(s) will be discarded. If the specified address cannot
be used, mmap() will fail. Because requiring a fixed address
for a mapping is less portable, the use of this option is dis‐
couraged.
JFYI, with 64-bit userland, this boils down to:
| mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
| mmap returned 0xffffffffffffffff
i.e. mmap() fails as expected, and the test succeeds.
Does all of this sound OK?
Thanks for your comments!
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* RE: [PATCH] USB: Add support for Xilinx USB host controller
From: Julie Zhu @ 2009-09-21 14:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-usb, gregkh, linuxppc-dev, John Linn
In-Reply-To: <fa686aa40909210714j428aa524qacc7a83f40db411b@mail.gmail.com>
Thanks, Grant and Ben,
> > Add bus glue driver for Xilinx USB host controller. The controller can
> be
> > configured as HS only or HS/FS hybrid. The driver uses the device tree
> file
> > to configure the driver according to the setting in the hardware system=
.
> >
> > This driver has been tested with usbtest using the NET2280 PCI card.
> >
> > Signed-off-by: Julie Zhu <julie.zhu@xilinx.com>
> =
> As Ben said, this is nice tight code. Two comments below.
> =
> > +/**
> > + * ehci_xilinx_port_handed_over - hand the port out if failed to enabl=
e
> it
> > + * @hcd: =A0 =A0 =A0 Pointer to the usb_hcd device to which the host
> controller bound
> > + * @portnum:Port number to which the device is attached.
> > + *
> > + * This function is used as a place to tell the user that the Xilinx
> USB host
> > + * controller does support LS devices. And in an HS only configuration=
,
> it
> > + * does not support FS devices neither. It is hoped that this can help=
> a
> =
> s/neither/either
> =
> [...]
> > +static struct of_device_id ehci_hcd_xilinx_of_match[] =3D {
> > + =A0 =A0 =A0 {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .compatible =3D "usb-ehci",
> > + =A0 =A0 =A0 },
> =
> This looks wrong. Since this driver only works with Xilinx USB
> controllers,
> it should be binding against "xlnx,xps-usb-host-1.00.a", and the meaning
> of
> that binding needs to be documented in Documentation/powerpc/dts-bindings=
.
> =
I have changed the compatible to "xlnx,xps-usb-host-1.00.a", thanks for cat=
ching this.
Where should I put the binding for Xilinx USB host controller? usb-ehci.txt=
or xilinx.txt?
Thanks,
Julie.
> Having this driver bind against the generic "usb-ehci" will cause
> conflicts
> with the ehci-ppc-of driver.
> =
> Cheers,
> g.
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* High load average but low cpu (xenomai can be the explanation?)
From: dibacco @ 2009-09-21 15:13 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have an MPC880 @133MHz. If I look into the load (with uptime) I get
values around 3.0 but my CPU is always under 5 percent (top). How could I
explain this? I'm using linux 2.6.19 with xenomai but no xenomai application is
running at all. I have a cramfs on a nor flash. What could be the problem? If I
kill the process I developed the average load goes down.
Thank you,
Adi
^ 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