* Re: [PATCH -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: Kumar Gala @ 2009-06-10 23:16 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244670419.29684.1600.camel@localhost.localdomain>
On Jun 10, 2009, at 4:46 PM, Nate Case wrote:
> Hi Kumar,
>
> Thanks for the feedback. Response below:
>
>>> +
>>> + root = of_find_node_by_path("/");
>>> + if (root == NULL)
>>> + return;
>>> +
>>> + model = of_get_property(root, "model", NULL);
>>> + if (strncasecmp(model, "xes,", strlen("xes,")) != 0)
>>> + return;
>>
>> What is this check for?
>
> Historical accident. A while back we somehow ended up with a case of
> probe() succeeding when it shouldn't have, and this was the
> workaround.
> I'll remove it since it's useless now.
>
>>> +
>>> + printk(KERN_INFO "X-ES MPC85xx-based single-board computer: %s\n",
>>> + model + strlen("xes,"));
>>
>> Why not print the name from machine_id.name
>
> Because machine_id->name will give us "X-ES MPC8572" from the machine
> description rather than the actual board name (e.g., xpedite5370).
>
> In our situation, we have several boards that share largely the same
> hardware design. I decided to just put 1 machine definition per
> processor rather than having a machine definition for every board
> (which
> would get pretty crazy for our case). For example, we have at least 6
> MPC8572-based boards with more on the way, but all of their changes
> can
> be described in the device tree (e.g., changes in number of ethernet
> ports or PCI express controllers), so there's no need for a machine
> definition for all of them.
>
>>> +machine_device_initcall(xes_mpc8572, xes_mpc85xx_publish_devices);
>>> +machine_device_initcall(xes_mpc8548, xes_mpc85xx_publish_devices);
>>
>> Do you not need this for xes_mpc8540?
>
> Yes, thanks. I'll fix this and the other things you mentioned and
> re-submit. Will this be able to make it into your next tree destined
> for 2.6.31?
If it get submitted pretty soon I'd be willing to take it for .31.
Also can you split the patch into 3 pieces (defconfig, .dts, and
actual platform code)
- k
^ permalink raw reply
* Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: Kumar Gala @ 2009-06-10 23:24 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244673039-1089-1-git-send-email-ncase@xes-inc.com>
On Jun 10, 2009, at 5:30 PM, Nate Case wrote:
> Add support for X-ES single-board computers based on the Freescale
> MPC85xx processors. Changes include:
>
> * New machine support in platforms/85xx
> * dts files for supported boards
> * defconfig
> * Boot wrapper support for XPedite5200 to support legacy boot loader
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> ---
> Differences from patch v1:
> * Address comments from Kumar
> * Remove L1 cache setup (submitted as separate patch for all e500
> CPUs)
>
> arch/powerpc/boot/dts/xcalibur1501.dts | 759 +++++++++++
> arch/powerpc/boot/dts/xpedite5200.dts | 472 +++++++
> arch/powerpc/boot/dts/xpedite5200_xmon.dts | 510 +++++++
> arch/powerpc/boot/dts/xpedite5301.dts | 647 +++++++++
> arch/powerpc/boot/dts/xpedite5330.dts | 714 ++++++++++
> arch/powerpc/boot/dts/xpedite5370.dts | 683 ++++++++++
> arch/powerpc/boot/wrapper | 4 +
> arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1668 ++++++++++++++
> +++++++++
> arch/powerpc/platforms/85xx/Kconfig | 10 +
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 282 ++++
> 11 files changed, 5750 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/xcalibur1501.dts
> create mode 100644 arch/powerpc/boot/dts/xpedite5200.dts
> create mode 100644 arch/powerpc/boot/dts/xpedite5200_xmon.dts
> create mode 100644 arch/powerpc/boot/dts/xpedite5301.dts
> create mode 100644 arch/powerpc/boot/dts/xpedite5330.dts
> create mode 100644 arch/powerpc/boot/dts/xpedite5370.dts
> create mode 100644 arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
> create mode 100644 arch/powerpc/platforms/85xx/xes_mpc85xx.c
>
> diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/
> boot/dts/xcalibur1501.dts
> new file mode 100644
> index 0000000..497af7a
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/xcalibur1501.dts
> @@ -0,0 +1,759 @@
> +/*
> + * Copyright (C) 2008 Extreme Engineering Solutions, Inc.
> + * Based on MPC8572DS device tree from Freescale Semiconductor, Inc.
> + *
> + * XCalibur1501 6U CompactPCI single-board computer based on MPC8572E
> + *
> + * This is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +/ {
> + model = "xes,xcalibur1501";
> + compatible = "xes,xcalibur1501", "xes,MPC8572";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + form-factor = "6U cPCI";
> + boot-bank = <0x0>; /* 0: Primary flash, 1: Secondary flash */
I'm not a fan of taking device trees with properties that are
specified anywhere.
> +
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + pci2 = &pci2;
> + };
> +
> + pmcslots {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmcslot@0 {
> + cell-index = <0>;
> + /*
> + * boolean properties (true if defined):
> + * monarch;
> + * module-present;
> + */
> + };
> +
> + pmcslot@1 {
> + cell-index = <1>;
> + /*
> + * boolean properties (true if defined):
> + * monarch;
> + * module-present;
> + */
> + };
> + };
> +
> + xmcslots {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + xmcslot@0 {
> + cell-index = <0>;
> + /*
> + * boolean properties (true if defined):
> + * module-present;
> + */
> + };
> +
> + xmcslot@1 {
> + cell-index = <1>;
> + /*
> + * boolean properties (true if defined):
> + * module-present;
> + */
> + };
> + };
> +
> + cpci {
> + /*
> + * boolean properties (true if defined):
> + * system-controller;
> + */
> + system-controller;
> + };
> +
ditto. (see above)
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8572@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + next-level-cache = <&L2>;
> + };
> +
> + PowerPC,8572@1 {
> + device_type = "cpu";
> + reg = <0x1>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + next-level-cache = <&L2>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + };
> +
> + localbus@ef005000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8572-elbc", "fsl,elbc", "simple-bus";
> + reg = <0 0xef005000 0 0x1000>;
> + interrupts = <19 2>;
> + interrupt-parent = <&mpic>;
> + /* Local bus region mappings */
> + ranges = <0 0 0 0xf8000000 0x8000000 /* CS0: Flash 1 */
> + 1 0 0 0xf0000000 0x8000000 /* CS1: Flash 2 */
> + 2 0 0 0xef800000 0x40000 /* CS2: NAND CE1 */
> + 3 0 0 0xef840000 0x40000 /* CS3: NAND CE2 */
> + 4 0 0 0xe9000000 0x100000>; /* CS4: USB */
> +
> + nor-boot@0,0 {
> + compatible = "amd,s29gl01gp", "cfi-flash";
> + bank-width = <2>;
> + reg = <0 0 0x8000000>; /* 128MB */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "Primary user space";
> + reg = <0x00000000 0x6f00000>; /* 111 MB */
> + };
> + partition@6f00000 {
> + label = "Primary kernel";
> + reg = <0x6f00000 0x1000000>; /* 16 MB */
> + };
> + partition@7f00000 {
> + label = "Primary DTB";
> + reg = <0x7f00000 0x40000>; /* 256 KB */
> + };
> + partition@7f40000 {
> + label = "Primary U-Boot environment";
> + reg = <0x7f40000 0x40000>; /* 256 KB */
> + };
> + partition@7f80000 {
> + label = "Primary U-Boot";
> + reg = <0x7f80000 0x80000>; /* 512 KB */
> + read-only;
> + };
> + };
> +
> + nor-alternate@1,0 {
> + compatible = "amd,s29gl01gp", "cfi-flash";
> + bank-width = <2>;
> + //reg = <0xf0000000 0x08000000>; /* 128MB */
> + reg = <1 0 0x8000000>; /* 128MB */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "Secondary user space";
> + reg = <0x00000000 0x6f00000>; /* 111 MB */
> + };
> + partition@6f00000 {
> + label = "Secondary kernel";
> + reg = <0x6f00000 0x1000000>; /* 16 MB */
> + };
> + partition@7f00000 {
> + label = "Secondary DTB";
> + reg = <0x7f00000 0x40000>; /* 256 KB */
> + };
> + partition@7f40000 {
> + label = "Secondary U-Boot environment";
> + reg = <0x7f40000 0x40000>; /* 256 KB */
> + };
> + partition@7f80000 {
> + label = "Secondary U-Boot";
> + reg = <0x7f80000 0x80000>; /* 512 KB */
> + read-only;
> + };
> + };
> +
> + nand@2,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + /*
> + * Actual part could be ST Micro NAND08GW3B2A (1 GB),
> + * Micron MT29F8G08DAA (2x 512 MB), or Micron
> + * MT29F16G08FAA (2x 1 GB), depending on the build
> + * configuration
> + */
> + compatible = "fsl,mpc8572-fcm-nand",
> + "fsl,elbc-fcm-nand";
> + reg = <2 0 0x40000>;
> + /* U-Boot should fix this up if chip size > 1 GB */
> + partition@0 {
> + label = "NAND Filesystem";
> + reg = <0 0x40000000>;
> + };
> + };
> +
> + usb@4,0 {
> + compatible = "nxp,usb-isp1761";
> + reg = <4 0 0x100000>;
> + bus-width = <32>;
> + interrupt-parent = <&mpic>;
> + interrupts = <10 1>;
> + };
> + };
> +
> + soc8572@ef000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
should have a compat like:
compatible = "fsl,mpc8572-immr", "simple-bus";
>
> + ranges = <0x0 0 0xef000000 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,mpc8572-ecm", "fsl,ecm";
> + reg = <0x1000 0x1000>;
> + interrupts = <17 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + memory-controller@2000 {
> + compatible = "fsl,mpc8572-memory-controller";
> + reg = <0x2000 0x1000>;
> + interrupt-parent = <&mpic>;
> + interrupts = <18 2>;
> + };
> +
> + memory-controller@6000 {
> + compatible = "fsl,mpc8572-memory-controller";
> + reg = <0x6000 0x1000>;
> + interrupt-parent = <&mpic>;
> + interrupts = <18 2>;
> + };
> +
> + L2: l2-cache-controller@20000 {
> + compatible = "fsl,mpc8572-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;
> +
> + temp-sensor@48 {
> + compatible = "dallas,ds1631", "dallas,ds1621";
> + reg = <0x48>;
> + };
> +
> + temp-sensor@4c {
> + compatible = "adi,adt7461";
> + reg = <0x4c>;
> + };
> +
> + cpu-supervisor@51 {
> + compatible = "dallas,ds4510";
> + reg = <0x51>;
> + };
> +
> + eeprom@54 {
> + compatible = "atmel,at24c128b";
> + reg = <0x54>;
> + };
> +
> + rtc@68 {
> + compatible = "stm,m41t00",
> + "dallas,ds1338";
> + reg = <0x68>;
> + };
> +
> + pcie-switch@6a {
> + compatible = "plx,pex8648";
> + reg = <0x6a>;
> + };
> +
> + /* On-board signals for VID, flash, serial */
> + gpio1: gpio@18 {
> + compatible = "nxp,pca9557";
> + reg = <0x18>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + polarity = <0x00>;
> + };
> +
> + /* PMC0/XMC0 signals */
> + gpio2: gpio@1c {
> + compatible = "nxp,pca9557";
> + reg = <0x1c>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + polarity = <0x00>;
> + };
> +
> + /* PMC1/XMC1 signals */
> + gpio3: gpio@1d {
> + compatible = "nxp,pca9557";
> + reg = <0x1d>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + polarity = <0x00>;
> + };
> +
> + /* CompactPCI signals (sysen, GA[4:0]) */
> + gpio4: gpio@1e {
> + compatible = "nxp,pca9557";
> + reg = <0x1e>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + polarity = <0x00>;
> + };
> +
> + /* CompactPCI J5 GPIO and FAL/DEG/PRST */
> + gpio5: gpio@1f {
> + compatible = "nxp,pca9557";
> + reg = <0x1f>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + polarity = <0x00>;
> + };
> + };
> +
> + 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,mpc8572-dma", "fsl,eloplus-dma";
> + reg = <0xc300 0x4>;
> + ranges = <0x0 0xc100 0x200>;
> + cell-index = <1>;
> + dma-channel@0 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x0 0x80>;
> + cell-index = <0>;
> + interrupt-parent = <&mpic>;
> + interrupts = <76 2>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x80 0x80>;
> + cell-index = <1>;
> + interrupt-parent = <&mpic>;
> + interrupts = <77 2>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x100 0x80>;
> + cell-index = <2>;
> + interrupt-parent = <&mpic>;
> + interrupts = <78 2>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "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,mpc8572-dma", "fsl,eloplus-dma";
> + reg = <0x21300 0x4>;
> + ranges = <0x0 0x21100 0x200>;
> + cell-index = <0>;
> + dma-channel@0 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x0 0x80>;
> + cell-index = <0>;
> + interrupt-parent = <&mpic>;
> + interrupts = <20 2>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x80 0x80>;
> + cell-index = <1>;
> + interrupt-parent = <&mpic>;
> + interrupts = <21 2>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x100 0x80>;
> + cell-index = <2>;
> + interrupt-parent = <&mpic>;
> + interrupts = <22 2>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,mpc8572-dma-channel",
> + "fsl,eloplus-dma-channel";
> + reg = <0x180 0x80>;
> + cell-index = <3>;
> + interrupt-parent = <&mpic>;
> + interrupts = <23 2>;
> + };
> + };
> +
> + /* eTSEC 1 front panel 0 */
> + 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 = "sgmii";
> +
> + mdio@520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-mdio";
> + reg = <0x520 0x20>;
> +
> + phy0: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <4 1>;
> + reg = <0x1>;
> + device_type = "ethernet-phy";
> + };
> + phy1: ethernet-phy@2 {
> + interrupt-parent = <&mpic>;
> + interrupts = <4 1>;
> + reg = <0x2>;
> + device_type = "ethernet-phy";
> + };
> + phy2: ethernet-phy@3 {
> + interrupt-parent = <&mpic>;
> + interrupts = <5 1>;
> + reg = <0x3>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@4 {
> + interrupt-parent = <&mpic>;
> + interrupts = <5 1>;
> + reg = <0x4>;
> + device_type = "ethernet-phy";
> + };
> + tbi0: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
> + };
> + };
> + };
> +
> + /* eTSEC 2 front panel 1 */
> + 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 = "sgmii";
> +
> + 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";
> + };
> + };
> + };
> +
> + /* eTSEC 3 PICMG2.16 backplane port 0 */
> + 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 = "sgmii";
> +
> + 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";
> + };
> + };
> + };
> +
> + /* eTSEC 4 PICMG2.16 backplane port 1 */
> + enet3: ethernet@27000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <3>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x27000 0x1000>;
> + ranges = <0x0 0x27000 0x1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <37 2 38 2 39 2>;
> + interrupt-parent = <&mpic>;
> + tbi-handle = <&tbi3>;
> + phy-handle = <&phy3>;
> + phy-connection-type = "sgmii";
> +
> + mdio@520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-tbi";
> + reg = <0x520 0x20>;
> +
> + tbi3: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
> + };
> + };
> + };
> +
> + /* UART0 */
> + serial0: serial@4500 {
> + cell-index = <0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4500 0x100>;
> + clock-frequency = <0>;
> + interrupts = <42 2>;
> + interrupt-parent = <&mpic>;
> + /* U-Boot should populate as RS-232, RS-485, etc */
> + transceiver-mode = "Unknown";
this is a new property w/o any specification.
>
> + };
> +
> + /* UART1 */
> + serial1: serial@4600 {
> + cell-index = <1>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4600 0x100>;
> + clock-frequency = <0>;
> + interrupts = <42 2>;
> + interrupt-parent = <&mpic>;
> + /* U-Boot should populate as RS-232, RS-485, etc */
> + transceiver-mode = "Unknown";
> + };
> +
> + global-utilities@e0000 { //global utilities block
> + compatible = "fsl,mpc8572-guts";
> + reg = <0xe0000 0x1000>;
> + fsl,has-rstcr;
> + };
> +
> + msi@41600 {
> + compatible = "fsl,mpc8572-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>;
> + };
> +
> + crypto@30000 {
> + compatible = "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 = <0x9fe>;
> + 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";
> + };
> +
> + gpio0: gpio@f000 {
> + compatible = "fsl,mpc8572-gpio";
> + reg = <0xf000 0x1000>;
> + interrupts = <47 2>;
> + interrupt-parent = <&mpic>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + heartbeat {
> + label = "Heartbeat";
> + gpios = <&gpio0 4 1>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + yellow {
> + label = "Yellow";
> + gpios = <&gpio0 5 1>;
> + };
> +
> + red {
> + label = "Red";
> + gpios = <&gpio0 6 1>;
> + };
> +
> + green {
> + label = "Green";
> + gpios = <&gpio0 7 1>;
> + };
> + };
> +
> + /* PME (pattern-matcher) */
> + pme@10000 {
> + compatible = "fsl,mpc8572-pme", "pme8572";
> + reg = <0x10000 0x5000>;
> + interrupts = <57 2 64 2 65 2 66 2 67 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + tlu@2f000 {
> + device_type = "tlu";
> + compatible = "fsl,mpc8572-tlu", "fsl_tlu";
> + reg = <0x2f000 0x1000>;
> + interupts = <61 2 >;
> + interrupt-parent = <&mpic>;
> + };
> +
> + tlu@15000 {
> + device_type = "tlu";
> + compatible = "fsl,mpc8572-tlu", "fsl_tlu";
> + reg = <0x15000 0x1000>;
> + interupts = <75 2>;
> + interrupt-parent = <&mpic>;
> + };
> + };
> +
> + /*
> + * PCI Express controller 3 @ ef008000 is not used.
> + * This would have been pci0 on other mpc85xx platforms.
> + *
> + * PCI Express controller 2 @ ef009000 is not used.
> + * This would have been pci1 on other mpc85xx platforms.
> + */
> +
> + /* PCI Express controller 1, wired to PEX8648 PCIe switch */
> + pci2: pcie@ef00a000 {
> + compatible = "fsl,mpc8548-pcie";
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <0 0xef00a000 0 0x1000>;
> + bus-range = <0 255>;
> + ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x40000000
> + 0x1000000 0x0 0x00000000 0 0xe8000000 0x0 0x10000>;
> + clock-frequency = <33333333>;
> + interrupt-parent = <&mpic>;
> + interrupts = <26 2>;
> + interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> + interrupt-map = <
> + /* IDSEL 0x0 */
> + 0x0 0x0 0x0 0x1 &mpic 0x0 0x1
> + 0x0 0x0 0x0 0x2 &mpic 0x1 0x1
> + 0x0 0x0 0x0 0x3 &mpic 0x2 0x1
> + 0x0 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 0x80000000
> + 0x2000000 0x0 0x80000000
> + 0x0 0x40000000
> +
> + 0x1000000 0x0 0x0
> + 0x1000000 0x0 0x0
> + 0x0 0x100000>;
> + };
> + };
> +};
^ permalink raw reply
* Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: Nate Case @ 2009-06-11 0:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <DF329655-9763-42EA-8170-645337949CF3@kernel.crashing.org>
On Wed, 2009-06-10 at 18:24 -0500, Kumar Gala wrote:
> > + form-factor = "6U cPCI";
> > + boot-bank = <0x0>; /* 0: Primary flash, 1: Secondary flash */
>
> I'm not a fan of taking device trees with properties that are
> specified anywhere.
I can just delete them for now. They're purely informational at this
point, but might be used in the future.
> > + soc8572@ef000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + compatible = "simple-bus";
>
> should have a compat like:
>
> compatible = "fsl,mpc8572-immr", "simple-bus";
Are you sure about this? I only see "simple-bus" in the mpc8572ds.dts
files in mainline and your next branch -- so I was just following your
lead here.
I'll split up the patch as well. It's not obvious where the 4-line boot
wrapper change should go, so I can make that one separate as well unless
you object.
--
Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* Re: Delay on intialization ide subsystem(most likely)
From: Benjamin Herrenschmidt @ 2009-06-11 0:44 UTC (permalink / raw)
To: Andrey Gusev; +Cc: linux-ide, petkovbb, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20090611015733.39bab13a@power-debian>
On Thu, 2009-06-11 at 01:57 +0400, Andrey Gusev wrote:
>
> I wrote about time, why it have such values on second CPU? Sorry, if this
> message is silly.
Oh that's just because it hasn't synchronized the timebases yet when
it prints those messages.
Cheers,
Ben.
> I found configuration, where there isn't delay, but I need more time for
> testing.
>
> >
> > > >
> > > >
> > > > > [ 70.584122] hdb:<3>ide-pmac lost interrupt, dma status: 8480
> > > >
> > > > DMA status indicates that DMA transfer is still active according
> > > > to the controller. This one is really a platform/hardware
> > > > specific issue.
> > > >
> > >
> > > Notes for Ben, I checked only 2.6.26, but may be somebody checked
> > > 2.6.24 or this is interpolation.
> > >
> > > Thanks,
> > > Andrey
> >
^ permalink raw reply
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Benjamin Herrenschmidt @ 2009-06-11 0:48 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev list
In-Reply-To: <4A302B67.4000401@mlbassoc.com>
On Wed, 2009-06-10 at 15:53 -0600, Gary Thomas wrote:
> Trying to understand the process (in preparation for any patches
> I may want to push upstream) - how can this be too late for 2.6.31?
> 2.6.30 just came out today...
I'm taking the liberty to reply to the list here because I think
more people need to understand that problem :-)
Because the process is such that new features can only be merged
during the 2 weeks merge window, which started ... yesterday.
Also, it's frowned upon to have lots of new stuff close to the end of
the merge window.
The idea is that stuff to go into 2.6.31 should have essentially been
ready to merge -before- the merge window opens, ie, before 2.6.30 is
released, for us maintainers to be ready to push things out when the
merge window open and spend that time sorting out collisions &
conflicts, -not- reviewing new features that have been sent way too
late.
In addition, before being merged, patches should generally be post long
in advance since they are likely to go through several revisions as
people review and comment on them. This process must happen long before
the patch is queued up for the actual merge.
So when the merge window opens, it's too late to have your patch be
submitted for the first time. Patches that have been submitted a while
ago and just didn't make it yet into my "next" branch due to my own
lazyness are generally fine. Bug fixes too, at least until -rc3 or -rc4,
after which only major bug fixes and regressions are accepted.
Cheers,
Ben.
^ permalink raw reply
* Re: next branch update
From: Benjamin Herrenschmidt @ 2009-06-11 0:50 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090610175602.722bf68d@lappy.seanm.ca>
On Wed, 2009-06-10 at 17:56 -0400, Sean MacLennan wrote:
> What ever happened to this patch?
Dunno... It should have been in patchwork. I remember the patch
in fact and I intended to merge it... Can you re-submit with appropriate
cset comment, signed-off-by etc... ?
(Mistakes -do- happen, which is why we can be flexible with the rules,
btw, but heh, 33 new patches the day the merge window opens is a bit
over the top).
Cheers,
Ben.
> diff --git b/arch/powerpc/platforms/44x/warp.c
> a/arch/powerpc/platforms/44x/warp.c index c511880..7f3c1c7 100644
> --- b/arch/powerpc/platforms/44x/warp.c
> +++ a/arch/powerpc/platforms/44x/warp.c
> @@ -43,7 +43,13 @@ static int __init warp_probe(void)
> {
> unsigned long root = of_get_flat_dt_root();
>
> - return of_flat_dt_is_compatible(root, "pika,warp");
> + if (!of_flat_dt_is_compatible(root, "pika,warp"))
> + return 0;
> +
> + /* For __dma_alloc_coherent */
> + ISA_DMA_THRESHOLD = ~0L;
> +
> + return 1;
> }
>
> I don't see it in patchworks and I don't see it in Ben's or Josh's tree.
>
> Cheers,
> Sean
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Stephen Rothwell @ 2009-06-11 1:05 UTC (permalink / raw)
To: Subrata Modak
Cc: Sachin P Sant, netdev, Linux-Kernel, Linuxppc-dev, Linux-Next,
Li Yang, Balbir Singh
In-Reply-To: <20090610174323.28045.70169.sendpatchset@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Hi Subrata,
On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
>
> /* Find the TBI PHY. If it's not there, we don't support SGMII */
> - ph = of_get_property(np, "tbi-handle", NULL);
> + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
You don't need this cast because of_get_property() returns "void *".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next branch update
From: Sean MacLennan @ 2009-06-11 1:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1244681452.5739.7.camel@pasglop>
On Thu, 11 Jun 2009 10:50:52 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> n Wed, 2009-06-10 at 17:56 -0400, Sean MacLennan wrote:
> > What ever happened to this patch?
>
> Dunno... It should have been in patchwork. I remember the patch
> in fact and I intended to merge it... Can you re-submit with
> appropriate cset comment, signed-off-by etc... ?
>
> (Mistakes -do- happen, which is why we can be flexible with the rules,
> btw, but heh, 33 new patches the day the merge window opens is a bit
> over the top).
I was expecting an rc9 and another week. Probably others where caught
off guard. Patch below.
Cheers,
Sean
If no device is passed to __dma_alloc_coherent, it defaults to using ISA_DMA_THRESHOLD
for the mask. This patch provides a reasonable default rather than 0.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 21ff868..7f3c1c7 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -43,7 +43,13 @@ static int __init warp_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- return of_flat_dt_is_compatible(root, "pika,warp");
+ if (!of_flat_dt_is_compatible(root, "pika,warp"))
+ return 0;
+
+ /* For __dma_alloc_coherent */
+ ISA_DMA_THRESHOLD = ~0L;
+
+ return 1;
}
define_machine(warp) {
^ permalink raw reply related
* Re: next branch update
From: Benjamin Herrenschmidt @ 2009-06-11 1:30 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev list
In-Reply-To: <20090610210923.2323202f@lappy.seanm.ca>
On Wed, 2009-06-10 at 21:09 -0400, Sean MacLennan wrote:
> I was expecting an rc9 and another week. Probably others where caught
> off guard. Patch below.
>
Note that this simple patch qualifies as a bug fix in my book and thus
is less constrainted. I would happily have merged it in -rc4 :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Michael Ellerman @ 2009-06-11 1:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244681320.5739.5.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
On Thu, 2009-06-11 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-06-10 at 15:53 -0600, Gary Thomas wrote:
>
> > Trying to understand the process (in preparation for any patches
> > I may want to push upstream) - how can this be too late for 2.6.31?
> > 2.6.30 just came out today...
>
> I'm taking the liberty to reply to the list here because I think
> more people need to understand that problem :-)
>
> Because the process is such that new features can only be merged
> during the 2 weeks merge window, which started ... yesterday.
>
> Also, it's frowned upon to have lots of new stuff close to the end of
> the merge window.
>
> The idea is that stuff to go into 2.6.31 should have essentially been
> ready to merge -before- the merge window opens, ie, before 2.6.30 is
> released, for us maintainers to be ready to push things out when the
> merge window open and spend that time sorting out collisions &
> conflicts, -not- reviewing new features that have been sent way too
> late.
The way I think of it is that the "merge window" is the time for
maintainers to merge with Linus.
So if you're sending patches to a maintainer you need to have sent all
your patches to them _before_ then. So the merge window for you is the
weeks prior to the "merge window".
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: David Gibson @ 2009-06-11 1:32 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244673039-1089-1-git-send-email-ncase@xes-inc.com>
On Wed, Jun 10, 2009 at 05:30:39PM -0500, Nate Case wrote:
> Add support for X-ES single-board computers based on the Freescale
> MPC85xx processors. Changes include:
[snip]
> diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
> new file mode 100644
> index 0000000..497af7a
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/xcalibur1501.dts
> @@ -0,0 +1,759 @@
> +/*
> + * Copyright (C) 2008 Extreme Engineering Solutions, Inc.
> + * Based on MPC8572DS device tree from Freescale Semiconductor, Inc.
> + *
> + * XCalibur1501 6U CompactPCI single-board computer based on MPC8572E
> + *
> + * This is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +/ {
> + model = "xes,xcalibur1501";
> + compatible = "xes,xcalibur1501", "xes,MPC8572";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + form-factor = "6U cPCI";
> + boot-bank = <0x0>; /* 0: Primary flash, 1: Secondary flash */
These last two aren't standard properties, so should probably be
"xes,form-factor" and "xes,boot-bank".
[snip]
> + pmcslots {
What does this structure model? Without any reg properties it's kind
of hard to see what you could do with it.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmcslot@0 {
Since you have an unit address, you must also have a reg property to
match, so reg = <0> in this case.
> + cell-index = <0>;
Don't use cell-index here, it's redundant with the reg value that you
should have.
> + /*
> + * boolean properties (true if defined):
> + * monarch;
> + * module-present;
> + */
> + };
> +
> + pmcslot@1 {
> + cell-index = <1>;
> + /*
> + * boolean properties (true if defined):
> + * monarch;
> + * module-present;
> + */
> + };
> + };
> +
> + xmcslots {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + xmcslot@0 {
> + cell-index = <0>;
Same comments here.
> + /*
> + * boolean properties (true if defined):
> + * module-present;
> + */
> + };
> +
> + xmcslot@1 {
> + cell-index = <1>;
> + /*
> + * boolean properties (true if defined):
> + * module-present;
> + */
> + };
> + };
> +
> + cpci {
> + /*
> + * boolean properties (true if defined):
> + * system-controller;
> + */
> + system-controller;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,8572@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + next-level-cache = <&L2>;
> + };
> +
> + PowerPC,8572@1 {
> + device_type = "cpu";
> + reg = <0x1>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <0x8000>; // L1, 32K
> + i-cache-size = <0x8000>; // L1, 32K
> + timebase-frequency = <0>;
> + bus-frequency = <0>;
> + clock-frequency = <0>;
> + next-level-cache = <&L2>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
I assume this node's reg property is supposed to be filled in by the
bootloader. Best to have an explanatory comment, and/or a template
reg property here.
[snip]
> + soc8572@ef000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "simple-bus";
This compatible value needs a more specific entry for the specific SoC
type.
[snip]
> + /* eTSEC 1 front panel 0 */
> + 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 = "sgmii";
> +
> + mdio@520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,gianfar-mdio";
> + reg = <0x520 0x20>;
> +
> + phy0: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <4 1>;
> + reg = <0x1>;
> + device_type = "ethernet-phy";
Drop this device_type.
> + };
> + phy1: ethernet-phy@2 {
> + interrupt-parent = <&mpic>;
> + interrupts = <4 1>;
> + reg = <0x2>;
> + device_type = "ethernet-phy";
> + };
> + phy2: ethernet-phy@3 {
> + interrupt-parent = <&mpic>;
> + interrupts = <5 1>;
> + reg = <0x3>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@4 {
> + interrupt-parent = <&mpic>;
> + interrupts = <5 1>;
> + reg = <0x4>;
> + device_type = "ethernet-phy";
> + };
> + tbi0: tbi-phy@11 {
> + reg = <0x11>;
> + device_type = "tbi-phy";
> + };
> + };
> + };
> +
> + /* eTSEC 2 front panel 1 */
> + 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 = "sgmii";
> +
> + 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";
> + };
> + };
> + };
> +
> + /* eTSEC 3 PICMG2.16 backplane port 0 */
> + 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 = "sgmii";
> +
> + 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";
And this one, too. Although this node should probably have a
compatible property instead.
[snip]
> + tlu@2f000 {
> + device_type = "tlu";
Drop this device_type also.
> diff --git a/arch/powerpc/boot/dts/xpedite5200.dts b/arch/powerpc/boot/dts/xpedite5200.dts
> new file mode 100644
> index 0000000..15a5883
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/xpedite5200.dts
Analagous comments for the other device trees.
--
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 00/33] My PS3-specific patches for 2.6.31
From: Benjamin Herrenschmidt @ 2009-06-11 1:35 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244683951.4674.5.camel@concordia>
On Thu, 2009-06-11 at 11:32 +1000, Michael Ellerman wrote:
> The way I think of it is that the "merge window" is the time for
> maintainers to merge with Linus.
>
> So if you're sending patches to a maintainer you need to have sent all
> your patches to them _before_ then. So the merge window for you is the
> weeks prior to the "merge window".
Right. But a patch generally needs time to be reviewed, spun several
times, etc... so just the week before the merge window is probably too
late :-)
A good rule is that people should start sending things to the list for
review about one kernel release in advance :-)
Now, -rc4 should generally be the wakeup call. It's when I start
frowning even on bug fixes, and putting together a next branch, at least
normally. I can be flexible but people need to try to play nicely too.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Kumar Gala @ 2009-06-11 1:35 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, netdev, Haiying.Wang
In-Reply-To: <20090603.035132.157926180.davem@davemloft.net>
On Jun 3, 2009, at 5:51 AM, David Miller wrote:
> From: Haiying Wang <Haiying.Wang@freescale.com>
> Date: Tue, 2 Jun 2009 10:04:16 -0400
>
>> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
>
> I couldn't apply this to net-next-2.6 because this DTS
> file being patched doesn't exist there.
>
> Perhaps the powerpc-next tree can suck it in...
I'll pick this one up and send it via the powerpc tree.
- k
^ permalink raw reply
* linux-next: powerpc tree build warning
From: Stephen Rothwell @ 2009-06-11 1:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-next, Paul Mackerras, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
Hi Ben,
Today's linux-next build (powerpc ppc64_defconfig) produced this warning:
arch/powerpc/platforms/Kconfig.cputype:60:warning: defaults for choice values not supported
We appear to have CONFIG_PPC_BOOK3S int two places which is confusing
Kconfig.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
From: Kumar Gala @ 2009-06-11 1:50 UTC (permalink / raw)
To: leon.woestenberg; +Cc: Leon Woestenberg, linux-kernel, linuxppc-dev
In-Reply-To: <4a2a9611.06c8100a.49ae.ffff88e4@mx.google.com>
On Jun 6, 2009, at 11:15 AM, leon.woestenberg@gmail.com wrote:
> The PCIe MSI interrupts are missing from the device tree source, and
> thus were not enabled. This patch adds them.
>
> v2 of the patch fixes inconsistent white space, reported by David
> Gibson.
>
> Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
>
> Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
> Tested-by: Leon Woestenberg <leon@sidebranch.com>
applied to next.
- k
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: Add I2C device mappings in DTS for SBC610
From: Kumar Gala @ 2009-06-11 1:50 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090519094057.11438.12921.stgit@ES-J7S4D2J>
On May 19, 2009, at 4:40 AM, Martyn Welch wrote:
> Mappings for temperature sensors (adt7461 and lm92) are missing from
> the
> SBC610's DTS file.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/boot/dts/gef_sbc610.dts | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Update sdhci nodes per new bindings
From: Kumar Gala @ 2009-06-11 1:51 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090610151926.GA32386@oksana.dev.rtsoft.ru>
On Jun 10, 2009, at 10:19 AM, Anton Vorontsov wrote:
> As of commit 404614728f857d0ac63d29c3a29d0cf392a15598 ("Update FSL
> esdhc binding"), we use "fsl,esdhc" compatible entry as a base
> match. U-Boot will use the same compatible to fixup esdhc nodes.
>
> This patch updates 83xx dts files so that they conform to the new
> bindings.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 2 +-
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8378_mds.dts | 2 +-
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8379_mds.dts | 2 +-
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH 4/4] MPC85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS
From: Kumar Gala @ 2009-06-11 1:51 UTC (permalink / raw)
To: Haiying Wang; +Cc: linuxppc-dev, davem, netdev
In-Reply-To: <1243951456-4685-4-git-send-email-Haiying.Wang@freescale.com>
On Jun 2, 2009, at 9:04 AM, Haiying Wang wrote:
> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts | 63 +++++++++++++++++++++++++
> +++++++++
> 1 files changed, 63 insertions(+), 0 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Kumar Gala @ 2009-06-11 1:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <1242155174-2513-1-git-send-email-wd@denx.de>
On May 12, 2009, at 2:06 PM, Wolfgang Denk wrote:
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
>
> Also introduce aliases for serial[01] and ethernet[01].
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Scott Wood <scottwood@freescale.com>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> I am not really sure what the typical flash size on MPC8272ADS boards
> is. The board I used for testing is marked as "Prototype", so it may
> not be the release configuration. On the other hand, the manual also
> says 8 MB, Vitaly Borduk confirms 8 MB on his board, too, and Scott
> Wood eventually tested only with cuImage which fixes up the localbus
> mappings, thus eventually concealing the issue.
>
> I'm posting this as reference in case the 8 MB should turn out to be
> correct. -- wd
>
> arch/powerpc/boot/dts/mpc8272ads.dts | 19 +++++++++++++------
> 1 files changed, 13 insertions(+), 6 deletions(-)
applied to next.
- k
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11 1:56 UTC (permalink / raw)
To: Stephen Rothwell, netdev, Li Yang
Cc: Sachin P Sant, Linuxppc-dev, Linux-Next, Linux-Kernel,
Balbir Singh
In-Reply-To: <20090611110523.1fd56a41.sfr@canb.auug.org.au>
On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> Hi Subrata,
>
> On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> >
> > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > - ph = of_get_property(np, "tbi-handle", NULL);
> > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
>
> You don't need this cast because of_get_property() returns "void *".
Stephen,
True. But without this gcc complains:
CC [M] drivers/net/ucc_geth.o
drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
from pointer target type
Else gcc just builds fine:
CC [M] drivers/net/ucc_geth.o
This is an just an extra caution to fix both the build and warning
regression(s).
Regards--
Subrata
>
^ permalink raw reply
* Re: [PATCH 00/33] My PS3-specific patches for 2.6.31
From: Michael Ellerman @ 2009-06-11 2:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Gary Thomas
In-Reply-To: <1244684128.5739.30.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
On Thu, 2009-06-11 at 11:35 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-06-11 at 11:32 +1000, Michael Ellerman wrote:
> > The way I think of it is that the "merge window" is the time for
> > maintainers to merge with Linus.
> >
> > So if you're sending patches to a maintainer you need to have sent all
> > your patches to them _before_ then. So the merge window for you is the
> > weeks prior to the "merge window".
>
> Right. But a patch generally needs time to be reviewed, spun several
> times, etc... so just the week before the merge window is probably too
> late :-)
Sure. I mean that's when you should be sending polished code that's
ready to merge. In the same way that the maintainers are sending
polished ready to merge code to Linus during the merge window.
But absolutely, most patches need to be reviewed at least once before
they're ready, which is probably a week at best.
But really people should just be sending patches ASAP, even if they're
not 100% finished, so they get as much exposure as early as possible.
Sitting on patches waiting for the "right time" to send them is the
wrong approach IMHO.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Michael Ellerman @ 2009-06-11 2:03 UTC (permalink / raw)
To: subrata
Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On Thu, 2009-06-11 at 07:26 +0530, Subrata Modak wrote:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > Hi Subrata,
> >
> > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > >
> > > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > - ph = of_get_property(np, "tbi-handle", NULL);
> > > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> >
> > You don't need this cast because of_get_property() returns "void *".
>
> Stephen,
>
> True. But without this gcc complains:
>
> CC [M] drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers from pointer target type
^^^^^^^^^^^
And what does that warning actually mean?
Your cast actually introduces a bug.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH][Resend][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Subrata Modak @ 2009-06-11 2:13 UTC (permalink / raw)
To: michael, netdev, Li Yang, Stephen Rothwell
Cc: Sachin P Sant, Linux-Kernel, Linuxppc-dev, Linux-Next,
Subrata Modak, Balbir Singh
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]
Hi Michael,
>On Thu, 2009-06-11 at 12:03 +1000, Michael Ellerman wrote:
>On Thu, 2009-06-11 at 07:26 +0530, Subrata Modak wrote:
> > On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > > Hi Subrata,
> > >
> > > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > > >
> > > > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > > - ph = of_get_property(np, "tbi-handle", NULL);
> > > > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> > >
> > > You don't need this cast because of_get_property() returns "void *".
> >
> > Stephen,
> >
> > True. But without this gcc complains:
> >
> > CC [M] drivers/net/ucc_geth.o
> > drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> > drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers from pointer target type
> ^^^^^^^^^^^
>
> And what does that warning actually mean?
>
> Your cast actually introduces a bug.
>
Ok fine. Here is a revised patch.
Subject: [PATCH][Resend][BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
Reference(s):
http://lkml.org/lkml/2009/6/4/241,
http://lkml.org/lkml/2009/6/10/338,
Fix the following build error:
drivers/net/ucc_geth.c: In function bucc_geth_probeb:
drivers/net/ucc_geth.c:3822: error: 'ph' undeclared (first use in this function)
drivers/net/ucc_geth.c:3822: error: (Each undeclared identifier is reported only once
drivers/net/ucc_geth.c:3822: error: for each function it appears in.)
drivers/net/ucc_geth.c:3832: error: 'mdio' undeclared (first use in this function)
make[2]: *** [drivers/net/ucc_geth.o] Error 1
Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---
--- linux-2.6.30-rc8/drivers/net/ucc_geth.c.orig 2009-06-10 11:58:39.000000000 -0500
+++ linux-2.6.30-rc8/drivers/net/ucc_geth.c 2009-06-10 20:53:25.000000000 -0500
@@ -3595,6 +3595,8 @@ static const struct net_device_ops ucc_g
static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *match)
{
+ struct device_node *mdio;
+ phandle *ph;
struct device *device = &ofdev->dev;
struct device_node *np = ofdev->node;
struct net_device *dev = NULL;
---
Regards--
Subrata
> cheers
^ permalink raw reply
* Re: [PATCH] Re:[BUILD FAILURE 04/04] Next June 04:PPC64 randconfig [drivers/net/ucc_geth.o]
From: Tony Breeds @ 2009-06-11 2:22 UTC (permalink / raw)
To: Subrata Modak
Cc: Sachin P Sant, Stephen Rothwell, netdev, Linux-Kernel,
Linuxppc-dev, Linux-Next, Li Yang, Balbir Singh
In-Reply-To: <1244685364.6494.14.camel@subratamodak.linux.ibm.com>
On Thu, Jun 11, 2009 at 07:26:04AM +0530, Subrata Modak wrote:
> On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > Hi Subrata,
> >
> > On Wed, 10 Jun 2009 23:13:23 +0530 Subrata Modak <subrata@linux.vnet.ibm.com> wrote:
> > >
> > > /* Find the TBI PHY. If it's not there, we don't support SGMII */
> > > - ph = of_get_property(np, "tbi-handle", NULL);
> > > + ph = (phandle *)of_get_property(np, "tbi-handle", NULL);
> >
> > You don't need this cast because of_get_property() returns "void *".
>
> Stephen,
>
> True. But without this gcc complains:
>
> CC [M] drivers/net/ucc_geth.o
> drivers/net/ucc_geth.c: In function ‘ucc_geth_probe’:
> drivers/net/ucc_geth.c:3824: warning: assignment discards qualifiers
> from pointer target type
>
> Else gcc just builds fine:
>
> CC [M] drivers/net/ucc_geth.o
>
> This is an just an extra caution to fix both the build and warning
> regression(s).
ph needs to be const.
I think the following untested (and hence un-signed-off-by) patch is closer,
however I also think that the whole SGMII setup code could use the various OF
helper functions better :)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index e2f2e91..796253d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3603,6 +3603,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
struct resource res;
struct device_node *phy;
int err, ucc_num, max_speed = 0;
+ const phandle *ph;
const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
@@ -3821,7 +3822,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
/* Find the TBI PHY. If it's not there, we don't support SGMII */
ph = of_get_property(np, "tbi-handle", NULL);
if (ph) {
- struct device_node *tbi = of_find_node_by_phandle(*ph);
+ struct device_node *tbi = of_find_node_by_phandle(*ph), *mdio;
struct of_device *ofdev;
struct mii_bus *bus;
const unsigned int *id;
Yours Tony
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: add nor flash partitions for mpc8569mds
From: Kumar Gala @ 2009-06-11 2:20 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc-dev, Haiying Wang
In-Reply-To: <1243389905.13410.6.camel@kevin>
On May 26, 2009, at 9:05 PM, Kevin Hao wrote:
> Add 4 partitions in nor flash. Also fix nor flash
> bank width bug.
Can you explain this.. I'm trying to understand why you set the bank-
width to 1
- k
>
>
> Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts | 24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/
> boot/dts/mpc8569mds.dts
> index 39c2927..1f98990 100644
> --- a/arch/powerpc/boot/dts/mpc8569mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8569mds.dts
> @@ -70,8 +70,30 @@
> #size-cells = <1>;
> compatible = "cfi-flash";
> reg = <0x0 0x0 0x02000000>;
> - bank-width = <2>;
> + bank-width = <1>;
> device-width = <1>;
> + partition@0 {
> + label = "ramdisk";
> + reg = <0x00000000 0x01c00000>;
> + };
> + partition@1c00000 {
> + label = "kernel";
> + reg = <0x01c00000 0x002e0000>;
> + };
> + partiton@1ee0000 {
> + label = "dtb";
> + reg = <0x01ee0000 0x00020000>;
> + };
> + partition@1f00000 {
> + label = "firmware";
> + reg = <0x01f00000 0x00080000>;
> + read-only;
> + };
> + partition@1f80000 {
> + label = "u-boot";
> + reg = <0x01f80000 0x00080000>;
> + read-only;
> + };
> };
>
> bcsr@1,0 {
> --
> 1.6.0.4.771.gef3b3
^ 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