* Re: [PATCH] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
From: Mark Huth @ 2009-06-25 5:11 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, netdev, Li Yang, David Miller
In-Reply-To: <20090624174557.GA31479@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> Currently the half-duplex operation seems to not work reliably for
> RGMII/GMII PHY interfaces. It takes about 10 minutes to boot NFS
> rootfs using 10/half link, following symptoms were observed:
>
> ucc_geth: QE UCC Gigabit Ethernet Controller
> ucc_geth: UCC1 at 0xe0082000 (irq = 32)
> [...]
> Sending DHCP and RARP requests .
> PHY: mdio@e0082120:07 - Link is Up - 10/Half
> ., OK
So why does the phy think this is a half-duplex network?
> [...]
> Looking up port of RPC 100003/2 on 10.0.0.2
> Looking up port of RPC 100005/1 on 10.0.0.2
> VFS: Mounted root (nfs filesystem) readonly on device 0:13.
> Freeing unused kernel memory: 204k init
> eth0: no IPv6 routers present
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 OK
> nfs: server 10.0.0.2 OK
> nfs: server 10.0.0.2 not responding, still trying
> [... few minutes of OK/not responding flood ...]
>
> The statistic shows that there are indeed some errors:
>
> # ethtool -S eth0 | grep -v ": 0"
> NIC statistics:
> tx-64-frames: 42
> tx-65-127-frames: 9
> tx-128-255-frames: 4768
> rx-64-frames: 41
> rx-65-127-frames: 260
> rx-128-255-frames: 2679
> tx-bytes-ok: 859634
> tx-multicast-frames: 5
> tx-broadcast-frames: 7
> rx-frames: 8333
> rx-bytes-ok: 8039364
> rx-bytes-all: 8039364
> stats-counter-mask: 4294901760
> tx-single-collision: 324
> tx-multiple-collision: 47
> tx-late-collsion: 604
> tx-aborted-frames: 604
The above two counters are the actual errors from a half-duplex ethernet
configuration. The size of the collision domain is limited so that the
collisions from one end will reach the other end within the minimum
frame length wire time. Thus the collision will be detected within the
first 64 bytes of the frame. A late collision indicates a
mis-configured network. The fact that everything seems to work when the
MAC is placed into full-duplex mode hints that the network is really a
full-duplex network.
Otherwise, if the network is really half-duplex, then presence of a
full-duplex node will result in the other nodes seeing CRC/framing
errors on receive, and possibly also late collisions, as the full-duplex
node does not observe the CS or the CD( carrier sense and collision
detect) part of CSMA/CD, because it doesn't care.
Putting a node in full-duplex will always make the nasty collision
related errors go away, but it may not be a proper diagnosis of the problem.
> tx-frames-ok: 4967
> tx-256-511-frames: 3
> tx-512-1023-frames: 79
> tx-1024-1518-frames: 71
> rx-256-511-frames: 37
> rx-512-1023-frames: 73
> rx-1024-1518-frames: 5243
>
> According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
> RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
> that cleared FDX bit is permitted for MII/RMII modes only.
>
> The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
> clearly wrong, and this patch completely cures the problems above.
Not so fast - RGMII and GMII refer to the interface between the MAC and
the PHY. While Gigabit physical links will always be full-duplex, phys
that detect lower operational modes will indicate half-duplex where
needed, and putting the MAC into full-duplex will make other nodes see
errors.
As Andy indicated later, it may be necessary to alter the interface
definition in those cases, depending on the particular hardware.
Forcing full-duplex does not seem to be a general solution.
Mark Huth
MontaVista Software
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/net/ucc_geth.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 464df03..e618cf2 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -1469,12 +1469,16 @@ static void adjust_link(struct net_device *dev)
> if (phydev->link) {
> u32 tempval = in_be32(&ug_regs->maccfg2);
> u32 upsmr = in_be32(&uf_regs->upsmr);
> + phy_interface_t phyi = ugeth->phy_interface;
> +
> /* Now we make sure that we can be in full duplex mode.
> * If not, we operate in half-duplex mode. */
> if (phydev->duplex != ugeth->oldduplex) {
> new_state = 1;
> - if (!(phydev->duplex))
> - tempval &= ~(MACCFG2_FDX);
> + if (!phydev->duplex &&
> + (phyi == PHY_INTERFACE_MODE_MII ||
> + phyi == PHY_INTERFACE_MODE_RMII))
> + tempval &= ~MACCFG2_FDX;
> else
> tempval |= MACCFG2_FDX;
> ugeth->oldduplex = phydev->duplex;
^ permalink raw reply
* [PATCH] powerpc/mpc85xx: Create dts for each core in CAMP mode for P2020DS
From: Yang Shi @ 2009-06-25 2:03 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Create the dts files for each core and splits the devices between
the two cores for P2020DS.
Resource partitioning follows the example set by MPC8572, with a
shared MIPC using protected resources, and with the remaining
resources divided as follows:
core0: memory, L2, i2c, dma1, global-util, eth0, eth1, crypto, pci0,
pci1, usb, spi, sdhci.
core1: L2, dma2, eth2, pci2, msi.
Based on MPC8572DS CAMP dts files.
(commit 361425fc32422c9716fc69e52455b7d44fc02c18)
Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
arch/powerpc/boot/dts/p2020ds_camp_core0.dts | 457 ++++++++++++++++++++++++++
arch/powerpc/boot/dts/p2020ds_camp_core1.dts | 209 ++++++++++++
2 files changed, 666 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds_camp_core0.dts
create mode 100644 arch/powerpc/boot/dts/p2020ds_camp_core1.dts
diff --git a/arch/powerpc/boot/dts/p2020ds_camp_core0.dts b/arch/powerpc/boot/dts/p2020ds_camp_core0.dts
new file mode 100644
index 0000000..5d74a9c
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds_camp_core0.dts
@@ -0,0 +1,457 @@
+/*
+ * P2020 DS Core0 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts file allows core0 to have memory, l2, i2c, dma1, global-util, eth0,
+ * eth1, crypto, usb, spi, sdhci, pci0, pci1.
+ *
+ * Copyright 2009 Wind River Systems Inc.
+ *
+ * Based largely on the P2020DS SMP and MPC8572DS CAMP DTS which are:
+ *
+ * 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", "fsl,MPC8572DS-CAMP";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P2020@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p2020-immr", "simple-bus";
+ ranges = <0x0 0xffe00000 0x100000>;
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,p2020-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,p2020-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ };
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ dfsrr;
+ };
+
+ 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>;
+ 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>;
+ };
+ };
+ };
+
+ 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>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ };
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <0>;
+ };
+
+ spi@7000 {
+ compatible = "fsl,mpc8536-espi", "fsl,espi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7000 0x1000>;
+ interrupts = <59 0x2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ gpio: gpio-controller@f000 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8572-gpio";
+ reg = <0xf000 0x100>;
+ interrupts = <47 0x2>;
+ interrupt-parent = <&mpic>;
+ gpio-controller;
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p2020-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2, 512k
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma";
+ reg = <0x21300 0x4>;
+ ranges = <0x0 0x21100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <20 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <21 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <22 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <23 2>;
+ };
+ };
+
+ usb@22000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-usb2-dr";
+ reg = <0x22000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <28 0x2>;
+ phy_type = "ulpi";
+ };
+
+ sdhci@2e000 {
+ compatible = "fsl,mpc8536-esdhc";
+ reg = <0x2e000 0x1000>;
+ interrupts = <72 0x2>;
+ interrupt-parent = <&mpic>;
+ /* Filled in by U-Boot */
+ clock-frequency = <0>;
+ };
+
+ crypto@30000 {
+ compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
+ "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
+ reg = <0x30000 0x10000>;
+ interrupts = <45 2 58 2>;
+ interrupt-parent = <&mpic>;
+ fsl,num-channels = <4>;
+ fsl,channel-fifo-len = <24>;
+ fsl,exec-units-mask = <0xbfe>;
+ fsl,descriptor-types-mask = <0x3ab0ebf>;
+ };
+
+ mpic: pic@40000 {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ protected-sources = <
+ 31 32 33 26 42 /* eth2 pci2 serial */
+ 76 77 78 79 /* dma2 */
+ 0xe0 0xe1 0xe2 0xe3 /* msi */
+ 0xe4 0xe5 0xe6 0xe7
+ >;
+ };
+
+ global-utilities@e0000 { //global utilities block
+ compatible = "fsl,p2020-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+ };
+
+ pci0: pcie@ffe08000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xffe08000 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0x80000000 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 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 = <0xffe09000 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 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>;
+ };
+ };
+ };
+ };
+
+ };
+};
diff --git a/arch/powerpc/boot/dts/p2020ds_camp_core1.dts b/arch/powerpc/boot/dts/p2020ds_camp_core1.dts
new file mode 100644
index 0000000..231d274
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds_camp_core1.dts
@@ -0,0 +1,209 @@
+/*
+ * P2020 DS Core1 Device Tree Source in CAMP mode.
+ *
+ * In CAMP mode, each core needs to have its own dts. Only mpic and L2 cache
+ * can be shared, all the other devices must be assigned to one core only.
+ * This dts allows core1 to have l2, dma2, eth2, pci2, msi.
+ *
+ * Please note to add "-b 1" for core1's dts compiling.
+ *
+ * Copyright 2009 Wind River Systems Inc.
+ *
+ * Based largely on the P2020DS SMP and MPC8572DS CAMP DTS which are:
+ *
+ * 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", "fsl,MPC8572DS-CAMP";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet2 = &enet2;
+ serial0 = &serial0;
+ pci2 = &pci2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P2020@1{
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ soc@ffe00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p2020-immr", "simple-bus";
+ ranges = <0x0 0xffe00000 0x100000>;
+ bus-frequency = <0>; // Filled out by uboot
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x24520 0x20>;
+
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ reg = <0x2>;
+ };
+ };
+
+ enet2: ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <2>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x26000 0x1000>;
+ ranges = <0x0 0x26000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <31 2 32 2 33 2>;
+ interrupt-parent = <&mpic>;
+ phy-handle = <&phy2>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ serial0: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <0>;
+ };
+
+ dma@c300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,eloplus-dma";
+ reg = <0xc300 0x4>;
+ ranges = <0x0 0xc100 0x200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <76 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <77 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <78 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <79 2>;
+ };
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p2020-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2, 512k
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+
+ mpic: pic@40000 {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x40000 0x40000>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ protected-sources = <
+ 18 16 17 42 45 58 /* MEM ecm L2 serial crypto */
+ 29 30 34 35 36 40 /* enet0 enet1 */
+ 24 25 20 21 22 23 /* pci0 pci1 dma1 */
+ 3 43 59 28 72 /* mdio i2c spi usb */
+ 0x9 0xa /* pci slot */
+ 0x6 0x7 0xe 0x5 /* Audio Legacy SATA */
+ >;
+ };
+
+ 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>;
+ };
+ };
+
+ pci2: pcie@ffe0a000 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xffe0a000 0x1000>;
+ bus-range = <0 255>;
+ ranges = <0x2000000 0x0 0xc0000000 0xc0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 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>;
+ };
+ };
+};
--
1.6.0.4
^ permalink raw reply related
* [PATCH] Add EDAC support for P2020DS
From: Yang Shi @ 2009-06-25 1:39 UTC (permalink / raw)
To: djiang, galak; +Cc: linuxppc-dev, bluesmoke-devel
Based on Kumar's new compatible types patch, add P2020 into
MPC85xx EDAC compatible lists so that EDAC can recognize
P2020 meomry controller and L2 cache controller and export
the relevant fields to sysfs.
EDAC MPC85xx DDR3 support is needed if DDR3 memory stick is
installed on a P2020DS board so that EDAC core can recognize
DDR3 memory type.
Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
(85xx DDR3 EDAC patch is currently in akpm's mm tree)
drivers/edac/mpc85xx_edac.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 7c8c2d7..85575fb 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -646,6 +646,7 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{ .compatible = "fsl,mpc8560-l2-cache-controller", },
{ .compatible = "fsl,mpc8568-l2-cache-controller", },
{ .compatible = "fsl,mpc8572-l2-cache-controller", },
+ { .compatible = "fsl,p2020-l2-cache-controller", },
{},
};
@@ -978,6 +979,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8560-memory-controller", },
{ .compatible = "fsl,mpc8568-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
+ { .compatible = "fsl,p2020-memory-controller", },
{},
};
--
1.6.0.4
^ permalink raw reply related
* [PATCH v2 2/2] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-25 1:02 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Li Yang, Andy Fleming, netdev
It appears that gianfar driver has the same problem with RGMII
half-duplex mode as ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[...]
Sending DHCP requests .
PHY: mdio@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set for RGMII.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/gianfar.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..503b455 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,18 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
+ phy_interface_t phyi = phydev->interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII ||
+ (phyi == PHY_INTERFACE_MODE_GMII &&
+ phydev->speed < 1000)))
+ tempval &= ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
^ permalink raw reply related
* [PATCH v2 1/2] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-25 1:02 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Li Yang, Andy Fleming, netdev
Currently the half-duplex operation seems to not work reliably for
RGMII PHY interfaces. It takes about 10 minutes to boot NFS rootfs
using 10/half link, following symptoms were observed:
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0082000 (irq = 32)
[...]
Sending DHCP and RARP requests .
PHY: mdio@e0082120:07 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:13.
Freeing unused kernel memory: 204k init
eth0: no IPv6 routers present
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
The statistic shows that there are indeed some errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
tx-64-frames: 42
tx-65-127-frames: 9
tx-128-255-frames: 4768
rx-64-frames: 41
rx-65-127-frames: 260
rx-128-255-frames: 2679
tx-bytes-ok: 859634
tx-multicast-frames: 5
tx-broadcast-frames: 7
rx-frames: 8333
rx-bytes-ok: 8039364
rx-bytes-all: 8039364
stats-counter-mask: 4294901760
tx-single-collision: 324
tx-multiple-collision: 47
tx-late-collsion: 604
tx-aborted-frames: 604
tx-frames-ok: 4967
tx-256-511-frames: 3
tx-512-1023-frames: 79
tx-1024-1518-frames: 71
rx-256-511-frames: 37
rx-512-1023-frames: 73
rx-1024-1518-frames: 5243
According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
that cleared FDX bit is permitted for MII/RMII modes only.
The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
clearly wrong, and this patch completely cures the problems above.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 464df03..0c26a59 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1469,12 +1469,18 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = in_be32(&ug_regs->maccfg2);
u32 upsmr = in_be32(&uf_regs->upsmr);
+ phy_interface_t phyi = ugeth->phy_interface;
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != ugeth->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FDX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII ||
+ (phyi == PHY_INTERFACE_MODE_GMII &&
+ phydev->speed < 1000)))
+ tempval &= ~MACCFG2_FDX;
else
tempval |= MACCFG2_FDX;
ugeth->oldduplex = phydev->duplex;
--
1.6.3.1
^ permalink raw reply related
* Re: How the kernel printk works before do console_setup.
From: Benjamin Herrenschmidt @ 2009-06-24 22:56 UTC (permalink / raw)
To: Tim Bird; +Cc: Johnny Hung, linuxppc-dev, linux-kernel, linux-embedded
In-Reply-To: <4A41B3A5.9010807@am.sony.com>
> Before the console is set up, the printk data is formatted
> and put into the kernel log buffer, but not sent to any console.
> Any messages printk'ed before that are buffered but do not
> appear. When the console is initialized, then all buffered
> messages are sent to the console, and subsequent printks cause
> the message to go to the log buffer, but then immediately
> get sent from there to the console.
>
> Under certain conditions you can examine the log buffer of
> a kernel that failed to initialize it's console, after a
> warm reset of the machine, using the firmware memory dump
> command.
On ppc, we have tricks to display things earlier :-)
We can initialize the serial ports way before console_setup() (and we do
in most cases) and we use what we call the "udbg" console until the real
one takes over. The "udbg" console is a very small layer which outputs
via a provided "putc" routine. Platforms can provide their own here, we
have a collection of standard ones for legacy UARTs (it should be
automatically setup in that case by the code in legacy_serial), Apple
ESCCs, etc... We even have compile time options that allow that stuff to
be initialized before start_kernel...
Cheers,
Ben.
> See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot
> for some tips on accessing the log buffer of a previous boot.
>
> Note also, that if the serial console does not come up,
> but the kernel successfully boots, and you can get a network
> login on the machine, you can always print out the kernel log
> buffer messages using 'dmesg' at a user-space shell prompt.
>
> Hope this helps!
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: 85xx Address space query
From: Scott Wood @ 2009-06-24 22:52 UTC (permalink / raw)
To: kernel mailz; +Cc: linuxppc-dev
In-Reply-To: <abe8a1fd0906241046x2e3ee7d5h6a6c0231086a6f0e@mail.gmail.com>
kernel mailz wrote:
> But If the app was running with PID=1, interrupt occurs, kernel code
> gets executed in PID=1, how does the kernel handle this ? and goes
> back to PID=0, since its translations are all in PID=0
PID 0 is special, it's mappings are present regardless of the value of
the PID register.
-Scott
^ permalink raw reply
* Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 21:50 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, netdev, Li Yang, David Miller
In-Reply-To: <20090624213945.GB4163@oksana.dev.rtsoft.ru>
On Thu, Jun 25, 2009 at 01:39:45AM +0400, Anton Vorontsov wrote:
> On Wed, Jun 24, 2009 at 04:25:06PM -0500, Andy Fleming wrote:
> [...]
> >>> My concern is that you will be detecting the GMII interface, and
> >>> disallowing half-duplex, despite the fact that the interface is
> >>> actually
> >>> running at 10 or 100 Mbit.
> >>
> >> Very interesting, though I'm not sure I'm completely following. :-)
> >>
> >> Are you saying that I should do this instead:
> >>
> >> if (!phydev->duplex &&
> >> (phyi == PHY_INTERFACE_MODE_MII ||
> >> phyi == PHY_INTERFACE_MODE_RMII ||
> >> (phyi == PHY_INTERFACE_MODE_GMII &&
> >> phydev->speed < 1000)))
> >> tempval &= ~MACCFG2_FULL_DUPLEX;
> >> else
> >> tempval |= MACCFG2_FULL_DUPLEX;
> >>
> >> i.e. we detected GMII interface initially, but it downgraded
> >> to MII since speed is < 1000, thus we can set half-duplex in MAC?
> >
> > Yeah, I think that works out more correctly.
>
> Cool, thanks.
>
> Do you happen to know how gianfar iface auto-detection works in HW?
> I mean, if we connect 100 Mbs link to the GMII PHY, then
> gfar_get_interface() would return MII, correct?
Stupid me. HW has nothing to do with this. GMII, just as you said,
is just a marker, comes from FSL_GIANFAR_DEV_HAS_GIGABIT flag.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 21:39 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, netdev, Li Yang, David Miller
In-Reply-To: <FFCBF074-5F39-4D0C-A0C3-F488A619C821@freescale.com>
On Wed, Jun 24, 2009 at 04:25:06PM -0500, Andy Fleming wrote:
[...]
>>> My concern is that you will be detecting the GMII interface, and
>>> disallowing half-duplex, despite the fact that the interface is
>>> actually
>>> running at 10 or 100 Mbit.
>>
>> Very interesting, though I'm not sure I'm completely following. :-)
>>
>> Are you saying that I should do this instead:
>>
>> if (!phydev->duplex &&
>> (phyi == PHY_INTERFACE_MODE_MII ||
>> phyi == PHY_INTERFACE_MODE_RMII ||
>> (phyi == PHY_INTERFACE_MODE_GMII &&
>> phydev->speed < 1000)))
>> tempval &= ~MACCFG2_FULL_DUPLEX;
>> else
>> tempval |= MACCFG2_FULL_DUPLEX;
>>
>> i.e. we detected GMII interface initially, but it downgraded
>> to MII since speed is < 1000, thus we can set half-duplex in MAC?
>
> Yeah, I think that works out more correctly.
Cool, thanks.
Do you happen to know how gianfar iface auto-detection works in HW?
I mean, if we connect 100 Mbs link to the GMII PHY, then
gfar_get_interface() would return MII, correct?
If so, then I think I'll also have to change
phy_interface_t phyi = phydev->interface;
to
phy_interface_t phyi = gfar_get_interface(dev);
since phydev->interface may contain outdated information.
Or this can't happen?
> And I suspect that the same is true for UCC
Yup. Much thanks for catching this!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Andy Fleming @ 2009-06-24 21:25 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, netdev, Li Yang, David Miller
In-Reply-To: <20090624211038.GA29555@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
>
>> *Technically*, full
>> duplex is required for GMII, as GMII is used only for gigabit.
>> However,
>> we've been treating the GMII interface type as an indicator that
>> the PHY
>> *has* a GMII connection to the NIC. When gianfar detects the speed
>> is
>> 10/100 it switches to the compatible MII interface via this code,
>> just
>> below:
>>
>> case 100:
>> case 10:
>> tempval =
>> ((tempval & ~(MACCFG2_IF)) |
>> MACCFG2_MII);
>>
>>
>> My concern is that you will be detecting the GMII interface, and
>> disallowing half-duplex, despite the fact that the interface is
>> actually
>> running at 10 or 100 Mbit.
>
> Very interesting, though I'm not sure I'm completely following. :-)
>
> Are you saying that I should do this instead:
>
> if (!phydev->duplex &&
> (phyi == PHY_INTERFACE_MODE_MII ||
> phyi == PHY_INTERFACE_MODE_RMII ||
> (phyi == PHY_INTERFACE_MODE_GMII &&
> phydev->speed < 1000)))
> tempval &= ~MACCFG2_FULL_DUPLEX;
> else
> tempval |= MACCFG2_FULL_DUPLEX;
>
> i.e. we detected GMII interface initially, but it downgraded
> to MII since speed is < 1000, thus we can set half-duplex in MAC?
Yeah, I think that works out more correctly. And I suspect that the
same is true for UCC
Andy
[-- Attachment #2: Type: text/html, Size: 3986 bytes --]
^ permalink raw reply
* Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 21:10 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, netdev, Li Yang, David Miller
In-Reply-To: <ED58F994-6BDC-4496-8445-EA1D984F1379@freescale.com>
On Wed, Jun 24, 2009 at 03:18:59PM -0500, Andy Fleming wrote:
>
> On Jun 24, 2009, at 1:27 PM, Anton Vorontsov wrote:
>
>> It appears that gianfar driver has the same problem[1] that I
>> just fixed for ucc_geth.
>>
>> NFS boot using 10/half link takes about 10 minutes to complete:
>>
>
>>
>> The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
>> I didn't find where documentation forbids clearing Full Duplex bit
>> for non-MII/RMII modes, it's pretty distinct that the bit should be
>> set.
>>
>> It's no wonder though, QE Ethernet and TSEC are pretty similar.
>
>> - if (!(phydev->duplex))
>> - tempval &= ~(MACCFG2_FULL_DUPLEX);
>> + if (!phydev->duplex &&
>> + (phyi == PHY_INTERFACE_MODE_MII ||
>> + phyi == PHY_INTERFACE_MODE_RMII))
>
>
> Hmm....have you tested this on a GMII interface?
Nope, only RGMII.
> *Technically*, full
> duplex is required for GMII, as GMII is used only for gigabit. However,
> we've been treating the GMII interface type as an indicator that the PHY
> *has* a GMII connection to the NIC. When gianfar detects the speed is
> 10/100 it switches to the compatible MII interface via this code, just
> below:
>
> case 100:
> case 10:
> tempval =
> ((tempval & ~(MACCFG2_IF)) |
> MACCFG2_MII);
>
>
> My concern is that you will be detecting the GMII interface, and
> disallowing half-duplex, despite the fact that the interface is actually
> running at 10 or 100 Mbit.
Very interesting, though I'm not sure I'm completely following. :-)
Are you saying that I should do this instead:
if (!phydev->duplex &&
(phyi == PHY_INTERFACE_MODE_MII ||
phyi == PHY_INTERFACE_MODE_RMII ||
(phyi == PHY_INTERFACE_MODE_GMII &&
phydev->speed < 1000)))
tempval &= ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
i.e. we detected GMII interface initially, but it downgraded
to MII since speed is < 1000, thus we can set half-duplex in MAC?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-24 21:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Li Yang, Ira Snyder
In-Reply-To: <B40B03DC-6064-45A3-A1E5-283F16769FFE@kernel.crashing.org>
Kumar Gala wrote:
> On Jun 24, 2009, at 12:56 PM, Dan Williams wrote:
> Lets go ahead w/2.6.31 (if its ok w/you).
>
Ok, I'll take this as an acked-by and send it off.
Thanks,
Dan
^ permalink raw reply
* Re: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Andy Fleming @ 2009-06-24 20:18 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, netdev, Li Yang, David Miller
In-Reply-To: <20090624182734.GA14306@oksana.dev.rtsoft.ru>
On Jun 24, 2009, at 1:27 PM, Anton Vorontsov wrote:
> It appears that gianfar driver has the same problem[1] that I
> just fixed for ucc_geth.
>
> NFS boot using 10/half link takes about 10 minutes to complete:
>
>
> The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
> I didn't find where documentation forbids clearing Full Duplex bit
> for non-MII/RMII modes, it's pretty distinct that the bit should be
> set.
>
> It's no wonder though, QE Ethernet and TSEC are pretty similar.
> - if (!(phydev->duplex))
> - tempval &= ~(MACCFG2_FULL_DUPLEX);
> + if (!phydev->duplex &&
> + (phyi == PHY_INTERFACE_MODE_MII ||
> + phyi == PHY_INTERFACE_MODE_RMII))
Hmm....have you tested this on a GMII interface? *Technically*, full
duplex is required for GMII, as GMII is used only for gigabit.
However, we've been treating the GMII interface type as an indicator
that the PHY *has* a GMII connection to the NIC. When gianfar detects
the speed is 10/100 it switches to the compatible MII interface via
this code, just below:
case 100:
case 10:
tempval =
((tempval & ~(MACCFG2_IF)) |
MACCFG2_MII);
My concern is that you will be detecting the GMII interface, and
disallowing half-duplex, despite the fact that the interface is
actually running at 10 or 100 Mbit.
Andy
^ permalink raw reply
* Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Kumar Gala @ 2009-06-24 19:13 UTC (permalink / raw)
To: Dan Williams; +Cc: linuxppc-dev@ozlabs.org, Li Yang, Ira Snyder
In-Reply-To: <4A4268B7.8060106@intel.com>
On Jun 24, 2009, at 12:56 PM, Dan Williams wrote:
> Dan Williams wrote:
>> Kumar Gala wrote:
>>>>> Kumar, Leo,
>>>>>
>>>>> Can I get your acked-by's for the current state of async_tx.git/
>>>>> next? I
>>>>> just pushed out Ira's latest so it may take a moment to mirror
>>>>> out.
>>>> Acked-by: Li Yang <leoli@freescale.com>
>>>>
>>>> However, the addition of arch/powerpc/include/asm/fsldma.h still
>>>> needs
>>>> the ack from Kumar. It doesn't seem to be a common practice
>>>> though.
>>> hmm, why are we moving fsldma.h?
>> There are now two fsldma.h files.
>> drivers/dma/fsldma.h: no changes, houses the private driver
>> implementation details.
>> arch/powerpc/include/asm/fsldma.h: adds some helper routines and
>> definitions for the DMA_SLAVE capability of the driver. It defines
>> an interface for other drivers to use fsldma to initiate device-to-
>> memory dma. Any drivers that use the interface will depend on
>> CONFIG_FSL_DMA hence placing this public header under arch/powerpc/
>> include.
>
> Kumar? Shall we push this decision off to 2.6.32, I would prefer
> not to as Ira had his initial patches available before the merge
> window opened?
>
> Ira, aside from the pci read multiple patch are there any others
> that are suitable for 2.6.31 if the dma_slave implementation gets
> held back?
Lets go ahead w/2.6.31 (if its ok w/you).
- k
^ permalink raw reply
* [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 18:27 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Li Yang, Andy Fleming, netdev
It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.
NFS boot using 10/half link takes about 10 minutes to complete:
eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
[...]
Sending DHCP requests .
PHY: mdio@e0024520:02 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:11.
Freeing unused kernel memory: 188k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
And just as with ucc_geth, statistic shows errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
rx-dropped-by-kernel: 2
tx-rx-64-frames: 49
tx-rx-65-127-frames: 1270
tx-rx-128-255-frames: 9992
tx-rx-256-511-frames: 75
tx-rx-512-1023-frames: 142
tx-rx-1024-1518-frames: 8828
rx-bytes: 13299414
rx-packets: 13122
rx-jabber-frames: 9
tx-byte-counter: 1284847
tx-packets: 8115
tx-broadcast-packets: 3
tx-deferral-packets: 43
tx-single-collision-packets: 15
tx-multiple-collision-packets: 301
tx-late-collision-packets: 872
tx-total-collision: 999
tx-undersize-frames: 6
The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.
It's no wonder though, QE Ethernet and TSEC are pretty similar.
[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/gianfar.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
+ phy_interface_t phyi = phydev->interface;
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FULL_DUPLEX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII))
+ tempval &= ~MACCFG2_FULL_DUPLEX;
else
tempval |= MACCFG2_FULL_DUPLEX;
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-24 17:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org, Li Yang, Ira Snyder
In-Reply-To: <4A40FB26.8080301@intel.com>
Dan Williams wrote:
> Kumar Gala wrote:
>>>> Kumar, Leo,
>>>>
>>>> Can I get your acked-by's for the current state of async_tx.git/
>>>> next? I
>>>> just pushed out Ira's latest so it may take a moment to mirror out.
>>> Acked-by: Li Yang <leoli@freescale.com>
>>>
>>> However, the addition of arch/powerpc/include/asm/fsldma.h still needs
>>> the ack from Kumar. It doesn't seem to be a common practice though.
>> hmm, why are we moving fsldma.h?
>
> There are now two fsldma.h files.
>
> drivers/dma/fsldma.h: no changes, houses the private driver
> implementation details.
>
> arch/powerpc/include/asm/fsldma.h: adds some helper routines and
> definitions for the DMA_SLAVE capability of the driver. It defines an
> interface for other drivers to use fsldma to initiate device-to-memory
> dma. Any drivers that use the interface will depend on CONFIG_FSL_DMA
> hence placing this public header under arch/powerpc/include.
>
Kumar? Shall we push this decision off to 2.6.32, I would prefer not to
as Ira had his initial patches available before the merge window opened?
Ira, aside from the pci read multiple patch are there any others that
are suitable for 2.6.31 if the dma_slave implementation gets held back?
Thanks,
Dan
^ permalink raw reply
* Re: 85xx Address space query
From: kernel mailz @ 2009-06-24 17:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D47FC871-1535-4DBF-8617-6EEA8C180484@kernel.crashing.org>
On Wed, Jun 24, 2009 at 6:45 PM, Kumar Gala<galak@kernel.crashing.org> wrot=
e:
>
> On Jun 24, 2009, at 4:44 AM, kernel mailz wrote:
>
>> Hi,
>>
>> I am a newbie, trying to learn but have a few queries, nice if you could
>> respond
>> For linux on 85xx systems...
>>
>> (a) Kernel code runs in PR=3D0 AS=3D0 and PID=3D0, which user space appl=
ication
>> run in PR=3D1 AS=3D0 and PID 1-255.
>> Is this correct.
>
> correct.
>
>> (b) I am writing a small program where the application code opens invoke=
s
>> a ioctl call and passes a buffer pointer ( say 0x10000 in user space)
>> Now the driver code is using copy_from_user.
>> How this works internally ?
>>
>> 1. User code executes ioctl
>> 2. interrupt goes to the kernel
>
> On the interrupt the PR changes from 0 -> 1
>
>> 3. ioctl handler in driver gets invoked
>> The buffer pointer still contains 0x10000.
>>
>> How kernel code running in PR=3D0 accesses it and does the copy. I am no=
t
>> able to see a address space switch in the asm code of copy_tofrom_user.
>
> There isn't a address space switch. =A0But address spaces exist at the sa=
me
> time. =A0The user app is given 0..0xc000_0000 and the kernel uses
> 0xc000_0000..0xffff_ffff.
>
Ah Ok, I get it Thanks Kumar
But If the app was running with PID=3D1, interrupt occurs, kernel code
gets executed in PID=3D1, how does the kernel handle this ? and goes
back to PID=3D0, since its translations are all in PID=3D0
> - k
>
^ permalink raw reply
* [PATCH] ucc_geth: Fix half-duplex operation for non-MII/RMII interfaces
From: Anton Vorontsov @ 2009-06-24 17:45 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, Li Yang, netdev
Currently the half-duplex operation seems to not work reliably for
RGMII/GMII PHY interfaces. It takes about 10 minutes to boot NFS
rootfs using 10/half link, following symptoms were observed:
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC1 at 0xe0082000 (irq = 32)
[...]
Sending DHCP and RARP requests .
PHY: mdio@e0082120:07 - Link is Up - 10/Half
., OK
[...]
Looking up port of RPC 100003/2 on 10.0.0.2
Looking up port of RPC 100005/1 on 10.0.0.2
VFS: Mounted root (nfs filesystem) readonly on device 0:13.
Freeing unused kernel memory: 204k init
eth0: no IPv6 routers present
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
[... few minutes of OK/not responding flood ...]
The statistic shows that there are indeed some errors:
# ethtool -S eth0 | grep -v ": 0"
NIC statistics:
tx-64-frames: 42
tx-65-127-frames: 9
tx-128-255-frames: 4768
rx-64-frames: 41
rx-65-127-frames: 260
rx-128-255-frames: 2679
tx-bytes-ok: 859634
tx-multicast-frames: 5
tx-broadcast-frames: 7
rx-frames: 8333
rx-bytes-ok: 8039364
rx-bytes-all: 8039364
stats-counter-mask: 4294901760
tx-single-collision: 324
tx-multiple-collision: 47
tx-late-collsion: 604
tx-aborted-frames: 604
tx-frames-ok: 4967
tx-256-511-frames: 3
tx-512-1023-frames: 79
tx-1024-1518-frames: 71
rx-256-511-frames: 37
rx-512-1023-frames: 73
rx-1024-1518-frames: 5243
According to current QEIWRM (Rev. 2 5/2009), FDX bit can be 0 for
RGMII(10/100) modes, while MPC8568ERM (Rev. C 02/2007) spec says
that cleared FDX bit is permitted for MII/RMII modes only.
The symptoms above were seen on MPC8569E-MDS boards, so QEIWRM is
clearly wrong, and this patch completely cures the problems above.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 464df03..e618cf2 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1469,12 +1469,16 @@ static void adjust_link(struct net_device *dev)
if (phydev->link) {
u32 tempval = in_be32(&ug_regs->maccfg2);
u32 upsmr = in_be32(&uf_regs->upsmr);
+ phy_interface_t phyi = ugeth->phy_interface;
+
/* Now we make sure that we can be in full duplex mode.
* If not, we operate in half-duplex mode. */
if (phydev->duplex != ugeth->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
- tempval &= ~(MACCFG2_FDX);
+ if (!phydev->duplex &&
+ (phyi == PHY_INTERFACE_MODE_MII ||
+ phyi == PHY_INTERFACE_MODE_RMII))
+ tempval &= ~MACCFG2_FDX;
else
tempval |= MACCFG2_FDX;
ugeth->oldduplex = phydev->duplex;
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH] pseries: cpu: Reduce the polling interval in __cpu_up()
From: Joel Schopp @ 2009-06-24 16:39 UTC (permalink / raw)
To: Gautham R Shenoy; +Cc: Nathan Lynch, linuxppc-dev, linux-kernel
In-Reply-To: <20090624092637.32078.88042.stgit@sofia.in.ibm.com>
>
> The code needs testing on other powerpc platforms.
>
I think given the numbers you showed this is a good improvement, and it
clearly can't do any harm on platforms that implement msleep correctly.
For what it's worth:
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
> Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
> ---
> arch/powerpc/kernel/smp.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 65484b2..00c13a1 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -411,9 +411,8 @@ int __cpuinit __cpu_up(unsigned int cpu)
> * CPUs can take much longer to come up in the
> * hotplug case. Wait five seconds.
> */
> - for (c = 25; c && !cpu_callin_map[cpu]; c--) {
> - msleep(200);
> - }
> + for (c = 5000; c && !cpu_callin_map[cpu]; c--)
> + msleep(1);
> #endif
>
> if (!cpu_callin_map[cpu]) {
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH] powerpc/85xx: Fix ethernet link detection on MPC8569E-MDS boards
From: Anton Vorontsov @ 2009-06-24 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Linux isn't able to detect link changes on ethernet ports that were
used by U-Boot. This is because U-Boot wrongly clears interrupt
polarity bit (INTPOL, 0x400) in the extended status register (EXT_SR,
0x1b) of Marvell PHYs.
There is no easy way for PHY drivers to know IRQ line polarity (we
could extract it from the device tree and pass it to phydevs, but
that'll be quite a lot of work), so for now just reset the PHYs to
their default states.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 3268c95..34664c0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -223,6 +223,19 @@ static void __init mpc85xx_mds_setup_arch(void)
/* Turn UCC1 & UCC2 on */
setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+ } else if (machine_is(mpc8569_mds)) {
+#define BCSR7_UCC12_GETHnRST (0x1 << 2)
+#define BCSR8_UEM_MARVELL_RST (0x1 << 1)
+ /*
+ * U-Boot mangles interrupt polarity for Marvell PHYs,
+ * so reset built-in and UEM Marvell PHYs, this puts
+ * the PHYs into their normal state.
+ */
+ clrbits8(&bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ setbits8(&bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
+
+ setbits8(&bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ clrbits8(&bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
}
iounmap(bcsr_regs);
}
--
1.6.3.1
^ permalink raw reply related
* Re: [Question] m25p80 driver versus spi clock rate
From: Steven A. Falco @ 2009-06-24 16:14 UTC (permalink / raw)
To: David Brownell
Cc: linuxppc-dev@ozlabs.org, Stefan Roese, linux-mtd, Mike Frysinger
In-Reply-To: <200906240813.01220.david-b@pacbell.net>
David Brownell wrote:
> On Wednesday 24 June 2009, Steven A. Falco wrote:
>> Your changes to bitbang_work look good.
>
> You tested?
>
Yes - I built a kernel with your patch, combined with the changes I
just posted to linuxppc-dev@ozlabs.org as:
"[PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per-word and 0 speed_hz"
I was successful in operating both the m25p16 at 16 MHz and the AVR
at 240 KHz, as verified by oscilloscope. So my "ack" includes testing.
>
>> I'm not clear on why you first set do_setup = -1 but later
>> use do_setup = 1. Perhaps they should both be "1". Other than that,
>>
>> Acked-by: Steven A. Falco <sfalco@harris.com>
>
> The "-1" is for the init path, "1" for per-transfer overrides;
> this way it avoids some extra calls to set up the bits/speed.
Got it. No further comments. My "ack" stands.
I'll start looking at a revised version of the spi_ppc4xx.c driver,
integrating your comments.
Steve
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: David Brownell @ 2009-06-24 15:13 UTC (permalink / raw)
To: Steven A. Falco
Cc: linuxppc-dev@ozlabs.org, Stefan Roese, linux-mtd, Mike Frysinger
In-Reply-To: <4A423750.8080605@harris.com>
On Wednesday 24 June 2009, Steven A. Falco wrote:
> Your changes to bitbang_work look good.
You tested?
> I'm not clear on why you first set do_setup = -1 but later
> use do_setup = 1. Perhaps they should both be "1". Other than that,
>
> Acked-by: Steven A. Falco <sfalco@harris.com>
The "-1" is for the init path, "1" for per-transfer overrides;
this way it avoids some extra calls to set up the bits/speed.
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: Stefan Roese @ 2009-06-24 14:50 UTC (permalink / raw)
To: Steven A. Falco
Cc: David Brownell, linuxppc-dev@ozlabs.org, linux-mtd,
Mike Frysinger
In-Reply-To: <4A423A0A.2010004@harris.com>
On Wednesday 24 June 2009 16:36:58 Steven A. Falco wrote:
> > I have to admit that I didn't find the time to rework the driver after
> > David's latest review. Frankly, this could take some time since I'm
> > currently busy with other tasks. So it would be great if someone else
> > (Steven?) might pick up here and resubmit this driver so that we can get
> > it finally included.
> >
> > Thanks.
> >
> > Best regards,
> > Stefan
>
> Ok - I'll take that on.
Great, thanks.
> Please, both David and Stefan send me the latest versions
> and/or patches you have, and I'll integrate them and post
> to the PPC list.
I just sent you my latest driver version (v6). Here a link to David's latest
review:
http://article.gmane.org/gmane.linux.ports.ppc64.devel/55229
Best regards,
Stefan
^ permalink raw reply
* Re: [Question] m25p80 driver versus spi clock rate
From: Steven A. Falco @ 2009-06-24 14:36 UTC (permalink / raw)
To: Stefan Roese
Cc: David Brownell, linuxppc-dev@ozlabs.org, linux-mtd,
Mike Frysinger
In-Reply-To: <200906241633.35571.sr@denx.de>
Stefan Roese wrote:
> On Wednesday 24 June 2009 16:25:20 Steven A. Falco wrote:
>>> Speaking of spi_ppc4xx issues ... I still have an oldish
>>> copy in my review queue, it needs something like the
>>> appended patch. (Plus something to accept bpw == 0.)
>>> Is there a newer version?
>> That is a question for Stefan. Perhaps when I post my patch
>> to the PPC list, we can move this further along...
>
> I have to admit that I didn't find the time to rework the driver after David's
> latest review. Frankly, this could take some time since I'm currently busy
> with other tasks. So it would be great if someone else (Steven?) might pick up
> here and resubmit this driver so that we can get it finally included.
>
> Thanks.
>
> Best regards,
> Stefan
Ok - I'll take that on.
Please, both David and Stefan send me the latest versions
and/or patches you have, and I'll integrate them and post
to the PPC list.
Steve
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
^ permalink raw reply
* [PATCH v1] Make spi_ppc4xx.c tolerate 0 bits-per-word and 0 speed_hz
From: Steven A. Falco @ 2009-06-24 14:34 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: David Brownell, Stefan Roese
If a SPI transfer is set up, but does not explicitly set bits-per-word
and speed_hz, then the transaction fails, because spi_ppc4xx_setupxfer
rejects it.
This patch modifies the logic to chose the struct spi_transfer parameters
only if they are non-zero. Otherwise, the struct spi_device parameters
are used.
Additionally, since there is no OF binding for bits-per-word, we have to
tolerate the case where both t->bits_per_word and spi->bits_per_word are
zero.
---
This was brought to light by a pending patch to spi_bitbang, which results
in more calls to spi_ppc4xx_setupxfer.
drivers/spi/spi_ppc4xx.c | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
index e46292b..9775bf2 100644
--- a/drivers/spi/spi_ppc4xx.c
+++ b/drivers/spi/spi_ppc4xx.c
@@ -151,16 +151,24 @@ static int spi_ppc4xx_setupxfer(struct spi_device *spi, struct spi_transfer *t)
/* Write new configration */
out_8(&hw->regs->mode, cs->mode);
+ /* Start with the generic configuration for this device. */
+ bpw = spi->bits_per_word;
+ cs->speed_hz = spi->max_speed_hz;
+
/*
- * Allow platform reduce the interrupt load on the CPU during SPI
- * transfers. We do not target maximum performance, but rather allow
- * platform to limit SPI bus frequency and interrupt rate.
+ * Allow the platform to reduce the interrupt load on the CPU during
+ * SPI transfers. We do not target maximum performance, but rather
+ * allow the platform to limit SPI bus frequency and interrupt rate.
*/
- bpw = t ? t->bits_per_word : spi->bits_per_word;
- cs->speed_hz = t ? min(t->speed_hz, spi->max_speed_hz) :
- spi->max_speed_hz;
+ if(t) {
+ if(t->bits_per_word)
+ bpw = t->bits_per_word;
+
+ if(t->speed_hz)
+ cs->speed_hz = min(t->speed_hz, spi->max_speed_hz);
+ }
- if (bpw != 8) {
+ if (bpw && bpw != 8) {
dev_err(&spi->dev, "invalid bits-per-word (%d)\n", bpw);
return -EINVAL;
}
--
1.6.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox