* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Sascha Hauer @ 2007-10-08 8:48 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
Hi,
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
We finally solved this problem. It has nothing to do with locking
though. The problem is that the bcom engine was not reenabled after
resetting the fec. The following patch solves this.
Reenable the bestcom engine after resetting the mpc52xx fec
controller.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx/fec.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/drivers/net/fec_mpc52xx/fec.c
===================================================================
--- linux-2.6.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux-2.6/drivers/net/fec_mpc52xx/fec.c
@@ -788,6 +788,9 @@ static void fec_reset(struct net_device
fec_alloc_rx_buffers(priv->rx_dmatsk);
+ bcom_enable(priv->rx_dmatsk);
+ bcom_enable(priv->tx_dmatsk);
+
fec_start(dev);
}
>
> Juergen
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Vertretung Sued/Muenchen, Germany
> Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Sascha Hauer @ 2007-10-08 9:01 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-embedded
In-Reply-To: <200709281112.18480.jbe@pengutronix.de>
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
> PHY: f0003000:00 - Link is Down
> PHY: f0003000:00 - Link is Up - 100/Full
>
> The link is up again, but any connection is dead (no answers to ping etc.).
> But the serial console is still working. I'm not sure if the RT-Preempt patch
> *causes* this behavior or only *discover* it. Any idea?
While the previous patch I sent fixed the reset path for the fec
controller this patch makes sure the chip does not have to be resetted.
Problem was that we ran out of receive buffers when we nmapped our
board (nmap sends lots of small packages in a short period of time).
By increasing the number of rx buffers this problem does not appear
anymore.
This patch produces a significant memory overhead to the driver of about
340k, so we might want to have this configurable as a module parameter.
Let me know what the preferred way is, I can update the patch
accordingly.
Sascha
Increase the number of RX packets in the fec_mpc52xx driver. This is
necessary to no run out of rx packets when lots of small packets arrive
in short time (for example when nmapping the board)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/fec_mpc52xx/fec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/drivers/net/fec_mpc52xx/fec.h
===================================================================
--- linux-2.6.orig/drivers/net/fec_mpc52xx/fec.h
+++ linux-2.6/drivers/net/fec_mpc52xx/fec.h
@@ -19,7 +19,7 @@
/* Tunable constant */
/* FEC_RX_BUFFER_SIZE includes 4 bytes for CRC32 */
#define FEC_RX_BUFFER_SIZE 1522 /* max receive packet size */
-#define FEC_RX_NUM_BD 64
+#define FEC_RX_NUM_BD 256
#define FEC_TX_NUM_BD 64
#define FEC_RESET_DELAY 50 /* uS */
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* [PATCH 0/3] [POWERPC] Add AMCC 405EX PPC and Kilauea eval board support
From: Stefan Roese @ 2007-10-08 9:04 UTC (permalink / raw)
To: linuxppc-dev
This series adds AMCC 405EX support including the Kilauea eval board to
arch/powerpc. Please review and comment.
Best regards,
Stefan
^ permalink raw reply
* [PATCH 3/3] [POWERPC] Kilauea DTS
From: Stefan Roese @ 2007-10-08 9:10 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/kilauea.dts | 253 +++++++++++++++++++++++++++++++++++++
1 files changed, 253 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/kilauea.dts
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
new file mode 100644
index 0000000..4683174
--- /dev/null
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -0,0 +1,253 @@
+/*
+ * Device Tree Source for AMCC Kilauea (405EX)
+ *
+ * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,kilauea";
+ compatible = "amcc,kilauea";
+ dcr-parent = <&/cpus/PowerPC,405EX@0>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,405EX@0 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <4000>; /* 16 kB */
+ d-cache-size = <4000>; /* 16 kB */
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405ex", "ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-405ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-405ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1c 4 1d 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405ex", "ibm,plb4";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: memory-controller {
+ compatible = "ibm,sdram-405ex";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405ex", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ interrupt-map-mask = <ffffffff>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405ex", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <ef600000 ef600000 a00000>;
+ dcr-reg = <0a0 5>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-405ex", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+
+ nor_flash@0,0 {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ bank-width = <2>;
+ reg = <0 000000 4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "Kernel";
+ reg = <0 180000>;
+ };
+ partition@180000 {
+ label = "ramdisk";
+ reg = <180000 200000>;
+ };
+ partition@380000 {
+ label = "file system";
+ reg = <380000 3aa0000>;
+ };
+ partition@3e20000 {
+ label = "kozio";
+ reg = <3e20000 140000>;
+ };
+ partition@3f60000 {
+ label = "env";
+ reg = <3f60000 40000>;
+ };
+ partition@3fa0000 {
+ label = "u-boot";
+ reg = <3fa0000 60000>;
+ };
+ };
+ };
+
+ UART0: serial@ef600200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600200 8>;
+ virtual-reg = <ef600200>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ };
+
+ UART1: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ IIC0: i2c@ef600400 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405ex", "ibm,iic";
+ reg = <ef600400 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600500 {
+ device_type = "i2c";
+ compatible = "ibm,iic-405ex", "ibm,iic";
+ reg = <ef600500 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+
+ RGMII0: emac-rgmii@ef600b00 {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-405ex", "ibm,rgmii";
+ reg = <ef600b00 104>;
+ };
+
+ EMAC0: ethernet@ef600900 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-405ex", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 18 4
+ /*Wake*/ 1 &UIC1 1d 4>;
+ reg = <ef600900 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ };
+
+ EMAC1: ethernet@ef600a00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-405ex", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC0 19 4
+ /*Wake*/ 1 &UIC1 1f 4>;
+ reg = <ef600a00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <1>;
+ cell-index = <1>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ };
+ };
+ };
+};
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/3] [POWERPC] Add AMCC 405EX support to cputable.c
From: Stefan Roese @ 2007-10-08 9:07 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/kernel/cputable.c | 11 +++++++++++
1 files changed, 11 insertions(+)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b03a442..ea81d1e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1103,6 +1103,17 @@ static struct cpu_spec cpu_specs[] = {
.dcache_bsize = 32,
.platform = "ppc405",
},
+ { /* 405EX */
+ .pvr_mask = 0xffff0000,
+ .pvr_value = 0x12910000,
+ .cpu_name = "405EX",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = "ppc405",
+ },
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stefan Roese @ 2007-10-08 9:08 UTC (permalink / raw)
To: linuxppc-dev
This patch adds basic support for the new 405EX and the AMCC eval board
Kilauea to arch/powerpc.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/platforms/40x/Kconfig | 17 +++++++--
arch/powerpc/platforms/40x/Makefile | 5 ++-
arch/powerpc/platforms/40x/kilauea.c | 63 ++++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/platforms/40x/kilauea.c
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index a0a50b1..da8d02d 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -29,6 +29,14 @@
# help
# This option enables support for the extra features of the EP405PC board.
+config KILAUEA
+ bool "Kilauea"
+ depends on 40x
+ default y
+ select 405EX
+ help
+ This option enables support for the AMCC PPC405EX evaluation board.
+
#config REDWOOD_5
# bool "Redwood-5"
# depends on 40x
@@ -89,14 +97,17 @@ config 403GCX
#depends on OAK
select IBM405_ERR51
+config 405EP
+ bool
+
+config 405EX
+ bool
+
config 405GP
bool
select IBM405_ERR77
select IBM405_ERR51
-config 405EP
- bool
-
config 405GPR
bool
diff --git a/arch/powerpc/platforms/40x/Makefile b/arch/powerpc/platforms/40x/Makefile
index 0a3cfe9..51dadee 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -1,2 +1,3 @@
-obj-$(CONFIG_WALNUT) += walnut.o
-obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
+obj-$(CONFIG_KILAUEA) += kilauea.o
+obj-$(CONFIG_WALNUT) += walnut.o
+obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
new file mode 100644
index 0000000..6cbd528
--- /dev/null
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -0,0 +1,63 @@
+/*
+ * Kilauea board specific routines
+ *
+ * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * Based on the Walnut code by
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright 2007 IBM Corporation
+ *
+ * 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.
+ */
+#include <linux/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/of_platform.h>
+
+static struct of_device_id kilauea_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init kilauea_device_probe(void)
+{
+ if (!machine_is(kilauea))
+ return 0;
+
+ of_platform_bus_probe(NULL, kilauea_of_bus, NULL);
+
+ return 0;
+}
+device_initcall(kilauea_device_probe);
+
+static int __init kilauea_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,kilauea"))
+ return 0;
+
+ return 1;
+}
+
+static void __init kilauea_setup_arch(void)
+{
+}
+
+define_machine(kilauea) {
+ .name = "Kilauea",
+ .probe = kilauea_probe,
+ .setup_arch = kilauea_setup_arch,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.3.4
^ permalink raw reply related
* problem port linux to MPC860T
From: keng_629 @ 2007-10-08 9:34 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
recently i am working with porting the linux2.6.23 to MPC860T
i use the lighter to test where my kernel is now runing.
i find it out of control after the local_irq_enable() funciton in the asmlinkage void __init start_kernel(void) in init/main.c file.
Can somebody give me a hand?thank you
[-- Attachment #2: Type: text/html, Size: 858 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stephen Rothwell @ 2007-10-08 11:48 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200710081108.51625.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Mon, 8 Oct 2007 11:08:51 +0200 Stefan Roese <sr@denx.de> wrote:
>
> +++ b/arch/powerpc/platforms/40x/kilauea.c
>
> +#include <asm/of_platform.h>
Here I go again :-)
linux/of_platform.h please
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Add AMCC Kilauea eval board support to platforms/40x
From: Stefan Roese @ 2007-10-08 12:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell
In-Reply-To: <20071008214848.f6c6070d.sfr@canb.auug.org.au>
On Monday 08 October 2007, Stephen Rothwell wrote:
> > +#include <asm/of_platform.h>
>
> Here I go again :-)
>
> linux/of_platform.h please
Right. I was watching all your reviews lately and wanted not to make this
error. Didn't work out as it seems. :-)
I'll wait a while for further comments and send a fixed version soon.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Anton Vorontsov @ 2007-10-08 12:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EB9BE8E7-6437-403F-A7F4-953B393FDF51@kernel.crashing.org>
On Fri, Oct 05, 2007 at 03:58:00PM -0500, Kumar Gala wrote:
>
> On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
>
>> On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
>>> Hello.
>>>
>>> Anton Vorontsov wrote:
>>>
>>>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
>>>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
>>>
>>> Of course. But shouldn't those be the subnoses of the "soc" type node?
>>
>> Nope. PCI's ranges = <>; isn't in the SOC address space.
>>
>> Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC: Add 64-bit
>> phys addr support to 32-bit pci" that started using of_translate_address()
>> for ranges, and of_translate_address() will not work if PCI placed in the
>> SOC node. Not sure if that patch applied or not, though.
>
> I'm confused, what's the actual issue with PCI that this patch addresses?
Which patch? Valentine's or mine under the subject? Don't know about the
former, but mine patch is pretty obvious: your commit
5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc node,
but you forgot to change regs = <>, thus instead of e000a000/e0008000,
kernel used a000/8000 for accessing PCI ccsr registers.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH respin 0/7] MPC8568E-MDS related patches
From: Anton Vorontsov @ 2007-10-08 12:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <27C7E568-B28A-4659-803F-9D271B2E1AF6@kernel.crashing.org>
On Fri, Oct 05, 2007 at 05:09:28PM -0500, Kumar Gala wrote:
>
> On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
>
>> Hello Kumar,
>>
>> This is respin of MPC8568E-MDS patches, on top of master branch
>> as of today.
>>
>> If there are no objections against SPI patch, please Ack it, thus
>> David could pick it up.
>
> I've applied patches 1-5 however I'm not able to get UCC enet working on my
> board.
I wonder how you managed to boot it w/o sixth (PCI) patch in this patch set,
for me board hanged w/o it.
> Is there something special that has to be done? (I've got the card
> standalone, no MDS backplane).
Nothing special, from what I can remember. Though, double checking switches
on the board might help.
Also, .config and bootlog would help.
> I'm using the 1.3.0-rc2 u-boot w/o any modifications.
1.2.0-g60174746 here.
> Also, I tried a PCIe e1000 card w/the .dts that's in my tree and that works
> w/o any issue.
Strange enough. I'd say it's impossible with your current tree. Maybe you've
used some stale dtb? Because dts is seriously broken as now, and I can't
believe that it worked for you. ;-)
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Geert Uytterhoeven @ 2007-10-08 12:16 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071006213542.954029915@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1092 bytes --]
On Sat, 6 Oct 2007 geoffrey.levand@am.sony.com wrote:
> --- a/arch/powerpc/platforms/ps3/os-area.c
> +++ b/arch/powerpc/platforms/ps3/os-area.c
> +static int db_get_video_mode(const struct os_area_db *db,
> + unsigned int *video_mode)
^^^^^^^^^^^^^^
> +{
> + return db_get_64(db, &os_area_db_id_video_mode, (uint64_t*)video_mode);
^^^^^^^^^^^
> +}
Woops, memory corruption, when writing a 64-bit value to a 32-bit variable.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH] PowerPC PCI: add 64-bit physical address support to setup_indirect_pci.
From: Valentine Barshak @ 2007-10-08 12:51 UTC (permalink / raw)
To: linuxppc-dev
Add 64-bit physical address support to setup_indirect_pci().
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/indirect_pci.c | 6 ++++--
include/asm-powerpc/pci-bridge.h | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/sysdev/indirect_pci.c linux-2.6/arch/powerpc/sysdev/indirect_pci.c
--- linux-2.6.orig/arch/powerpc/sysdev/indirect_pci.c 2007-10-08 16:29:54.000000000 +0400
+++ linux-2.6/arch/powerpc/sysdev/indirect_pci.c 2007-10-08 16:45:40.000000000 +0400
@@ -149,9 +149,11 @@ static struct pci_ops indirect_pci_ops =
};
void __init
-setup_indirect_pci(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data, u32 flags)
+setup_indirect_pci(struct pci_controller* hose,
+ resource_size_t cfg_addr,
+ resource_size_t cfg_data, u32 flags)
{
- unsigned long base = cfg_addr & PAGE_MASK;
+ resource_size_t base = cfg_addr & PAGE_MASK;
void __iomem *mbase;
mbase = ioremap(base, PAGE_SIZE);
diff -pruN linux-2.6.orig/include/asm-powerpc/pci-bridge.h linux-2.6/include/asm-powerpc/pci-bridge.h
--- linux-2.6.orig/include/asm-powerpc/pci-bridge.h 2007-10-08 16:30:41.000000000 +0400
+++ linux-2.6/include/asm-powerpc/pci-bridge.h 2007-10-08 16:45:40.000000000 +0400
@@ -98,7 +98,8 @@ extern int early_find_capability(struct
int dev_fn, int cap);
extern void setup_indirect_pci(struct pci_controller* hose,
- u32 cfg_addr, u32 cfg_data, u32 flags);
+ resource_size_t cfg_addr,
+ resource_size_t cfg_data, u32 flags);
extern void setup_grackle(struct pci_controller *hose);
extern void __init update_bridge_resource(struct pci_dev *dev,
struct resource *res);
^ permalink raw reply
* Re: TASK_SIZE default 0x80000000 ?
From: Kumar Gala @ 2007-10-08 13:31 UTC (permalink / raw)
To: Dan Malek; +Cc: PowerPC dev list, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <B108919F-98D7-45B0-BEB0-48D345F0BE4B@embeddedalley.com>
On Oct 7, 2007, at 1:35 PM, Dan Malek wrote:
>
> On Oct 7, 2007, at 8:02 AM, Kumar Gala wrote:
>
>> It would seem like we should set the default on 8xx & PReP to
>> 0x80000000 and not allow it to be modified
>
> For as much as this has been discussed in the past,
> I don't know why the 8xx doesn't check KERNEL_BASE
> and work properly with the options. There is no reason
> this can't work. The history is I wrote the tlb handlers
> to test the MS bit due to a hardcoded address, not that
> the address is hardcoded because I wanted to just
> test a bit. Unlike PReP, there is no reason to
> disallow modification, if this test was changed.
Ok, I'll work up a patch for 8xx to test against PAGE_OFFSET (as benh
suggested).
- k
^ permalink raw reply
* Re: TASK_SIZE default 0x80000000 ?
From: Kumar Gala @ 2007-10-08 13:31 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <1191791123.6392.0.camel@pasglop>
On Oct 7, 2007, at 4:05 PM, Benjamin Herrenschmidt wrote:
>
>> Can you explain (a) further -- I'm assuming the BAT mapping is 1:1
>> for that region?
>>
>> For (b) it looks like:
>> * 40x, 44x, fsl-booke compare against TASK_SIZE in their software
>> handlers.
>> * 8xx still tests 0x80000000
>> * 6xx (603) compares against KERNELBASE
>>
>> It would seem like we should set the default on 8xx & PReP to
>> 0x80000000 and not allow it to be modified since that will break the
>> world and for everything else move it to match KERNELBASE. Any
>> issues with that?
>
> The proper value is neither :-)
>
> It should be compared against PAGE_OFFSET.
I'll work up a patch to switch us to testing PAGE_OFFSET instead.
- k
^ permalink raw reply
* Re: [PATCH 6/7] [POWERPC] mpc8568mds.dts: fix PCI/PCIe nodes
From: Kumar Gala @ 2007-10-08 13:32 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071008120849.GA32540@localhost.localdomain>
On Oct 8, 2007, at 7:08 AM, Anton Vorontsov wrote:
> On Fri, Oct 05, 2007 at 03:58:00PM -0500, Kumar Gala wrote:
>>
>> On Oct 5, 2007, at 1:05 PM, Anton Vorontsov wrote:
>>
>>> On Fri, Oct 05, 2007 at 09:56:46PM +0400, Sergei Shtylyov wrote:
>>>> Hello.
>>>>
>>>> Anton Vorontsov wrote:
>>>>
>>>>> Commit 5bece127f0666996ca90772229e00332a34e516c tried to fix
>>>>> PCI/PCIe nodes, but actually it broke them even harder. ;-)
>>>>
>>>> Of course. But shouldn't those be the subnoses of the "soc"
>>>> type node?
>>>
>>> Nope. PCI's ranges = <>; isn't in the SOC address space.
>>>
>>> Valentine Barshak posted a patch titled "[RFC] [PATCH] PowerPC:
>>> Add 64-bit
>>> phys addr support to 32-bit pci" that started using
>>> of_translate_address()
>>> for ranges, and of_translate_address() will not work if PCI
>>> placed in the
>>> SOC node. Not sure if that patch applied or not, though.
>>
>> I'm confused, what's the actual issue with PCI that this patch
>> addresses?
>
> Which patch? Valentine's or mine under the subject? Don't know
> about the
> former, but mine patch is pretty obvious: your commit
> 5bece127f0666996ca90772229e00332a34e516c moved PCI nodes out of soc
> node,
> but you forgot to change regs = <>, thus instead of e000a000/e0008000,
> kernel used a000/8000 for accessing PCI ccsr registers.
Yeah, I see that bug now. It looks like I wasn't getting my new .dts
on the board. Will fixup that issue in my patch.
- k
^ permalink raw reply
* Re: [PATCH respin 0/7] MPC8568E-MDS related patches
From: Kumar Gala @ 2007-10-08 13:46 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071008121647.GB32540@localhost.localdomain>
On Oct 8, 2007, at 7:16 AM, Anton Vorontsov wrote:
> On Fri, Oct 05, 2007 at 05:09:28PM -0500, Kumar Gala wrote:
>>
>> On Oct 5, 2007, at 12:40 PM, Anton Vorontsov wrote:
>>
>>> Hello Kumar,
>>>
>>> This is respin of MPC8568E-MDS patches, on top of master branch
>>> as of today.
>>>
>>> If there are no objections against SPI patch, please Ack it, thus
>>> David could pick it up.
>>
>> I've applied patches 1-5 however I'm not able to get UCC enet
>> working on my
>> board.
>
> I wonder how you managed to boot it w/o sixth (PCI) patch in this
> patch set,
> for me board hanged w/o it.
>
>> Is there something special that has to be done? (I've got the card
>> standalone, no MDS backplane).
>
> Nothing special, from what I can remember. Though, double checking
> switches
> on the board might help.
>
> Also, .config and bootlog would help.
>
>> I'm using the 1.3.0-rc2 u-boot w/o any modifications.
>
> 1.2.0-g60174746 here.
>
>> Also, I tried a PCIe e1000 card w/the .dts that's in my tree and
>> that works
>> w/o any issue.
>
> Strange enough. I'd say it's impossible with your current tree.
> Maybe you've
> used some stale dtb? Because dts is seriously broken as now, and I
> can't
> believe that it worked for you. ;-)
Ignore me. Using the updated dtb makes things work. I need to double
check PCIe but UCC geth appears to function now.
- k
^ permalink raw reply
* Re: [patch 6/6] PS3: Add os-area database routines
From: Ranulf Doswell @ 2007-10-08 13:48 UTC (permalink / raw)
To: geoffrey.levand@am.sony.com; +Cc: linuxppc-dev
In-Reply-To: <20071006213542.954029915@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
On 06/10/2007, geoffrey.levand@am.sony.com <geoffrey.levand@am.sony.com>
wrote:
> enum os_area_db_owner {
> OS_AREA_DB_OWNER_ANY = -1,
> OS_AREA_DB_OWNER_NONE = 0,
> OS_AREA_DB_OWNER_PROTOTYPE = 1,
> OS_AREA_DB_OWNER_LINUX = 2,
> OS_AREA_DB_OWNER_PETITBOOT = 3,
> OS_AREA_DB_OWNER_MAX = 32,
>};
>
>enum os_area_db_key {
> OS_AREA_DB_KEY_ANY = -1,
> OS_AREA_DB_KEY_NONE = 0,
> OS_AREA_DB_KEY_RTC_DIFF = 1,
> OS_AREA_DB_KEY_VIDEO_MODE = 2,
> OS_AREA_DB_KEY_MAX = 8,
>};
How do we go about claiming one of these OS_AREA_DB_OWNER_ keys? I'd very
much like to use this functionality in my python-ps3 games library.
My requirement is to be able to persist various options such as player names
and rankings. I had already been thinking about generating a unique token
and storing it somewhere at the end of the flash area so that when my game
connects to a game server, it can identify itself and be provided with all
the previous settings. Obviously, just claiming a random area of flash isn't
ideal, so your standardised solution would be perfect for this.
I would like, therefore, to reserve a single key to hold a 64-bit sized
token in order to identify the machine across reboots. I don't mind
particularly whether it's private to my application or a generally available
field, but certainly having an identifier I can rely on would be very
useful.
Cheers,
Ralf.
[-- Attachment #2: Type: text/html, Size: 1729 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC PCI: add 64-bit physical address support to setup_indirect_pci.
From: Kumar Gala @ 2007-10-08 13:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: PowerPC dev list, Benjamin Herrenschmidt
In-Reply-To: <20071008125124.GA6225@ru.mvista.com>
On Oct 8, 2007, at 7:51 AM, Valentine Barshak wrote:
> Add 64-bit physical address support to setup_indirect_pci().
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [PATCH 01/15] [POWERPC] TQM5200 DTS
From: Kumar Gala @ 2007-10-08 13:52 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <fa686aa40710072327j304b7a62q602ed2553787abd4@mail.gmail.com>
On Oct 8, 2007, at 1:27 AM, Grant Likely wrote:
> On 10/7/07, Marian Balakowicz <m8@semihalf.com> wrote:
>> +
>> + pci@0d00 {
>> + #interrupt-cells = <1>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + device_type = "pci";
>> + compatible = "mpc5200-pci";
>> + reg = <d00 100>;
>> + interrupt-map-mask = <f800 0 0 7>;
>> + interrupt-map = <c000 0 0 1 &mpc5200_pic 0
>> 0 3
>> + c000 0 0 2 &mpc5200_pic 0
>> 0 3
>> + c000 0 0 3 &mpc5200_pic 0
>> 0 3
>> + c000 0 0 4 &mpc5200_pic 0
>> 0 3>;
>> + clock-frequency = <0>; // From boot loader
>> + interrupts = <2 8 0 2 9 0 2 a 0>;
>> + interrupt-parent = <&mpc5200_pic>;
>> + bus-range = <0 0>;
>> + ranges = <42000000 0 80000000 80000000 0
>> 10000000
>> + 02000000 0 90000000 90000000 0
>> 10000000
>> + 01000000 0 00000000 a0000000 0
>> 01000000>;
>> + };
>
> Also, the PCI node should no longer be a child of the 'soc' node. See
> the latest lite5200.dts file in Paul Mackerras' powerpc tree for an
> example.
Also, note how the PCI node is a sibling of the soc node not a child
of it.
- k
^ permalink raw reply
* Re: [PATCH 12/15] [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(), mpc52xx_power_off().
From: Kumar Gala @ 2007-10-08 13:56 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4708C3B2.1050103@semihalf.com>
On Oct 7, 2007, at 6:32 AM, Marian Balakowicz wrote:
>
> Add common MPC5200 helper routines: mpc52xx_restart(), mpc52xx_halt(),
> mpc52xx_power_off().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 45 +++++++++++++++
> ++++++++++++
> include/asm-powerpc/mpc52xx.h | 7 ++++
> 2 files changed, 52 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/
> powerpc/platforms/52xx/mpc52xx_common.c
> index b1cd7b0..e7087d7 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -88,6 +88,14 @@ mpc52xx_find_ipb_freq(struct device_node *node)
> }
> EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
>
> +/*
> + * This variable is mapped in mpc52xx_setup_cpu() by a call to
> + * mpc52xx_find_and_map(), and used in mpc52xx_restart(). This is
> because
> + * mpc52xx_restart() can be called from interrupt context (e.g.,
> watchdog
> + * interrupt handler), and mpc52xx_find_and_map() (ioremap() to be
> exact)
> + * can't be called from interrupt context.
> + */
> +volatile struct mpc52xx_gpt *mpc52xx_gpt0 = NULL;
>
> void __init
> mpc52xx_setup_cpu(void)
> @@ -95,6 +103,9 @@ mpc52xx_setup_cpu(void)
> struct mpc52xx_cdm __iomem *cdm;
> struct mpc52xx_xlb __iomem *xlb;
>
> + /* mpc52xx_gpt0 is mapped here and used in mpc52xx_restart */
> + mpc52xx_gpt0 = mpc52xx_find_and_map("mpc5200-gpt");
> +
> /* Map zones */
> cdm = mpc52xx_find_and_map("mpc5200-cdm");
> xlb = mpc52xx_find_and_map("mpc5200-xlb");
> @@ -138,3 +149,37 @@ mpc52xx_declare_of_platform_devices(void)
> "Error while probing of_platform bus\n");
> }
>
> +void
> +mpc52xx_restart(char *cmd)
> +{
> + local_irq_disable();
> +
> + /* Turn on the watchdog and wait for it to expire. It effectively
> + does a reset */
> + if (mpc52xx_gpt0) {
> + out_be32(&mpc52xx_gpt0->mode, 0x00000000);
> + out_be32(&mpc52xx_gpt0->count, 0x000000ff);
> + out_be32(&mpc52xx_gpt0->mode, 0x00009004);
> + } else
> + printk("mpc52xx_restart: Can't access gpt. "
> + "Restart impossible, system halted\n");
> +
> + while (1);
> +}
> +
> +void
> +mpc52xx_halt(void)
> +{
> + local_irq_disable();
> +
> + while (1);
> +}
> +
> +void
> +mpc52xx_power_off(void)
> +{
> + /* By default we don't have any way of shut down.
> + If a specific board wants to, it can set the power down
> + code to any hardware implementation dependent code */
> + mpc52xx_halt();
> +}
If you are just going to spin don't bother implementing these. The
generic routines will do the same.
- k
^ permalink raw reply
* Re: [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Kumar Gala @ 2007-10-08 13:57 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <47075FA7.3030108@semihalf.com>
On Oct 6, 2007, at 5:12 AM, Marian Balakowicz wrote:
> Hello,
>
> The following series of patches adds arch/powerpc support for three
> MPC5200 based boards:
> TQM5200, CM5200 and Motion-PRO.
>
> Included are also patches with modifications to common 52xx code.
> New helper
> routine mpc52xx_find_and_map_path() is added, and is being used in
> LED driver
> for Motion-PRO. Another patch adds mpc52xx_restart(), mpc52xx_halt()
> and mpc52xx_power_off(). This modification has been around for some
> time now
> and relies on Sascha Hauer's patch.
>
> 01/15 [POWERPC] TQM5200 DTS
> 02/15 [POWERPC] TQM5200 defconfig
> 03/15 [POWERPC] TQM5200 board support
> 04/15 [POWERPC] cm5200 DTS
> 05/15 [POWERPC] cm5200 defconfig
> 06/15 [POWERPC] cm5200 board support
> 07/15 [POWERPC] Promess motionpro DTS
> 08/15 [POWERPC] Promess motionpro defconfig
> 09/15 [POWERPC] Promess motionpro board support
> 10/15 [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility
> functions.
> 11/15 [POWERPC] Motion-PRO: Add LED support.
> 12/15 [POWERPC] Add mpc52xx_restart(), mpc52xx_halt(),
> mpc52xx_power_off().
> 13/15 [POWERPC] Init restart/halt/power_off machine hooks for tqm5200.
> 14/15 [POWERPC] Init restart/halt/power_off machine hooks for cm5200.
> 15/15 [POWERPC] Init restart/halt/power_off machine hooks for
> motionpro.
Why don't you submit patch 12/15 first so you can just fold 13/14/15
into their respect board support patches. In general any generic
clean patches first is usually a good idea followed by the patches
that depend on them.
- k
^ permalink raw reply
* Re: [patch 2/6] PS3: Remove unused os-area params
From: Ranulf Doswell @ 2007-10-08 14:00 UTC (permalink / raw)
To: geoffrey.levand@am.sony.com; +Cc: linuxppc-dev
In-Reply-To: <20071006213542.595771597@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On 06/10/2007, geoffrey.levand@am.sony.com <geoffrey.levand@am.sony.com>
wrote:
> struct saved_params {
>- /* param 0 */
> s64 rtc_diff;
> unsigned int av_multi_out;
>- unsigned int ctrl_button;
>- /* param 1 */
>- u8 static_ip_addr[4];
>- u8 network_mask[4];
>- u8 default_gateway[4];
>- /* param 2 */
>- u8 dns_primary[4];
>- u8 dns_secondary[4];
> } static saved_params;
As these values are correctly populated by the hypervisor from the
preferences on the standard PS3 OS, it is incredibly useful to have this
information available.
Whilst none of the current 'popular' distributions use these fields, I am
currently in the process of making a bootable CD image that does use them in
order to initialise the network. Not having this information available means
that the only sensible option is to use DHCP, which may well not be
available in every case.
Please can we have these fields back? They don't actually take up all that
much room, yet they are incredibly useful.
--
Ranulf Doswell
One of the major reasons for the downfall of the Roman Empire was, lacking
zero, they had no way to indicate termination of their C strings.
[-- Attachment #2: Type: text/html, Size: 1425 bytes --]
^ permalink raw reply
* [PATCH] ehea: use kernel event queue
From: Jan-Bernd Themann @ 2007-10-08 14:01 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher, Anton Blanchard
eHEA recovery and DLPAR functions are called seldomly. The eHEA workqueues
are replaced by the kernel event queue.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
The patch has been built against upstream git
drivers/net/ehea/ehea.h | 3 +--
drivers/net/ehea/ehea_main.c | 28 ++++++++--------------------
drivers/net/ehea/ehea_qmr.c | 3 +--
3 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 3022089..ac21526 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0077"
+#define DRV_VERSION "EHEA_0078"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -391,7 +391,6 @@ struct ehea_adapter {
struct ibmebus_dev *ebus_dev;
struct ehea_port *port[EHEA_MAX_PORTS];
struct ehea_eq *neq; /* notification event queue */
- struct workqueue_struct *ehea_wq;
struct tasklet_struct neq_tasklet;
struct ehea_mr mr;
u32 pd; /* protection domain */
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 5bc0a15..2ba57e6 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -94,7 +94,6 @@ MODULE_PARM_DESC(use_lro, " Large Receive Offload, 1: enable, 0: disable, "
static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
-struct workqueue_struct *ehea_driver_wq;
struct work_struct ehea_rereg_mr_task;
struct semaphore dlpar_mem_lock;
@@ -421,7 +420,7 @@ static int ehea_treat_poll_error(struct ehea_port_res *pr, int rq,
if (cqe->status & EHEA_CQE_STAT_FAT_ERR_MASK) {
ehea_error("Critical receive error. Resetting port.");
- queue_work(pr->port->adapter->ehea_wq, &pr->port->reset_task);
+ schedule_work(&pr->port->reset_task);
return 1;
}
@@ -596,8 +595,7 @@ static struct ehea_cqe *ehea_proc_cqes(struct ehea_port_res *pr, int my_quota)
ehea_error("Send Completion Error: Resetting port");
if (netif_msg_tx_err(pr->port))
ehea_dump(cqe, sizeof(*cqe), "Send CQE");
- queue_work(pr->port->adapter->ehea_wq,
- &pr->port->reset_task);
+ schedule_work(&pr->port->reset_task);
break;
}
@@ -716,7 +714,7 @@ static irqreturn_t ehea_qp_aff_irq_handler(int irq, void *param)
eqe = ehea_poll_eq(port->qp_eq);
}
- queue_work(port->adapter->ehea_wq, &port->reset_task);
+ schedule_work(&port->reset_task);
return IRQ_HANDLED;
}
@@ -2395,7 +2393,7 @@ static int ehea_stop(struct net_device *dev)
if (netif_msg_ifdown(port))
ehea_info("disabling port %s", dev->name);
- flush_workqueue(port->adapter->ehea_wq);
+ flush_scheduled_work();
down(&port->port_lock);
netif_stop_queue(dev);
ret = ehea_down(dev);
@@ -2710,7 +2708,7 @@ static void ehea_tx_watchdog(struct net_device *dev)
if (netif_carrier_ok(dev) &&
!test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))
- queue_work(port->adapter->ehea_wq, &port->reset_task);
+ schedule_work(&port->reset_task);
}
int ehea_sense_adapter_attr(struct ehea_adapter *adapter)
@@ -3243,15 +3241,9 @@ static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
goto out_kill_eq;
}
- adapter->ehea_wq = create_workqueue("ehea_wq");
- if (!adapter->ehea_wq) {
- ret = -EIO;
- goto out_free_irq;
- }
-
ret = ehea_create_device_sysfs(dev);
if (ret)
- goto out_kill_wq;
+ goto out_free_irq;
ret = ehea_setup_ports(adapter);
if (ret) {
@@ -3265,9 +3257,6 @@ static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
out_rem_dev_sysfs:
ehea_remove_device_sysfs(dev);
-out_kill_wq:
- destroy_workqueue(adapter->ehea_wq);
-
out_free_irq:
ibmebus_free_irq(NULL, adapter->neq->attr.ist1, adapter);
@@ -3293,7 +3282,7 @@ static int __devexit ehea_remove(struct ibmebus_dev *dev)
ehea_remove_device_sysfs(dev);
- destroy_workqueue(adapter->ehea_wq);
+ flush_scheduled_work();
ibmebus_free_irq(NULL, adapter->neq->attr.ist1, adapter);
tasklet_kill(&adapter->neq_tasklet);
@@ -3351,7 +3340,6 @@ int __init ehea_module_init(void)
printk(KERN_INFO "IBM eHEA ethernet device driver (Release %s)\n",
DRV_VERSION);
- ehea_driver_wq = create_workqueue("ehea_driver_wq");
INIT_WORK(&ehea_rereg_mr_task, ehea_rereg_mrs);
sema_init(&dlpar_mem_lock, 1);
@@ -3385,7 +3373,7 @@ out:
static void __exit ehea_module_exit(void)
{
- destroy_workqueue(ehea_driver_wq);
+ flush_scheduled_work();
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
ehea_destroy_busmap();
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index 329a252..83b7643 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -34,7 +34,6 @@
struct ehea_busmap ehea_bmap = { 0, 0, NULL };
extern u64 ehea_driver_flags;
-extern struct workqueue_struct *ehea_driver_wq;
extern struct work_struct ehea_rereg_mr_task;
@@ -618,7 +617,7 @@ u64 ehea_map_vaddr(void *caddr)
if (unlikely(mapped_addr == -1))
if (!test_and_set_bit(__EHEA_STOP_XFER, &ehea_driver_flags))
- queue_work(ehea_driver_wq, &ehea_rereg_mr_task);
+ schedule_work(&ehea_rereg_mr_task);
return mapped_addr;
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] fsl_spi_init: Support non-QE processors
From: Kumar Gala @ 2007-10-08 14:09 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: PowerPC dev list, Stephen Rothwell
In-Reply-To: <87ejg8vwhb.fsf@macbook.be.48ers.dk>
On Oct 6, 2007, at 3:06 PM, Peter Korsgaard wrote:
>>>>>> "Kumar" == Kumar Gala <galak@kernel.crashing.org> writes:
>
> Kumar> On Oct 3, 2007, at 11:01 PM, Stephen Rothwell wrote:
>
>>> On Wed, 03 Oct 2007 17:43:50 +0200 Peter Korsgaard
>>> <jacmet@sunsite.dk> wrote:
>>>>
>>>> @@ -1220,14 +1220,17 @@ int __init fsl_spi_init(struct
>>>> spi_board_info *board_infos,
>>>> {
>>>> struct device_node *np;
>>>> unsigned int i;
>>>> - const u32 *sysclk;
>>>> + const u32 *qe_sysclk = 0, *soc_sysclk = 0;
>>>
>>> Please use NULL when referring to pointers.
>
> Kumar> Peter, any chance of getting a respin. I'd like this to go
> Kumar> into 2.6.24.
>
> Certainly. Sorry for the delay, I have been offline for 2 days
> building my house ..
applied.
No problem, sounds like fun.
If you get a chance can you test my for-2.6.24 board to make SPI is
functional as you expect.
thanks
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox