date:20091222

[PATCH 1/2] Adding PCI-E support for PowerPC 460SX based SOC.

2009-12-22 Thread tmarri

From: Tirumala Marri tma...@amcc.com


Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kerenl:2.6.33-rc1
Testing: This patch has been tested on 460SX based redwood board . One board 
configured as  
root complex and other as Endpoint. Checked for link up . From root complex 
lspci command
shows the end point. Also programmed IO tested using loop back as well as board 
to board.
---
 arch/powerpc/boot/dts/redwood.dts |  122 +
 arch/powerpc/sysdev/ppc4xx_pci.c  |  119 
 arch/powerpc/sysdev/ppc4xx_pci.h  |   58 +
 3 files changed, 299 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
index d2af32e..81636c0 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -234,10 +234,132 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+   };
+   PCIE0: pc...@d {
+   device_type = pci;
+   #interrupt-cells = 1;
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = ibm,plb-pciex-460sx, ibm,plb-pciex;
+   primary;
+   port = 0x0; /* port number */
+   reg = 0x000d 0x 0x2000 /* Config space 
access */
+  0x000c 0x1000 0x1000;   /* 
Registers */
+   dcr-reg = 0x100 0x020;
+   sdr-base = 0x300;
+
+   /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+   ranges = 0x0200 0x 0x8000 0x000e 
0x 0x 0x8000
+ 0x0100 0x 0x 0x000f 
0x8000 0x 0x0001;
+
+   /* Inbound 2GB range starting at 0 */
+   dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000;
 
+   /* This drives busses 10 to 0x1f */
+   bus-range = 0x10 0x1f;
+
+   /* Legacy interrupts (note the weird polarity, the 
bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the numbers are 
actually for
+* port of the root complex virtual P2P bridge. But I 
want
+* to avoid putting a node for it in the tree, so the 
numbers
+* below are basically de-swizzled numbers.
+* The real slot is on idsel 0, so the swizzling is 1:1
+*/
+   interrupt-map-mask = 0x0 0x0 0x0 0x7;
+   interrupt-map = 
+   0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /* swizzled int A 
*/
+   0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /* swizzled int B 
*/
+   0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /* swizzled int C 
*/
+   0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /* swizzled int D 
*/;
+   };
+
+   PCIE1: pc...@d2000 {
+   device_type = pci;
+   #interrupt-cells = 1;
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = ibm,plb-pciex-460sx, ibm,plb-pciex;
+   primary;
+   port = 0x1; /* port number */
+   reg = 0x000d 0x2000 0x2000 /* Config space 
access */
+  0x000c 0x10001000 0x1000;   /* 
Registers */
+   dcr-reg = 0x120 0x020;
+   sdr-base = 0x340;
+
+   /* Outbound ranges, one memory and one IO,
+* later cannot be changed
+*/
+   ranges = 0x0200 0x 0x8000 0x000e 
0x8000 0x 0x8000
+ 0x0100 0x 0x 0x000f 
0x8001 0x 0x0001;
+
+   /* Inbound 2GB range starting at 0 */
+   dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000;
+
+   /* This drives busses 10 to 0x1f */
+   bus-range = 0x20 0x2f;
+
+   /* Legacy interrupts (note the weird polarity, the 
bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the numbers are 
actually for
+* port of the root complex virtual P2P bridge. But I 
want
+* to avoid putting a node for it

[PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

2009-12-22 Thread tmarri

From: Tirumala Marri tma...@amcc.com


Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell Ethernet 
card) 
was plugged into the one of the PCI-E ports. I was able to run the 
traffic
with MSI interrupts. 
---
 arch/powerpc/boot/dts/redwood.dts  |   15 ++
 arch/powerpc/configs/44x/redwood_defconfig |5 +-
 arch/powerpc/platforms/44x/Kconfig |1 +
 arch/powerpc/sysdev/Kconfig|7 +
 arch/powerpc/sysdev/Makefile   |1 +
 arch/powerpc/sysdev/ppc4xx_msi.c   |  335 
 arch/powerpc/sysdev/ppc4xx_msi.h   |   49 
 7 files changed, 411 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /* swizzled int C 
*/
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /* swizzled int D 
*/;
};
+   MSI: ppc4xx-...@40030 {
+   compatible = amcc,ppc4xx-msi, ppc4xx-msi;
+   reg =  0x4 0x0030 0x100
+   0x4 0x0030 0x100;
+   sdr-base = 0x3B0;
+   interrupts =0 1 2 3;
+   interrupt-parent = MSI;
+   #interrupt-cells = 1;
+   #address-cells = 0;
+   #size-cells = 0;
+   interrupt-map = 0 UIC0 0xC 1
+   1 UIC0 0x0D 1
+   2 UIC0 0x0E 1
+   3 UIC0 0x0F 1;
+   };
 
};
 
diff --git a/arch/powerpc/configs/44x/redwood_defconfig 
b/arch/powerpc/configs/44x/redwood_defconfig
index ed31d4f..5d16c88 100644
--- a/arch/powerpc/configs/44x/redwood_defconfig
+++ b/arch/powerpc/configs/44x/redwood_defconfig
@@ -158,6 +158,7 @@ CONFIG_DEFAULT_AS=y
 CONFIG_DEFAULT_IOSCHED=anticipatory
 # CONFIG_FREEZER is not set
 CONFIG_PPC4xx_PCI_EXPRESS=y
+CONFIG_PPC_MSI_BITMAP=y
 
 #
 # Platform support
@@ -264,7 +265,7 @@ CONFIG_PCIEPORTBUS=y
 CONFIG_PCIEAER=y
 # CONFIG_PCIEASPM is not set
 CONFIG_ARCH_SUPPORTS_MSI=y
-# CONFIG_PCI_MSI is not set
+CONFIG_PCI_MSI=y
 # CONFIG_PCI_LEGACY is not set
 # CONFIG_PCI_DEBUG is not set
 # CONFIG_PCI_STUB is not set
@@ -1062,7 +1063,7 @@ CONFIG_PRINT_STACK_DEPTH=64
 # CONFIG_DEBUG_PAGEALLOC is not set
 # CONFIG_CODE_PATCHING_SELFTEST is not set
 # CONFIG_FTR_FIXUP_SELFTEST is not set
-# CONFIG_MSI_BITMAP_SELFTEST is not set
+CONFIG_MSI_BITMAP_SELFTEST=y
 # CONFIG_XMON is not set
 # CONFIG_IRQSTACKS is not set
 # CONFIG_VIRQ_DEBUG is not set
diff --git a/arch/powerpc/platforms/44x/Kconfig 
b/arch/powerpc/platforms/44x/Kconfig
index 7486bff..85b9c33 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -126,6 +126,7 @@ config REDWOOD
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
+   select 4xx_MSI
help
  This option enables support for the AMCC PPC460SX Redwood board.
 
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..32f5a40 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
depends on PCI  4xx
default n
 
+config 4xx_MSI
+   bool
+   depends on PCI_MSI
+   depends on PCI  4xx
+   default n
+
 config PPC_MSI_BITMAP
bool
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+   default y if 4xx_MSI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5642924..d60c33b 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_PPC_I8259)   += i8259.o
 obj-$(CONFIG_IPIC) += ipic.o
 obj-$(CONFIG_4xx)  += uic.o
 obj-$(CONFIG_4xx_SOC)  += ppc4xx_soc.o
+obj-$(CONFIG_4xx_MSI)  += ppc4xx_msi.o
 obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
 obj-$(CONFIG_XILINX_PCI)   += xilinx_pci.o
 obj-$(CONFIG_OF_RTC)   += of_rtc.o
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 000..752da4b
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2009 Applied Micro Circuits corporation,
+ * All rights reserved.
+ *
+ * Author: Feng Kan f...@amcc.com
+ *Tirumala Marri tma...@amcc.com
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as

Re: MPC8313e RDB rev A4 and rev C network throughput

2009-12-22 Thread RONETIX - Asen Dimov


Hi,
I checked the RCW(RCWLR and RCWHR) and they are the same(taken from 
NOR), S3 and S4 switches are the same too.

I will take a look at the priority levels on CSB.

Regards,
Asen

Liu Dave-R63238 wrote:

One possible cause is the two board has different RCW.
So that the freq of core/csb/ Is different. 

  

-Original Message-
From: 
linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org 
[mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlab

s.org] On Behalf Of RONETIX - Asen Dimov
Sent: Tuesday, December 22, 2009 6:28 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: MPC8313e RDB rev A4 and rev C network throughput

Hello all,
I have made some test on network throughput with MPC8313e RDB 
revA4 and revC.
Some have mentioned that CSB(Coherent System Bus) frequency 
or untuned TCP/IP stack, could cause decrease of network throughput.


**Test results

-on MPC8313e RDB revA4 with kernel 2.6.20 and u-boot 1.1.6 
created with

ltib-mpc8313erdb-20070824
iperf -c 172.16.0.1 -l 2m -w 256k -throughput is 510Mbps


-on MPC8313e RDB revA4 with kernel 2.6.23 and u-boot 1.3.0 generated 
with ltib-mpc8313erdb-20081222

iperf -c 172.16.0.1 -l 2m -w 256k
-throughput is 510Mbps


-on MPC8313e RDB revC with kernel 2.6.23 (the same u-boot, kernel and 
rootfs as in rev A4, only dtb file differs)

iperf -c 172.16.0.1 -l 2m -w 256k
-throughput is 360Mbps.


Have someone made such measurements? Any ideas why MPC8313e RDB revC 
gives worser throughput than revA4?


** Notes
*The PC (CPU:Intel(R) Core(TM)2 Duo CPU, E8400 @ 3.00GHz;
 RAM:  2x2G DDR2 @ 800Mhz ;
 NIC: R8168B PCI Express Gigabit Ethernet controller, driver 
8.014.00-NAPI;
 OS: Fedora release 10 (Cambridge) with kernel: 
2.6.27.38-170.2.113.fc10.i686.PAE #1 SMP )

*Commnads to set PC

ethtool -s eth0 autoneg off speed 1000 duplex full
ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 1
echo 131071  /proc/sys/net/core/rmem_max
echo 131071  /proc/sys/net/core/wmem_max
echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_rmem
echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_wmem
iperf -s -l 2m -w 70k


*The MPC8313e RDB(CPU: 333Mhz; CSB: 166Mhz) revA4 and 
revC(using PHY not 
switch)

*Commnads to set a board before using iperf

ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 1
#The PC  lan card is set to advertise 1000Mbps only, so the 
board switches to 1000Mbps too.

echo 131071  /proc/sys/net/core/rmem_max
echo 131071  /proc/sys/net/core/wmem_max
echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_rmem
echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_wmem

Regards,
Asen

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev





___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] of/flattree: use callback to setup initrd from /chosen

2009-12-22 Thread Jeremy Kerr

At present, the fdt code sets the kernel-wide initrd_start and
initrd_end variables when parsing /chosen. On ARM, we only set these
once the bootmem has been reserved.

This change adds an arch callback to setup the initrd from the device
tree:

 void early_init_dt_setup_initrd_arch(unsigned long start,
  unsigned long end);

The arch-specific code can then setup the initrd however it likes.

Compiled on powerpc, with CONFIG_BLK_DEV_INITRD=y and =n.

Signed-off-by: Jeremy Kerr jeremy.k...@canonical.com

---
 arch/microblaze/kernel/prom.c |   10 ++
 arch/powerpc/kernel/prom.c|   10 ++
 drivers/of/fdt.c  |   15 +--
 include/linux/of_fdt.h|   10 ++
 4 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 15853de..4fb5d87 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -101,6 +101,16 @@ void __init early_init_devtree_arch(void)
/* No Microblaze specific code here */
 }
 
+#ifdef CONFIG_BLK_DEV_INITRD
+void __init early_init_dt_setup_initrd_arch(unsigned long start,
+   unsigned long end)
+{
+   initrd_start = (unsigned long)__va(start);
+   initrd_end = (unsigned long)__va(end);
+   initrd_below_start_ok = 1;
+}
+#endif
+
 /***
  *
  * New implementation of the OF find APIs, return a refcounted
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 6fea025..236b02c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -467,6 +467,16 @@ int __init early_init_dt_scan_memory_arch(unsigned long 
node, const char *uname,
 }
 #endif /* CONFIG_PPC_PSERIES */
 
+#ifdef CONFIG_BLK_DEV_INITRD
+void __init early_init_dt_setup_initrd_arch(unsigned long start,
+   unsigned long end)
+{
+   initrd_start = (unsigned long)__va(start);
+   initrd_end = (unsigned long)__va(end);
+   initrd_below_start_ok = 1;
+}
+#endif
+
 void __init early_reserve_mem(void)
 {
u64 base, size;
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 7cb386c..ad0b09a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -398,28 +398,23 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
  */
 void __init early_init_dt_check_for_initrd(unsigned long node)
 {
-   unsigned long len;
+   unsigned long start, end, len;
__be32 *prop;
 
pr_debug(Looking for initrd properties... );
 
prop = of_get_flat_dt_prop(node, linux,initrd-start, len);
if (prop) {
-   initrd_start = (unsigned long)
-   __va(of_read_ulong(prop, len/4));
+   start = of_read_ulong(prop, len/4);
 
prop = of_get_flat_dt_prop(node, linux,initrd-end, len);
if (prop) {
-   initrd_end = (unsigned long)
-   __va(of_read_ulong(prop, len/4));
-   initrd_below_start_ok = 1;
-   } else {
-   initrd_start = 0;
+   end = of_read_ulong(prop, len/4);
+   early_init_dt_setup_initrd_arch(start, end);
}
}
 
-   pr_debug(initrd_start=0x%lx  initrd_end=0x%lx\n,
-initrd_start, initrd_end);
+   pr_debug(initrd_start=0x%lx  initrd_end=0x%lx\n, start, end);
 }
 #else
 inline void early_init_dt_check_for_initrd(unsigned long node)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 77ae0a4..4aba9a6 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -81,6 +81,16 @@ extern void early_reserve_mem(void);
 extern void early_init_devtree_arch(void);
 extern u64 dt_mem_next_cell(int s, __be32 **cellp);
 
+/*
+ * If BLK_DEV_INITRD, the fdt early init code will call this function,
+ * to be provided by the arch code. start and end are specified as
+ * physical addresses.
+ */
+#ifdef CONFIG_BLK_DEV_INITRD
+extern void early_init_dt_setup_initrd_arch(unsigned long start,
+   unsigned long end);
+#endif
+
 /* With CONFIG_HAVE_LMB, we can just use the lmb_ functions to add  allocate
  * memory; otherwise, the arch has to provide its own functions to do this.
  */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of/flattree: use callback to setup initrd from /chosen

2009-12-22 Thread Michael Ellerman

On Tue, 2009-12-22 at 17:39 +0800, Jeremy Kerr wrote:
 At present, the fdt code sets the kernel-wide initrd_start and
 initrd_end variables when parsing /chosen. On ARM, we only set these
 once the bootmem has been reserved.
 
 This change adds an arch callback to setup the initrd from the device
 tree:
 
  void early_init_dt_setup_initrd_arch(unsigned long start,
 unsigned long end);

arch_early_init_dt_setup_initrd() makes more sense to me, but ..

 +#ifdef CONFIG_BLK_DEV_INITRD
 +void __init early_init_dt_setup_initrd_arch(unsigned long start,
 + unsigned long end)
 +{
 + initrd_start = (unsigned long)__va(start);
 + initrd_end = (unsigned long)__va(end);
 + initrd_below_start_ok = 1;
 +}
 +#endif

Given you have two identical implementations why not make that the
default and make it weak, and let ARM override it.

cheers




signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of/flattree: use callback to setup initrd from /chosen

2009-12-22 Thread Jeremy Kerr

Hi Michael,

   void early_init_dt_setup_initrd_arch(unsigned long start,
unsigned long end);
 
 arch_early_init_dt_setup_initrd() makes more sense to me, but ..

foo_arch has been the general convention for arch-specific hooks in 
drivers/of/.

  +#ifdef CONFIG_BLK_DEV_INITRD
  +void __init early_init_dt_setup_initrd_arch(unsigned long start,
  +   unsigned long end)
  +{
  +   initrd_start = (unsigned long)__va(start);
  +   initrd_end = (unsigned long)__va(end);
  +   initrd_below_start_ok = 1;
  +}
  +#endif
 
 Given you have two identical implementations why not make that the
 default and make it weak, and let ARM override it.

Yeah, that would be good too; just been avoiding weak as a potential source of 
magic voodoo complexity. Grant - up to you on this one.

Cheers,


Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] Adding PCI-E support for PowerPC 460SX based SOC.

2009-12-22 Thread Josh Boyer

On Tue, Dec 22, 2009 at 12:49:41AM -0800, tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com


Signed-off-by: Tirumala Marri tma...@amcc.com

Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com

Ben, do you want to take this through your tree or mine?

josh

---
Kerenl:2.6.33-rc1
Testing: This patch has been tested on 460SX based redwood board . One board 
configured as  
root complex and other as Endpoint. Checked for link up . From root complex 
lspci command
shows the end point. Also programmed IO tested using loop back as well as 
board to board.
---
 arch/powerpc/boot/dts/redwood.dts |  122 +
 arch/powerpc/sysdev/ppc4xx_pci.c  |  119 
 arch/powerpc/sysdev/ppc4xx_pci.h  |   58 +
 3 files changed, 299 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
index d2af32e..81636c0 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -234,10 +234,132 @@
   has-inverted-stacr-oc;
   has-new-stacr-staopc;
   };
+  };
+  PCIE0: pc...@d {
+  device_type = pci;
+  #interrupt-cells = 1;
+  #size-cells = 2;
+  #address-cells = 3;
+  compatible = ibm,plb-pciex-460sx, ibm,plb-pciex;
+  primary;
+  port = 0x0; /* port number */
+  reg = 0x000d 0x 0x2000 /* Config space 
access */
+ 0x000c 0x1000 0x1000;   /* 
Registers */
+  dcr-reg = 0x100 0x020;
+  sdr-base = 0x300;
+
+  /* Outbound ranges, one memory and one IO,
+   * later cannot be changed
+   */
+  ranges = 0x0200 0x 0x8000 0x000e 
0x 0x 0x8000
+0x0100 0x 0x 0x000f 
0x8000 0x 0x0001;
+
+  /* Inbound 2GB range starting at 0 */
+  dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000;
 
+  /* This drives busses 10 to 0x1f */
+  bus-range = 0x10 0x1f;
+
+  /* Legacy interrupts (note the weird polarity, the 
bridge seems
+   * to invert PCIe legacy interrupts).
+   * We are de-swizzling here because the numbers are 
actually for
+   * port of the root complex virtual P2P bridge. But I 
want
+   * to avoid putting a node for it in the tree, so the 
numbers
+   * below are basically de-swizzled numbers.
+   * The real slot is on idsel 0, so the swizzling is 1:1
+   */
+  interrupt-map-mask = 0x0 0x0 0x0 0x7;
+  interrupt-map = 
+  0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /* swizzled int A 
*/
+  0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /* swizzled int B 
*/
+  0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /* swizzled int C 
*/
+  0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /* swizzled int D 
*/;
+  };
+
+  PCIE1: pc...@d2000 {
+  device_type = pci;
+  #interrupt-cells = 1;
+  #size-cells = 2;
+  #address-cells = 3;
+  compatible = ibm,plb-pciex-460sx, ibm,plb-pciex;
+  primary;
+  port = 0x1; /* port number */
+  reg = 0x000d 0x2000 0x2000 /* Config space 
access */
+ 0x000c 0x10001000 0x1000;   /* 
Registers */
+  dcr-reg = 0x120 0x020;
+  sdr-base = 0x340;
+
+  /* Outbound ranges, one memory and one IO,
+   * later cannot be changed
+   */
+  ranges = 0x0200 0x 0x8000 0x000e 
0x8000 0x 0x8000
+0x0100 0x 0x 0x000f 
0x8001 0x 0x0001;
+
+  /* Inbound 2GB range starting at 0 */
+  dma-ranges = 0x4200 0x0 0x0 0x0 0x0 0x0 
0x8000;
+
+  /* This drives busses 10 to 0x1f */
+  bus-range = 0x20 0x2f;
+
+  /* Legacy interrupts (note the weird polarity, the 
bridge seems
+   * to invert PCIe legacy interrupts).
+   * We are de-swizzling here because the numbers are 
actually for
+   *

Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

2009-12-22 Thread Josh Boyer

On Tue, Dec 22, 2009 at 12:49:51AM -0800, tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com


Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
   When 460SX configured as root as a end point E1000(Intell Ethernet 
 card) 
   was plugged into the one of the PCI-E ports. I was able to run the 
 traffic
   with MSI interrupts. 
---
 arch/powerpc/boot/dts/redwood.dts  |   15 ++
 arch/powerpc/configs/44x/redwood_defconfig |5 +-
 arch/powerpc/platforms/44x/Kconfig |1 +
 arch/powerpc/sysdev/Kconfig|7 +
 arch/powerpc/sysdev/Makefile   |1 +
 arch/powerpc/sysdev/ppc4xx_msi.c   |  335 
 arch/powerpc/sysdev/ppc4xx_msi.h   |   49 
 7 files changed, 411 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
   0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /* swizzled int C 
 */
   0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /* swizzled int D 
 */;
   };
+  MSI: ppc4xx-...@40030 {
+  compatible = amcc,ppc4xx-msi, ppc4xx-msi;
+  reg =  0x4 0x0030 0x100
+  0x4 0x0030 0x100;
+  sdr-base = 0x3B0;
+  interrupts =0 1 2 3;
+  interrupt-parent = MSI;
+  #interrupt-cells = 1;
+  #address-cells = 0;
+  #size-cells = 0;
+  interrupt-map = 0 UIC0 0xC 1
+  1 UIC0 0x0D 1
+  2 UIC0 0x0E 1
+  3 UIC0 0x0F 1;
+  };
 
   };
 
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..32f5a40 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
   depends on PCI  4xx
   default n
 
+config 4xx_MSI

This should probably be named PPC4xx_MSI, similar to how
PPC4xx_PCI_EXPRESS is named.

+  bool
+  depends on PCI_MSI
+  depends on PCI  4xx
+  default n
+
 config PPC_MSI_BITMAP
   bool
   depends on PCI_MSI
   default y if MPIC
   default y if FSL_PCI
+  default y if 4xx_MSI

diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c 
b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 000..752da4b
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2009 Applied Micro Circuits corporation,
+ * All rights reserved.

Please don't add the 'All rights reserved.' to new files.  It is
inaccurate and confusing given that it's a GPLv2 file.

+ *
+ * Author: Feng Kan f...@amcc.com
+ *   Tirumala Marri tma...@amcc.com
+ * 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; version 2 of the
+ * License.
+ */
+#include linux/irq.h
+#include linux/bootmem.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/of_platform.h
+#include linux/interrupt.h
+#include linux/device.h
+#include asm/prom.h
+#include asm/hw_irq.h
+#include asm/ppc-pci.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+#include ppc4xx_msi.h
+
+
+static struct ppc4xx_msi *ppc4xx_msi;
+
+struct ppc4xx_msi_feature {
+  u32 ppc4xx_pic_ip;
+  u32 msiir_offset;
+};
+
+static int ppc4xx_msi_init_allocator(struct ppc4xx_msi *msi_data)
+{
+  int rc;
+
+  rc = msi_bitmap_alloc(msi_data-bitmap, NR_MSI_IRQS,
+  msi_data-irqhost-of_node);
+  if (rc)
+  return rc;
+  rc = msi_bitmap_reserve_dt_hwirqs(msi_data-bitmap);
+  if (rc  0) {
+  msi_bitmap_free(msi_data-bitmap);
+  return rc;
+  }
+  return 0;
+}
+
+
+static void ppc4xx_msi_cascade(unsigned int irq, struct irq_desc *desc)
+{
+  unsigned int cascade_irq;
+  struct ppc4xx_msi *msi_data = ppc4xx_msi;
+  int msir_index = -1;
+
+  raw_spin_lock(desc-lock);
+  if (desc-chip-mask_ack) {
+  desc-chip-mask_ack(irq);
+  } else {
+  desc-chip-mask(irq);
+  desc-chip-ack(irq);
+  }
+
+  if (unlikely(desc-status  IRQ_INPROGRESS))
+  goto unlock;
+
+  msir_index = (int)desc-handler_data;
+
+  if (msir_index = NR_MSI_IRQS)
+  cascade_irq = NO_IRQ;
+
+  desc-status |= IRQ_INPROGRESS;
+
+  cascade_irq = irq_linear_revmap(msi_data-irqhost, msir_index);
+  if (cascade_irq != NO_IRQ)
+  generic_handle_irq(cascade_irq);
+

Re: [PATCH] of/flattree: use callback to setup initrd from /chosen

2009-12-22 Thread Michael Ellerman

On Tue, 2009-12-22 at 18:54 +0800, Jeremy Kerr wrote:
 Hi Michael,
 
void early_init_dt_setup_initrd_arch(unsigned long start,
   unsigned long end);
  
  arch_early_init_dt_setup_initrd() makes more sense to me, but ..
 
 foo_arch has been the general convention for arch-specific hooks in 
 drivers/of/.

Yuck, doh, guess I should have read those patches before they went in :)

   +#ifdef CONFIG_BLK_DEV_INITRD
   +void __init early_init_dt_setup_initrd_arch(unsigned long start,
   + unsigned long end)
   +{
   + initrd_start = (unsigned long)__va(start);
   + initrd_end = (unsigned long)__va(end);
   + initrd_below_start_ok = 1;
   +}
   +#endif
  
  Given you have two identical implementations why not make that the
  default and make it weak, and let ARM override it.
 
 Yeah, that would be good too; just been avoiding weak as a potential source 
 of 
 magic voodoo complexity. Grant - up to you on this one.

Yeah, depends on what toolchains you're supporting, modern ones should
be OK but it can be troublesome.

cheers




signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 03/31] hvc_console: make the ops pointer const.

2009-12-22 Thread Amit Shah

From: Rusty Russell ru...@rustcorp.com.au

This is nicer for modern R/O protection.  And noone needs it non-const, so
constify the callers as well.

Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amit Shah amit.s...@redhat.com
To: Christian Borntraeger borntrae...@de.ibm.com
Cc: linuxppc-...@ozlabs.org
---
 drivers/char/hvc_beat.c   |2 +-
 drivers/char/hvc_console.c|7 ---
 drivers/char/hvc_console.h|7 ---
 drivers/char/hvc_iseries.c|2 +-
 drivers/char/hvc_iucv.c   |2 +-
 drivers/char/hvc_rtas.c   |2 +-
 drivers/char/hvc_udbg.c   |2 +-
 drivers/char/hvc_vio.c|2 +-
 drivers/char/hvc_xen.c|2 +-
 drivers/char/virtio_console.c |2 +-
 10 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/char/hvc_beat.c b/drivers/char/hvc_beat.c
index 0afc8b8..6913fc3 100644
--- a/drivers/char/hvc_beat.c
+++ b/drivers/char/hvc_beat.c
@@ -84,7 +84,7 @@ static int hvc_beat_put_chars(uint32_t vtermno, const char 
*buf, int cnt)
return cnt;
 }
 
-static struct hv_ops hvc_beat_get_put_ops = {
+static const struct hv_ops hvc_beat_get_put_ops = {
.get_chars = hvc_beat_get_chars,
.put_chars = hvc_beat_put_chars,
 };
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 416d342..d8dac58 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -125,7 +125,7 @@ static struct hvc_struct *hvc_get_by_index(int index)
  * console interfaces but can still be used as a tty device.  This has to be
  * static because kmalloc will not work during early console init.
  */
-static struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
+static const struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
 static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
{[0 ... MAX_NR_HVC_CONSOLES - 1] = -1};
 
@@ -247,7 +247,7 @@ static void destroy_hvc_struct(struct kref *kref)
  * vty adapters do NOT get an hvc_instantiate() callback since they
  * appear after early console init.
  */
-int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops)
+int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops)
 {
struct hvc_struct *hp;
 
@@ -749,7 +749,8 @@ static const struct tty_operations hvc_ops = {
 };
 
 struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
-   struct hv_ops *ops, int outbuf_size)
+  const struct hv_ops *ops,
+  int outbuf_size)
 {
struct hvc_struct *hp;
int i;
diff --git a/drivers/char/hvc_console.h b/drivers/char/hvc_console.h
index 10950ca..52ddf4d 100644
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -55,7 +55,7 @@ struct hvc_struct {
int outbuf_size;
int n_outbuf;
uint32_t vtermno;
-   struct hv_ops *ops;
+   const struct hv_ops *ops;
int irq_requested;
int data;
struct winsize ws;
@@ -76,11 +76,12 @@ struct hv_ops {
 };
 
 /* Register a vterm and a slot index for use as a console (console_init) */
-extern int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops);
+extern int hvc_instantiate(uint32_t vtermno, int index,
+  const struct hv_ops *ops);
 
 /* register a vterm for hvc tty operation (module_init or hotplug add) */
 extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int data,
-   struct hv_ops *ops, int outbuf_size);
+   const struct hv_ops *ops, int outbuf_size);
 /* remove a vterm from hvc tty operation (module_exit or hotplug remove) */
 extern int hvc_remove(struct hvc_struct *hp);
 
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 936d05b..fd02426 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -197,7 +197,7 @@ done:
return sent;
 }
 
-static struct hv_ops hvc_get_put_ops = {
+static const struct hv_ops hvc_get_put_ops = {
.get_chars = get_chars,
.put_chars = put_chars,
.notifier_add = notifier_add_irq,
diff --git a/drivers/char/hvc_iucv.c b/drivers/char/hvc_iucv.c
index fe62bd0..21681a8 100644
--- a/drivers/char/hvc_iucv.c
+++ b/drivers/char/hvc_iucv.c
@@ -922,7 +922,7 @@ static int hvc_iucv_pm_restore_thaw(struct device *dev)
 
 
 /* HVC operations */
-static struct hv_ops hvc_iucv_ops = {
+static const struct hv_ops hvc_iucv_ops = {
.get_chars = hvc_iucv_get_chars,
.put_chars = hvc_iucv_put_chars,
.notifier_add = hvc_iucv_notifier_add,
diff --git a/drivers/char/hvc_rtas.c b/drivers/char/hvc_rtas.c
index 88590d0..61c4a61 100644
--- a/drivers/char/hvc_rtas.c
+++ b/drivers/char/hvc_rtas.c
@@ -71,7 +71,7 @@ static int hvc_rtas_read_console(uint32_t vtermno, char *buf, 
int count)
return i;
 }
 
-static struct hv_ops hvc_rtas_get_put_ops = {
+static const struct hv_ops

[PATCH 04/31] hvc_console: Remove __devinit annotation from hvc_alloc

2009-12-22 Thread Amit Shah

Virtio consoles can be hotplugged, so hvc_alloc gets called from
multiple sites: from the initial probe() routine as well as later on
from workqueue handlers which aren't __devinit code.

So, drop the __devinit annotation for hvc_alloc.

Signed-off-by: Amit Shah amit.s...@redhat.com
Cc: linuxppc-...@ozlabs.org
---
 drivers/char/hvc_console.c |6 +++---
 drivers/char/hvc_console.h |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d8dac58..4c3b59b 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -748,9 +748,9 @@ static const struct tty_operations hvc_ops = {
.chars_in_buffer = hvc_chars_in_buffer,
 };
 
-struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
-  const struct hv_ops *ops,
-  int outbuf_size)
+struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
+const struct hv_ops *ops,
+int outbuf_size)
 {
struct hvc_struct *hp;
int i;
diff --git a/drivers/char/hvc_console.h b/drivers/char/hvc_console.h
index 52ddf4d..54381eb 100644
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -80,8 +80,8 @@ extern int hvc_instantiate(uint32_t vtermno, int index,
   const struct hv_ops *ops);
 
 /* register a vterm for hvc tty operation (module_init or hotplug add) */
-extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int data,
-   const struct hv_ops *ops, int outbuf_size);
+extern struct hvc_struct * hvc_alloc(uint32_t vtermno, int data,
+const struct hv_ops *ops, int outbuf_size);
 /* remove a vterm from hvc tty operation (module_exit or hotplug remove) */
 extern int hvc_remove(struct hvc_struct *hp);
 
-- 
1.6.2.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] Make cpu hotplug driver lock part of ppc_md

2009-12-22 Thread Nathan Fontenot


The recently introduced cpu_hotplug_driver_lock used to serialize
cpu hotplug operations, namely for the pseries platform, causes a build
issue for other platforms.  The base cpu hotplug code attempts
to take this lock, but it may not be needed for all platforms.  This patch
moves the lock/unlock routines to be part of the ppc_md structure
so that platforms needing the lock can take it.  This also makes the
previous cpu_hotplug_driver_lock, defined in pseries code, pseries specific.

The past failure without this patch was seen when building pmac and may
be present in other platform builds.  The error is included below for reference.

drivers/built-in.o: In function `.store_online':
cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
make: *** [.tmp_vmlinux1] Error 1

Signed-of-by: Nathan Fontenot nf...@austin.ibm.com
---
arch/powerpc/include/asm/machdep.h |2 ++
arch/powerpc/kernel/smp.c  |   14 ++
arch/powerpc/platforms/pseries/dlpar.c |6 --
3 files changed, 20 insertions(+), 2 deletions(-)

Index: powerpc/arch/powerpc/include/asm/machdep.h
===
--- powerpc.orig/arch/powerpc/include/asm/machdep.h 2009-12-21 
20:51:49.0 -0600
+++ powerpc/arch/powerpc/include/asm/machdep.h  2009-12-21 21:07:40.0 
-0600
@@ -270,6 +270,8 @@
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
ssize_t (*cpu_probe)(const char *, size_t);
ssize_t (*cpu_release)(const char *, size_t);
+   void (*cpu_hotplug_driver_lock)(void);
+   void (*cpu_hotplug_driver_unlock)(void);
#endif
};

Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
===
--- powerpc.orig/arch/powerpc/platforms/pseries/dlpar.c 2009-12-21 
20:51:49.0 -0600
+++ powerpc/arch/powerpc/platforms/pseries/dlpar.c  2009-12-21 
21:26:23.0 -0600
@@ -346,12 +346,12 @@

static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);

-void cpu_hotplug_driver_lock()
+static void pseries_cpu_hotplug_driver_lock(void)
{
mutex_lock(pseries_cpu_hotplug_mutex);
}

-void cpu_hotplug_driver_unlock()
+static void pseries_cpu_hotplug_driver_unlock(void)
{
mutex_unlock(pseries_cpu_hotplug_mutex);
}
@@ -550,6 +550,8 @@
{
ppc_md.cpu_probe = dlpar_cpu_probe;
ppc_md.cpu_release = dlpar_cpu_release;
+   ppc_md.cpu_hotplug_driver_lock = pseries_cpu_hotplug_driver_lock;
+   ppc_md.cpu_hotplug_driver_unlock = pseries_cpu_hotplug_driver_unlock;

return 0;
}
Index: powerpc/arch/powerpc/kernel/smp.c
===
--- powerpc.orig/arch/powerpc/kernel/smp.c  2009-12-21 20:51:49.0 
-0600
+++ powerpc/arch/powerpc/kernel/smp.c   2009-12-21 21:24:23.0 -0600
@@ -619,4 +619,18 @@
if (smp_ops-cpu_die)
smp_ops-cpu_die(cpu);
}
+
+#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
+void cpu_hotplug_driver_lock(void)
+{
+   if (ppc_md.cpu_hotplug_driver_lock)
+   ppc_md.cpu_hotplug_driver_lock();
+}
+
+void cpu_hotplug_driver_unlock(void)
+{
+   if (ppc_md.cpu_hotplug_driver_unlock)
+   ppc_md.cpu_hotplug_driver_unlock();
+}
#endif
+#endif /* CONFIG_HOTPLUG_CPU */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

I2C bus clock on MPC85XX systems

2009-12-22 Thread Felix Radensky


Hi,

Almost all MPC85XX based systems have the compatible=:fsl-i2c in 
respective
i2c device tree nodes. This causes FSL i2c driver to use the following 
backward

compatible values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
frequency and i2c clock prescaler.

On my custom MPC8536 based board with 432MHz CCB clock this results in
65KHz i2c clock frequency (checked with scope). U-Boot correctly configures
the clock to 400KHz.

I've fixed the problem by modifying device tree to use different 
compatible value,

similar to what socrates board does. Is this the right approach ?

Thanks.

Felix.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: I2C bus clock on MPC85XX systems

2009-12-22 Thread Wolfgang Grandegger

Felix Radensky wrote:
 Hi,
 
 Almost all MPC85XX based systems have the compatible=:fsl-i2c in
 respective
 i2c device tree nodes. This causes FSL i2c driver to use the following
 backward
 compatible values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
 frequency and i2c clock prescaler.
 
 On my custom MPC8536 based board with 432MHz CCB clock this results in
 65KHz i2c clock frequency (checked with scope). U-Boot correctly configures
 the clock to 400KHz.
 
 I've fixed the problem by modifying device tree to use different
 compatible value,
 similar to what socrates board does. Is this the right approach ?

Are you aware of the properties described in
Documentation/powerpc/dts-bindings/fsl/i2c.txt:

http://lxr.linux.no/#linux+v2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt

Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: MPC8313e RDB rev A4 and rev C network throughput

2009-12-22 Thread Liu Dave-R63238

One possible cause is the two board has different RCW.
So that the freq of core/csb/ Is different. 

 -Original Message-
 From: 
 linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org 
 [mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlab
 s.org] On Behalf Of RONETIX - Asen Dimov
 Sent: Tuesday, December 22, 2009 6:28 AM
 To: linuxppc-dev@lists.ozlabs.org
 Subject: MPC8313e RDB rev A4 and rev C network throughput
 
 Hello all,
 I have made some test on network throughput with MPC8313e RDB 
 revA4 and revC.
 Some have mentioned that CSB(Coherent System Bus) frequency 
 or untuned TCP/IP stack, could cause decrease of network throughput.
 
 **Test results
 
 -on MPC8313e RDB revA4 with kernel 2.6.20 and u-boot 1.1.6 
 created with
 ltib-mpc8313erdb-20070824
 iperf -c 172.16.0.1 -l 2m -w 256k -throughput is 510Mbps
 
 
 -on MPC8313e RDB revA4 with kernel 2.6.23 and u-boot 1.3.0 generated 
 with ltib-mpc8313erdb-20081222
 iperf -c 172.16.0.1 -l 2m -w 256k
 -throughput is 510Mbps
 
 
 -on MPC8313e RDB revC with kernel 2.6.23 (the same u-boot, kernel and 
 rootfs as in rev A4, only dtb file differs)
 iperf -c 172.16.0.1 -l 2m -w 256k
 -throughput is 360Mbps.
 
 
 Have someone made such measurements? Any ideas why MPC8313e RDB revC 
 gives worser throughput than revA4?
 
 ** Notes
 *The PC (CPU:Intel(R) Core(TM)2 Duo CPU, E8400 @ 3.00GHz;
  RAM:  2x2G DDR2 @ 800Mhz ;
  NIC: R8168B PCI Express Gigabit Ethernet controller, driver 
 8.014.00-NAPI;
  OS: Fedora release 10 (Cambridge) with kernel: 
 2.6.27.38-170.2.113.fc10.i686.PAE #1 SMP )
 *Commnads to set PC
 
 ethtool -s eth0 autoneg off speed 1000 duplex full
 ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 1
 echo 131071  /proc/sys/net/core/rmem_max
 echo 131071  /proc/sys/net/core/wmem_max
 echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_rmem
 echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_wmem
 iperf -s -l 2m -w 70k
 
 
 *The MPC8313e RDB(CPU: 333Mhz; CSB: 166Mhz) revA4 and 
 revC(using PHY not 
 switch)
 *Commnads to set a board before using iperf
 
 ifconfig eth1 172.16.0.1/12 mtu 6000 txqueuelen 1
 #The PC  lan card is set to advertise 1000Mbps only, so the 
 board switches to 1000Mbps too.
 echo 131071  /proc/sys/net/core/rmem_max
 echo 131071  /proc/sys/net/core/wmem_max
 echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_rmem
 echo 40961048576   8388608  /proc/sys/net/ipv4/tcp_wmem
 
 Regards,
 Asen
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev
 
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

2009-12-22 Thread Tirumala Reddy Marri

Josh,
 Thanks for the comments. I will fix them re-submit it.
Regards,
Marri

-Original Message-
From: Josh Boyer [mailto:jwbo...@gmail.com] On Behalf Of Josh Boyer
Sent: Tuesday, December 22, 2009 4:08 AM
To: Tirumala Reddy Marri
Cc: linuxppc-dev@lists.ozlabs.org; writetoma...@yahoo.com
Subject: Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

On Tue, Dec 22, 2009 at 12:49:51AM -0800, tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com


Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
   When 460SX configured as root as a end point E1000(Intell
Ethernet card) 
   was plugged into the one of the PCI-E ports. I was able to run
the traffic
   with MSI interrupts. 
---
 arch/powerpc/boot/dts/redwood.dts  |   15 ++
 arch/powerpc/configs/44x/redwood_defconfig |5 +-
 arch/powerpc/platforms/44x/Kconfig |1 +
 arch/powerpc/sysdev/Kconfig|7 +
 arch/powerpc/sysdev/Makefile   |1 +
 arch/powerpc/sysdev/ppc4xx_msi.c   |  335

 arch/powerpc/sysdev/ppc4xx_msi.h   |   49 
 7 files changed, 411 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h

diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
   0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /*
swizzled int C */
   0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /*
swizzled int D */;
   };
+  MSI: ppc4xx-...@40030 {
+  compatible = amcc,ppc4xx-msi, ppc4xx-msi;
+  reg =  0x4 0x0030 0x100
+  0x4 0x0030 0x100;
+  sdr-base = 0x3B0;
+  interrupts =0 1 2 3;
+  interrupt-parent = MSI;
+  #interrupt-cells = 1;
+  #address-cells = 0;
+  #size-cells = 0;
+  interrupt-map = 0 UIC0 0xC 1
+  1 UIC0 0x0D 1
+  2 UIC0 0x0E 1
+  3 UIC0 0x0F 1;
+  };
 
   };
 
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..32f5a40 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
   depends on PCI  4xx
   default n
 
+config 4xx_MSI

This should probably be named PPC4xx_MSI, similar to how
PPC4xx_PCI_EXPRESS is named.

+  bool
+  depends on PCI_MSI
+  depends on PCI  4xx
+  default n
+
 config PPC_MSI_BITMAP
   bool
   depends on PCI_MSI
   default y if MPIC
   default y if FSL_PCI
+  default y if 4xx_MSI

diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c
b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 000..752da4b
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2009 Applied Micro Circuits corporation,
+ * All rights reserved.

Please don't add the 'All rights reserved.' to new files.  It is
inaccurate and confusing given that it's a GPLv2 file.

+ *
+ * Author: Feng Kan f...@amcc.com
+ *   Tirumala Marri tma...@amcc.com
+ * 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; version 2 of the
+ * License.
+ */
+#include linux/irq.h
+#include linux/bootmem.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/of_platform.h
+#include linux/interrupt.h
+#include linux/device.h
+#include asm/prom.h
+#include asm/hw_irq.h
+#include asm/ppc-pci.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+#include ppc4xx_msi.h
+
+
+static struct ppc4xx_msi *ppc4xx_msi;
+
+struct ppc4xx_msi_feature {
+  u32 ppc4xx_pic_ip;
+  u32 msiir_offset;
+};
+
+static int ppc4xx_msi_init_allocator(struct ppc4xx_msi *msi_data)
+{
+  int rc;
+
+  rc = msi_bitmap_alloc(msi_data-bitmap, NR_MSI_IRQS,
+  msi_data-irqhost-of_node);
+  if (rc)
+  return rc;
+  rc = msi_bitmap_reserve_dt_hwirqs(msi_data-bitmap);
+  if (rc  0) {
+  msi_bitmap_free(msi_data-bitmap);
+  return rc;
+  }
+  return 0;
+}
+
+
+static void ppc4xx_msi_cascade(unsigned int irq, struct irq_desc
*desc)
+{
+  unsigned int cascade_irq;
+  struct ppc4xx_msi *msi_data = ppc4xx_msi;
+  int msir_index = -1;
+
+  raw_spin_lock(desc-lock);
+  if (desc-chip-mask_ack) {
+  desc-chip-mask_ack(irq);
+  } else {
+  desc-chip-mask(irq);
+  desc-chip-ack(irq);
+  }
+
+  if (unlikely(desc-status

Re: I2C bus clock on MPC85XX systems

2009-12-22 Thread Felix Radensky


Hi, Wolfgang

Wolfgang Grandegger wrote:

Felix Radensky wrote:
  

Hi,

Almost all MPC85XX based systems have the compatible=:fsl-i2c in
respective
i2c device tree nodes. This causes FSL i2c driver to use the following
backward
compatible values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
frequency and i2c clock prescaler.

On my custom MPC8536 based board with 432MHz CCB clock this results in
65KHz i2c clock frequency (checked with scope). U-Boot correctly configures
the clock to 400KHz.

I've fixed the problem by modifying device tree to use different
compatible value,
similar to what socrates board does. Is this the right approach ?



Are you aware of the properties described in
Documentation/powerpc/dts-bindings/fsl/i2c.txt:

http://lxr.linux.no/#linux+v2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt

Wolfgang.

  

Sure, I'm aware of these properties. I've used

compatible = fsl,mpc8543-i2c, fsl-i2c;
clock-frequency = 40;

for my custom board.

I think, however, that device trees for FSL reference designs should use 
them as well, to avoid setting i2c
clock to some strange values. I may be wrong, but I think most custom 
board developers borrow from

reference device trees, so having a sane starting point would help.

Thanks.

Felix.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: I2C bus clock on MPC85XX systems

2009-12-22 Thread Wolfgang Grandegger

Felix Radensky wrote:
 Hi, Wolfgang
 
 Wolfgang Grandegger wrote:
 Felix Radensky wrote:
  
 Hi,

 Almost all MPC85XX based systems have the compatible=:fsl-i2c in
 respective
 i2c device tree nodes. This causes FSL i2c driver to use the following
 backward
 compatible values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
 frequency and i2c clock prescaler.

 On my custom MPC8536 based board with 432MHz CCB clock this results in
 65KHz i2c clock frequency (checked with scope). U-Boot correctly
 configures
 the clock to 400KHz.

 I've fixed the problem by modifying device tree to use different
 compatible value,
 similar to what socrates board does. Is this the right approach ?
 

 Are you aware of the properties described in
 Documentation/powerpc/dts-bindings/fsl/i2c.txt:

 http://lxr.linux.no/#linux+v2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt


 Wolfgang.

   
 Sure, I'm aware of these properties. I've used
 
 compatible = fsl,mpc8543-i2c, fsl-i2c;
 clock-frequency = 40;
 
 for my custom board.
 
 I think, however, that device trees for FSL reference designs should use
 them as well, to avoid setting i2c
 clock to some strange values. I may be wrong, but I think most custom

The FSR=0x31 DFSR=0x10 are not strange values. They have been used in
mainline kernels ( 2.6.30) for a long time.

 board developers borrow from
 reference device trees, so having a sane starting point would help.

The trees provided by Freescale are usually based on older kernel
version. Borrow from such trees is OK, but the project developers should
use a recent kernel version for development.

Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: I2C bus clock on MPC85XX systems

2009-12-22 Thread Felix Radensky


Hi, Wolfgang

Wolfgang Grandegger wrote:

Felix Radensky wrote:
  

Hi, Wolfgang

Wolfgang Grandegger wrote:


Felix Radensky wrote:
 
  

Hi,

Almost all MPC85XX based systems have the compatible=:fsl-i2c in
respective
i2c device tree nodes. This causes FSL i2c driver to use the following
backward
compatible values: FSR=0x31 DFSR=0x10. This is regardless of CCB clock
frequency and i2c clock prescaler.

On my custom MPC8536 based board with 432MHz CCB clock this results in
65KHz i2c clock frequency (checked with scope). U-Boot correctly
configures
the clock to 400KHz.

I've fixed the problem by modifying device tree to use different
compatible value,
similar to what socrates board does. Is this the right approach ?



Are you aware of the properties described in
Documentation/powerpc/dts-bindings/fsl/i2c.txt:

http://lxr.linux.no/#linux+v2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt


Wolfgang.

  
  

Sure, I'm aware of these properties. I've used

compatible = fsl,mpc8543-i2c, fsl-i2c;
clock-frequency = 40;

for my custom board.

I think, however, that device trees for FSL reference designs should use
them as well, to avoid setting i2c
clock to some strange values. I may be wrong, but I think most custom



The FSR=0x31 DFSR=0x10 are not strange values. They have been used in
mainline kernels ( 2.6.30) for a long time.

  

board developers borrow from
reference device trees, so having a sane starting point would help.



The trees provided by Freescale are usually based on older kernel
version. Borrow from such trees is OK, but the project developers should
use a recent kernel version for development.
  


I was talking about modern vanilla kernels for Freescale reference 
boards. See, for example

http://lxr.linux.no/#linux+v2.6.32/arch/powerpc/boot/dts/mpc8536ds.dts

Felix.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: I2C bus clock on MPC85XX systems

2009-12-22 Thread Wolfgang Grandegger

Hi Felix,

Felix Radensky wrote:
 Hi, Wolfgang
 
 Wolfgang Grandegger wrote:
[snip]
 The trees provided by Freescale are usually based on older kernel
 version. Borrow from such trees is OK, but the project developers should
 use a recent kernel version for development.
   
 
 I was talking about modern vanilla kernels for Freescale reference
 boards. See, for example
 http://lxr.linux.no/#linux+v2.6.32/arch/powerpc/boot/dts/mpc8536ds.dts

Only a few boards use these new properties to set a reasonable I2C
clock. But I agree, adding clock-frequency = 10; would make it
more obvious to the users how to define a proper frequency.

Wolfgang.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Does gpio_to_irq() work for MPC52xx gpios?

2009-12-22 Thread Bill Gatliff

Guys:


Is it possible to specify an individual GPIO pin as an interrupt source
with the current MPC52xx code?

I don't see anything in mpc52xx_gpio.c that registers an interrupt
handler, which I think would be a necessary step towards demultiplexing
the GPIO interrupt event.  So I'm thinking that code to allow me to
register an interrupt handler for a specific GPIO pin just isn't there...


b.g.

-- 
Bill Gatliff
b...@billgatliff.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Does gpio_to_irq() work for MPC52xx gpios?

2009-12-22 Thread Peter Korsgaard

 Bill == Bill Gatliff b...@billgatliff.com writes:

 Bill Guys:
 Bill Is it possible to specify an individual GPIO pin as an interrupt source
 Bill with the current MPC52xx code?

No (not yet). In Ben's latest pull request there's a patch from me to
add basic infrastructure for gpio_to_irq(). I've recently added irq
support to the mpc8xxx driver, but so far nothing has been written for
52xx.

http://patchwork.ozlabs.org/patch/41550/

-- 
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] phylib: Fix deadlock on resume

2009-12-22 Thread Anton Vorontsov

Sometimes kernel hangs on resume with the following trace:

 ucc_geth e0102000.ucc: resume
 INFO: task bash:1764 blocked for more than 120 seconds.
 echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
 bash  D 0fecf43c 0  1764   1763 0x
 Call Trace:
 [cf9a7c10] [c0012868] ret_from_except+0x0/0x14 (unreliable)
 --- Exception: cf9a7ce0 at __switch_to+0x4c/0x6c
 LR = 0xcf9a7cc0
 [cf9a7cd0] [c0008c14] __switch_to+0x4c/0x6c (unreliable)
 [cf9a7ce0] [c028bcfc] schedule+0x158/0x260
 [cf9a7d10] [c028c720] __mutex_lock_slowpath+0x80/0xd8
 [cf9a7d40] [c01cf388] phy_stop+0x20/0x70
 [cf9a7d50] [c01d514c] ugeth_resume+0x6c/0x13c
 [...]

Here is why.

On suspend:

- PM core starts suspending devices, ucc_geth_suspend gets called;

- ucc_geth calls phy_stop() on suspend. Note that phy_stop() is
  mostly asynchronous so it doesn't block ucc_geth's suspend routine,
  it just sets PHY_HALTED state and disables PHY's interrupts;

- Suddenly the state machine gets scheduled, it grabs the phydev-lock
  mutex and tries to process the PHY_HALTED state, so it calls
  phydev-adjust_link(phydev-attached_dev). In ucc_geth case
  adjust_link() calls msleep(), which reschedules the code flow back to
  PM core, which now finishes suspend and so we end up sleeping with
  phydev-lock mutex held.

On resume:

- PM core starts resuming devices (notice that nobody rescheduled
  the state machine yet, so the mutex is still held), the core calls
  ucc_geth's resume routine;

- ucc_geth_resume restarts the PHY with phy_stop()/phy_start()
  sequence, and the phy_*() calls are trying to grab the phydev-lock
  mutex. Here comes the deadlock.

This patch fixes the issue by stopping the state machine on suspend
and starting it again on resume.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/net/phy/mdio_bus.c |   24 ++--
 1 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index bd4e8d7..49252d3 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -303,8 +303,18 @@ static int mdio_bus_suspend(struct device * dev, 
pm_message_t state)
struct phy_driver *phydrv = to_phy_driver(dev-driver);
struct phy_device *phydev = to_phy_device(dev);
 
+   /*
+* We must stop the state machine manually, otherwise it stops out of
+* control, possibly with the phydev-lock held. Upon resume, netdev
+* may call phy routines that try to grab the same lock, and that may
+* lead to a deadlock.
+*/
+   if (phydev-attached_dev)
+   phy_stop_machine(phydev);
+
if (!mdio_bus_phy_may_suspend(phydev))
return 0;
+
return phydrv-suspend(phydev);
 }
 
@@ -312,10 +322,20 @@ static int mdio_bus_resume(struct device * dev)
 {
struct phy_driver *phydrv = to_phy_driver(dev-driver);
struct phy_device *phydev = to_phy_device(dev);
+   int ret;
 
if (!mdio_bus_phy_may_suspend(phydev))
-   return 0;
-   return phydrv-resume(phydev);
+   goto no_resume;
+
+   ret = phydrv-resume(phydev);
+   if (ret  0)
+   return ret;
+
+no_resume:
+   if (phydev-attached_dev)
+   phy_start_machine(phydev, NULL);
+
+   return 0;
 }
 
 struct bus_type mdio_bus_type = {
-- 
1.6.3.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/3] phylib: Properly reinitialize PHYs after hibernation

2009-12-22 Thread Anton Vorontsov

Since hibernation assumes power loss, we should fully reinitialize
PHYs (including platform fixups), as if PHYs were just attached.

This patch factors phy_init_hw() out of phy_attach_direct(), then
converts mdio_bus to dev_pm_ops and adds an appropriate restore()
callback.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/net/phy/mdio_bus.c   |   50 --
 drivers/net/phy/phy_device.c |   30 
 include/linux/phy.h  |1 +
 3 files changed, 59 insertions(+), 22 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 49252d3..667fc09 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -295,10 +295,9 @@ static bool mdio_bus_phy_may_suspend(struct phy_device 
*phydev)
return true;
 }
 
-/* Suspend and resume.  Copied from platform_suspend and
- * platform_resume
- */
-static int mdio_bus_suspend(struct device * dev, pm_message_t state)
+#ifdef CONFIG_PM
+
+static int mdio_bus_suspend(struct device *dev)
 {
struct phy_driver *phydrv = to_phy_driver(dev-driver);
struct phy_device *phydev = to_phy_device(dev);
@@ -318,7 +317,7 @@ static int mdio_bus_suspend(struct device * dev, 
pm_message_t state)
return phydrv-suspend(phydev);
 }
 
-static int mdio_bus_resume(struct device * dev)
+static int mdio_bus_resume(struct device *dev)
 {
struct phy_driver *phydrv = to_phy_driver(dev-driver);
struct phy_device *phydev = to_phy_device(dev);
@@ -338,11 +337,48 @@ no_resume:
return 0;
 }
 
+static int mdio_bus_restore(struct device *dev)
+{
+   struct phy_device *phydev = to_phy_device(dev);
+   struct net_device *netdev = phydev-attached_dev;
+   int ret;
+
+   if (!netdev)
+   return 0;
+
+   ret = phy_init_hw(phydev);
+   if (ret  0)
+   return ret;
+
+   /* The PHY needs to renegotiate. */
+   phydev-link = 0;
+   phydev-state = PHY_UP;
+
+   phy_start_machine(phydev, NULL);
+
+   return 0;
+}
+
+static struct dev_pm_ops mdio_bus_pm_ops = {
+   .suspend = mdio_bus_suspend,
+   .resume = mdio_bus_resume,
+   .freeze = mdio_bus_suspend,
+   .thaw = mdio_bus_resume,
+   .restore = mdio_bus_restore,
+};
+
+#define MDIO_BUS_PM_OPS (mdio_bus_pm_ops)
+
+#else
+
+#define MDIO_BUS_PM_OPS NULL
+
+#endif /* CONFIG_PM */
+
 struct bus_type mdio_bus_type = {
.name   = mdio_bus,
.match  = mdio_bus_match,
-   .suspend= mdio_bus_suspend,
-   .resume = mdio_bus_resume,
+   .pm = MDIO_BUS_PM_OPS,
 };
 EXPORT_SYMBOL(mdio_bus_type);
 
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b10fedd..8212b2b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -378,6 +378,20 @@ void phy_disconnect(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(phy_disconnect);
 
+int phy_init_hw(struct phy_device *phydev)
+{
+   int ret;
+
+   if (!phydev-drv || !phydev-drv-config_init)
+   return 0;
+
+   ret = phy_scan_fixups(phydev);
+   if (ret  0)
+   return ret;
+
+   return phydev-drv-config_init(phydev);
+}
+
 /**
  * phy_attach_direct - attach a network device to a given PHY device pointer
  * @dev: network device to attach
@@ -425,21 +439,7 @@ int phy_attach_direct(struct net_device *dev, struct 
phy_device *phydev,
/* Do initial configuration here, now that
 * we have certain key parameters
 * (dev_flags and interface) */
-   if (phydev-drv-config_init) {
-   int err;
-
-   err = phy_scan_fixups(phydev);
-
-   if (err  0)
-   return err;
-
-   err = phydev-drv-config_init(phydev);
-
-   if (err  0)
-   return err;
-   }
-
-   return 0;
+   return phy_init_hw(phydev);
 }
 EXPORT_SYMBOL(phy_attach_direct);
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index b1368b8..7968def 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -447,6 +447,7 @@ struct phy_device* get_phy_device(struct mii_bus *bus, int 
addr);
 int phy_device_register(struct phy_device *phy);
 int phy_clear_interrupt(struct phy_device *phydev);
 int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
+int phy_init_hw(struct phy_device *phydev);
 int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface);
 struct phy_device * phy_attach(struct net_device *dev,
-- 
1.6.3.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3] ucc_geth: Fix netdev watchdog triggering on suspend

2009-12-22 Thread Anton Vorontsov

Sometimes ucc_geth fails to suspend with the following trace:

 ucc_geth e0103000.ucc: suspend
 ucc_geth e0102000.ucc: suspend
 NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
 [ cut here ]
 Badness at net/sched/sch_generic.c:255
 NIP: c021cb5c LR: c021cb5c CTR: c01ab4b4
 [...]
 NIP [c021cb5c] dev_watchdog+0x298/0x2a8
 LR [c021cb5c] dev_watchdog+0x298/0x2a8
 Call Trace:
 [c0389da0] [c021cb5c] dev_watchdog+0x298/0x2a8 (unreliable)
 [c0389e00] [c0031ed8] run_timer_softirq+0x16c/0x1dc
 [c0389e50] [c002c638] __do_softirq+0xa4/0x11c
 [...]

This patch fixes the issue by properly detaching the device on
suspend, and attaching it back on resume.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/net/ucc_geth.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index afaf088..7225d5d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3601,6 +3601,7 @@ static int ucc_geth_suspend(struct of_device *ofdev, 
pm_message_t state)
if (!netif_running(ndev))
return 0;
 
+   netif_device_detach(ndev);
napi_disable(ugeth-napi);
 
/*
@@ -3659,7 +3660,7 @@ static int ucc_geth_resume(struct of_device *ofdev)
phy_start(ugeth-phydev);
 
napi_enable(ugeth-napi);
-   netif_start_queue(ndev);
+   netif_device_attach(ndev);
 
return 0;
 }
-- 
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Make cpu hotplug driver lock part of ppc_md

2009-12-22 Thread Michael Ellerman

On Tue, 2009-12-22 at 08:45 -0600, Nathan Fontenot wrote:
 The recently introduced cpu_hotplug_driver_lock used to serialize
 cpu hotplug operations, namely for the pseries platform, causes a build
 issue for other platforms.  The base cpu hotplug code attempts
 to take this lock, but it may not be needed for all platforms.  This patch
 moves the lock/unlock routines to be part of the ppc_md structure
 so that platforms needing the lock can take it.  This also makes the
 previous cpu_hotplug_driver_lock, defined in pseries code, pseries specific.
 
 The past failure without this patch was seen when building pmac and may
 be present in other platform builds.  The error is included below for 
 reference.
 
 drivers/built-in.o: In function `.store_online':
 cpu.c:(.ref.text+0xf5c): undefined reference to `.cpu_hotplug_driver_lock'
 cpu.c:(.ref.text+0xfc8): undefined reference to `.cpu_hotplug_driver_unlock'
 make: *** [.tmp_vmlinux1] Error 1

Why does the pmac code /not/ need a lock? And would it be harmless if it
was locked too?

If so, you could just make the mutex available to all powerpc code, and
rename it, and then we wouldn't need all this jiggery pokery just to
take  release a lock.

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer

2009-12-22 Thread Masami Hiramatsu

Michael Neuling wrote:
 In message 4b2b934c.1060...@redhat.com you wrote:


 Mahesh Jagannath Salgaonkar wrote:
 Michael Neuling wrote:
 In message 4b29ee5f.9020...@linux.vnet.ibm.com you wrote:
 Hi Michael,

 Michael Neuling wrote:
 + * regs_get_argument_nth() - get Nth argument at function call
 + * @regs:pt_regs which contains registers at function entry.
 + * @n:argument number.
 + *
 + * regs_get_argument_nth() returns @n th argument of a function call.
 + * Since usually the kernel stack will be changed right after
 function en
 try
 ,
 + * you must use this at function entry. If the @n th entry is NOT
 in the
 + * kernel stack or pt_regs, this returns 0.
 + */
 +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned
 int n)
 +{
 +if (n  ARRAY_SIZE(arg_offs_table))
 +return *(unsigned long *)((char *)regs + arg_offs_table[n]);
 +else {
 +/*
 + * If more arguments are passed that can be stored in
 + * registers, the remaining arguments are stored in the
 + * parameter save area located at fixed offset from stack
 + * pointer.
 + * Following the PowerPC ABI, the first few arguments are
 + * actually passed in registers (r3-r10), with equivalent
 space
 + * left unused in the parameter save area.
 + */
 +n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
 +return regs_get_kernel_stack_nth(regs, n);
 How do we handle FP args?
 Currently this patch does not support FP args.

 This might be OK.  I don't think we use floating point parameters in any
 function definitions in the kernel. 
 We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
 they are static inline, so they probably don't even end up as
 functions. 
 I guess we need to make sure that we're not limiting the interface in
 such a way that we can't support it later if the above changes. 
 regs_get_argument_nth returns an unsigned long which makes returning a
 128 bit VMX register impossible.  This might be a show stopper for me.
 How are the x86 guys dealing with this?

 Nope, x86 does not deal with bigger registers (Masami, correct me if I
 am wrong). The return data type is opaque to user. Hence this enables us
 to handle any such situations in future without effecting user space API.

 Right, we don't use those bigger registers in the kernel context.
 (some special functions use it inside, but most of codes
  are just using general regs)
 
 Sure, but kernel interfaces are for now.  What happens if this changes in
 the future?
 
 And regs_get_argument_nth is just an accessor of pt_regs field.
 This means that it just provides field in pt_regs.
 
 Sure, that's how it's implemented, but that's not what the name of the
 function suggests it does.

Hmm, OK, maybe I see what you think.
Actually, this function doesn't cover all functions in the kernel
even on x86, because each ABI depends on how function is defined,
e.g. func(fmt,...) and asmlinkage(i386) function will put all
arguments on the stack.

Originally, I had introduced this function only for helping user
of kprobe-tracer who wants to trace function arguments without
any arch specific knowledge. However, now we have perf-probe which
can analyze debuginfo to find function arguments and local variables.
So, this function is a bit out-of-dated :-)

How about removing this function from this patch? I can also
update kprobe-tracer to drop the function argument support.
Instead of that, I think it is enough to add a description of
how to get function arguments in Documentation/trace/kprobetrace.txt

Thank you,

 
 Mikey
 

 +}
 +}
 +/*
   * does not yet catch signals sent when the child dies.
   * in exit.c or in signal.c.
   */
 Index: linux-2.6-tip/kernel/trace/Kconfig
 ===
 --- linux-2.6-tip.orig/kernel/trace/Kconfig
 +++ linux-2.6-tip/kernel/trace/Kconfig
 @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
  
  config KPROBE_EVENT
  depends on KPROBES
 -depends on X86
 +depends on X86 || PPC
  bool Enable kprobes-based dynamic events
  select TRACING
  default y

 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev

 Thanks for reviewing.

 We are creating a new user space API here, so I'm keen for others to take
 a good look at the interface before we commit to something we are going
 to have to keep forever. 
 Who is the main consumer of this (/me is pretty ignorant of kprobes)?
 What do they think of the interface?

 The user space API are already present in the upstream kernel and
 currently only supported architecture is x86. This patch provides ppc
 architecture specific interfaces that enables powerpc also in par with x86.

 Yes, there is a kprobe tracer in ftrace (see Documentation/trace/kprobetrace.
 txt).
 and this tracer is only for probing

[PATCH 0/3] Build fixes for test-devicetree

2009-12-22 Thread Jeremy Kerr

Hi all,

A small series of patches to fix minor build breakages when compiling
gcl's test-devicetree tree on ARM.

I've CC-ed lkml  linuxppc-dev for the fs/proc/ changes, but these
patches are only applicable to gcl's tree at present.

Cheers,


Jeremy

---
Jeremy Kerr (3):
  of: include linux/proc_fs.h
  of: make set_node_proc_entry private to proc_devtree.c
  proc_devtree: include linux/of.h

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] of: include linux/proc_fs.h

2009-12-22 Thread Jeremy Kerr

We use a few procfs-specific functions (eg, proc_device_tree_*) which
aren't covered by the current includes. This causes the following build
error on arm:

drivers/of/base.c: In function 'prom_add_property':
drivers/of/base.c:861: error: implicit declaration of function 
'proc_device_tree_add_prop'
drivers/of/base.c: In function 'prom_remove_property':
drivers/of/base.c:902: error: implicit declaration of function 
'proc_device_tree_remove_prop'
drivers/of/base.c: In function 'prom_update_property':
drivers/of/base.c:946: error: implicit declaration of function 
'proc_device_tree_update_prop'

Add proc_fs.h for these prototypes.

Signed-off-by: Jeremy Kerr jeremy.k...@canonical.com

---
 drivers/of/base.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 974f64e..2dcb7a3 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -20,6 +20,7 @@
 #include linux/module.h
 #include linux/of.h
 #include linux/spinlock.h
+#include linux/proc_fs.h
 
 struct device_node *allnodes;
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/3] of: make set_node_proc_entry private to proc_devtree.c

2009-12-22 Thread Jeremy Kerr

We only need set_node_proc_entry in proc_devtree.c, so move it there.

This fixes the !HAVE_ARCH_DEVTREE_FIXUPS build, as we can't make make
the definition in linux/of.h conditional on this #define (definitions in
asm/prom.h can't be exposed to linux/of.h, due to the enforced #include
ordering).

Signed-off-by: Jeremy Kerr jeremy.k...@canonical.com

---
 fs/proc/proc_devtree.c |5 +++--
 include/linux/of.h |6 --
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
index 7ba79a5..31fc7e0 100644
--- a/fs/proc/proc_devtree.c
+++ b/fs/proc/proc_devtree.c
@@ -13,12 +13,13 @@
 #include asm/uaccess.h
 #include internal.h
 
-#ifndef HAVE_ARCH_DEVTREE_FIXUPS
 static inline void set_node_proc_entry(struct device_node *np,
   struct proc_dir_entry *de)
 {
-}
+#ifdef HAVE_ARCH_DEVTREE_FIXUPS
+   np-pde = de;
 #endif
+}
 
 static struct proc_dir_entry *proc_device_tree;
 
diff --git a/include/linux/of.h b/include/linux/of.h
index 67c9206..9078747 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -75,12 +75,6 @@ static inline void of_node_set_flag(struct device_node *n, 
unsigned long flag)
set_bit(flag, n-_flags);
 }
 
-static inline void
-set_node_proc_entry(struct device_node *dn, struct proc_dir_entry *de)
-{
-   dn-pde = de;
-}
-
 extern struct device_node *of_find_all_nodes(struct device_node *prev);
 
 #if defined(CONFIG_SPARC)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3] proc_devtree: include linux/of.h

2009-12-22 Thread Jeremy Kerr

Currenly, proc_devtree.c depends on asm/prom.h to include linux/of.h, to
provide some device-tree definitions (eg, struct property).

Instead, include linux/of.h directly. We still need asm/prom.h for
HAVE_ARCH_DEVTREE_FIXUPS.

Signed-off-by: Jeremy Kerr jeremy.k...@canonical.com

---
 fs/proc/proc_devtree.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
index 31fc7e0..2ea10dd 100644
--- a/fs/proc/proc_devtree.c
+++ b/fs/proc/proc_devtree.c
@@ -9,6 +9,7 @@
 #include linux/proc_fs.h
 #include linux/stat.h
 #include linux/string.h
+#include linux/of.h
 #include asm/prom.h
 #include asm/uaccess.h
 #include internal.h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer

2009-12-22 Thread Michael Neuling



In message 4b317324.3000...@redhat.com you wrote:
 Michael Neuling wrote:
  In message 4b2b934c.1060...@redhat.com you wrote:
 
 
  Mahesh Jagannath Salgaonkar wrote:
  Michael Neuling wrote:
  In message 4b29ee5f.9020...@linux.vnet.ibm.com you wrote:
  Hi Michael,
 
  Michael Neuling wrote:
  + * regs_get_argument_nth() - get Nth argument at function call
  + * @regs:pt_regs which contains registers at function entry.
  + * @n:argument number.
  + *
  + * regs_get_argument_nth() returns @n th argument of a function call
.
  + * Since usually the kernel stack will be changed right after
  function en
  try
  ,
  + * you must use this at function entry. If the @n th entry is NOT
  in the
  + * kernel stack or pt_regs, this returns 0.
  + */
  +unsigned long regs_get_argument_nth(struct pt_regs *regs, unsigned
  int n)
  +{
  +if (n  ARRAY_SIZE(arg_offs_table))
  +return *(unsigned long *)((char *)regs + arg_offs_table[n]);
  +else {
  +/*
  + * If more arguments are passed that can be stored in
  + * registers, the remaining arguments are stored in the
  + * parameter save area located at fixed offset from stack
  + * pointer.
  + * Following the PowerPC ABI, the first few arguments are
  + * actually passed in registers (r3-r10), with equivalent
  space
  + * left unused in the parameter save area.
  + */
  +n += (PARAMETER_SAVE_AREA_OFFSET / sizeof(unsigned long));
  +return regs_get_kernel_stack_nth(regs, n);
  How do we handle FP args?
  Currently this patch does not support FP args.
 
  This might be OK.  I don't think we use floating point parameters in any
  function definitions in the kernel. 
  We do use altivec in the raid6 driver (drivers/md/raid6altivec.uc) but
  they are static inline, so they probably don't even end up as
  functions. 
  I guess we need to make sure that we're not limiting the interface in
  such a way that we can't support it later if the above changes. 
  regs_get_argument_nth returns an unsigned long which makes returning a
  128 bit VMX register impossible.  This might be a show stopper for me.
  How are the x86 guys dealing with this?
 
  Nope, x86 does not deal with bigger registers (Masami, correct me if I
  am wrong). The return data type is opaque to user. Hence this enables us
  to handle any such situations in future without effecting user space API.
 
  Right, we don't use those bigger registers in the kernel context.
  (some special functions use it inside, but most of codes
   are just using general regs)
  
  Sure, but kernel interfaces are for now.  What happens if this changes in
  the future?
  
  And regs_get_argument_nth is just an accessor of pt_regs field.
  This means that it just provides field in pt_regs.
  
  Sure, that's how it's implemented, but that's not what the name of the
  function suggests it does.
 
 Hmm, OK, maybe I see what you think.
 Actually, this function doesn't cover all functions in the kernel
 even on x86, because each ABI depends on how function is defined,
 e.g. func(fmt,...) and asmlinkage(i386) function will put all
 arguments on the stack.
 
 Originally, I had introduced this function only for helping user
 of kprobe-tracer who wants to trace function arguments without
 any arch specific knowledge. However, now we have perf-probe which
 can analyze debuginfo to find function arguments and local variables.
 So, this function is a bit out-of-dated :-)
 
 How about removing this function from this patch? I can also
 update kprobe-tracer to drop the function argument support.
 Instead of that, I think it is enough to add a description of
 how to get function arguments in Documentation/trace/kprobetrace.txt

Sounds like a better solution to me.  

Cheers,
Mikey

 Thank you,
 
  
  Mikey
  
 
  +}
  +}
  +/*
* does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
*/
  Index: linux-2.6-tip/kernel/trace/Kconfig
  ===
  --- linux-2.6-tip.orig/kernel/trace/Kconfig
  +++ linux-2.6-tip/kernel/trace/Kconfig
  @@ -464,7 +464,7 @@ config BLK_DEV_IO_TRACE
   
   config KPROBE_EVENT
   depends on KPROBES
  -depends on X86
  +depends on X86 || PPC
   bool Enable kprobes-based dynamic events
   select TRACING
   default y
 
  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@lists.ozlabs.org
  https://lists.ozlabs.org/listinfo/linuxppc-dev
 
  Thanks for reviewing.
 
  We are creating a new user space API here, so I'm keen for others to tak
e
  a good look at the interface before we commit to something we are going
  to have to keep forever. 
  Who is the main consumer of this (/me is pretty ignorant of kprobes)?
  What do they think of the interface?
 
  The user space API are already present in the upstream kernel and
  currently only supported architecture

[PATCH] viodasd.c: Remove VIOD_KERN_level macros for printks

2009-12-22 Thread Joe Perches

Use #define pr_fmt(fmt) viod:  fmt
Remove #define VIOD_KERN_WARNING and VIOD_KERN_INFO
Convert printk(VIOD_KERN_level to pr_level
Coalesce long format strings

Signed-off-by: Joe Perches j...@perches.com
Acked-by: Stephen Rothwell s...@canb.auug.org.au

 drivers/block/viodasd.c |   86 +++---
 1 files changed, 36 insertions(+), 50 deletions(-)

diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c
index a8c8b56..1b3def1 100644
--- a/drivers/block/viodasd.c
+++ b/drivers/block/viodasd.c
@@ -28,6 +28,9 @@
  * All disk operations are performed by sending messages back and forth to
  * the OS/400 partition.
  */
+
+#define pr_fmt(fmt) viod:  fmt
+
 #include linux/major.h
 #include linux/fs.h
 #include linux/module.h
@@ -63,9 +66,6 @@ MODULE_LICENSE(GPL);
 
 #define VIOD_VERS  1.64
 
-#define VIOD_KERN_WARNING  KERN_WARNING viod: 
-#define VIOD_KERN_INFO KERN_INFO viod: 
-
 enum {
PARTITION_SHIFT = 3,
MAX_DISKNO = HVMAXARCHITECTEDVIRTUALDISKS,
@@ -156,7 +156,7 @@ static int viodasd_open(struct block_device *bdev, fmode_t 
mode)
((u64)DEVICE_NO(d)  48) | ((u64)flags  32),
0, 0, 0);
if (hvrc != 0) {
-   printk(VIOD_KERN_WARNING HV open failed %d\n, (int)hvrc);
+   pr_warning(HV open failed %d\n, (int)hvrc);
return -EIO;
}
 
@@ -167,9 +167,8 @@ static int viodasd_open(struct block_device *bdev, fmode_t 
mode)
const struct vio_error_entry *err =
vio_lookup_rc(viodasd_err_table, we.sub_result);
 
-   printk(VIOD_KERN_WARNING
-   bad rc opening disk: %d:0x%04x (%s)\n,
-   (int)we.rc, we.sub_result, err-msg);
+   pr_warning(bad rc opening disk: %d:0x%04x (%s)\n,
+  (int)we.rc, we.sub_result, err-msg);
return -EIO;
}
 
@@ -195,8 +194,7 @@ static int viodasd_release(struct gendisk *disk, fmode_t 
mode)
((u64)DEVICE_NO(d)  48) /* | ((u64)flags  32) */,
0, 0, 0);
if (hvrc != 0)
-   printk(VIOD_KERN_WARNING HV close call failed %d\n,
-   (int)hvrc);
+   pr_warning(HV close call failed %d\n, (int)hvrc);
return 0;
 }
 
@@ -288,8 +286,7 @@ static int send_request(struct request *req)
bevent = (struct vioblocklpevent *)
vio_get_event_buffer(viomajorsubtype_blockio);
if (bevent == NULL) {
-   printk(VIOD_KERN_WARNING
-  error allocating disk event buffer\n);
+   pr_warning(error allocating disk event buffer\n);
goto error_ret;
}
 
@@ -333,9 +330,8 @@ static int send_request(struct request *req)
}
 
if (hvrc != HvLpEvent_Rc_Good) {
-   printk(VIOD_KERN_WARNING
-  error sending disk event to OS/400 (rc %d)\n,
-  (int)hvrc);
+   pr_warning(error sending disk event to OS/400 (rc %d)\n,
+  (int)hvrc);
goto error_ret;
}
spin_unlock_irqrestore(viodasd_spinlock, flags);
@@ -402,7 +398,7 @@ retry:
((u64)dev_no  48) | ((u64)flags 32),
0, 0, 0);
if (hvrc != 0) {
-   printk(VIOD_KERN_WARNING bad rc on HV open %d\n, (int)hvrc);
+   pr_warning(bad rc on HV open %d\n, (int)hvrc);
return 0;
}
 
@@ -416,9 +412,8 @@ retry:
goto retry;
}
if (we.max_disk  (MAX_DISKNO - 1)) {
-   printk_once(VIOD_KERN_INFO
-   Only examining the first %d of %d disks connected\n,
-   MAX_DISKNO, we.max_disk + 1);
+   printk_once(KERN_INFO pr_fmt(Only examining the first %d of %d 
disks connected\n),
+   MAX_DISKNO, we.max_disk + 1);
}
 
/* Send the close event to OS/400.  We DON'T expect a response */
@@ -432,17 +427,15 @@ retry:
((u64)dev_no  48) | ((u64)flags  32),
0, 0, 0);
if (hvrc != 0) {
-   printk(VIOD_KERN_WARNING
-  bad rc sending event to OS/400 %d\n, (int)hvrc);
+   pr_warning(bad rc sending event to OS/400 %d\n, (int)hvrc);
return 0;
}
 
if (d-dev == NULL) {
/* this is when we reprobe for new disks */
if (vio_create_viodasd(dev_no) == NULL) {
-   printk(VIOD_KERN_WARNING
-   cannot allocate virtual device for disk %d\n,
-   dev_no);
+   pr_warning(cannot allocate virtual device for disk 
%d\n,
+

[PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

2009-12-22 Thread tmarri

From: Tirumala Marri tma...@amcc.com

Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run the 
traffic
with MSI interrupts.
---
 arch/powerpc/boot/dts/redwood.dts  |   15 ++
 arch/powerpc/configs/44x/redwood_defconfig |5 +-
 arch/powerpc/platforms/44x/Kconfig |1 +
 arch/powerpc/sysdev/Kconfig|7 +
 arch/powerpc/sysdev/Makefile   |1 +
 arch/powerpc/sysdev/ppc4xx_msi.c   |  342 
 arch/powerpc/sysdev/ppc4xx_msi.h   |   39 
 7 files changed, 408 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
 create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /* swizzled int C 
*/
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /* swizzled int D 
*/;
};
+   MSI: ppc4xx-...@40030 {
+   compatible = amcc,ppc4xx-msi, ppc4xx-msi;
+   reg =  0x4 0x0030 0x100
+   0x4 0x0030 0x100;
+   sdr-base = 0x3B0;
+   interrupts =0 1 2 3;
+   interrupt-parent = MSI;
+   #interrupt-cells = 1;
+   #address-cells = 0;
+   #size-cells = 0;
+   interrupt-map = 0 UIC0 0xC 1
+   1 UIC0 0x0D 1
+   2 UIC0 0x0E 1
+   3 UIC0 0x0F 1;
+   };
 
};
 
diff --git a/arch/powerpc/configs/44x/redwood_defconfig 
b/arch/powerpc/configs/44x/redwood_defconfig
index ed31d4f..5d16c88 100644
--- a/arch/powerpc/configs/44x/redwood_defconfig
+++ b/arch/powerpc/configs/44x/redwood_defconfig
@@ -158,6 +158,7 @@ CONFIG_DEFAULT_AS=y
 CONFIG_DEFAULT_IOSCHED=anticipatory
 # CONFIG_FREEZER is not set
 CONFIG_PPC4xx_PCI_EXPRESS=y
+CONFIG_PPC_MSI_BITMAP=y
 
 #
 # Platform support
@@ -264,7 +265,7 @@ CONFIG_PCIEPORTBUS=y
 CONFIG_PCIEAER=y
 # CONFIG_PCIEASPM is not set
 CONFIG_ARCH_SUPPORTS_MSI=y
-# CONFIG_PCI_MSI is not set
+CONFIG_PCI_MSI=y
 # CONFIG_PCI_LEGACY is not set
 # CONFIG_PCI_DEBUG is not set
 # CONFIG_PCI_STUB is not set
@@ -1062,7 +1063,7 @@ CONFIG_PRINT_STACK_DEPTH=64
 # CONFIG_DEBUG_PAGEALLOC is not set
 # CONFIG_CODE_PATCHING_SELFTEST is not set
 # CONFIG_FTR_FIXUP_SELFTEST is not set
-# CONFIG_MSI_BITMAP_SELFTEST is not set
+CONFIG_MSI_BITMAP_SELFTEST=y
 # CONFIG_XMON is not set
 # CONFIG_IRQSTACKS is not set
 # CONFIG_VIRQ_DEBUG is not set
diff --git a/arch/powerpc/platforms/44x/Kconfig 
b/arch/powerpc/platforms/44x/Kconfig
index 7486bff..9c3b8ca 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -126,6 +126,7 @@ config REDWOOD
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
+   select PPC4xx_MSI
help
  This option enables support for the AMCC PPC460SX Redwood board.
 
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..c8f1486 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
depends on PCI  4xx
default n
 
+config PPC4xx_MSI
+   bool
+   depends on PCI_MSI
+   depends on PCI  4xx
+   default n
+
 config PPC_MSI_BITMAP
bool
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+   default y if PPC4xx_MSI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5642924..4c67d2d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_PPC_I8259)   += i8259.o
 obj-$(CONFIG_IPIC) += ipic.o
 obj-$(CONFIG_4xx)  += uic.o
 obj-$(CONFIG_4xx_SOC)  += ppc4xx_soc.o
+obj-$(CONFIG_PPC4xx_MSI)   += ppc4xx_msi.o
 obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
 obj-$(CONFIG_XILINX_PCI)   += xilinx_pci.o
 obj-$(CONFIG_OF_RTC)   += of_rtc.o
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 000..3c2ef32
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,342 @@
+/*
+ * Copyright (C) 2009 Applied Micro Circuits corporation.
+ *
+ * Author: Feng Kan f...@amcc.com
+ *Tirumala Marri tma...@amcc.com
+ * 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

[PATCH 1/2] Adding PCI-E support for PowerPC 460SX based SOC.

[PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

Re: MPC8313e RDB rev A4 and rev C network throughput

[PATCH] of/flattree: use callback to setup initrd from /chosen

Re: [PATCH] of/flattree: use callback to setup initrd from /chosen

Re: [PATCH] of/flattree: use callback to setup initrd from /chosen

Re: [PATCH 1/2] Adding PCI-E support for PowerPC 460SX based SOC.

Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

Re: [PATCH] of/flattree: use callback to setup initrd from /chosen

[PATCH 03/31] hvc_console: make the ops pointer const.

[PATCH 04/31] hvc_console: Remove __devinit annotation from hvc_alloc

[PATCH] Make cpu hotplug driver lock part of ppc_md

I2C bus clock on MPC85XX systems

Re: I2C bus clock on MPC85XX systems

RE: MPC8313e RDB rev A4 and rev C network throughput

RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

Re: I2C bus clock on MPC85XX systems

Re: I2C bus clock on MPC85XX systems

Re: I2C bus clock on MPC85XX systems

Re: I2C bus clock on MPC85XX systems

Does gpio_to_irq() work for MPC52xx gpios?

Re: Does gpio_to_irq() work for MPC52xx gpios?

[PATCH 1/3] phylib: Fix deadlock on resume

[PATCH 2/3] phylib: Properly reinitialize PHYs after hibernation

[PATCH 3/3] ucc_geth: Fix netdev watchdog triggering on suspend

Re: [PATCH] Make cpu hotplug driver lock part of ppc_md

Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer

[PATCH 0/3] Build fixes for test-devicetree

[PATCH 1/3] of: include linux/proc_fs.h

[PATCH 2/3] of: make set_node_proc_entry private to proc_devtree.c

[PATCH 3/3] proc_devtree: include linux/of.h

Re: [PATCH -tip tracing/kprobes] PPC: Powerpc port of the kprobe-based event tracer

[PATCH] viodasd.c: Remove VIOD_KERN_level macros for printks

[PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.

34 matches

Site Navigation

Mail list logo

Footer information