* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2009-04-22 5:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug fixes for powerpc, plus some documentation and
defconfig updates and a MAINTAINERS update.
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 89 -
Documentation/powerpc/dts-bindings/mtd-physmap.txt | 80 +
MAINTAINERS | 5=20
arch/powerpc/boot/dts/lite5200b.dts | 39=20
arch/powerpc/configs/52xx/cm5200_defconfig | 69 +
arch/powerpc/configs/52xx/lite5200b_defconfig | 74 +
arch/powerpc/configs/52xx/motionpro_defconfig | 77 +
arch/powerpc/configs/52xx/pcm030_defconfig | 69 +
arch/powerpc/configs/52xx/tqm5200_defconfig | 76 +
arch/powerpc/configs/85xx/mpc8536_ds_defconfig | 1802 ------------=
--------
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 1802 ------------=
--------
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 1309 ------------=
---
arch/powerpc/configs/mpc5200_defconfig | 188 ++
arch/powerpc/configs/mpc85xx_defconfig | 252 +--
arch/powerpc/configs/mpc85xx_smp_defconfig | 343 ++--
arch/powerpc/include/asm/elf.h | 3=20
arch/powerpc/kernel/prom_parse.c | 11=20
arch/powerpc/mm/hash_utils_64.c | 2=20
arch/powerpc/platforms/fsl_uli1575.c | 5=20
arch/powerpc/platforms/pasemi/setup.c | 4=20
arch/powerpc/platforms/ps3/os-area.c | 2=20
arch/powerpc/sysdev/fsl_rio.c | 28=20
drivers/macintosh/Kconfig | 2=20
drivers/macintosh/mediabay.c | 2=20
include/linux/fsl_devices.h | 4=20
25 files changed, 896 insertions(+), 5441 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt
delete mode 100644 arch/powerpc/configs/85xx/mpc8536_ds_defconfig
delete mode 100644 arch/powerpc/configs/85xx/mpc8544_ds_defconfig
delete mode 100644 arch/powerpc/configs/85xx/mpc8568mds_defconfig
rename arch/powerpc/configs/{85xx/mpc8572_ds_defconfig =3D> mpc85xx_sm=
p_defconfig} (91%)
Alexander Beregalov (1):
powerpc: Make macintosh/mediabay driver depend on CONFIG_BLOCK
Andreas Schwab (1):
powerpc/32: Don't clobber personality flags on exec
Anton Vorontsov (2):
powerpc/5200: Bring the legacy fsl_spi_platform_data hooks back
fsl_rio: Pass the proper device to dma mapping routines
Bartlomiej Zolnierkiewicz (1):
powerpc: Fix modular build of ide-pmac when mediabay is built in
Geoff Levand (3):
powerpc/ps3: Fix CONFIG_PS3_FLASH=3Dn build warning
maintainers: Fix PS3 patterns
powerpc/pasemi: Fix build error on UP
Grant Likely (2):
powerpc/5200: Add FLASH nodes to lite5200 device tree
powerpc/5200: defconfig updates
Ilpo J=E4rvinen (1):
powerpc: Fix of_node_put() exit path in of_irq_map_one()
Kumar Gala (4):
powerpc/85xx: Updated generic mpc85xx_defconfig
powerpc/85xx: Enabled a bunch of FSL specific drivers/options
powerpc/85xx: Added SMP defconfig
powerpc/85xx: Remove defconfigs that mpc85xx_{smp_}defconfig cove=
r
Michael Ellerman (1):
powerpc: Fix crash on CPU hotplug
Stefan Roese (2):
powerpc/of-device-tree: Factor MTD physmap bindings out of bootin=
g-without-of
powerpc/device-tree: Document MTD nodes with multiple "reg" tuple=
s
Timur Tabi (1):
powerpc: don't disable SATA interrupts on Freescale MPC8610 HPCD
^ permalink raw reply
* Re: [PATCH v6] spi: Add PPC4xx SPI driver
From: David Brownell @ 2009-04-22 5:36 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <1231411250-25380-1-git-send-email-sr@denx.de>
On Thursday 08 January 2009, Stefan Roese wrote:
> This adds a SPI driver for the SPI controller found in the IBM/AMCC
> 4xx PowerPC's.
Note that given some patches now in the mm tree, this needs
something like the appended fixup. Some common code has now
moved into the spi core.
- Dave
---
drivers/spi/spi_ppc4xx.c | 19 +++----------------
1 file changed, 3 insertions(+), 16 deletions(-)
--- a/drivers/spi/spi_ppc4xx.c
+++ b/drivers/spi/spi_ppc4xx.c
@@ -61,9 +61,6 @@
/* RxD ready */
#define SPI_PPC4XX_SR_RBR (0x80 >> 7)
-/* the spi->mode bits understood by this driver: */
-#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
-
/* clock settings (SCP and CI) for various SPI modes */
#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
#define SPI_CLK_MODE1 0
@@ -198,9 +195,6 @@ static int spi_ppc4xx_setup(struct spi_d
struct spi_ppc4xx_cs *cs = spi->controller_state;
int init = 0;
- if (!spi->bits_per_word)
- spi->bits_per_word = 8;
-
if (spi->bits_per_word != 8) {
dev_err(&spi->dev, "invalid bits-per-word (%d)\n",
spi->bits_per_word);
@@ -212,12 +206,6 @@ static int spi_ppc4xx_setup(struct spi_d
return -EINVAL;
}
- if (spi->mode & ~MODEBITS) {
- dev_dbg(&spi->dev, "setup: unsupported mode bits %x\n",
- spi->mode & ~MODEBITS);
- return -EINVAL;
- }
-
if (cs == NULL) {
cs = kzalloc(sizeof *cs, GFP_KERNEL);
if (!cs)
@@ -268,10 +256,6 @@ static int spi_ppc4xx_setup(struct spi_d
}
}
- dev_dbg(&spi->dev, "%s: mode %d, %u bpw, %d hz\n",
- __func__, spi->mode, spi->bits_per_word,
- spi->max_speed_hz);
-
return 0;
}
@@ -442,6 +426,9 @@ static int __init spi_ppc4xx_of_probe(st
}
}
+ /* the spi->mode bits understood by this driver: */
+ master->modebits = SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST;
+
/* Setup the state for the bitbang driver */
bbp = &hw->bitbang;
bbp->master = hw->master;
^ permalink raw reply
* [PATCH v4] powerpc/85xx: Add P2020DS board support
From: Kumar Gala @ 2009-04-22 5:44 UTC (permalink / raw)
To: linuxppc-dev
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe controllers.
Signed-off-by: Ted Peters <Ted.Peters@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* Fixed copyright
* fixed l2-cache size
* Fixed usb compat prop
- k
arch/powerpc/boot/dts/p2020ds.dts | 668 ++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 35 ++-
arch/powerpc/platforms/fsl_uli1575.c | 1 +
arch/powerpc/sysdev/fsl_pci.c | 2 +
include/linux/pci_ids.h | 2 +
5 files changed, 707 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds.dts
diff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dts
new file mode 100644
index 0000000..66acb19
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -0,0 +1,668 @@
+/*
+ * P2020 DS Device Tree Source
+ *
+ * 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,P2020DS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P2020@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+
+ PowerPC,P2020@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ localbus@ffe05000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc", "simple-bus";
+ reg = <0 0xffe05000 0 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x1 0x0 0x0 0xe0000000 0x08000000
+ 0x2 0x0 0x0 0xffa00000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000
+ 0x4 0x0 0x0 0xffa40000 0x00040000
+ 0x5 0x0 0x0 0xffa80000 0x00040000
+ 0x6 0x0 0x0 0xffac0000 0x00040000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ ramdisk@0 {
+ reg = <0x0 0x03000000>;
+ read-only;
+ };
+
+ diagnostic@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ read-only;
+ };
+
+ dink@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ read-only;
+ };
+
+ kernel@4000000 {
+ reg = <0x04000000 0x00400000>;
+ read-only;
+ };
+
+ jffs2@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ };
+
+ dtb@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ read-only;
+ };
+
+ u-boot@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ u-boot@0 {
+ reg = <0x0 0x02000000>;
+ read-only;
+ };
+
+ jffs2@2000000 {
+ reg = <0x02000000 0x10000000>;
+ };
+
+ ramdisk@12000000 {
+ reg = <0x12000000 0x08000000>;
+ read-only;
+ };
+
+ kernel@1a000000 {
+ reg = <0x1a000000 0x04000000>;
+ };
+
+ dtb@1e000000 {
+ reg = <0x1e000000 0x01000000>;
+ read-only;
+ };
+
+ empty@1f000000 {
+ reg = <0x1f000000 0x21000000>;
+ };
+ };
+
+ nand@4,0 {
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x4 0x0 0x40000>;
+ };
+
+ nand@5,0 {
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x5 0x0 0x40000>;
+ };
+
+ nand@6,0 {
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x6 0x0 0x40000>;
+ };
+ };
+
+ soc@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p2020-immr", "simple-bus";
+ ranges = <0x0 0 0xffe00000 0x100000>;
+ reg = <0 0xffe00000 0 0x1000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
+ bus-frequency = <0>; // Filled out by uboot.
+
+ memory-controller@2000 {
+ compatible = "fsl,p2020-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 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>;
+ interrupts = <16 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;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ 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>;
+ };
+ };
+
+ 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";
+ };
+
+
+ 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>;
+ tbi-handle = <&tbi0>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x520 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>;
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <3 1>;
+ reg = <0x2>;
+ };
+ 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 = <&tbi1>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ 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>;
+ tbi-handle = <&tbi2>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,p2020-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+
+ msi@41600 {
+ compatible = "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>;
+ };
+
+ 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";
+ };
+ };
+
+ pci0: pcie@ffe08000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0 0xffe08000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <24 2>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x8 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x9 0x1
+ 0000 0x0 0x0 0x3 &mpic 0xa 0x1
+ 0000 0x0 0x0 0x4 &mpic 0xb 0x1
+ >;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x10000>;
+ };
+ };
+
+ pci1: 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 0xffc10000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <25 2>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
+ interrupt-map = <
+
+ // IDSEL 0x11 func 0 - PCI slot 1
+ 0x8800 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8800 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 1 - PCI slot 1
+ 0x8900 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8900 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 2 - PCI slot 1
+ 0x8a00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8a00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 3 - PCI slot 1
+ 0x8b00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8b00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 4 - PCI slot 1
+ 0x8c00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8c00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 5 - PCI slot 1
+ 0x8d00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8d00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 6 - PCI slot 1
+ 0x8e00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8e00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 7 - PCI slot 1
+ 0x8f00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8f00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x1d Audio
+ 0xe800 0x0 0x0 0x1 &i8259 0x6 0x2
+
+ // IDSEL 0x1e Legacy
+ 0xf000 0x0 0x0 0x1 &i8259 0x7 0x2
+ 0xf100 0x0 0x0 0x1 &i8259 0x7 0x2
+
+ // IDSEL 0x1f IDE/SATA
+ 0xf800 0x0 0x0 0x1 &i8259 0xe 0x2
+ 0xf900 0x0 0x0 0x1 &i8259 0x5 0x2
+ >;
+
+ 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 0x10000>;
+ uli1575@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x10000>;
+ isa@1e {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <0xf000 0x0 0x0 0x0 0x0>;
+ ranges = <0x1 0x0 0x1000000 0x0 0x0
+ 0x1000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ reg = <0x1 0x20 0x2
+ 0x1 0xa0 0x2
+ 0x1 0x4d0 0x2>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ compatible = "chrp,iic";
+ interrupts = <4 1>;
+ interrupt-parent = <&mpic>;
+ };
+
+ i8042@60 {
+ #size-cells = <0>;
+ #address-cells = <1>;
+ reg = <0x1 0x60 0x1 0x1 0x64 0x1>;
+ interrupts = <1 3 12 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ reg = <0x0>;
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ reg = <0x1>;
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible = "pnpPNP,b00";
+ reg = <0x1 0x70 0x2>;
+ };
+
+ gpio@400 {
+ reg = <0x1 0x400 0x80>;
+ };
+ };
+ };
+ };
+
+ };
+
+ pci2: 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>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x0 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x1 0x1
+ 0000 0x0 0x0 0x3 &mpic 0x2 0x1
+ 0000 0x0 0x0 0x4 &mpic 0x3 0x1
+ >;
+ 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 0x10000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index de66de7..25f750c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -163,7 +163,8 @@ static void __init mpc85xx_ds_setup_arch(void)
#ifdef CONFIG_PCI
for_each_node_by_type(np, "pci") {
if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
- of_device_is_compatible(np, "fsl,mpc8548-pcie")) {
+ of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
+ of_device_is_compatible(np, "fsl,p2020-pcie")) {
struct resource rsrc;
of_address_to_resource(np, 0, &rsrc);
if ((rsrc.start & 0xfffff) == primary_phb_addr)
@@ -214,6 +215,7 @@ static int __init mpc85xxds_publish_devices(void)
}
machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
machine_device_initcall(mpc8572_ds, mpc85xxds_publish_devices);
+machine_device_initcall(p2020_ds, mpc85xxds_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -232,6 +234,23 @@ static int __init mpc8572_ds_probe(void)
}
}
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init p2020_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,P2020DS")) {
+#ifdef CONFIG_PCI
+ primary_phb_addr = 0x9000;
+#endif
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
define_machine(mpc8544_ds) {
.name = "MPC8544 DS",
.probe = mpc8544_ds_probe,
@@ -259,3 +278,17 @@ define_machine(mpc8572_ds) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p2020_ds) {
+ .name = "P2020 DS",
+ .probe = p2020_ds_probe,
+ .setup_arch = mpc85xx_ds_setup_arch,
+ .init_IRQ = mpc85xx_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/platforms/fsl_uli1575.c b/arch/powerpc/platforms/fsl_uli1575.c
index 4b10c36..0a4a3bb 100644
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -55,6 +55,7 @@ static inline bool is_quirk_valid(void)
{
return (machine_is(mpc86xx_hpcn) ||
machine_is(mpc8544_ds) ||
+ machine_is(p2020_ds) ||
machine_is(mpc8572_ds))
}
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 78021d8..36db7b3 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -296,6 +296,8 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8536, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2020E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2020, quirk_fsl_pcie_header);
#endif /* CONFIG_PPC_85xx || CONFIG_PPC_86xx */
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 06ba90c..36a1dd0 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2286,6 +2286,8 @@
#define PCI_DEVICE_ID_MPC8572 0x0041
#define PCI_DEVICE_ID_MPC8536E 0x0050
#define PCI_DEVICE_ID_MPC8536 0x0051
+#define PCI_DEVICE_ID_P2020E 0x0070
+#define PCI_DEVICE_ID_P2020 0x0071
#define PCI_DEVICE_ID_MPC8641 0x7010
#define PCI_DEVICE_ID_MPC8641D 0x7011
#define PCI_DEVICE_ID_MPC8610 0x7018
--
1.6.0.6
^ permalink raw reply related
* RE: [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Liu Dave-R63238 @ 2009-04-22 4:54 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
In-Reply-To: <1240371105-18400-1-git-send-email-galak@kernel.crashing.org>
> + L2: l2-cache-controller@20000 {
> + compatible =3D "fsl,p2020-l2-cache-controller";
> + reg =3D <0x20000 0x1000>;
> + cache-line-size =3D <32>; // 32 bytes
> + cache-size =3D <0x100000>; // L2, 1M
> + interrupt-parent =3D <&mpic>;
> + interrupts =3D <16 2>;
> + };
One nit --here should be 512KB L2 cache
> + usb@22000 {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + compatible =3D "fsl-usb2-mph";
> + reg =3D <0x22000 0x1000>;
> + interrupt-parent =3D <&mpic>;
> + interrupts =3D <28 0x2>;
> + phy_type =3D "ulpi";
> + };
It should be "fsl-usb2-dr"
^ permalink raw reply
* Re: [BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
From: Paul Mackerras @ 2009-04-22 3:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: sachinp, Stephen Rothwell, Adrian Bunk, linux-kernel,
Stefan Bader, Linuxppc-dev, linux-next, Marcelo Tosatti, subrata,
Alexander Beregalov
In-Reply-To: <200904212104.14665.bzolnier@gmail.com>
Bartlomiej Zolnierkiewicz writes:
> mediabay shouldn't include <linux/ide.h> unconditionally so
> remove the superfluous include from mediabay.c (<asm/mediabay.h>
> will pull <linux/ide.h> in for CONFIG_BLK_DEV_IDE_PMAC=y).
I don't like relying on second-hand imports like that. I prefer the
previous patch, that made mediabay depend on CONFIG_BLOCK.
BTW, if including <linux/ide.h> causes an error when CONFIG_BLOCK=n,
then there is a bug in <linux/ide.h>, IMO.
Paul.
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Kumar Gala @ 2009-04-22 3:51 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49EE5A80.4030209@mlbassoc.com>
On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
> Kumar Gala wrote:
>>
>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>
>>>
>>> I found the difference - in 2.6.28 the inbound/outbound windows
>>> don't seem to be set up at all. In 2.6.26, the function
>>> 'fsl_add_bridge'
>>> was common among architectures and ended up calling 'setup_pci_atmu'
>>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>>
>>> I'm sure this is the problem.
>>
>> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci
>> code
>> calling setup_pci_atmu().
>
> It did not directly; it called 'fsl_add_bridge' which in turn called
> 'setup_pci_atmu'
Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx
only in 83xx.
> I modified the 2.6.28 driver to also call this function. Now the
> inbound/outbound windows are set up, but the bridge still has
> no allocations, so the problem remains.
>
> I need to move on; I may just live with sliding the PCI space
> up for now (doesn't really hurt anything, just seems like a hack)
It is and you are glossing over a real bug.
Are you using u-boot to boot? If so is the board port public?
- k
^ permalink raw reply
* [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Kumar Gala @ 2009-04-22 3:31 UTC (permalink / raw)
To: linuxppc-dev
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe controllers.
Signed-off-by: Ted Peters <Ted.Peters@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
* Fixed soc node compat to have "p2020-immr"
* Fixed up SEC node per Kim's comments
- k
arch/powerpc/boot/dts/p2020ds.dts | 668 ++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 35 ++-
arch/powerpc/platforms/fsl_uli1575.c | 1 +
arch/powerpc/sysdev/fsl_pci.c | 2 +
include/linux/pci_ids.h | 2 +
5 files changed, 707 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds.dts
diff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dts
new file mode 100644
index 0000000..ea46f7a
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -0,0 +1,668 @@
+/*
+ * P2020 DS Device Tree Source
+ *
+ * Copyright 2007-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,P2020DS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ pci2 = &pci2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P2020@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+
+ PowerPC,P2020@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ localbus@ffe05000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc", "simple-bus";
+ reg = <0 0xffe05000 0 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+
+ ranges = <0x0 0x0 0x0 0xe8000000 0x08000000
+ 0x1 0x0 0x0 0xe0000000 0x08000000
+ 0x2 0x0 0x0 0xffa00000 0x00040000
+ 0x3 0x0 0x0 0xffdf0000 0x00008000
+ 0x4 0x0 0x0 0xffa40000 0x00040000
+ 0x5 0x0 0x0 0xffa80000 0x00040000
+ 0x6 0x0 0x0 0xffac0000 0x00040000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ ramdisk@0 {
+ reg = <0x0 0x03000000>;
+ read-only;
+ };
+
+ diagnostic@3000000 {
+ reg = <0x03000000 0x00e00000>;
+ read-only;
+ };
+
+ dink@3e00000 {
+ reg = <0x03e00000 0x00200000>;
+ read-only;
+ };
+
+ kernel@4000000 {
+ reg = <0x04000000 0x00400000>;
+ read-only;
+ };
+
+ jffs2@4400000 {
+ reg = <0x04400000 0x03b00000>;
+ };
+
+ dtb@7f00000 {
+ reg = <0x07f00000 0x00080000>;
+ read-only;
+ };
+
+ u-boot@7f80000 {
+ reg = <0x07f80000 0x00080000>;
+ read-only;
+ };
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x2 0x0 0x40000>;
+
+ u-boot@0 {
+ reg = <0x0 0x02000000>;
+ read-only;
+ };
+
+ jffs2@2000000 {
+ reg = <0x02000000 0x10000000>;
+ };
+
+ ramdisk@12000000 {
+ reg = <0x12000000 0x08000000>;
+ read-only;
+ };
+
+ kernel@1a000000 {
+ reg = <0x1a000000 0x04000000>;
+ };
+
+ dtb@1e000000 {
+ reg = <0x1e000000 0x01000000>;
+ read-only;
+ };
+
+ empty@1f000000 {
+ reg = <0x1f000000 0x21000000>;
+ };
+ };
+
+ nand@4,0 {
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x4 0x0 0x40000>;
+ };
+
+ nand@5,0 {
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x5 0x0 0x40000>;
+ };
+
+ nand@6,0 {
+ compatible = "fsl,elbc-fcm-nand";
+ reg = <0x6 0x0 0x40000>;
+ };
+ };
+
+ soc@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p2020-immr", "simple-bus";
+ ranges = <0x0 0 0xffe00000 0x100000>;
+ reg = <0 0xffe00000 0 0x1000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
+ bus-frequency = <0>; // Filled out by uboot.
+
+ memory-controller@2000 {
+ compatible = "fsl,p2020-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p2020-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x100000>; // L2, 1M
+ interrupt-parent = <&mpic>;
+ interrupts = <16 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;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ 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>;
+ };
+ };
+
+ 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-mph";
+ reg = <0x22000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <28 0x2>;
+ phy_type = "ulpi";
+ };
+
+
+ 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>;
+ tbi-handle = <&tbi0>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x520 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>;
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <3 1>;
+ reg = <0x2>;
+ };
+ 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 = <&tbi1>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ 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>;
+ tbi-handle = <&tbi2>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ interrupts = <42 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,p2020-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+
+ msi@41600 {
+ compatible = "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>;
+ };
+
+ 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";
+ };
+ };
+
+ pci0: pcie@ffe08000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0 0xffe08000 0 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <24 2>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x8 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x9 0x1
+ 0000 0x0 0x0 0x3 &mpic 0xa 0x1
+ 0000 0x0 0x0 0x4 &mpic 0xb 0x1
+ >;
+ pcie@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x10000>;
+ };
+ };
+
+ pci1: 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 0xffc10000 0x0 0x10000>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupts = <25 2>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
+ interrupt-map = <
+
+ // IDSEL 0x11 func 0 - PCI slot 1
+ 0x8800 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8800 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 1 - PCI slot 1
+ 0x8900 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8900 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 2 - PCI slot 1
+ 0x8a00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8a00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 3 - PCI slot 1
+ 0x8b00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8b00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 4 - PCI slot 1
+ 0x8c00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8c00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 5 - PCI slot 1
+ 0x8d00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8d00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 6 - PCI slot 1
+ 0x8e00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8e00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x11 func 7 - PCI slot 1
+ 0x8f00 0x0 0x0 0x1 &i8259 0x9 0x2
+ 0x8f00 0x0 0x0 0x2 &i8259 0xa 0x2
+
+ // IDSEL 0x1d Audio
+ 0xe800 0x0 0x0 0x1 &i8259 0x6 0x2
+
+ // IDSEL 0x1e Legacy
+ 0xf000 0x0 0x0 0x1 &i8259 0x7 0x2
+ 0xf100 0x0 0x0 0x1 &i8259 0x7 0x2
+
+ // IDSEL 0x1f IDE/SATA
+ 0xf800 0x0 0x0 0x1 &i8259 0xe 0x2
+ 0xf900 0x0 0x0 0x1 &i8259 0x5 0x2
+ >;
+
+ 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 0x10000>;
+ uli1575@0 {
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x10000>;
+ isa@1e {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <0xf000 0x0 0x0 0x0 0x0>;
+ ranges = <0x1 0x0 0x1000000 0x0 0x0
+ 0x1000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ reg = <0x1 0x20 0x2
+ 0x1 0xa0 0x2
+ 0x1 0x4d0 0x2>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ compatible = "chrp,iic";
+ interrupts = <4 1>;
+ interrupt-parent = <&mpic>;
+ };
+
+ i8042@60 {
+ #size-cells = <0>;
+ #address-cells = <1>;
+ reg = <0x1 0x60 0x1 0x1 0x64 0x1>;
+ interrupts = <1 3 12 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ reg = <0x0>;
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ reg = <0x1>;
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible = "pnpPNP,b00";
+ reg = <0x1 0x70 0x2>;
+ };
+
+ gpio@400 {
+ reg = <0x1 0x400 0x80>;
+ };
+ };
+ };
+ };
+
+ };
+
+ pci2: 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>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x0 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x1 0x1
+ 0000 0x0 0x0 0x3 &mpic 0x2 0x1
+ 0000 0x0 0x0 0x4 &mpic 0x3 0x1
+ >;
+ 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 0x10000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index de66de7..25f750c 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -163,7 +163,8 @@ static void __init mpc85xx_ds_setup_arch(void)
#ifdef CONFIG_PCI
for_each_node_by_type(np, "pci") {
if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
- of_device_is_compatible(np, "fsl,mpc8548-pcie")) {
+ of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
+ of_device_is_compatible(np, "fsl,p2020-pcie")) {
struct resource rsrc;
of_address_to_resource(np, 0, &rsrc);
if ((rsrc.start & 0xfffff) == primary_phb_addr)
@@ -214,6 +215,7 @@ static int __init mpc85xxds_publish_devices(void)
}
machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
machine_device_initcall(mpc8572_ds, mpc85xxds_publish_devices);
+machine_device_initcall(p2020_ds, mpc85xxds_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -232,6 +234,23 @@ static int __init mpc8572_ds_probe(void)
}
}
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init p2020_ds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,P2020DS")) {
+#ifdef CONFIG_PCI
+ primary_phb_addr = 0x9000;
+#endif
+ return 1;
+ } else {
+ return 0;
+ }
+}
+
define_machine(mpc8544_ds) {
.name = "MPC8544 DS",
.probe = mpc8544_ds_probe,
@@ -259,3 +278,17 @@ define_machine(mpc8572_ds) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
+
+define_machine(p2020_ds) {
+ .name = "P2020 DS",
+ .probe = p2020_ds_probe,
+ .setup_arch = mpc85xx_ds_setup_arch,
+ .init_IRQ = mpc85xx_ds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/platforms/fsl_uli1575.c b/arch/powerpc/platforms/fsl_uli1575.c
index 4b10c36..0a4a3bb 100644
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -55,6 +55,7 @@ static inline bool is_quirk_valid(void)
{
return (machine_is(mpc86xx_hpcn) ||
machine_is(mpc8544_ds) ||
+ machine_is(p2020_ds) ||
machine_is(mpc8572_ds))
}
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 78021d8..36db7b3 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -296,6 +296,8 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8536, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2020E, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P2020, quirk_fsl_pcie_header);
#endif /* CONFIG_PPC_85xx || CONFIG_PPC_86xx */
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 06ba90c..36a1dd0 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2286,6 +2286,8 @@
#define PCI_DEVICE_ID_MPC8572 0x0041
#define PCI_DEVICE_ID_MPC8536E 0x0050
#define PCI_DEVICE_ID_MPC8536 0x0051
+#define PCI_DEVICE_ID_P2020E 0x0070
+#define PCI_DEVICE_ID_P2020 0x0071
#define PCI_DEVICE_ID_MPC8641 0x7010
#define PCI_DEVICE_ID_MPC8641D 0x7011
#define PCI_DEVICE_ID_MPC8610 0x7018
--
1.6.0.6
^ permalink raw reply related
* Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Randy Dunlap @ 2009-04-22 3:00 UTC (permalink / raw)
To: David Brownell
Cc: sachinp, Stephen Rothwell, samr, linux-usb, linux-kernel,
Linuxppc-dev, linux-next, subrata, Alexander Beregalov
In-Reply-To: <200904211919.38104.david-b@pacbell.net>
David Brownell wrote:
> On Tuesday 21 April 2009, Randy Dunlap wrote:
>>> Since its feasible to say 'n' to both we get the compile error. How do
>>> we enforce having at least one set?
>> Looks like using "choice" without "optional" would do it.
>> See Documentation/kbuild/kconfig-language.txt and various examples
>> in Kconfig* files.
>
> That won't quite work ... "at least one" includes "two"
> (i.e. a PCI card in little-endian, a native controller
> in big-endian). Real-world systems need such configs,
> or so I'm told, and that's why their supported.
Yes, I see.
> Is there maybe a way to force Kconfig to just reject
> such illegal configs -- neither option set -- rather
> than trying some how to fix it?
Not that I know of. cc-ing Sam.
> Or maybe ... if neither one is set, have the header
> force both on, and issue a warning.
That should be doable. We'd prefer to catch it via Kconfig,
but that doesn't look promising just now.
--
~Randy
^ permalink raw reply
* Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: David Brownell @ 2009-04-22 2:19 UTC (permalink / raw)
To: Randy Dunlap
Cc: sachinp, Stephen Rothwell, linux-usb, linux-kernel, Linuxppc-dev,
linux-next, subrata, Alexander Beregalov
In-Reply-To: <49EE4341.50701@oracle.com>
On Tuesday 21 April 2009, Randy Dunlap wrote:
>
> > Since its feasible to say 'n' to both we get the compile error. How do
> > we enforce having at least one set?
>
> Looks like using "choice" without "optional" would do it.
> See Documentation/kbuild/kconfig-language.txt and various examples
> in Kconfig* files.
That won't quite work ... "at least one" includes "two"
(i.e. a PCI card in little-endian, a native controller
in big-endian). Real-world systems need such configs,
or so I'm told, and that's why their supported.
Is there maybe a way to force Kconfig to just reject
such illegal configs -- neither option set -- rather
than trying some how to fix it?
Or maybe ... if neither one is set, have the header
force both on, and issue a warning.
^ permalink raw reply
* Re: [PATCH v2] powerpc/85xx: Add P2020DS board support
From: David Gibson @ 2009-04-22 1:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1240348762-13581-1-git-send-email-galak@kernel.crashing.org>
On Tue, Apr 21, 2009 at 04:19:22PM -0500, Kumar Gala wrote:
> The P2020 is a dual e500v2 core based SOC with:
> * 3 PCIe controllers
> * 2 General purpose DMA controllers
> * 2 sRIO controllers
> * 3 eTSECS
> * USB 2.0
> * SDHC
> * SPI, I2C, DUART
> * enhanced localbus
> * and optional Security (P2020E) security w/XOR acceleration
>
> The p2020 DS reference board is pretty similar to the existing MPC85xx
> DS boards and has a ULI 1575 connected on one of the PCIe
> controllers.
[snip]
> + soc@ffe00000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
If I understood the description correctly, this one doesn't have the
excuse of being a copy of an already broken device tree. There needs
to be a soc-variant specific string in the compatible property here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/5] powerpc: Add 36-bit device tree for mpc8641hpcn
From: David Gibson @ 2009-04-22 1:26 UTC (permalink / raw)
To: Becky Bruce; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <3772A304-5235-44BE-9947-379375382BAF@kernel.crashing.org>
On Tue, Apr 21, 2009 at 10:33:34AM -0500, Becky Bruce wrote:
>
> On Apr 20, 2009, at 8:10 PM, David Gibson wrote:
>
>> On Mon, Apr 20, 2009 at 11:26:47AM -0500, Becky Bruce wrote:
>>> The new dts places most of the devices in physical address space
>>> above 32-bits, which allows us to have more than 4GB of RAM present.
>>>
>>> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
>>> ---
>>> arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597 ++++++++++++++++++
>>> ++++++++++
>>> 1 files changed, 597 insertions(+), 0 deletions(-)
>>> create mode 100644 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
>>>
>>> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts b/arch/
>>> powerpc/boot/dts/mpc8641_hpcn_36b.dts
>>> new file mode 100644
>>> index 0000000..baa3dba
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
>>> @@ -0,0 +1,597 @@
>>> +/*
>>> + * MPC8641 HPCN Device Tree Source
>>> + *
>>> + * Copyright 2006 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.
>>> + */
>>
>> [snip]
>>> + soc8641@fffe00000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + device_type = "soc";
>>> + compatible = "simple-bus";
>>
>> Uh, you definitely need something more specific in the compatible
>> property before "simple-bus".
>
> This is a copy of the existing mpc8641hpcn dts file, with just physical
> address changes, so if there's a problem here it definitely exists in the
> current 8641hpcn dts, and possibly other dts files as well. I think the
> correct solution is for me to go look at that .dts (and any others that
> may be similar), and put out a followup to fix them all.
Ok, fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [BUILD FAILURE 09/12] Next April 21 : PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Michael Ellerman @ 2009-04-22 0:08 UTC (permalink / raw)
To: subrata
Cc: sachinp, Stephen Rothwell, Greg KH, David A. Schleef,
linux-kernel, Linuxppc-dev, linux-next, Alexander Beregalov
In-Reply-To: <1240340029.9110.142.camel@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]
On Wed, 2009-04-22 at 00:23 +0530, Subrata Modak wrote:
> Reported this error on 14th April:
> http://lkml.org/lkml/2009/4/14/488,
>
> CC [M] drivers/staging/comedi/drivers.o
> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’
> undeclared (first use in this function)
> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier
> is reported only once
> drivers/staging/comedi/drivers.c:496: error: for each function it
> appears in.)
> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> make[2]: *** [drivers/staging/comedi] Error 2
> make[1]: *** [drivers/staging] Error 2
> make: *** [drivers] Error 2
Subrata, unless someone says otherwise, please do not send randconfig
failures for drivers in staging - those drivers have bigger problems
than randconfig failures.
To avoid them, do this:
# make randconfig
# sed -i -e 's/^\(CONFIG_STAGING\)=y/# \1 is not set/' .config
# make oldconfig
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc/85xx: Add P2020DS board support
From: Kim Phillips @ 2009-04-22 0:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1240348762-13581-1-git-send-email-galak@kernel.crashing.org>
On Tue, 21 Apr 2009 16:19:22 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> + crypto@30000 {
> + compatible = "fsl,sec3.0", "fsl,sec2.4", "fsl,sec2.2",
> + "fsl,sec2.1", "fsl,sec2.0";
should be:
compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
"fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
> + fsl,exec-units-mask = <0x9fe>;
and:
fsl,exec-units-mask = <0xbfe>;
to include the SNOW unit.
Kim
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Gary Thomas @ 2009-04-21 23:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <306F293D-44CD-4238-ADA9-BB7436C7004C@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>
>>
>> I found the difference - in 2.6.28 the inbound/outbound windows
>> don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge'
>> was common among architectures and ended up calling 'setup_pci_atmu'
>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>
>> I'm sure this is the problem.
>
> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
> calling setup_pci_atmu().
It did not directly; it called 'fsl_add_bridge' which in turn called
'setup_pci_atmu'
I modified the 2.6.28 driver to also call this function. Now the
inbound/outbound windows are set up, but the bridge still has
no allocations, so the problem remains.
I need to move on; I may just live with sliding the PCI space
up for now (doesn't really hurt anything, just seems like a hack)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Kumar Gala @ 2009-04-21 23:41 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49EE5021.4020703@mlbassoc.com>
On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>
> I found the difference - in 2.6.28 the inbound/outbound windows
> don't seem to be set up at all. In 2.6.26, the function
> 'fsl_add_bridge'
> was common among architectures and ended up calling 'setup_pci_atmu'
> which created those mappings. In 2.6.28, the 83xx PCI setup code
> has been refactored. It uses 'mpc83xx_add_bridge' instead of
> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>
> I'm sure this is the problem.
Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
calling setup_pci_atmu().
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
From: Anatolij Gustschin @ 2009-04-21 23:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <625ED025-8D5B-437F-BEA8-1A599B677D43@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 21, 2009, at 4:54 PM, Kumar Gala wrote:
>
>>
>> On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:
>>
>>> If the firmware missed to initialize the PHY correctly,
>>> Linux may hang up on socrates while eth0/eth1 interface
>>> startup (caused by continuous unacknowledged PHY interrupt).
>>>
>>> This patch adds PHY fixup to socrates platform code to
>>> ensure the PHY is pre-initialized correctly. It is needed
>>> to be compatible with older firmware.
>>>
>>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>>> ---
>>> Changes since first version:
>>> use macros instead of register numbers as
>>> suggested by Anton
>>>
>>> Kumar, could you please consider this patch for
>>> inclusion into 2.6.30? Thanks!
>>
>> Sorry. I dont think this is board specific and should at a minimum be
>> done in m88e1011_config_init in drivers/net/phy/marvell.c. Not sure
>> how 88E1011 differs from 88E1111, but I'm wondering if you really want
>> to set config_init for m88e1011 to m88e1111_config_init
>>
>> - k
>
> I got confused by the #'s.. I think we should have a struct in marvell.c
> for m88e1121 which I'm guessing is the PHY you are using.
yes, m88e1121 is correct. In 2.6.30-rc2 there is already a m88e1121
struct in marvell_drivers[] in drivers/net/phy/marvell.c.
The reason I'm not doing the m88e1121 pre-init stuff in config_init
is as follows:
m88e1121 is a multi-PHY device with two PHY ports and each port
could signal an interrupt. This PHY device can be pin-strapped to use
shared interrupt pin for both PHY ports (as used on socrates board).
PHY specific config_init will be called e.g. while eth0 startup in
phy_attach() which is called from phy_connect() in drivers/net/phy/phy_device.c.
phy_connect() then calls phy_start_interrupts() which registers the
interrupt handler and enables the interrupts for the PHY-port config_init
is called for. Now interrupts can be cleared/acknowledged for this
PHY-port (eth0 interface), but interrupts from the another PHY-port
can not be acknowledged as eth1 was not brought up yet.
Placing this fixup in drivers/net/phy/marvell.c as in config_init callback
could be done, but this will add more overhead as the fixup routine have
to do more work:
acquire 'struct mii_bus' pointer and walk through all registered PHYs
searching for the PHY which use the same interrupt, then getting
the address of this PHY on the bus and disable and clear PHY irqs
by writing/reading to/from this PHY, (but only in the case it was
not already brought up and has interrupts enabled!) e.g.:
struct mii_bus *bus = phydev->bus;
int addr;
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
struct phy_device *phy = bus->phy_map[addr];
if (addr != phydev->addr && bus->irq[addr] == phydev->irq &&
(phy->phy_id & 0x0ffffff0) == 0x01410cb0 &&
!(phy->interrupts & PHY_INTERRUPT_ENABLED)) {
int imask = phy_read(phy, MII_M1011_IMASK);
if (imask) {
phy_write(phy, 0x12, 0); /* disable */
phy_read(phy, 0x13); /* clear */
}
}
}
All this to allow support for multiple m88e1121 devices.
Otherwise, after registering first phy interrupt handler
and enabling interrupt pending irq on other PHY port or
other PHY device will lock up the board.
The fixup in this patch will only be done while mdio bus scan
before registering a PHY device.
Anatolij
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Gary Thomas @ 2009-04-21 23:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <46B035C0-624F-41E4-BFDD-C16479CF8FC8@kernel.crashing.org>
Kumar Gala wrote:
>>>> I'm still looking into how the PCI address register for the video
>>>> card did not get written, even though the system obviously thinks
>>>> it did (hence "virtual")
>>>>
>>>
>>> It most definitely has something to do with 0xC0000000 being
>>> assigned to the video card. I changed my DTS to move everything
>>> up (started the whole space at 0xC4000000) and the video card
>>> came to life! Of course, I'm not interested in this hack,
>>> so the simplest thing would be to figure out why 2.6.26 allocated
>>> that outgoing window and 2.6.28 doesn't
>>
>> So I think the difference is due to the change in PCI code between
>> 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in
>> .26 you have:
>>
>>>> c0000000-c7ffffff : 0000:00:00.0
>>
>> and in .28 its gone. This accounts for the allocation differences.
>> What I don't get is why the behavior would vary based on address.
>>
>> Can you dump out the PCI inbound/outbound registers. I have a theory
>> as to what's going on and want to confirm it.
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge'
was common among architectures and ended up calling 'setup_pci_atmu'
which created those mappings. In 2.6.28, the 83xx PCI setup code
has been refactored. It uses 'mpc83xx_add_bridge' instead of
'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
I'm sure this is the problem.
> Also, what's your .dts look like for the PCI node.
For the record:
bus-range = <0 0>;
ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Kumar Gala @ 2009-04-21 22:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gary Thomas
In-Reply-To: <612CEF05-3EFB-4947-B5FC-B35C1F9568D7@kernel.crashing.org>
>>> I'm still looking into how the PCI address register for the video
>>> card did not get written, even though the system obviously thinks
>>> it did (hence "virtual")
>>>
>>
>> It most definitely has something to do with 0xC0000000 being
>> assigned to the video card. I changed my DTS to move everything
>> up (started the whole space at 0xC4000000) and the video card
>> came to life! Of course, I'm not interested in this hack,
>> so the simplest thing would be to figure out why 2.6.26 allocated
>> that outgoing window and 2.6.28 doesn't
>
> So I think the difference is due to the change in PCI code between
> 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device
> in .26 you have:
>
>>> c0000000-c7ffffff : 0000:00:00.0
>
> and in .28 its gone. This accounts for the allocation differences.
> What I don't get is why the behavior would vary based on address.
>
> Can you dump out the PCI inbound/outbound registers. I have a
> theory as to what's going on and want to confirm it.
Also, what's your .dts look like for the PCI node.
- k
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Kumar Gala @ 2009-04-21 22:38 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49EE4729.3000100@mlbassoc.com>
On Apr 21, 2009, at 5:22 PM, Gary Thomas wrote:
> Gary Thomas wrote:
>> Kumar Gala wrote:
>>> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>>>
>>>> The [two] big differences I see are that the video card (00:0d.0)
>>>> is being assigned 0xC0000000, which lspci marks as "virtual".
>>>> I think I've had trouble in the past with memory regions which
>>>> started at 0 relative to the PCI space. Also "virtual" concerns
>>>> me.
>>>>
>>>> Does this spark any ideas from anyone?
>>> Doesn't ring any bells. What does cat /proc/iomem look like
>>> between the
>>> two kernels.
>>
>> About what I gleaned from lspci. The working 2.6.26 kernel has
>> space mapped in the controller (exposed memory window, I think)
>> and the video card got moved down accordingly.
>>
>> ---------------------------------- 2.6.26
>> c0000000-cfffffff : /pci@ff008500
>> c0000000-c7ffffff : 0000:00:00.0
>> c8000000-cbffffff : 0000:00:0c.0
>> c8000000-cbffffff : CoralP_fb
>> cc000000-cc0fffff : 0000:00:00.0
>> cc100000-cc11ffff : 0000:00:0b.0
>> cc120000-cc12ffff : 0000:00:0a.0
>> cc130000-cc13ffff : 0000:00:0a.0
>> cc140000-cc140fff : 0000:00:0b.0
>> cc140000-cc140fff : sata_promise
>> cc141000-cc141fff : 0000:00:0d.0
>> cc141000-cc141fff : ohci_hcd
>> cc142000-cc142fff : 0000:00:0d.1
>> cc142000-cc142fff : ohci_hcd
>> cc143000-cc1430ff : 0000:00:0d.2
>> cc143000-cc1430ff : ehci_hcd
>> cc143100-cc143100 : 0000:00:00.0
>> f0000000-f1ffffff : f0000000.flash
>> ff000200-ff0002ff : wdt
>> ff003000-ff0030ff : i2c
>> ff003100-ff0031ff : i2c
>> ff004500-ff004507 : serial
>> ff004600-ff004607 : serial
>> ff022000-ff022fff : usb
>> ff022000-ff022fff : ehci_hcd
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : ehci_hcd
>> ff024000-ff024fff : ethernet
>> ff024520-ff02453f : mdio
>> ff025000-ff025fff : ethernet
>>
>> ---------------------------------- 2.6.28
>> c0000000-cfffffff : /pci@ff008500
>> c0000000-c3ffffff : 0000:00:0c.0
>> c0000000-c3ffffff : CoralP_fb
>> c4000000-c401ffff : 0000:00:0b.0
>> c4020000-c402ffff : 0000:00:0a.0
>> c4030000-c403ffff : 0000:00:0a.0
>> c4040000-c4040fff : 0000:00:0b.0
>> c4040000-c4040fff : sata_promise
>> c4041000-c4041fff : 0000:00:0d.0
>> c4041000-c4041fff : ohci_hcd
>> c4042000-c4042fff : 0000:00:0d.1
>> c4042000-c4042fff : ohci_hcd
>> c4043000-c40430ff : 0000:00:0d.2
>> c4043000-c40430ff : ehci_hcd
>> f0000000-f1ffffff : f0000000.flash
>> ff004500-ff004507 : serial
>> ff004600-ff004607 : serial
>> ff022000-ff022fff : usb
>> ff022000-ff022fff : ehci_hcd
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : ehci_hcd
>> ff024000-ff024fff : ethernet
>> ff024520-ff02453f : mdio
>> ff025000-ff025fff : ethernet
>>
>> I'm still looking into how the PCI address register for the video
>> card did not get written, even though the system obviously thinks
>> it did (hence "virtual")
>>
>
> It most definitely has something to do with 0xC0000000 being
> assigned to the video card. I changed my DTS to move everything
> up (started the whole space at 0xC4000000) and the video card
> came to life! Of course, I'm not interested in this hack,
> so the simplest thing would be to figure out why 2.6.26 allocated
> that outgoing window and 2.6.28 doesn't
So I think the difference is due to the change in PCI code between
2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in .
26 you have:
>> c0000000-c7ffffff : 0000:00:00.0
and in .28 its gone. This accounts for the allocation differences.
What I don't get is why the behavior would vary based on address.
Can you dump out the PCI inbound/outbound registers. I have a theory
as to what's going on and want to confirm it.
- k
^ permalink raw reply
* Re: PCI changes 2.6.26 => 2.6.28
From: Gary Thomas @ 2009-04-21 22:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <49EE306D.3000401@mlbassoc.com>
Gary Thomas wrote:
> Kumar Gala wrote:
>> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>>
>>> The [two] big differences I see are that the video card (00:0d.0)
>>> is being assigned 0xC0000000, which lspci marks as "virtual".
>>> I think I've had trouble in the past with memory regions which
>>> started at 0 relative to the PCI space. Also "virtual" concerns me.
>>>
>>> Does this spark any ideas from anyone?
>> Doesn't ring any bells. What does cat /proc/iomem look like between the
>> two kernels.
>
> About what I gleaned from lspci. The working 2.6.26 kernel has
> space mapped in the controller (exposed memory window, I think)
> and the video card got moved down accordingly.
>
> ---------------------------------- 2.6.26
> c0000000-cfffffff : /pci@ff008500
> c0000000-c7ffffff : 0000:00:00.0
> c8000000-cbffffff : 0000:00:0c.0
> c8000000-cbffffff : CoralP_fb
> cc000000-cc0fffff : 0000:00:00.0
> cc100000-cc11ffff : 0000:00:0b.0
> cc120000-cc12ffff : 0000:00:0a.0
> cc130000-cc13ffff : 0000:00:0a.0
> cc140000-cc140fff : 0000:00:0b.0
> cc140000-cc140fff : sata_promise
> cc141000-cc141fff : 0000:00:0d.0
> cc141000-cc141fff : ohci_hcd
> cc142000-cc142fff : 0000:00:0d.1
> cc142000-cc142fff : ohci_hcd
> cc143000-cc1430ff : 0000:00:0d.2
> cc143000-cc1430ff : ehci_hcd
> cc143100-cc143100 : 0000:00:00.0
> f0000000-f1ffffff : f0000000.flash
> ff000200-ff0002ff : wdt
> ff003000-ff0030ff : i2c
> ff003100-ff0031ff : i2c
> ff004500-ff004507 : serial
> ff004600-ff004607 : serial
> ff022000-ff022fff : usb
> ff022000-ff022fff : ehci_hcd
> ff023000-ff023fff : usb
> ff023000-ff023fff : usb
> ff023000-ff023fff : ehci_hcd
> ff024000-ff024fff : ethernet
> ff024520-ff02453f : mdio
> ff025000-ff025fff : ethernet
>
> ---------------------------------- 2.6.28
> c0000000-cfffffff : /pci@ff008500
> c0000000-c3ffffff : 0000:00:0c.0
> c0000000-c3ffffff : CoralP_fb
> c4000000-c401ffff : 0000:00:0b.0
> c4020000-c402ffff : 0000:00:0a.0
> c4030000-c403ffff : 0000:00:0a.0
> c4040000-c4040fff : 0000:00:0b.0
> c4040000-c4040fff : sata_promise
> c4041000-c4041fff : 0000:00:0d.0
> c4041000-c4041fff : ohci_hcd
> c4042000-c4042fff : 0000:00:0d.1
> c4042000-c4042fff : ohci_hcd
> c4043000-c40430ff : 0000:00:0d.2
> c4043000-c40430ff : ehci_hcd
> f0000000-f1ffffff : f0000000.flash
> ff004500-ff004507 : serial
> ff004600-ff004607 : serial
> ff022000-ff022fff : usb
> ff022000-ff022fff : ehci_hcd
> ff023000-ff023fff : usb
> ff023000-ff023fff : usb
> ff023000-ff023fff : ehci_hcd
> ff024000-ff024fff : ethernet
> ff024520-ff02453f : mdio
> ff025000-ff025fff : ethernet
>
> I'm still looking into how the PCI address register for the video
> card did not get written, even though the system obviously thinks
> it did (hence "virtual")
>
It most definitely has something to do with 0xC0000000 being
assigned to the video card. I changed my DTS to move everything
up (started the whole space at 0xC4000000) and the video card
came to life! Of course, I'm not interested in this hack,
so the simplest thing would be to figure out why 2.6.26 allocated
that outgoing window and 2.6.28 doesn't
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Performance differences with IRQ_ALL_CPUS
From: Kumar Gala @ 2009-04-21 22:07 UTC (permalink / raw)
To: Subodh Nijsure; +Cc: linuxppc-dev
In-Reply-To: <002601c9c2cc$c7821dc0$f272150a@cisco.com>
On Apr 21, 2009, at 5:01 PM, Subodh Nijsure wrote:
>
>
>> From: Kumar Gala
>> Sent: Tuesday, April 21, 2009 1:02 PM
>
>>
>>
>> On Apr 21, 2009, at 10:56 AM, Subodh Nijsure wrote:
>>
>>> Hi,
>>>
>>>
>>> I have board with MPC8572E (dual core PPC). I have one
>> board running
>>> kernel
>>> with IRQ_ALL_CPUS set to Y and another with that option
>> turned off.
>>> Kernel
>>> version #2.6.26
>>>
>>>
>>> With IRQ_ALL_CPUS turned off
>>> ( Here interrupts all go to CPU0 )
>>>
>>> hdparm -tT /dev/hda
>>> /dev/hda:
>>> Timing cached reads: 3048 MB in 2.00 seconds = 1523.79 MB/sec
>>> Timing buffered disk reads: 10 MB in 3.07 seconds = 3.25 MB/sec
>>>
>>> cat /proc/interrupts
>>> CPU0 CPU1
>>> 18: 1394100 0 OpenPIC Edge ide0
>>>
>>> With IRQ_ALL_CPUS turned on I see
>>> (Here interrupts go to CPU0 and CPU1 )
>>>
>>> hdparm -tT /dev/hda
>>>
>>> /dev/hda:
>>> Timing cached reads: 1076 MB in 2.00 seconds = 538.01 MB/sec
>>> Timing buffered disk reads: 10 MB in 3.08 seconds = 3.25 MB/sec
>>>
>>> cat /proc/interrupts
>>> CPU0 CPU1
>>> 18: 44951 54765 OpenPIC Edge ide0
>>>
>>> I "expected" that with IRQ_ALL_CPUS -- interrupt sharing I would be
>>> able to get higher througput but I see things otherway around.
>>>
>>> Would someone care to enlighten me as to why when I set
>> IRQ_ALL_CPUS
>>> disk I/O performance goes down so much? Under what circumstances
>>> should one then turn on IRQ_ALL_CPUS option on PPC platform?
>>>
>>> Regards,
>>> /Subodh
>>
>> This is probably because you are getting ill defined behavior
>> on 8572. The 8572 (and any FSL MPIC) doesn't actually
>> support having the PIC distribute interrupts to the different
>> CPUs. Its technically "illegal" to set more than one
>> destination processor.
>>
>> If you want to try and distribute interrupts than I suggest
>> looking at irqbalance.
>>
>
> Kumar, thanks for the info.
> Okay I will research irqbalance (from http://irqbalance.org/?) and
> see how
> that goes.
>
> If I want to lock say ethernet interrupts to (core0) CPU0 and Ide
> interrupts
> to (core1) CPU1 is there a way to fix that using device-tree
> specification?
No. We've actively avoided trying to convene such affinity in the
device tree.
However you can do:
cat 1 > /proc/irq/ENET_IRQ_NUM/affinity
cat 2 > /proc/irq/IDE_IRQ/affinity
at boot time.
This will get you affinity binding to a core.
The affinity file is bitmask related to core # (with lsb being core0
and msb being core31)
- k
^ permalink raw reply
* Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Randy Dunlap @ 2009-04-21 22:05 UTC (permalink / raw)
To: Kumar Gala
Cc: sachinp, Stephen Rothwell, linux-usb, linux-kernel,
David Brownell, Linuxppc-dev, linux-next, subrata,
Alexander Beregalov
In-Reply-To: <5A202317-5104-4784-845B-B8C46E0A3C48@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 21, 2009, at 2:03 PM, David Brownell wrote:
>
>> On Tuesday 21 April 2009, Subrata Modak wrote:
>>> Observing this for the first time:
>>>
>>> CC drivers/usb/host/ohci-hcd.o
>>> In file included from drivers/usb/host/ohci-hcd.c:1060:
>>> drivers/usb/host/ohci-ppc-of.c:242:2: error: #error "No endianess
>>
>> Hmm, scripts/get_maintainer.pl doesn't report
>> the PPC folk who maintain that file and its
>> kbuild infrastructure.
>>
>> Can we have some PPC folk look at (and fix) this?
>
> The problem is in the drivers/usb/host/Kconfig:
>
> config USB_OHCI_HCD_PPC_OF_BE
> bool "Support big endian HC"
> depends on USB_OHCI_HCD_PPC_OF
> default y
> select USB_OHCI_BIG_ENDIAN_DESC
> select USB_OHCI_BIG_ENDIAN_MMIO
>
> config USB_OHCI_HCD_PPC_OF_LE
> bool "Support little endian HC"
> depends on USB_OHCI_HCD_PPC_OF
> default n
> select USB_OHCI_LITTLE_ENDIAN
>
> Since its feasible to say 'n' to both we get the compile error. How do
> we enforce having at least one set?
Looks like using "choice" without "optional" would do it.
See Documentation/kbuild/kconfig-language.txt and various examples
in Kconfig* files.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
From: Kumar Gala @ 2009-04-21 22:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Anatolij Gustschin
In-Reply-To: <1D3E7471-098E-483F-A80D-4D02BB8F076C@kernel.crashing.org>
On Apr 21, 2009, at 4:54 PM, Kumar Gala wrote:
>
> On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:
>
>> If the firmware missed to initialize the PHY correctly,
>> Linux may hang up on socrates while eth0/eth1 interface
>> startup (caused by continuous unacknowledged PHY interrupt).
>>
>> This patch adds PHY fixup to socrates platform code to
>> ensure the PHY is pre-initialized correctly. It is needed
>> to be compatible with older firmware.
>>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> ---
>> Changes since first version:
>> use macros instead of register numbers as
>> suggested by Anton
>>
>> Kumar, could you please consider this patch for
>> inclusion into 2.6.30? Thanks!
>
> Sorry. I dont think this is board specific and should at a minimum
> be done in m88e1011_config_init in drivers/net/phy/marvell.c. Not
> sure how 88E1011 differs from 88E1111, but I'm wondering if you
> really want to set config_init for m88e1011 to m88e1111_config_init
>
> - k
I got confused by the #'s.. I think we should have a struct in
marvell.c for m88e1121 which I'm guessing is the PHY you are using.
- k
^ permalink raw reply
* RE: Performance differences with IRQ_ALL_CPUS
From: Subodh Nijsure @ 2009-04-21 22:01 UTC (permalink / raw)
To: 'Kumar Gala'; +Cc: linuxppc-dev
In-Reply-To: <01A4AE51-D835-4F15-8735-DE537B2F6FF3@kernel.crashing.org>
> From: Kumar Gala
> Sent: Tuesday, April 21, 2009 1:02 PM
>
>
> On Apr 21, 2009, at 10:56 AM, Subodh Nijsure wrote:
>
> > Hi,
> >
> >
> > I have board with MPC8572E (dual core PPC). I have one
> board running
> > kernel
> > with IRQ_ALL_CPUS set to Y and another with that option
> turned off.
> > Kernel
> > version #2.6.26
> >
> >
> > With IRQ_ALL_CPUS turned off
> > ( Here interrupts all go to CPU0 )
> >
> > hdparm -tT /dev/hda
> > /dev/hda:
> > Timing cached reads: 3048 MB in 2.00 seconds = 1523.79 MB/sec
> > Timing buffered disk reads: 10 MB in 3.07 seconds = 3.25 MB/sec
> >
> > cat /proc/interrupts
> > CPU0 CPU1
> > 18: 1394100 0 OpenPIC Edge ide0
> >
> > With IRQ_ALL_CPUS turned on I see
> > (Here interrupts go to CPU0 and CPU1 )
> >
> > hdparm -tT /dev/hda
> >
> > /dev/hda:
> > Timing cached reads: 1076 MB in 2.00 seconds = 538.01 MB/sec
> > Timing buffered disk reads: 10 MB in 3.08 seconds = 3.25 MB/sec
> >
> > cat /proc/interrupts
> > CPU0 CPU1
> > 18: 44951 54765 OpenPIC Edge ide0
> >
> > I "expected" that with IRQ_ALL_CPUS -- interrupt sharing I would be
> > able to get higher througput but I see things otherway around.
> >
> > Would someone care to enlighten me as to why when I set
> IRQ_ALL_CPUS
> > disk I/O performance goes down so much? Under what circumstances
> > should one then turn on IRQ_ALL_CPUS option on PPC platform?
> >
> > Regards,
> > /Subodh
>
> This is probably because you are getting ill defined behavior
> on 8572. The 8572 (and any FSL MPIC) doesn't actually
> support having the PIC distribute interrupts to the different
> CPUs. Its technically "illegal" to set more than one
> destination processor.
>
> If you want to try and distribute interrupts than I suggest
> looking at irqbalance.
>
Kumar, thanks for the info.
Okay I will research irqbalance (from http://irqbalance.org/?) and see how
that goes.
If I want to lock say ethernet interrupts to (core0) CPU0 and Ide interrupts
to (core1) CPU1 is there a way to fix that using device-tree specification?
I will look through the MPC8572 programmer's manual and see if there is such
a thing in processor itself.
/Subodh
^ permalink raw reply
* Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
From: Kumar Gala @ 2009-04-21 21:54 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1240334378-1643-1-git-send-email-agust@denx.de>
On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:
> If the firmware missed to initialize the PHY correctly,
> Linux may hang up on socrates while eth0/eth1 interface
> startup (caused by continuous unacknowledged PHY interrupt).
>
> This patch adds PHY fixup to socrates platform code to
> ensure the PHY is pre-initialized correctly. It is needed
> to be compatible with older firmware.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> Changes since first version:
> use macros instead of register numbers as
> suggested by Anton
>
> Kumar, could you please consider this patch for
> inclusion into 2.6.30? Thanks!
Sorry. I dont think this is board specific and should at a minimum be
done in m88e1011_config_init in drivers/net/phy/marvell.c. Not sure
how 88E1011 differs from 88E1111, but I'm wondering if you really want
to set config_init for m88e1011 to m88e1111_config_init
- k
> arch/powerpc/platforms/85xx/socrates.c | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/socrates.c b/arch/powerpc/
> platforms/85xx/socrates.c
> index d0e8443..bde0a97 100644
> --- a/arch/powerpc/platforms/85xx/socrates.c
> +++ b/arch/powerpc/platforms/85xx/socrates.c
> @@ -28,6 +28,7 @@
> #include <linux/delay.h>
> #include <linux/seq_file.h>
> #include <linux/of_platform.h>
> +#include <linux/phy.h>
>
> #include <asm/system.h>
> #include <asm/time.h>
> @@ -78,6 +79,23 @@ static void __init socrates_pic_init(void)
> of_node_put(np);
> }
>
> +#define MII_M1011_IMASK 0x12
> +#define MII_M1011_IEVENT 0x13
> +static int socrates_m88e1121_fixup(struct phy_device *phydev)
> +{
> + int err;
> +
> + err = phy_write(phydev, MII_M1011_IMASK, 0);
> + if (err < 0)
> + return err;
> +
> + err = phy_read(phydev, MII_M1011_IEVENT);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +
> /*
> * Setup the architecture
> */
> @@ -105,6 +123,8 @@ static struct of_device_id __initdata
> socrates_of_bus_ids[] = {
> static void __init socrates_init(void)
> {
> of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
> + phy_register_fixup_for_uid(0x1410cb0, 0xffffff0,
> + socrates_m88e1121_fixup);
> }
>
> /*
> --
> 1.5.6.3
^ 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