* Re: [PATCH] powerpc: setup Marvell mv64x60 platform devices for EDAC
From: Dale Farnsworth @ 2007-05-23 20:23 UTC (permalink / raw)
To: djiang, Linuxppc-dev, paulus, bluesmoke-devel
In-Reply-To: <20070522232432.GA26046@blade.az.mvista.com>
Dave Jiang wrote:
> Creating platform devices (memory controller, sram error registers, cpu error
> registers, PCI error registers) for Error Detection and Correction (EDAC)
> driver on the Marvell mv64x60 based platforms.
>
> The platform devices allow the mv64x60 EDAC driver to detect errors from the
> memory controller (ECC erorrs), SRAM controller, CPU data path error registers,
> and PCI error registers. The errors are reported to syslog. Software ECC
> scrubbing is provided. These replace the mv64x60 error handlers in the
> ppc branch
> They are being moved to EDAC subsystem in order to centralize error reporting.
>
> The error reporting can be triggered via interrupts from the mv64x60 bridge chip
> or via polling mechanism provided by the EDAC core code.
>
> The mv64x60 EDAC driver can be found at:
> http://bluesmoke.sourceforge.net/
>
> It's in development to be pushed into the kernel.
>
> Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
^ permalink raw reply
* Re: Problems with access to PCI on MVME3100
From: Bhupender Saharan @ 2007-05-23 20:12 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <4653E3A3.8020600@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]
Hi Johan,
>From the pci log it looks like that BAR registers are not mapped properly by
the BIOS/U-boot. Looks like you have 3 BARS which are asking for memory, But
that are not spaced apart propoerly. Mean physical address difference
between BAR0 and BAR2 shall be 512 Megabyte, but that is not what it is
programmed.
Need to fix up the memory allocation first. then we need to see if the DMA
descriptor are defimed propoerly. As you are saying you are porting the
driver from X-86 to PPC. SO endian coversion is required.....
Regards
Bhupi
On 5/22/07, Johan Borkhuis <j.borkhuis@dutchspace.nl> wrote:
>
> Hello,
>
> I am working on porting a PCI driver from I386-Linux to PPC (MVME-3100).
> The device is a Reflective Memory card (VMIC 5565), and we use a driver
> based on the standard Linux driver, provided by the supplier.
>
> I try to start a DMA transfer (using the DMA engine on the PCI card)
> from user space, but then I get a PCI Error. The following data is
> displayed:
> PCI Error!
> PCI ERROR DETECT REG 0x00000042
> PCI ERROR ADDRESS REG 0x00fffa00
> PCI ERROR EXT ADDRESS REG 0x00000000
> PCI ERROR ATTRIBUTES REG 0x0000c001
> PCI ERROR DATA HIGH REG 0x60010004
> PCI ERROR DATA LOW REG 0x10060020
> PCI STATUS REG 0x0000
> PCI GASKET TIMER REG 0x00003fff
> PCI PCIX TIMER REG 0x01ffffff
>
> Access to the registers from kernel mode is no problem. I did an mmap to
> map the registers into user space, and then access the registers as an
> array of chars or ints. Is there a limitation in access to PCI registers
> from user space on PPC?
>
> When I try to do this in kernel mode I don't get any errors, but the
> transfer is not started. I am not sure if this is a SW problem, or that
> it might be caused by the PCI-PCI bridge.
>
> The code runs perfectly on a I386 platform, and I use read[bwl] and
> write[bwl] to access the registers, so this should fix the endianess
> problems that exist.
>
> Below is the PCI information from the card:
> 01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
> Subsystem: PLX Technology, Inc.: Unknown device 9656
> Flags: 66Mhz, medium devsel, IRQ 52
> Memory at 00000000dfeffe00 (32-bit, non-prefetchable) [size=512]
> I/O ports at e0ffff00 [size=256]
> Memory at 00000000dfeffdc0 (32-bit, non-prefetchable) [size=64]
> Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
> Capabilities: [40] Power Management version 2
> Capabilities: [48] #00 [0080]
>
> Kind regards,
> Johan Borkhuis
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3490 bytes --]
^ permalink raw reply
* [PATCH 2.6.21-rt7] PowerPC: kill cpu_khz reference
From: Sergei Shtylyov @ 2007-05-23 20:02 UTC (permalink / raw)
To: mingo, tglx; +Cc: linuxppc-dev, linux-kernel
Remove forgotten reference to 'cpu_khz' which have been removed for PowerPC in
2.6.21-rt7...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
---
The irony here is that it was me who sent a patch to add that line. :-)
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
@@ -816,7 +816,6 @@ void __init time_init(void)
tb_ticks_per_jiffy = ppc_tb_freq / HZ;
tb_ticks_per_sec = ppc_tb_freq;
tb_ticks_per_usec = ppc_tb_freq / 1000000;
- cpu_khz = ppc_tb_freq / 1000;
tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 1000000);
calc_cputime_factors();
^ permalink raw reply
* FCC receiver BSY errors
From: Matvejchikov Ilya @ 2007-05-23 19:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
I use fs_enet driver on mpc8260. Sometimes at heavy uploading the
receiver busy error arises (FCC_ENET_BSY). After that the receiver
stops working. Only restart() function helps. Has anybody come across
such a problem? Is it possible that there is an erratum in mpc82xx?
Thanks.
^ permalink raw reply
* RE: anyone have a good config file for a taiga/hpc2 with a 7448?
From: Leisner, Martin @ 2007-05-23 18:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: Lund, Nathan, linuxppc-embedded
In-Reply-To: <8386E52C-335E-46E9-9608-8FEAC3A57BC9@kernel.crashing.org>
ah, yes, but the tundra ethernet support only started to appear in the=20
2.6.20 tree!!
We have a 2.6.10 where the ethernet worked and 2.6.19 with
non-functional
ethernet and I was wondering why...
thanks much,
marty
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozl
> abs.org] On Behalf Of Kumar Gala
> Sent: Wednesday, May 23, 2007 8:06 AM
> To: Leisner, Martin
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: anyone have a good config file for a taiga/hpc2=20
> with a 7448?
>=20
>=20
> On May 22, 2007, at 1:41 PM, Leisner, Martin wrote:
>=20
> > Before I tried to do one myself, I figured I'd bounce it=20
> off to see if
> > anyone has a working
> > .config (the newer kernel, the better).
>=20
> Does arch/powerpc/configs/mpc7448_hpc2_defconfig not work for you?
>=20
> - k
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [PATCH] Fix mpc52xx_uart_of_assign to use correct index
From: Grant Likely @ 2007-05-23 18:41 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <1179941455907-git-send-email-jrigby@freescale.com>
On 5/23/07, John Rigby <jrigby@freescale.com> wrote:
> Use idx as index into mpc52xx_uart_nodes instead of i
>
> Signed-off-by: John Rigby <jrigby@freescale.com>
Good catch
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Fix mpc52xx_uart_of_assign to use correct index
From: John Rigby @ 2007-05-23 17:30 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sylvain Munaut, John Rigby
Use idx as index into mpc52xx_uart_nodes instead of i
Signed-off-by: John Rigby <jrigby@freescale.com>
---
drivers/serial/mpc52xx_uart.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 3cc2fb9..0648017 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -1114,7 +1114,7 @@ mpc52xx_uart_of_assign(struct device_node *np, int idx)
/* If the slot is already occupied, then swap slots */
if (mpc52xx_uart_nodes[idx] && (free_idx != -1))
mpc52xx_uart_nodes[free_idx] = mpc52xx_uart_nodes[idx];
- mpc52xx_uart_nodes[i] = np;
+ mpc52xx_uart_nodes[idx] = np;
}
static void
--
1.5.1.1.174.gabbf5
^ permalink raw reply related
* [PATCH 4/4] powerpc: tweak EEH copyright info
From: Linas Vepstas @ 2007-05-23 17:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070523171328.GY5921@austin.ibm.com>
Twiddle the copyright notices. Per current guidelines, the use
of the (C) or (c) in source code is deprecated.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 6 +++++-
arch/powerpc/platforms/pseries/eeh_cache.c | 3 ++-
arch/powerpc/platforms/pseries/eeh_driver.c | 6 +++---
3 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:44:52.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:54:06.000000000 -0500
@@ -1,6 +1,8 @@
/*
* eeh.c
- * Copyright (C) 2001 Dave Engebretsen & Todd Inglett IBM Corporation
+ * Copyright IBM Corporation 2001, 2005, 2006
+ * Copyright Dave Engebretsen & Todd Inglett 2001
+ * Copyright Linas Vepstas 2005, 2006
*
* 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
@@ -15,6 +17,8 @@
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Please address comments and feedback to Linas Vepstas <linas@austin.ibm.com>
*/
#include <linux/delay.h>
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_cache.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh_cache.c 2007-05-23 11:44:43.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_cache.c 2007-05-23 11:54:31.000000000 -0500
@@ -2,7 +2,8 @@
* eeh_cache.c
* PCI address cache; allows the lookup of PCI devices based on I/O address
*
- * Copyright (C) 2004 Linas Vepstas <linas@austin.ibm.com> IBM Corporation
+ * Copyright IBM Corporation 2004
+ * Copyright Linas Vepstas <linas@austin.ibm.com> 2004
*
* 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
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2007-05-23 11:43:44.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_driver.c 2007-05-23 11:52:51.000000000 -0500
@@ -1,6 +1,7 @@
/*
* PCI Error Recovery Driver for RPA-compliant PPC64 platform.
- * Copyright (C) 2004, 2005 Linas Vepstas <linas@linas.org>
+ * Copyright IBM Corp. 2004 2005
+ * Copyright Linas Vepstas <linas@linas.org> 2004, 2005
*
* All rights reserved.
*
@@ -19,8 +20,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
- * Send feedback to <linas@us.ibm.com>
- *
+ * Send comments and feedback to Linas Vepstas <linas@austin.ibm.com>
*/
#include <linux/delay.h>
#include <linux/interrupt.h>
^ permalink raw reply
* [PATCH 3/4] powerpc: remove dead EEH code.
From: Linas Vepstas @ 2007-05-23 17:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070523171328.GY5921@austin.ibm.com>
Remove some dead code.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:57:28.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:57:34.000000000 -0500
@@ -117,7 +117,6 @@ static unsigned long no_cfg_addr;
static unsigned long ignored_check;
static unsigned long total_mmio_ffs;
static unsigned long false_positives;
-static unsigned long ignored_failures;
static unsigned long slot_resets;
#define IS_BRIDGE(class_code) (((class_code)<<16) == PCI_BASE_CLASS_BRIDGE)
@@ -1221,11 +1220,10 @@ static int proc_eeh_show(struct seq_file
"check not wanted=%ld\n"
"eeh_total_mmio_ffs=%ld\n"
"eeh_false_positives=%ld\n"
- "eeh_ignored_failures=%ld\n"
"eeh_slot_resets=%ld\n",
no_device, no_dn, no_cfg_addr,
ignored_check, total_mmio_ffs,
- false_positives, ignored_failures,
+ false_positives,
slot_resets);
}
^ permalink raw reply
* [PATCH 2/4] powerpc: show EEH per-device false positives.
From: Linas Vepstas @ 2007-05-23 17:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070523171328.GY5921@austin.ibm.com>
Track and report the number of 0xff false 0xff reads
generated by a specific device.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 5 +++++
arch/powerpc/platforms/pseries/eeh_sysfs.c | 3 +++
include/asm-powerpc/pci-bridge.h | 1 +
3 files changed, 9 insertions(+)
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:56:53.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:57:28.000000000 -0500
@@ -505,6 +505,7 @@ int eeh_dn_check_failure(struct device_n
printk(KERN_WARNING "EEH: read_slot_reset_state() failed; rc=%d dn=%s\n",
ret, dn->full_name);
false_positives++;
+ pdn->eeh_false_positives ++;
rc = 0;
goto dn_unlock;
}
@@ -513,6 +514,7 @@ int eeh_dn_check_failure(struct device_n
* they are empty when they don't have children. */
if ((rets[0] == 5) && (dn->child == NULL)) {
false_positives++;
+ pdn->eeh_false_positives ++;
rc = 0;
goto dn_unlock;
}
@@ -522,6 +524,7 @@ int eeh_dn_check_failure(struct device_n
printk(KERN_WARNING "EEH: event on unsupported device, rc=%d dn=%s\n",
ret, dn->full_name);
false_positives++;
+ pdn->eeh_false_positives ++;
rc = 0;
goto dn_unlock;
}
@@ -529,6 +532,7 @@ int eeh_dn_check_failure(struct device_n
/* If not the kind of error we know about, punt. */
if (rets[0] != 1 && rets[0] != 2 && rets[0] != 4 && rets[0] != 5) {
false_positives++;
+ pdn->eeh_false_positives ++;
rc = 0;
goto dn_unlock;
}
@@ -921,6 +925,7 @@ static void *early_enable_eeh(struct dev
pdn->eeh_mode = 0;
pdn->eeh_check_count = 0;
pdn->eeh_freeze_count = 0;
+ pdn->eeh_false_positives = 0;
if (status && strcmp(status, "ok") != 0)
return NULL; /* ignore devices with bad status */
Index: linux-2.6.22-rc1/include/asm-powerpc/pci-bridge.h
===================================================================
--- linux-2.6.22-rc1.orig/include/asm-powerpc/pci-bridge.h 2007-05-23 11:56:53.000000000 -0500
+++ linux-2.6.22-rc1/include/asm-powerpc/pci-bridge.h 2007-05-23 11:57:28.000000000 -0500
@@ -83,6 +83,7 @@ struct pci_dn {
int eeh_pe_config_addr; /* new-style partition endpoint address */
int eeh_check_count; /* # times driver ignored error */
int eeh_freeze_count; /* # times this device froze up. */
+ int eeh_false_positives; /* # times this device reported #ff's */
u32 config_space[16]; /* saved PCI config space */
#endif
};
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_sysfs.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh_sysfs.c 2007-05-23 11:57:23.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_sysfs.c 2007-05-23 11:57:28.000000000 -0500
@@ -58,6 +58,7 @@ EEH_SHOW_ATTR(eeh_config_addr, eeh_confi
EEH_SHOW_ATTR(eeh_pe_config_addr, eeh_pe_config_addr, "0x%x");
EEH_SHOW_ATTR(eeh_check_count, eeh_check_count, "%d");
EEH_SHOW_ATTR(eeh_freeze_count, eeh_freeze_count, "%d");
+EEH_SHOW_ATTR(eeh_false_positives, eeh_false_positives, "%d");
void eeh_sysfs_add_device(struct pci_dev *pdev)
{
@@ -67,6 +68,7 @@ void eeh_sysfs_add_device(struct pci_dev
rc += device_create_file(&pdev->dev, &dev_attr_eeh_config_addr);
rc += device_create_file(&pdev->dev, &dev_attr_eeh_pe_config_addr);
rc += device_create_file(&pdev->dev, &dev_attr_eeh_check_count);
+ rc += device_create_file(&pdev->dev, &dev_attr_eeh_false_positives);
rc += device_create_file(&pdev->dev, &dev_attr_eeh_freeze_count);
if (rc)
@@ -79,6 +81,7 @@ void eeh_sysfs_remove_device(struct pci_
device_remove_file(&pdev->dev, &dev_attr_eeh_config_addr);
device_remove_file(&pdev->dev, &dev_attr_eeh_pe_config_addr);
device_remove_file(&pdev->dev, &dev_attr_eeh_check_count);
+ device_remove_file(&pdev->dev, &dev_attr_eeh_false_positives);
device_remove_file(&pdev->dev, &dev_attr_eeh_freeze_count);
}
^ permalink raw reply
* [PATCH 1/4] powerpc: Add EEH sysfs blinkenlights
From: Linas Vepstas @ 2007-05-23 17:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070523171328.GY5921@austin.ibm.com>
Add sysfs blinkenlights for EEH statistics. Shuffle the
eeh_add_device_tree() call so that it appears in the correct
sequence.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/Makefile | 2
arch/powerpc/platforms/pseries/eeh.c | 4 +
arch/powerpc/platforms/pseries/eeh_cache.c | 2
arch/powerpc/platforms/pseries/eeh_sysfs.c | 84 +++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/pci_dlpar.c | 7 +-
include/asm-powerpc/ppc-pci.h | 3 +
6 files changed, 98 insertions(+), 4 deletions(-)
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_sysfs.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_sysfs.c 2007-05-23 11:57:23.000000000 -0500
@@ -0,0 +1,84 @@
+/*
+ * Sysfs entries for PCI Error Recovery for PAPR-compliant platform.
+ * Copyright IBM Corporation 2007
+ * Copyright Linas Vepstas <linas@austin.ibm.com> 2007
+ *
+ * All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Send comments and feedback to Linas Vepstas <linas@austin.ibm.com>
+ */
+#include <linux/pci.h>
+#include <asm/ppc-pci.h>
+#include <asm/pci-bridge.h>
+#include <linux/kobject.h>
+
+/**
+ * EEH_SHOW_ATTR -- create sysfs entry for eeh statistic
+ * @_name: name of file in sysfs directory
+ * @_memb: name of member in struct pci_dn to access
+ * @_format: printf format for display
+ *
+ * All of the attributes look very similar, so just
+ * auto-gen a cut-n-paste routine to display them.
+ */
+#define EEH_SHOW_ATTR(_name,_memb,_format) \
+static ssize_t eeh_show_##_name(struct device *dev, \
+ struct device_attribute *attr, char *buf) \
+{ \
+ struct pci_dev *pdev = to_pci_dev(dev); \
+ struct device_node *dn = pci_device_to_OF_node(pdev); \
+ struct pci_dn *pdn; \
+ \
+ if (!dn || PCI_DN(dn) == NULL) \
+ return 0; \
+ \
+ pdn = PCI_DN(dn); \
+ return sprintf(buf, _format "\n", pdn->_memb); \
+} \
+static DEVICE_ATTR(_name, S_IRUGO, eeh_show_##_name, NULL);
+
+
+EEH_SHOW_ATTR(eeh_mode, eeh_mode, "0x%x");
+EEH_SHOW_ATTR(eeh_config_addr, eeh_config_addr, "0x%x");
+EEH_SHOW_ATTR(eeh_pe_config_addr, eeh_pe_config_addr, "0x%x");
+EEH_SHOW_ATTR(eeh_check_count, eeh_check_count, "%d");
+EEH_SHOW_ATTR(eeh_freeze_count, eeh_freeze_count, "%d");
+
+void eeh_sysfs_add_device(struct pci_dev *pdev)
+{
+ int rc=0;
+
+ rc += device_create_file(&pdev->dev, &dev_attr_eeh_mode);
+ rc += device_create_file(&pdev->dev, &dev_attr_eeh_config_addr);
+ rc += device_create_file(&pdev->dev, &dev_attr_eeh_pe_config_addr);
+ rc += device_create_file(&pdev->dev, &dev_attr_eeh_check_count);
+ rc += device_create_file(&pdev->dev, &dev_attr_eeh_freeze_count);
+
+ if (rc)
+ printk(KERN_WARNING "EEH: Unable to create sysfs entries\n");
+}
+
+void eeh_sysfs_remove_device(struct pci_dev *pdev)
+{
+ device_remove_file(&pdev->dev, &dev_attr_eeh_mode);
+ device_remove_file(&pdev->dev, &dev_attr_eeh_config_addr);
+ device_remove_file(&pdev->dev, &dev_attr_eeh_pe_config_addr);
+ device_remove_file(&pdev->dev, &dev_attr_eeh_check_count);
+ device_remove_file(&pdev->dev, &dev_attr_eeh_freeze_count);
+}
+
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/Makefile
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/Makefile 2007-05-23 11:43:42.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/Makefile 2007-05-23 11:44:43.000000000 -0500
@@ -8,7 +8,7 @@ obj-y := lpar.o hvCall.o nvram.o recon
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_XICS) += xics.o
obj-$(CONFIG_SCANLOG) += scanlog.o
-obj-$(CONFIG_EEH) += eeh.o eeh_cache.o eeh_driver.o eeh_event.o
+obj-$(CONFIG_EEH) += eeh.o eeh_cache.o eeh_driver.o eeh_event.o eeh_sysfs.o
obj-$(CONFIG_KEXEC) += kexec.o
obj-$(CONFIG_PCI) += pci.o pci_dlpar.o
obj-$(CONFIG_PCI_MSI) += msi.o
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:43:44.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh.c 2007-05-23 11:56:53.000000000 -0500
@@ -1139,7 +1139,8 @@ static void eeh_add_device_late(struct p
pdn = PCI_DN(dn);
pdn->pcidev = dev;
- pci_addr_cache_insert_device (dev);
+ pci_addr_cache_insert_device(dev);
+ eeh_sysfs_add_device(dev);
}
void eeh_add_device_tree_late(struct pci_bus *bus)
@@ -1178,6 +1179,7 @@ static void eeh_remove_device(struct pci
printk(KERN_DEBUG "EEH: remove device %s\n", pci_name(dev));
#endif
pci_addr_cache_remove_device(dev);
+ eeh_sysfs_remove_device(dev);
dn = pci_device_to_OF_node(dev);
if (PCI_DN(dn)->pcidev) {
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_cache.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/eeh_cache.c 2007-05-23 11:43:44.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_cache.c 2007-05-23 11:56:52.000000000 -0500
@@ -295,6 +295,8 @@ void __init pci_addr_cache_build(void)
continue;
pci_dev_get (dev); /* matching put is in eeh_remove_device() */
PCI_DN(dn)->pcidev = dev;
+
+ eeh_sysfs_add_device(dev);
}
#ifdef DEBUG
Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/pci_dlpar.c
===================================================================
--- linux-2.6.22-rc1.orig/arch/powerpc/platforms/pseries/pci_dlpar.c 2007-05-23 11:43:42.000000000 -0500
+++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/pci_dlpar.c 2007-05-23 11:44:43.000000000 -0500
@@ -110,8 +110,6 @@ pcibios_fixup_new_pci_devices(struct pci
}
}
}
-
- eeh_add_device_tree_late(bus);
}
EXPORT_SYMBOL_GPL(pcibios_fixup_new_pci_devices);
@@ -139,6 +137,8 @@ pcibios_pci_config_bridge(struct pci_dev
/* Make the discovered devices available */
pci_bus_add_devices(child_bus);
+
+ eeh_add_device_tree_late(child_bus);
return 0;
}
@@ -171,6 +171,7 @@ pcibios_add_pci_devices(struct pci_bus *
if (!list_empty(&bus->devices)) {
pcibios_fixup_new_pci_devices(bus, 0);
pci_bus_add_devices(bus);
+ eeh_add_device_tree_late(bus);
}
} else if (mode == PCI_PROBE_NORMAL) {
/* use legacy probe */
@@ -179,6 +180,7 @@ pcibios_add_pci_devices(struct pci_bus *
if (num) {
pcibios_fixup_new_pci_devices(bus, 1);
pci_bus_add_devices(bus);
+ eeh_add_device_tree_late(bus);
}
list_for_each_entry(dev, &bus->devices, bus_list)
@@ -210,6 +212,7 @@ struct pci_controller * __devinit init_p
scan_phb(phb);
pcibios_fixup_new_pci_devices(phb->bus, 0);
pci_bus_add_devices(phb->bus);
+ eeh_add_device_tree_late(phb->bus);
return phb;
}
Index: linux-2.6.22-rc1/include/asm-powerpc/ppc-pci.h
===================================================================
--- linux-2.6.22-rc1.orig/include/asm-powerpc/ppc-pci.h 2007-05-23 11:43:42.000000000 -0500
+++ linux-2.6.22-rc1/include/asm-powerpc/ppc-pci.h 2007-05-23 11:44:43.000000000 -0500
@@ -139,6 +139,9 @@ void eeh_clear_slot (struct device_node
*/
struct device_node * find_device_pe(struct device_node *dn);
+void eeh_sysfs_add_device(struct pci_dev *pdev);
+void eeh_sysfs_remove_device(struct pci_dev *pdev);
+
#endif /* CONFIG_EEH */
#else /* CONFIG_PCI */
^ permalink raw reply
* [PATCH 0/4] powerpc: EEH blinkenlights, copyright cleanup
From: Linas Vepstas @ 2007-05-23 17:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Hi Paul,
A series of fun but low-priority patches to add per-device EEH
statistics to sysfs. Also, a copyright cleanup.
One RFC: summary EEH info is currently in /proc/ppc64/eeh.
I could prepare a patch to move this to somewhere in the
sysfs tree ... but I couldn't see the point. Is it worth
the effort? Do you (or anyone else) care?
--linas
^ permalink raw reply
* Re: ML403 2.6 kernel, root file system on NFS, stops after freeing unused kernel memory
From: Grant Likely @ 2007-05-23 16:58 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W12CE664522EEB409218C3FB2350@phx.gbl>
On 5/23/07, Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>
> Hi all
>
> I have studied the disscussion here mainly by Mirek32 (I think this was the name) but unfortunately the disscussion is finished without any suitable answer and solution.
>
> the 2.6 kernel comes up on ml403 with no problem, it gets an IP address from my DHCP and mounts the root file system from my NFS server , all of these are ok.
>
> Unfortunately , after "freeing unused kernel memory ", init , console stops working however the board is alive because it answers all of my pings correctly. I tried to make a telnet connection to the board with no success. ( I'm using ELDK 4.0)
>
> any suggestions what is happening here?
Is there a /dev/console node?
try booting with init=/bin/sh to see if you get a console.
Your /etc/inittab might not be starting a getty on the console device.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Phil Terry @ 2007-05-23 16:43 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <Pine.LNX.4.64.0705231119271.1028@localhost.localdomain>
On Wed, 2007-05-23 at 11:20 -0500, Kumar Gala wrote:
> On Wed, 23 May 2007, Phil Terry wrote:
>
> > On Wed, 2007-05-23 at 18:05 +0200, Segher Boessenkool wrote:
> > > >> The law should really be removed.
> > > > In my application I'm may be using a huge part of the 36-bit address
> > > > space to address multiple remote RIO boards in a peer DMA multicomputer
> > > > application. The default law just for maintenance messages isn't going
> > > > to cut it.
> > >
> > > If the firmware sets up the "law", it should put a property
> > > in the node describing the setting. If Linux sets up the
> > > laws, there shouldn't be a property (since it is a policy
> > > decision).
> > Ooops, I just posted a question to you before I saw this pop up sorry?
> >
> > But when you say "firmware" do you mean u-boot or your kernel loading
> > code or do you mean some aspect of the hardware, eg, its EEPROM program
> > which can vary from hardware to hardware instantiation?
> >
> > If you mean u-boot I'm confused (so whats new?). AFAIK u-boot can't
> > probe and set this up and even if it did, linux in the arch's I'm
> > familiar with sets everything up anew regardless of what the boot loader
> > did. AFAIK in the freescale processors the dtb is being passed in from
> > u-boot as a supplied with the kernel build "blob" not because it built
> > it dynamically. Or again have I got hold of the wrong end of the stick?
>
> That's mostly true, but you are looking at it from one implementations
> point of view, not from how its architected. In the future we may (and I
> will) have u-boot capable of doing more dynamic building of the device
> tree or someother firmware. All the kernel knows is its handed a device
> tree.
OK, but if the device tree is not allowed to dictate policy, to use
Segher's term, just hardware characteristics, how does that help us get
the embedded soc kernels away from being designed and built to specific
demo/eval board setups and make them more configurable?
I got the impression that to some extent thats how you/we/?? were trying
to use the dts stuff. If my board is exactly like freescales xyz demo
board except I move my rio map to here, my pci map to here, change a few
sizes etc., why do I have to go and patchup the arch setup code, modify
ppc_md routines, etc. Isn't the plan that I just edit the dts, compile
with dtc and have u-boot pass in the dtb to the stock kernel and its
boots on my board?
If dts can't do this because its not allowed policy statements then what
will do this?
What device in the dts represents the soc mpx/mpc where I can define
what the laws should be? Segher is right, its not a property of the
rapidio device, it doesn't have a BAR (though it does have ATMUs?). But
if I have a device representing the mpx/mpc (the soc itself?) then I can
specify ranges for child devices to operate in (the laws) and then in
the child device I can specify ranges for the ATMUs?
I'm probably trampling over a ton of old stuff here, sorry, excuse my
ramblings....
Please I'm not trying to start up any previous turf wars here, just
trying to understand the truce terms and the plan ahead so I can get
with the program. Appreciate the help for a newbie.
Cheers
Phil
>
> - k
>
> > > Cheers
> > Phil
> >
> > >
> > > >>> The dbells and mboxs can be removed. The default setting in rio is
> > > >>> okay.
> > > >>
> > > >> this could possibly be useful.
> > >
> > > Same issue. Even if the firmware uses a default setting,
> > > it should still put it in the device tree _iff_ it is the
> > > firmware's decision (and not the kernel's).
> > >
> > >
> > > Segher
> > >
> > >
> > >
> >
> >
>
>
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Kumar Gala @ 2007-05-23 16:20 UTC (permalink / raw)
To: Phil Terry; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <1179937253.11247.44.camel@pterry-fc6.micromemory.com>
On Wed, 23 May 2007, Phil Terry wrote:
> On Wed, 2007-05-23 at 18:05 +0200, Segher Boessenkool wrote:
> > >> The law should really be removed.
> > > In my application I'm may be using a huge part of the 36-bit address
> > > space to address multiple remote RIO boards in a peer DMA multicomputer
> > > application. The default law just for maintenance messages isn't going
> > > to cut it.
> >
> > If the firmware sets up the "law", it should put a property
> > in the node describing the setting. If Linux sets up the
> > laws, there shouldn't be a property (since it is a policy
> > decision).
> Ooops, I just posted a question to you before I saw this pop up sorry?
>
> But when you say "firmware" do you mean u-boot or your kernel loading
> code or do you mean some aspect of the hardware, eg, its EEPROM program
> which can vary from hardware to hardware instantiation?
>
> If you mean u-boot I'm confused (so whats new?). AFAIK u-boot can't
> probe and set this up and even if it did, linux in the arch's I'm
> familiar with sets everything up anew regardless of what the boot loader
> did. AFAIK in the freescale processors the dtb is being passed in from
> u-boot as a supplied with the kernel build "blob" not because it built
> it dynamically. Or again have I got hold of the wrong end of the stick?
That's mostly true, but you are looking at it from one implementations
point of view, not from how its architected. In the future we may (and I
will) have u-boot capable of doing more dynamic building of the device
tree or someother firmware. All the kernel knows is its handed a device
tree.
- k
> > Cheers
> Phil
>
> >
> > >>> The dbells and mboxs can be removed. The default setting in rio is
> > >>> okay.
> > >>
> > >> this could possibly be useful.
> >
> > Same issue. Even if the firmware uses a default setting,
> > it should still put it in the device tree _iff_ it is the
> > firmware's decision (and not the kernel's).
> >
> >
> > Segher
> >
> >
> >
>
>
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Phil Terry @ 2007-05-23 16:20 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <836bca7802dca173490f4d38e0c48b7a@kernel.crashing.org>
On Wed, 2007-05-23 at 18:05 +0200, Segher Boessenkool wrote:
> >> The law should really be removed.
> > In my application I'm may be using a huge part of the 36-bit address
> > space to address multiple remote RIO boards in a peer DMA multicomputer
> > application. The default law just for maintenance messages isn't going
> > to cut it.
>
> If the firmware sets up the "law", it should put a property
> in the node describing the setting. If Linux sets up the
> laws, there shouldn't be a property (since it is a policy
> decision).
Ooops, I just posted a question to you before I saw this pop up sorry?
But when you say "firmware" do you mean u-boot or your kernel loading
code or do you mean some aspect of the hardware, eg, its EEPROM program
which can vary from hardware to hardware instantiation?
If you mean u-boot I'm confused (so whats new?). AFAIK u-boot can't
probe and set this up and even if it did, linux in the arch's I'm
familiar with sets everything up anew regardless of what the boot loader
did. AFAIK in the freescale processors the dtb is being passed in from
u-boot as a supplied with the kernel build "blob" not because it built
it dynamically. Or again have I got hold of the wrong end of the stick?
Cheers
Phil
>
> >>> The dbells and mboxs can be removed. The default setting in rio is
> >>> okay.
> >>
> >> this could possibly be useful.
>
> Same issue. Even if the firmware uses a default setting,
> it should still put it in the device tree _iff_ it is the
> firmware's decision (and not the kernel's).
>
>
> Segher
>
>
>
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Phil Terry @ 2007-05-23 16:13 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev
In-Reply-To: <0389b4398a09293e6b6e0e4304a81ebe@kernel.crashing.org>
On Wed, 2007-05-23 at 18:00 +0200, Segher Boessenkool wrote:
> >>> interrupts = <30 1 31 1 32 1 35 1 36 1 37 1 38 1>;
> >>>
> >> Do you really use all of this interrupts? In my test, three <32 2 35 2
> >> 36 2> are okay, and the sense is 2.
> >
> > I think we need to list all the interrupts possible from RIO, not just
> > the
> > ones the driver happens to use.
>
> Yes exactly; the device tree describes the hardware, not
> the way that Linux (or any other OS) happens to use it.
So a law is a bit like a BAR in PCI, its a configuration by software of
the memory map determining which accesses are directed at the hardware.
Unlike PCI its not something we can go around probing the hardware for
and then doling out memory space to them. Its purely up to software as a
whole to decide its system wide memory map. Its not that the device
"needs" x amount of memory to work, its a case of for your application
how much of your memory would you like this device to handle for you.
Is this something the dts as a central, early boottime thing should be
in charge of, ie telling the kernel how to organize its total memory
map?
Excuse the noobie questions but I haven't been able to work out the
provenance of the open firmware stuff, and the resolution between the
ppc32, ppc64, powerpc, apple, ibm, freescale, etc., camps on how this
stuff should be used from the archives, too much noise to signal.
Cheers
Phil
>
> The same holds for the "law", "doorbells", and "mailboxes"
> properties -- I have no clue whether those are hardware
> properties or what else, you guys figure it out :-)
>
>
> Segher
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* ML403 2.6 kernel, root file system on NFS, stops after freeing unused kernel memory
From: Mohammad Sadegh Sadri @ 2007-05-23 16:06 UTC (permalink / raw)
To: Linux PPC Linux PPC
Hi all
I have studied the disscussion here mainly by Mirek32 (I think this was the=
name) but unfortunately the disscussion is finished without any suitable =
answer and solution.
the 2.6 kernel comes up on ml403 with no problem, it gets an IP address fro=
m my DHCP and mounts the root file system from my NFS server , all of these=
are ok.=20
Unfortunately , after "freeing unused kernel memory ", init , console stops=
working however the board is alive because it answers all of my pings corr=
ectly. I tried to make a telnet connection to the board with no success. ( =
I'm using ELDK 4.0)=20
any suggestions what is happening here?
how can I enable the telnet server so that I can make a telnet connection t=
o the board, As I said the board is alive and answers pings but does not pr=
int any thing on the screen.
thanks.
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=3Dwindows+vista&mkt=3Den-US&form=3DQBR=
E=
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Segher Boessenkool @ 2007-05-23 16:05 UTC (permalink / raw)
To: pterry; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <1179934657.11247.14.camel@pterry-fc6.micromemory.com>
>> The law should really be removed.
> In my application I'm may be using a huge part of the 36-bit address
> space to address multiple remote RIO boards in a peer DMA multicomputer
> application. The default law just for maintenance messages isn't going
> to cut it.
If the firmware sets up the "law", it should put a property
in the node describing the setting. If Linux sets up the
laws, there shouldn't be a property (since it is a policy
decision).
>>> The dbells and mboxs can be removed. The default setting in rio is
>>> okay.
>>
>> this could possibly be useful.
Same issue. Even if the firmware uses a default setting,
it should still put it in the device tree _iff_ it is the
firmware's decision (and not the kernel's).
Segher
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Segher Boessenkool @ 2007-05-23 16:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <Pine.LNX.4.64.0705230916170.535@localhost.localdomain>
>>> interrupts = <30 1 31 1 32 1 35 1 36 1 37 1 38 1>;
>>>
>> Do you really use all of this interrupts? In my test, three <32 2 35 2
>> 36 2> are okay, and the sense is 2.
>
> I think we need to list all the interrupts possible from RIO, not just
> the
> ones the driver happens to use.
Yes exactly; the device tree describes the hardware, not
the way that Linux (or any other OS) happens to use it.
The same holds for the "law", "doorbells", and "mailboxes"
properties -- I have no clue whether those are hardware
properties or what else, you guys figure it out :-)
Segher
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Segher Boessenkool @ 2007-05-23 15:55 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev list, David Gibson
In-Reply-To: <1B5F013528140F45B5C671039279CA5701BBBDE3@NANUK.pc.tundra.com>
> On power up, because this pin is pulled high by the LED, the
> TXC_RXC_DELAY mode is enabled, causing a 1.9ns delay between the clock
> and data on the GMII interface. Tsi109 could not operate properly with
> this delay. The TXC_RXC_DELAY mode has to be disabled by software.
>
> If the Quality/TXC_RXC_DELAY pin is left not connected PHY will work in
> normal mode without delay and therefore the workaround is not required.
So it is a board-specific workaround.
> I think that for situations like one on the Holly board we may need
> board-specific hooks which modify normal initialization. As in our
> case:
> no LED - no trouble.
Should be initiated from the platform code yes; it could
be as simple as passing a flag to the init function.
> -----Original Message-----
Don't top-post :-)
Segher
^ permalink raw reply
* RE: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Phil Terry @ 2007-05-23 15:54 UTC (permalink / raw)
To: Wei.Zhang; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C234AEC@zch01exm26.fsl.freescale.net>
On Wed, 2007-05-23 at 22:03 +0800, Zhang Wei-r63237 wrote:
> Hi, Mark
>
> Yes, I'm glad to share it. I have added the memory mapping codes into
> it.
>
> These codes are reviewing and testing with our engineers.
Can you tell me what your testing it on cos we need to get a good
interim base for our own development. The 8641_hpcn doesn't have support
for serial rapidio so I was looking at the 8548 eval system. The ltib
support is way back at 2.6.10 for that board but I was going to try and
make my powerpc/rapidio support both the 8641 and 8548 so I could test
in this way. Is your patch generic or 8641 specific?
Also either on this list or privately can you tell me what the plans are
for migrating the other freescale processors to powerpc and updating to
the latest kernel?
Cheers
Phil
> Could you
> waiting for a little while? It will be soon.
>
> Best Regards,
> Zhang Wei
>
> > -----Original Message-----
> > From: Mark A. Greer [mailto:mgreer@mvista.com]
> > Sent: Wednesday, May 23, 2007 9:33 PM
> > To: Zhang Wei-r63237
> > Cc: pterry@micromemory.com; linuxppc-dev@ozlabs.org
> > Subject: Re: Porting RapidIO from ppc arch to powerpc arch in
> > support of MPC8641D
> >
> > On Wed, May 23, 2007 at 09:26:59PM +0800, Zhang Wei-r63237 wrote:
> > > I've finished the porting RIO from ppc to powerpc, do you need some
> > > helps?
> >
> > Care to share the patches?
> >
> > Mark
> >
>
>
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Mark A. Greer @ 2007-05-23 15:53 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C234AEC@zch01exm26.fsl.freescale.net>
On Wed, May 23, 2007 at 10:03:30PM +0800, Zhang Wei-r63237 wrote:
> Hi, Mark
>
> Yes, I'm glad to share it. I have added the memory mapping codes into
> it.
>
> These codes are reviewing and testing with our engineers. Could you
> waiting for a little while? It will be soon.
Of course. I'm definitely interested in what you have, though, so
please share it as soon as you feel comfortable with it.
Mark
^ permalink raw reply
* RE: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Phil Terry @ 2007-05-23 15:42 UTC (permalink / raw)
To: Wei.Zhang; +Cc: linuxppc-dev
In-Reply-To: <46B96294322F7D458F9648B60E15112C234AEC@zch01exm26.fsl.freescale.net>
On Wed, 2007-05-23 at 22:03 +0800, Zhang Wei-r63237 wrote:
> Hi, Mark
>
> Yes, I'm glad to share it. I have added the memory mapping codes into
> it.
I have memory mapping requirements for my board above and beyond the
current driver. I'd like to see the above to see if its addressing my
needs.
>
> These codes are reviewing and testing with our engineers. Could you
> waiting for a little while? It will be soon.
Well I'm stuck for hw to test on at the moment so I don't need tested
patches right now but I would like to see whats covered so I can check
what I still need to do for my application. Soon means???
Cheers
Phil
>
> Best Regards,
> Zhang Wei
>
> > -----Original Message-----
> > From: Mark A. Greer [mailto:mgreer@mvista.com]
> > Sent: Wednesday, May 23, 2007 9:33 PM
> > To: Zhang Wei-r63237
> > Cc: pterry@micromemory.com; linuxppc-dev@ozlabs.org
> > Subject: Re: Porting RapidIO from ppc arch to powerpc arch in
> > support of MPC8641D
> >
> > On Wed, May 23, 2007 at 09:26:59PM +0800, Zhang Wei-r63237 wrote:
> > > I've finished the porting RIO from ppc to powerpc, do you need some
> > > helps?
> >
> > Care to share the patches?
> >
> > Mark
> >
>
>
^ permalink raw reply
* RE: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Phil Terry @ 2007-05-23 15:37 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <Pine.LNX.4.64.0705230916170.535@localhost.localdomain>
On Wed, 2007-05-23 at 09:21 -0500, Kumar Gala wrote:
> On Wed, 23 May 2007, Zhang Wei-r63237 wrote:
>
> > > So I'm taking the boot/dts/mpc8641_hpcn.dts and producing a new
> > > mpc8641D_umem.dts with the following addition to the soc.
> > >
> > > srio@c0000 {
> > > device_type = "srio";
> > > compatible = "86xx,85xx";
>
> We really need to think about this, is their really any difference between
> srio and prio from a software view point?
I didn't mean to imply that, the above was just my strawman for
discussion purposes in my overview question. As per a suggestion I was
now calling it rapidio@c0000.
But maybe this is moot, the patches are on their way (yippee) Thanks
Zhang.
>
> > > reg = <c0000 20000>;
> > > law = <400000000 e00000000>;
> >
> > Please use range = <0 address_start size>
>
> The law should really be removed.
In my application I'm may be using a huge part of the 36-bit address
space to address multiple remote RIO boards in a peer DMA multicomputer
application. The default law just for maintenance messages isn't going
to cut it. Now I suppose we could say that my DMA oriented driver should
be responsible for another law for that purpose but that seemed wasteful
to me, there aren't that many laws to go around. So I wanted to hijack
and make this one configurable. But this was just my first idea so I'm
open to suggestions.
>
> >
> > > dbells = <0 ffff>;
> > > mboxs = <0 4>;
> >
> > The dbells and mboxs can be removed. The default setting in rio is okay.
>
> this could possibly be useful.
Again, the current setup seems to be the minimum required to support
rionet. The hardware can support multiple mailboxes as is not just mbox
0 used by rionet. As I understand it one message unit is dedicated to
mbox 0 and mboxes 1 to 63 are used by the second message unit. I want in
my application to use the "clean" mbox 0 for my apps messaging and
relegate rionet to mbox 1. So in the interests of generality I wanted to
make the number of mboxes supported configurable. Is this something I
should not do in dts but relegate somewhere else?
The doorbells is debatable. There is only a single unit supporting all
doorbells in extant hardware (AFAIK) so this was again for generality in
case a dual doorbell hw unit arrives.
>
> >
> > > interrupt-parent = <&mpic>;
> > > interrupts = <30 1 31 1 32 1 35 1 36 1 37 1 38 1>;
> > > };
> > >
> > Do you really use all of this interrupts? In my test, three <32 2 35 2
> > 36 2> are okay, and the sense is 2.
>
> I think we need to list all the interrupts possible from RIO, not just the
> ones the driver happens to use.
Sorry about the senses, again I just threw that in the email as a
strawman to kick off discussion (which now seems moot as Wei has the
patches (yippee)). The second set of interrupts 37 and 38 are for the
second message unit which I want to use (see above). 30 is for
port-write/error which I will be using to get interrupts from my
switches for topology changes. 31 is the out doorbell done which the
driver doesn't use cos of the synchronous nature of the out doorbell I
suppose.
>
> - 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