* Re: [PATCH 2/2] Base pSeries PCIe support
From: Olof Johansson @ 2006-03-31 22:48 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060331161330.3c723103.moilanen@austin.ibm.com>
On Fri, Mar 31, 2006 at 04:13:30PM -0600, Jake Moilanen wrote:
> This patch hooks our current interrupt subsystem and sets up a single
> vector MSI as if it was a LSI. Multiple MSI vectors is coming in the
> future.
>
> The NR_IRQS got bumped up to 1024, as vectors can go much higher.
> Unfortunately, this number was arbitrarily picked as there is no claim
> at what the max number really is by either the firmware team, or the
> PAPR+.
What does this do to the kernel size?
> Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
>
> ---
>
> Index: 2.6.16/arch/powerpc/kernel/prom.c
> ===================================================================
> --- 2.6.16.orig/arch/powerpc/kernel/prom.c 2006-03-31 15:11:20.000000000 -0600
> +++ 2.6.16/arch/powerpc/kernel/prom.c 2006-03-31 15:37:10.000000000 -0600
> @@ -88,6 +88,8 @@
> struct device_node *dflt_interrupt_controller;
> int num_interrupt_controllers;
>
> +void __init finish_msi_node(struct device_node *dn, unsigned long *mem_start, int measure_only);
The other one is called "finish_node_interrupts", "finish_node_msi"
would make sense here.
> +
> /*
> * Wrapper for allocating memory for various data that needs to be
> * attached to device nodes as they are processed at boot or when
> @@ -120,6 +122,22 @@
> return NULL;
> }
>
> +int
> +property_present(struct device_node *np, const char *name)
> +{
> + struct property *pp;
> +
> + read_lock(&devtree_lock);
> + for (pp = np->properties; pp != 0; pp = pp->next)
> + if (strcmp(pp->name, name) == 0) {
> + return 1;
> + }
> + read_unlock(&devtree_lock);
> +
> + return 0;
> +}
Please use of_find_property() instead of reimplementing it, i.e. do what
get_property() does now, just don't return the value.
I assume you can't use get_property() because the properties you look
for lack values, right?
> +
> /*
> * Find the interrupt parent of a node.
> */
> @@ -341,6 +359,14 @@
> return 0;
> }
>
> +#ifdef CONFIG_PPC_PSERIES
> + if(property_present(np, "ibm,req#msi")) {
> + printk(KERN_EMERG "Found MSI\n");
KERN_DEBUG, if anything, right?
Also, get rid of the ifdef.
> + finish_msi_node(np, mem_start, measure_only);
> + return 0;
> + }
> +#endif
> +
> ints = (unsigned int *) get_property(np, "interrupts", &intlen);
> TRACE("ints=%p, intlen=%d\n", ints, intlen);
> if (ints == NULL)
> @@ -503,6 +529,80 @@
> DBG(" <- finish_device_tree\n");
> }
>
> +void __init finish_msi_node(struct device_node *dn, unsigned long *mem_start, int measure_only)
I know you said no hotplug support yet, but in preparation, it might
make sense to mark it as __devinit instead.
> +{
> + static int seq_num = 1;
> + int i;
> + int rc;
> + int query_token = rtas_token("ibm,query-interrupt-source-number");
> + int devfn;
> + int busno;
> + u32 *reg;
> + int reglen;
> + int ret[3];
> + unsigned int virq;
> + unsigned int addr;
> + unsigned long buid = -1;
> + unsigned long wait_time;
> +
> + reg = (u32 *) get_property(dn, "reg", ®len);
> + if (reg == NULL || reglen < 20)
> + return;
> +
> + devfn = (reg[0] >> 8) & 0xff;
> + busno = (reg[0] >> 16) & 0xff;
> +
> + buid = get_phb_buid(dn->parent);
> + addr = (busno << 16) | (devfn << 8);
> +
> + while (1) {
> + rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
> + buid >> 32, buid & 0xffffffff,
> + 1, 1, seq_num);
> +
> + if (!rc)
> + break;
> + else if (rc == RTAS_BUSY)
> + udelay(1);
> + else if (rtas_is_extended_busy(rc)) {
> + wait_time = rtas_extended_busy_delay_time(rc);
> + udelay(wait_time * 1000);
> + } else {
> + printk(KERN_WARNING "error[%d]: getting the number of"
> + "MSI interrupts for %s\n", rc, dn->name);
> + return;
> + }
This is reimplemented with a few variations in a few places now. They
should be consolidated into a single function that will handle the
delay itself.
> +
> + seq_num = ret[1];
> + }
> +
> + dn->n_intrs = ret[0];
> +
> + dn->intrs = prom_alloc(dn->n_intrs * sizeof(*(dn->intrs)), mem_start);
> + if (!dn->intrs) {
> + printk(KERN_EMERG "finish_msi_node: can't allocate space\n");
> + return;
> + }
> +
> + if (measure_only)
> + return;
You probably want to return from measure_only _before_ you allocate and
populate intrs...
> +
> + for (i = 0; i < dn->n_intrs; i++) {
> + rc = rtas_call(query_token, 4, 3, ret, addr, buid >> 32, buid & 0xffffffff, i);
> +
> + if (!rc) {
> + virq = virt_irq_create_mapping(ret[0]);
> +
> + dn->intrs[i].line = irq_offset_up(virq);
> + dn->intrs[i].sense = ret[1];
> + } else {
> + printk(KERN_WARNING "error[%d]: query-interrupt-source-number for %s\n",
> + rc, dn->name);
> + }
> + }
> +
> +}
> +
> static inline char *find_flat_dt_string(u32 offset)
> {
> return ((char *)initial_boot_params) +
> Index: 2.6.16/include/asm-powerpc/irq.h
> ===================================================================
> --- 2.6.16.orig/include/asm-powerpc/irq.h 2006-03-31 15:11:12.000000000 -0600
> +++ 2.6.16/include/asm-powerpc/irq.h 2006-03-31 15:15:46.000000000 -0600
> @@ -47,7 +47,7 @@
> /*
> * Maximum number of interrupt sources that we can handle.
> */
> -#define NR_IRQS 512
> +#define NR_IRQS 1024
>
> /* Interrupt numbers are virtual in case they are sparsely
> * distributed by the hardware.
> Index: 2.6.16/include/asm-powerpc/pci-bridge.h
> ===================================================================
> --- 2.6.16.orig/include/asm-powerpc/pci-bridge.h 2006-03-31 15:11:36.000000000 -0600
> +++ 2.6.16/include/asm-powerpc/pci-bridge.h 2006-03-31 15:34:50.000000000 -0600
> @@ -141,6 +141,7 @@
> void pcibios_fixup_new_pci_devices(struct pci_bus *bus, int fix_bus);
>
> extern int pcibios_remove_root_bus(struct pci_controller *phb);
> +extern unsigned long __devinit get_phb_buid (struct device_node *phb);
I think the get_phb_buid() call from prom.c might break 32-bit, since
rtas_pci.c isn't always built there. An empty declaration here for
#ifndef CONFIG_<x> would take care of it.
>
> static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
> {
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-03-31 22:35 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200604010028.43685.arnd@arndb.de>
On Sat, 1 Apr 2006 00:28:43 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> Am Saturday 01 April 2006 00:02 schrieb Jake Moilanen:
> > Here are the two base patches for PCIe on pSeries for 2.6.17.
> >
> > This is enough to probe, find, configure, and run basic I/O to PCIe
> > enabled devices.
>
> Does this use the draft PCIe bindings from Sun, or something else?
> Is it compatible with the way that Apple represents PCIe devices
> as plain PCI?
>
> I'm just curious.
You can find some info on it:
http://playground.sun.com/1275/bindings/pci/pci-express.txt
Jake
^ permalink raw reply
* Re: [PATCH 0/2] Base pSeries PCIe support
From: Doug Maxey @ 2006-03-31 22:39 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060331160203.f2bf8b53.moilanen@austin.ibm.com>
On Fri, 31 Mar 2006 16:02:03 CST, Jake Moilanen wrote:
>Here are the two base patches for PCIe on pSeries for 2.6.17.
>
>This is enough to probe, find, configure, and run basic I/O to PCIe
>enabled devices.
>
Where are the bindings for pcie? In the papr?
Have you heard of any effort to publish?
++doug
^ permalink raw reply
* Re: [PATCH 0/2] Base pSeries PCIe support
From: Arnd Bergmann @ 2006-03-31 22:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20060331160203.f2bf8b53.moilanen@austin.ibm.com>
Am Saturday 01 April 2006 00:02 schrieb Jake Moilanen:
> Here are the two base patches for PCIe on pSeries for 2.6.17.
>
> This is enough to probe, find, configure, and run basic I/O to PCIe
> enabled devices.
Does this use the draft PCIe bindings from Sun, or something else?
Is it compatible with the way that Apple represents PCIe devices
as plain PCI?
I'm just curious.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-03-31 22:18 UTC (permalink / raw)
To: Dave Hansen; +Cc: linuxppc-dev, paulus
In-Reply-To: <1143843311.9731.111.camel@localhost.localdomain>
On Fri, 31 Mar 2006 14:15:11 -0800
Dave Hansen <haveblue@us.ibm.com> wrote:
> On Fri, 2006-03-31 at 16:05 -0600, Jake Moilanen wrote:
> > --- 2.6.16.orig/arch/powerpc/kernel/rtas_pci.c 2006-03-31 15:11:20.000000000 -0600
> > +++ 2.6.16/arch/powerpc/kernel/rtas_pci.c 2006-03-31 15:15:35.000000000 -0600
> > @@ -315,7 +315,8 @@
> > for (node = of_get_next_child(root, NULL);
> > node != NULL;
> > node = of_get_next_child(root, node)) {
> > - if (node->type == NULL || strcmp(node->type, "pci") != 0)
> > +
> > + if (node->type == NULL || ((strcmp(node->type, "pci") != 0) && (strcmp(node->type, "pciex") != 0)))
> > continue;
>
> That one looks to have gone a wee bit over 80 columns.
I need to stop developing on my widescreen. :)
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
---
Index: 2.6.16/arch/powerpc/Kconfig
===================================================================
--- 2.6.16.orig/arch/powerpc/Kconfig 2006-03-31 16:13:26.000000000 -0600
+++ 2.6.16/arch/powerpc/Kconfig 2006-03-31 16:13:36.000000000 -0600
@@ -808,6 +808,8 @@
endchoice
+source "drivers/pci/pcie/Kconfig"
+
source "drivers/pci/Kconfig"
source "drivers/pcmcia/Kconfig"
Index: 2.6.16/arch/powerpc/kernel/pci_64.c
===================================================================
--- 2.6.16.orig/arch/powerpc/kernel/pci_64.c 2006-03-31 16:13:26.000000000 -0600
+++ 2.6.16/arch/powerpc/kernel/pci_64.c 2006-03-31 16:13:36.000000000 -0600
@@ -395,7 +395,7 @@
dev->current_state = 4; /* unknown power state */
- if (!strcmp(type, "pci")) {
+ if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
/* a PCI-PCI bridge */
dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
dev->rom_base_reg = PCI_ROM_ADDRESS1;
Index: 2.6.16/arch/powerpc/kernel/rtas_pci.c
===================================================================
--- 2.6.16.orig/arch/powerpc/kernel/rtas_pci.c 2006-03-31 16:13:26.000000000 -0600
+++ 2.6.16/arch/powerpc/kernel/rtas_pci.c 2006-03-31 16:14:10.000000000 -0600
@@ -315,7 +315,9 @@
for (node = of_get_next_child(root, NULL);
node != NULL;
node = of_get_next_child(root, node)) {
- if (node->type == NULL || strcmp(node->type, "pci") != 0)
+
+ if (node->type == NULL || ((strcmp(node->type, "pci") != 0) &&
+ (strcmp(node->type, "pciex") != 0)))
continue;
phb = pcibios_alloc_controller(node);
^ permalink raw reply
* [PATCH 2/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-03-31 22:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20060331160203.f2bf8b53.moilanen@austin.ibm.com>
This patch hooks our current interrupt subsystem and sets up a single
vector MSI as if it was a LSI. Multiple MSI vectors is coming in the
future.
The NR_IRQS got bumped up to 1024, as vectors can go much higher.
Unfortunately, this number was arbitrarily picked as there is no claim
at what the max number really is by either the firmware team, or the
PAPR+.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
---
Index: 2.6.16/arch/powerpc/kernel/prom.c
===================================================================
--- 2.6.16.orig/arch/powerpc/kernel/prom.c 2006-03-31 15:11:20.000000000 -0600
+++ 2.6.16/arch/powerpc/kernel/prom.c 2006-03-31 15:37:10.000000000 -0600
@@ -88,6 +88,8 @@
struct device_node *dflt_interrupt_controller;
int num_interrupt_controllers;
+void __init finish_msi_node(struct device_node *dn, unsigned long *mem_start, int measure_only);
+
/*
* Wrapper for allocating memory for various data that needs to be
* attached to device nodes as they are processed at boot or when
@@ -120,6 +122,22 @@
return NULL;
}
+int
+property_present(struct device_node *np, const char *name)
+{
+ struct property *pp;
+
+ read_lock(&devtree_lock);
+ for (pp = np->properties; pp != 0; pp = pp->next)
+ if (strcmp(pp->name, name) == 0) {
+ return 1;
+ }
+ read_unlock(&devtree_lock);
+
+ return 0;
+}
+
+
/*
* Find the interrupt parent of a node.
*/
@@ -341,6 +359,14 @@
return 0;
}
+#ifdef CONFIG_PPC_PSERIES
+ if(property_present(np, "ibm,req#msi")) {
+ printk(KERN_EMERG "Found MSI\n");
+ finish_msi_node(np, mem_start, measure_only);
+ return 0;
+ }
+#endif
+
ints = (unsigned int *) get_property(np, "interrupts", &intlen);
TRACE("ints=%p, intlen=%d\n", ints, intlen);
if (ints == NULL)
@@ -503,6 +529,80 @@
DBG(" <- finish_device_tree\n");
}
+void __init finish_msi_node(struct device_node *dn, unsigned long *mem_start, int measure_only)
+{
+ static int seq_num = 1;
+ int i;
+ int rc;
+ int query_token = rtas_token("ibm,query-interrupt-source-number");
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ unsigned int virq;
+ unsigned int addr;
+ unsigned long buid = -1;
+ unsigned long wait_time;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ while (1) {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 1, 1, seq_num);
+
+ if (!rc)
+ break;
+ else if (rc == RTAS_BUSY)
+ udelay(1);
+ else if (rtas_is_extended_busy(rc)) {
+ wait_time = rtas_extended_busy_delay_time(rc);
+ udelay(wait_time * 1000);
+ } else {
+ printk(KERN_WARNING "error[%d]: getting the number of"
+ "MSI interrupts for %s\n", rc, dn->name);
+ return;
+ }
+
+ seq_num = ret[1];
+ }
+
+ dn->n_intrs = ret[0];
+
+ dn->intrs = prom_alloc(dn->n_intrs * sizeof(*(dn->intrs)), mem_start);
+ if (!dn->intrs) {
+ printk(KERN_EMERG "finish_msi_node: can't allocate space\n");
+ return;
+ }
+
+ if (measure_only)
+ return;
+
+ for (i = 0; i < dn->n_intrs; i++) {
+ rc = rtas_call(query_token, 4, 3, ret, addr, buid >> 32, buid & 0xffffffff, i);
+
+ if (!rc) {
+ virq = virt_irq_create_mapping(ret[0]);
+
+ dn->intrs[i].line = irq_offset_up(virq);
+ dn->intrs[i].sense = ret[1];
+ } else {
+ printk(KERN_WARNING "error[%d]: query-interrupt-source-number for %s\n",
+ rc, dn->name);
+ }
+ }
+
+}
+
static inline char *find_flat_dt_string(u32 offset)
{
return ((char *)initial_boot_params) +
Index: 2.6.16/include/asm-powerpc/irq.h
===================================================================
--- 2.6.16.orig/include/asm-powerpc/irq.h 2006-03-31 15:11:12.000000000 -0600
+++ 2.6.16/include/asm-powerpc/irq.h 2006-03-31 15:15:46.000000000 -0600
@@ -47,7 +47,7 @@
/*
* Maximum number of interrupt sources that we can handle.
*/
-#define NR_IRQS 512
+#define NR_IRQS 1024
/* Interrupt numbers are virtual in case they are sparsely
* distributed by the hardware.
Index: 2.6.16/include/asm-powerpc/pci-bridge.h
===================================================================
--- 2.6.16.orig/include/asm-powerpc/pci-bridge.h 2006-03-31 15:11:36.000000000 -0600
+++ 2.6.16/include/asm-powerpc/pci-bridge.h 2006-03-31 15:34:50.000000000 -0600
@@ -141,6 +141,7 @@
void pcibios_fixup_new_pci_devices(struct pci_bus *bus, int fix_bus);
extern int pcibios_remove_root_bus(struct pci_controller *phb);
+extern unsigned long __devinit get_phb_buid (struct device_node *phb);
static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
{
^ permalink raw reply
* [PATCH 1/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-03-31 22:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20060331160203.f2bf8b53.moilanen@austin.ibm.com>
Added recognition of device_type: "pciex" and made PCIe portdrv
buildable on PPC64.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
---
Index: 2.6.16/arch/powerpc/Kconfig
===================================================================
--- 2.6.16.orig/arch/powerpc/Kconfig 2006-03-31 15:11:20.000000000 -0600
+++ 2.6.16/arch/powerpc/Kconfig 2006-03-31 15:15:35.000000000 -0600
@@ -808,6 +808,8 @@
endchoice
+source "drivers/pci/pcie/Kconfig"
+
source "drivers/pci/Kconfig"
source "drivers/pcmcia/Kconfig"
Index: 2.6.16/arch/powerpc/kernel/pci_64.c
===================================================================
--- 2.6.16.orig/arch/powerpc/kernel/pci_64.c 2006-03-31 15:11:20.000000000 -0600
+++ 2.6.16/arch/powerpc/kernel/pci_64.c 2006-03-31 15:15:35.000000000 -0600
@@ -395,7 +395,7 @@
dev->current_state = 4; /* unknown power state */
- if (!strcmp(type, "pci")) {
+ if (!strcmp(type, "pci") || !strcmp(type, "pciex")) {
/* a PCI-PCI bridge */
dev->hdr_type = PCI_HEADER_TYPE_BRIDGE;
dev->rom_base_reg = PCI_ROM_ADDRESS1;
Index: 2.6.16/arch/powerpc/kernel/rtas_pci.c
===================================================================
--- 2.6.16.orig/arch/powerpc/kernel/rtas_pci.c 2006-03-31 15:11:20.000000000 -0600
+++ 2.6.16/arch/powerpc/kernel/rtas_pci.c 2006-03-31 15:15:35.000000000 -0600
@@ -315,7 +315,8 @@
for (node = of_get_next_child(root, NULL);
node != NULL;
node = of_get_next_child(root, node)) {
- if (node->type == NULL || strcmp(node->type, "pci") != 0)
+
+ if (node->type == NULL || ((strcmp(node->type, "pci") != 0) && (strcmp(node->type, "pciex") != 0)))
continue;
phb = pcibios_alloc_controller(node);
^ permalink raw reply
* [PATCH 0/2] Base pSeries PCIe support
From: Jake Moilanen @ 2006-03-31 22:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Here are the two base patches for PCIe on pSeries for 2.6.17.
This is enough to probe, find, configure, and run basic I/O to PCIe
enabled devices.
The patches do not include PCIe hotplug, nor multiple MSI vectors per
adapter.
These patches have had limited testing, as firmware still is working on
a few MSI bugs of their own.
^ permalink raw reply
* [PATCH] powerpc/pseries: whitespace cleanups
From: Nathan Fontenot @ 2006-03-31 21:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
This patch is nothing but whitespace cleanup for eeh.c. This removes spaces
between function calls and their parameters, edits lines that are longer than
80 characters and puts function return variables and function names on one
line.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Index: nfont/kernel/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- nfont.orig/kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-31
09:02:17.%N -0600
+++ nfont/kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 14:34:43.%N
-0600
@@ -111,7 +111,7 @@ static unsigned long slot_resets;
/* --------------------------------------------------------------- */
/* Below lies the EEH event infrastructure */
-void eeh_slot_error_detail (struct pci_dn *pdn, int severity)
+void eeh_slot_error_detail(struct pci_dn *pdn, int severity)
{
int config_addr;
unsigned long flags;
@@ -126,13 +126,10 @@ void eeh_slot_error_detail (struct pci_d
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_slot_error_detail,
- 8, 1, NULL, config_addr,
- BUID_HI(pdn->phb->buid),
- BUID_LO(pdn->phb->buid), NULL, 0,
- virt_to_phys(slot_errbuf),
- eeh_error_buf_size,
- severity);
+ rc = rtas_call(ibm_slot_error_detail, 8, 1, NULL, config_addr,
+ BUID_HI(pdn->phb->buid), BUID_LO(pdn->phb->buid),
+ NULL, 0, virt_to_phys(slot_errbuf),
+ eeh_error_buf_size, severity);
if (rc == 0)
log_error(slot_errbuf, ERR_TYPE_RTAS_LOG, 0);
@@ -184,7 +181,7 @@ static inline unsigned long eeh_token_to
return pa | (token & (PAGE_SIZE-1));
}
-/**
+/**
* Return the "partitionable endpoint" (pe) under which this device lies
*/
struct device_node * find_device_pe(struct device_node *dn)
@@ -203,8 +200,7 @@ struct device_node * find_device_pe(stru
* and the slot is frozen, then the driver can deadlock in
* an interrupt context, which is bad.
*/
-
-static void __eeh_mark_slot (struct device_node *dn, int mode_flag)
+static void __eeh_mark_slot(struct device_node *dn, int mode_flag)
{
while (dn) {
if (PCI_DN(dn)) {
@@ -217,13 +213,13 @@ static void __eeh_mark_slot (struct devi
dev->error_state = pci_channel_io_frozen;
if (dn->child)
- __eeh_mark_slot (dn->child, mode_flag);
+ __eeh_mark_slot(dn->child, mode_flag);
}
dn = dn->sibling;
}
}
-void eeh_mark_slot (struct device_node *dn, int mode_flag)
+void eeh_mark_slot(struct device_node *dn, int mode_flag)
{
dn = find_device_pe (dn);
@@ -232,36 +228,36 @@ void eeh_mark_slot (struct device_node *
dn = dn->parent;
PCI_DN(dn)->eeh_mode |= mode_flag;
- __eeh_mark_slot (dn->child, mode_flag);
+ __eeh_mark_slot(dn->child, mode_flag);
}
-static void __eeh_clear_slot (struct device_node *dn, int mode_flag)
+static void __eeh_clear_slot(struct device_node *dn, int mode_flag)
{
while (dn) {
if (PCI_DN(dn)) {
PCI_DN(dn)->eeh_mode &= ~mode_flag;
PCI_DN(dn)->eeh_check_count = 0;
if (dn->child)
- __eeh_clear_slot (dn->child, mode_flag);
+ __eeh_clear_slot(dn->child, mode_flag);
}
dn = dn->sibling;
}
}
-void eeh_clear_slot (struct device_node *dn, int mode_flag)
+void eeh_clear_slot(struct device_node *dn, int mode_flag)
{
unsigned long flags;
spin_lock_irqsave(&confirm_error_lock, flags);
-
+
dn = find_device_pe (dn);
-
+
/* Back up one, since config addrs might be shared */
if (PCI_DN(dn) && PCI_DN(dn)->eeh_pe_config_addr)
dn = dn->parent;
PCI_DN(dn)->eeh_mode &= ~mode_flag;
PCI_DN(dn)->eeh_check_count = 0;
- __eeh_clear_slot (dn->child, mode_flag);
+ __eeh_clear_slot(dn->child, mode_flag);
spin_unlock_irqrestore(&confirm_error_lock, flags);
}
@@ -305,8 +301,8 @@ int eeh_dn_check_failure(struct device_n
pdn->eeh_mode & EEH_MODE_NOCHECK) {
ignored_check++;
#ifdef DEBUG
- printk ("EEH:ignored check (%x) for %s %s\n",
- pdn->eeh_mode, pci_name (dev), dn->full_name);
+ printk("EEH:ignored check (%x) for %s %s\n",
+ pdn->eeh_mode, pci_name(dev), dn->full_name);
#endif
return 0;
}
@@ -327,16 +323,17 @@ int eeh_dn_check_failure(struct device_n
if (pdn->eeh_mode & EEH_MODE_ISOLATED) {
pdn->eeh_check_count ++;
if (pdn->eeh_check_count >= EEH_MAX_FAILS) {
- printk (KERN_ERR "EEH: Device driver ignored %d bad
reads, panicing\n",
- pdn->eeh_check_count);
+ printk(KERN_ERR "EEH: Device driver ignored %d bad "
+ "reads, panicing\n", pdn->eeh_check_count);
dump_stack();
-
+
/* re-read the slot reset state */
if (read_slot_reset_state(pdn, rets) != 0)
rets[0] = -1; /* reset state unknown */
- /* If we are here, then we hit an infinite loop. Stop.
*/
- panic("EEH: MMIO halt (%d) on device:%s\n", rets[0],
pci_name(dev));
+ /* If we're here, then we hit an infinite loop. Stop.
*/+ panic("EEH: MMIO halt (%d) on device:%s\n",
+ rets[0], pci_name(dev));
}
goto dn_unlock;
}
@@ -352,8 +349,8 @@ int eeh_dn_check_failure(struct device_n
/* If the call to firmware failed, punt */
if (ret != 0) {
- printk(KERN_WARNING "EEH: read_slot_reset_state() failed;
rc=%d dn=%s\n",
- ret, dn->full_name);
+ printk(KERN_WARNING "EEH: read_slot_reset_state() failed; "
+ "rc=%d dn=%s\n", ret, dn->full_name);
false_positives++;
rc = 0;
goto dn_unlock;
@@ -361,8 +358,8 @@ int eeh_dn_check_failure(struct device_n
/* If EEH is not supported on this device, punt. */
if (rets[1] != 1) {
- printk(KERN_WARNING "EEH: event on unsupported device, rc=%d
dn=%s\n",
- ret, dn->full_name);
+ printk(KERN_WARNING "EEH: event on unsupported device, rc=%d "
+ "dn=%s\n", ret, dn->full_name);
false_positives++;
rc = 0;
goto dn_unlock;
@@ -384,11 +381,11 @@ int eeh_dn_check_failure(struct device_n
}
slot_resets++;
-
+
/* Avoid repeated reports of this failure, including problems
* with other functions on this device, and functions under
* bridges. */
- eeh_mark_slot (dn, EEH_MODE_ISOLATED);
+ eeh_mark_slot(dn, EEH_MODE_ISOLATED);
spin_unlock_irqrestore(&confirm_error_lock, flags);
state = pci_channel_io_normal;
@@ -396,12 +393,13 @@ int eeh_dn_check_failure(struct device_n
state = pci_channel_io_frozen;
if (rets[0] == 5)
state = pci_channel_io_perm_failure;
- eeh_send_failure_event (dn, dev, state, rets[2]);
+ eeh_send_failure_event(dn, dev, state, rets[2]);
/* Most EEH events are due to device driver bugs. Having
* a stack trace will help the device-driver authors figure
* out what happened. So print that out. */
- if (rets[0] != 5) dump_stack();
+ if (rets[0] != 5)
+ dump_stack();
return 1;
dn_unlock:
@@ -438,7 +436,7 @@ unsigned long eeh_check_failure(const vo
}
dn = pci_device_to_OF_node(dev);
- eeh_dn_check_failure (dn, dev);
+ eeh_dn_check_failure(dn, dev);
pci_dev_put(dev);
return val;
@@ -453,26 +451,29 @@ EXPORT_SYMBOL(eeh_check_failure);
* a number of milliseconds to wait until the PCI slot is
* ready to be used.
*/
-static int
-eeh_slot_availability(struct pci_dn *pdn)
+static int eeh_slot_availability(struct pci_dn *pdn)
{
int rc;
int rets[3];
rc = read_slot_reset_state(pdn, rets);
- if (rc) return rc;
+ if (rc)
+ return rc;
- if (rets[1] == 0) return -1; /* EEH is not supported */
- if (rets[0] == 0) return 0; /* Oll Korrect */
+ if (rets[1] == 0)
+ return -1; /* EEH is not supported */
+ if (rets[0] == 0)
+ return 0; /* Oll Korrect */
if (rets[0] == 5) {
- if (rets[2] == 0) return -1; /* permanently unavailable */
+ if (rets[2] == 0)
+ return -1; /* permanently unavailable */
return rets[2]; /* number of millisecs to wait */
}
if (rets[0] == 1)
return 250;
- printk (KERN_ERR "EEH: Slot unavailable: rc=%d, rets=%d %d %d\n",
+ printk(KERN_ERR "EEH: Slot unavailable: rc=%d, rets=%d %d %d\n",
rc, rets[0], rets[1], rets[2]);
return -1;
}
@@ -486,18 +487,16 @@ eeh_slot_availability(struct pci_dn *pdn
* safe to call in an interrupt context.
*
*/
-
-static void
-rtas_pci_slot_reset(struct pci_dn *pdn, int state)
+static void rtas_pci_slot_reset(struct pci_dn *pdn, int state)
{
int config_addr;
int rc;
- BUG_ON (pdn==NULL);
+ BUG_ON (pdn==NULL);
if (!pdn->phb) {
- printk (KERN_WARNING "EEH: in slot reset, device node %s has
no phb\n",
- pdn->node->full_name);
+ printk(KERN_WARNING "EEH: in slot reset, device node %s "
+ "has no phb\n", pdn->node->full_name);
return;
}
@@ -506,14 +505,13 @@ rtas_pci_slot_reset(struct pci_dn *pdn,
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_set_slot_reset,4,1, NULL,
- config_addr,
- BUID_HI(pdn->phb->buid),
- BUID_LO(pdn->phb->buid),
+ rc = rtas_call(ibm_set_slot_reset,4,1, NULL, config_addr,
+ BUID_HI(pdn->phb->buid), BUID_LO(pdn->phb->buid),
state);
if (rc) {
- printk (KERN_WARNING "EEH: Unable to reset the failed slot,
(%d) #RST=%d dn=%s\n",
- rc, state, pdn->node->full_name);
+ printk(KERN_WARNING "EEH: Unable to reset the failed slot, "
+ "(%d) #RST=%d dn=%s\n", rc, state,
+ pdn->node->full_name);
return;
}
}
@@ -523,39 +521,38 @@ rtas_pci_slot_reset(struct pci_dn *pdn,
*
* Return 0 if success, else a non-zero value.
*/
-
-int
-rtas_set_slot_reset(struct pci_dn *pdn)
+int rtas_set_slot_reset(struct pci_dn *pdn)
{
int i, rc;
- rtas_pci_slot_reset (pdn, 1);
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
#define PCI_BUS_RST_HOLD_TIME_MSEC 250
- msleep (PCI_BUS_RST_HOLD_TIME_MSEC);
-
- /* We might get hit with another EEH freeze as soon as the
+ msleep(PCI_BUS_RST_HOLD_TIME_MSEC);
+
+ /* We might get hit with another EEH freeze as soon as the
* pci slot reset line is dropped. Make sure we don't miss
* these, and clear the flag now. */
- eeh_clear_slot (pdn->node, EEH_MODE_ISOLATED);
+ eeh_clear_slot(pdn->node, EEH_MODE_ISOLATED);
- rtas_pci_slot_reset (pdn, 0);
+ rtas_pci_slot_reset(pdn, 0);
/* After a PCI slot has been reset, the PCI Express spec requires
* a 1.5 second idle time for the bus to stabilize, before starting
* up traffic. */
#define PCI_BUS_SETTLE_TIME_MSEC 1800
- msleep (PCI_BUS_SETTLE_TIME_MSEC);
+ msleep(PCI_BUS_SETTLE_TIME_MSEC);
/* Now double check with the firmware to make sure the device is
* ready to be used; if not, wait for recovery. */
- for (i=0; i<10; i++) {
- rc = eeh_slot_availability (pdn);
+ for (i = 0; i < 10; i++) {
+ rc = eeh_slot_availability(pdn);
if (rc < 0)
- printk (KERN_ERR "EEH: failed (%d) to reset slot
%s\n", rc, pdn->node->full_name);
+ printk(KERN_ERR "EEH: failed (%d) to reset slot %s\n",
+ rc, pdn->node->full_name);
if (rc == 0)
return 0;
if (rc < 0)
@@ -564,9 +561,10 @@ rtas_set_slot_reset(struct pci_dn *pdn)
msleep (rc+100);
}
- rc = eeh_slot_availability (pdn);
+ rc = eeh_slot_availability(pdn);
if (rc)
- printk (KERN_ERR "EEH: timeout resetting slot %s\n",
pdn->node->full_name);
+ printk(KERN_ERR "EEH: timeout resetting slot %s\n",
+ pdn->node->full_name);
return rc;
}
@@ -577,7 +575,7 @@ rtas_set_slot_reset(struct pci_dn *pdn)
* Although firmware will set up BARs during boot, it doesn't
* set up device BAR's after a device reset, although it will,
* if requested, set up bridge configuration. Thus, we need to
- * configure the PCI devices ourselves.
+ * configure the PCI devices ourselves.
*/
/**
@@ -586,12 +584,14 @@ rtas_set_slot_reset(struct pci_dn *pdn)
* the expansion ROM base address, the latency timer, and etc.
* from the saved values in the device node.
*/
-static inline void __restore_bars (struct pci_dn *pdn)
+static inline void __restore_bars(struct pci_dn *pdn)
{
int i;
- if (NULL==pdn->phb) return;
- for (i=4; i<10; i++) {
+ if (NULL==pdn->phb)
+ return;
+
+ for (i = 4; i < 10; i++) {
rtas_write_config(pdn, i*4, 4, pdn->config_space[i]);
}
@@ -601,11 +601,11 @@ static inline void __restore_bars (struc
#define BYTE_SWAP(OFF) (8*((OFF)/4)+3-(OFF))
#define SAVED_BYTE(OFF) (((u8 *)(pdn->config_space))[BYTE_SWAP(OFF)])
- rtas_write_config (pdn, PCI_CACHE_LINE_SIZE, 1,
- SAVED_BYTE(PCI_CACHE_LINE_SIZE));
+ rtas_write_config(pdn, PCI_CACHE_LINE_SIZE, 1,
+ SAVED_BYTE(PCI_CACHE_LINE_SIZE));
- rtas_write_config (pdn, PCI_LATENCY_TIMER, 1,
- SAVED_BYTE(PCI_LATENCY_TIMER));
+ rtas_write_config(pdn, PCI_LATENCY_TIMER, 1,
+ SAVED_BYTE(PCI_LATENCY_TIMER));
/* max latency, min grant, interrupt pin and line */
rtas_write_config(pdn, 15*4, 4, pdn->config_space[15]);
@@ -620,15 +620,15 @@ static inline void __restore_bars (struc
void eeh_restore_bars(struct pci_dn *pdn)
{
struct device_node *dn;
- if (!pdn)
+ if (!pdn)
return;
-
+
if ((pdn->eeh_mode & EEH_MODE_SUPPORTED)
&& !IS_BRIDGE(pdn->class_code))- __restore_bars (pdn);
+ __restore_bars(pdn);
dn = pdn->node->child;
while (dn) {
- eeh_restore_bars (PCI_DN(dn));
+ eeh_restore_bars(PCI_DN(dn));
dn = dn->sibling;
}
}
@@ -645,9 +645,9 @@ static void eeh_save_bars(struct pci_dn
{
int i;
- if (!pdn )
+ if (!pdn)
return;
-
+
for (i = 0; i < 16; i++)
rtas_read_config(pdn, i * 4, 4, &pdn->config_space[i]);
}
@@ -663,13 +663,11 @@ rtas_configure_bridge(struct pci_dn *pdn
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;
- rc = rtas_call(ibm_configure_bridge,3,1, NULL,
- config_addr,
- BUID_HI(pdn->phb->buid),
- BUID_LO(pdn->phb->buid));
+ rc = rtas_call(ibm_configure_bridge,3,1, NULL, config_addr,
+ BUID_HI(pdn->phb->buid), BUID_LO(pdn->phb->buid));
if (rc) {
- printk (KERN_WARNING "EEH: Unable to configure device bridge
(%d) for %s\n",
- rc, pdn->node->full_name);
+ printk(KERN_WARNING "EEH: Unable to configure device bridge "
+ "(%d) for %s\n", rc, pdn->node->full_name);
}
}
@@ -750,31 +748,35 @@ static void *early_enable_eeh(struct dev
pdn->eeh_mode |= EEH_MODE_SUPPORTED;
pdn->eeh_config_addr = regs[0];
- /* If the newer, better, ibm,get-config-addr-info is
supported,
- * then use that instead. */
+ /* If the newer, better, ibm,get-config-addr-info
+ * is supported, then use that instead. */
pdn->eeh_pe_config_addr = 0;
if (ibm_get_config_addr_info != RTAS_UNKNOWN_SERVICE)
{
unsigned int rets[2];
- ret = rtas_call (ibm_get_config_addr_info, 4,
2, rets,
- pdn->eeh_config_addr,
- info->buid_hi, info->buid_lo,
- 0);
+ ret = rtas_call(ibm_get_config_addr_info, 4,
2,
+ rets, pdn->eeh_config_addr,
+ info->buid_hi, info->buid_lo,
+ 0);
if (ret == 0)
pdn->eeh_pe_config_addr = rets[0];
}
#ifdef DEBUG
- printk(KERN_DEBUG "EEH: %s: eeh enabled, config=%x
pe_config=%x\n",
- dn->full_name, pdn->eeh_config_addr,
pdn->eeh_pe_config_addr);
+ printk(KERN_DEBUG "EEH: %s: eeh enabled, config=%x "
+ "pe_config=%x\n", dn->full_name,
+ pdn->eeh_config_addr,
pdn->eeh_pe_config_addr);
#endif
} else {
/* This device doesn't support EEH, but it may have an
* EEH parent, in which case we mark it as supported.
*/ if (dn->parent && PCI_DN(dn->parent)
- && (PCI_DN(dn->parent)->eeh_mode &
EEH_MODE_SUPPORTED)) {
+ && (PCI_DN(dn->parent)->eeh_mode
+ & EEH_MODE_SUPPORTED)) {
+
/* Parent supports EEH. */
pdn->eeh_mode |= EEH_MODE_SUPPORTED;
- pdn->eeh_config_addr =
PCI_DN(dn->parent)->eeh_config_addr;
+ pdn->eeh_config_addr =
+ PCI_DN(dn->parent)->eeh_config_addr;
return NULL;
}
}
@@ -818,7 +820,7 @@ void __init eeh_init(void)
ibm_read_slot_reset_state = rtas_token("ibm,read-slot-reset-state");
ibm_slot_error_detail = rtas_token("ibm,slot-error-detail");
ibm_get_config_addr_info = rtas_token("ibm,get-config-addr-info");
- ibm_configure_bridge = rtas_token ("ibm,configure-bridge");
+ ibm_configure_bridge = rtas_token("ibm,configure-bridge");
if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
return;
@@ -828,8 +830,9 @@ void __init eeh_init(void)
eeh_error_buf_size = 1024;
}
if (eeh_error_buf_size > RTAS_ERROR_LOG_MAX) {
- printk(KERN_WARNING "EEH: rtas-error-log-max is bigger than
allocated "
- "buffer ! (%d vs %d)", eeh_error_buf_size,
RTAS_ERROR_LOG_MAX);
+ printk(KERN_WARNING "EEH: rtas-error-log-max is bigger than "
+ "allocated buffer ! (%d vs %d)", eeh_error_buf_size,
+ RTAS_ERROR_LOG_MAX);
eeh_error_buf_size = RTAS_ERROR_LOG_MAX;
}
@@ -848,7 +851,8 @@ void __init eeh_init(void)
}
if (eeh_subsystem_enabled)
- printk(KERN_INFO "EEH: PCI Enhanced I/O Error Handling
Enabled\n");
+ printk(KERN_INFO "EEH: PCI Enhanced I/O Error Handling "
+ "Enabled\n");
else
printk(KERN_WARNING "EEH: No capable adapters found\n");
}
@@ -925,12 +929,12 @@ static void eeh_add_device_late(struct p
printk(KERN_DEBUG "EEH: adding device %s\n", pci_name(dev));
#endif
- pci_dev_get (dev);
+ pci_dev_get(dev);
dn = pci_device_to_OF_node(dev);
pdn = PCI_DN(dn);
pdn->pcidev = dev;
- pci_addr_cache_insert_device (dev);
+ pci_addr_cache_insert_device(dev);
}
/**
@@ -957,7 +961,7 @@ static void eeh_remove_device(struct pci
dn = pci_device_to_OF_node(dev);
PCI_DN(dn)->pcidev = NULL;
- pci_dev_put (dev);
+ pci_dev_put(dev);
}
void eeh_remove_bus_device(struct pci_dev *dev)
@@ -990,9 +994,9 @@ static int proc_eeh_show(struct seq_file
"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,
+ no_device, no_dn, no_cfg_addr,
+ ignored_check, total_mmio_ffs,
+ false_positives, ignored_failures,
slot_resets);
}
^ permalink raw reply
* Re: mpc5200b and floating point
From: Dan Malek @ 2006-03-31 18:58 UTC (permalink / raw)
To: Roger Larsson; +Cc: linuxppc-embedded
In-Reply-To: <200603312027.22359.roger.larsson@norran.net>
On Mar 31, 2006, at 1:27 PM, Roger Larsson wrote:
> Since a lot of PowerPC do not have floating point processor your tools
> might be setup to compile without it (compare with sse2 on x86).
Nearly all of the PowerPC do have floating point, only a few do not.
It's highly unlikely to find a PowerPC tool set that was custom
built to not enable floating point. Don't forget that the compiler
flags are only a small part of the picture, you need matching
compiler run time support and application libraries as well.
Just using the compiler flags and not selecting the proper
libraries will not be a positive experience.
-- Dan
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Linas Vepstas @ 2006-03-31 17:06 UTC (permalink / raw)
To: Greg KH
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331054654.GA6632@kroah.com>
On Thu, Mar 30, 2006 at 09:46:54PM -0800, Greg KH wrote:
>
> (hint, use a tab...)
glurg.
[PATCH]: e1000: prevent statistics from getting garbled during reset.
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, returning
garbage data upstream. This patch skips statistics data collection
if the PCI device is not on the bus.
This patch presumes that an earlier patch,
[PATCH] PCI Error Recovery: e1000 network device driver
has already been applied.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/e1000/e1000_main.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-30 17:51:37.924162779 -0600
+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-30 17:54:07.659188391 -0600
@@ -3069,14 +3069,18 @@ void
e1000_update_stats(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pdev = adapter->pdev;
unsigned long flags;
uint16_t phy_tmp;
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
- /* Prevent stats update while adapter is being reset */
+ /* Prevent stats update while adapter is being reset,
+ * or if the pci connection is down. */
if (adapter->link_speed == 0)
return;
+ if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+ return;
spin_lock_irqsave(&adapter->stats_lock, flags);
^ permalink raw reply
* Re: mpc5200b and floating point
From: White @ 2006-03-31 18:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060331133619.GD7738@localhost.localdomain>
Am Fri, 31 Mar 2006 15:36:20 +0200 schrieb Sascha Hauer
<s.hauer@pengutronix.de> :
Please check your Toolchain.
Have you build it ?
Do you use glibc or something like uclibc ?
At my beginning with mpc5200 i hat simular problems.
I had the wrong Compilerflags during build of my ToolChain.
(uclibc).
Good Luck.
> Hi,
>
> I'm working with a mpc5200b custom board and I'm trying to run an
> application with floating point. All floating point variables seem to
> zero all the time. Since I'm not very familiar with powerpc it might be
> something stupid I have overlooked.
> Any hints?
>
> Thank you,
>
> Sascha Hauer
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: mpc5200b and floating point
From: Roger Larsson @ 2006-03-31 18:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060331133619.GD7738@localhost.localdomain>
On fredag 31 mars 2006 15.36, Sascha Hauer wrote:
> Hi,
>
> I'm working with a mpc5200b custom board and I'm trying to run an
> application with floating point. All floating point variables seem to
> zero all the time. Since I'm not very familiar with powerpc it might be
> something stupid I have overlooked.
Since a lot of PowerPC do not have floating point processor your tools
might be setup to compile without it (compare with sse2 on x86).
Check your compiler flags again.
Define -mcpu= and -mhard-float
Undefine -msoft-float
/RogerL
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: EEH Cleanup
From: Linas Vepstas @ 2006-03-31 18:04 UTC (permalink / raw)
To: Nathan Fontenot, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200603311013.22208.nfont@austin.ibm.com>
Please apply.
This patch removes unnecessary exports, marks functions as static when
possible, and simplifies some list-related code.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Paul, please apply and forward upstream.
On Fri, Mar 31, 2006 at 10:13:21AM -0600, Nathan Fontenot wrote:
> This patch removes unnecessary exports, marks functions as static when
> possible, and simplifies some list-related code.
Nathan's original patch did not apply cleanly for me, nor did it build
cleanly. However, the one below does.
Linas.
arch/powerpc/platforms/pseries/eeh.c | 62 ++++++++++++++++-------------------
include/asm-powerpc/eeh.h | 20 -----------
2 files changed, 30 insertions(+), 52 deletions(-)
Index: linux-2.6.16-git19/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.16-git19.orig/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 11:38:49.000000000 -0600
+++ linux-2.6.16-git19/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 11:54:24.901762378 -0600
@@ -865,7 +865,7 @@ void __init eeh_init(void)
* on the CEC architecture, type of the device, on earlier boot
* command-line arguments & etc.
*/
-void eeh_add_device_early(struct device_node *dn)
+static void eeh_add_device_early(struct device_node *dn)
{
struct pci_controller *phb;
struct eeh_early_enable_info info;
@@ -882,7 +882,6 @@ void eeh_add_device_early(struct device_
info.buid_lo = BUID_LO(phb->buid);
early_enable_eeh(dn, &info);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_early);
void eeh_add_device_tree_early(struct device_node *dn)
{
@@ -893,20 +892,6 @@ void eeh_add_device_tree_early(struct de
}
EXPORT_SYMBOL_GPL(eeh_add_device_tree_early);
-void eeh_add_device_tree_late(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- eeh_add_device_late(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *subbus = dev->subordinate;
- if (subbus)
- eeh_add_device_tree_late(subbus);
- }
- }
-}
-
/**
* eeh_add_device_late - perform EEH initialization for the indicated pci device
* @dev: pci device for which to set up EEH
@@ -914,7 +899,7 @@ void eeh_add_device_tree_late(struct pci
* This routine must be used to complete EEH initialization for PCI
* devices that were added after system boot (e.g. hotplug, dlpar).
*/
-void eeh_add_device_late(struct pci_dev *dev)
+static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct pci_dn *pdn;
@@ -933,16 +918,33 @@ void eeh_add_device_late(struct pci_dev
pci_addr_cache_insert_device (dev);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_late);
+
+void eeh_add_device_tree_late(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ eeh_add_device_late(dev);
+ if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ struct pci_bus *subbus = dev->subordinate;
+ if (subbus)
+ eeh_add_device_tree_late(subbus);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(eeh_add_device_tree_late);
/**
* eeh_remove_device - undo EEH setup for the indicated pci device
* @dev: pci device to be removed
*
- * This routine should be when a device is removed from a running
- * system (e.g. by hotplug or dlpar).
+ * This routine should be called when a device is removed from
+ * a running system (e.g. by hotplug or dlpar). It unregisters
+ * the PCI device from the EEH subsystem. I/O errors affecting
+ * this device will no longer be detected after this call; thus,
+ * i/o errors affecting this slot may leave this device unusable.
*/
-void eeh_remove_device(struct pci_dev *dev)
+static void eeh_remove_device(struct pci_dev *dev)
{
struct device_node *dn;
if (!dev || !eeh_subsystem_enabled)
@@ -958,21 +960,17 @@ void eeh_remove_device(struct pci_dev *d
PCI_DN(dn)->pcidev = NULL;
pci_dev_put (dev);
}
-EXPORT_SYMBOL_GPL(eeh_remove_device);
void eeh_remove_bus_device(struct pci_dev *dev)
{
+ struct pci_bus *bus = dev->subordinate;
+ struct pci_dev *child, *tmp;
+
eeh_remove_device(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *bus = dev->subordinate;
- struct list_head *ln;
- if (!bus)
- return;
- for (ln = bus->devices.next; ln != &bus->devices; ln = ln->next) {
- struct pci_dev *pdev = pci_dev_b(ln);
- if (pdev)
- eeh_remove_bus_device(pdev);
- }
+
+ if (bus && dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ list_for_each_entry_safe(child, tmp, &bus->devices, bus_list)
+ eeh_remove_bus_device(child);
}
}
EXPORT_SYMBOL_GPL(eeh_remove_bus_device);
Index: linux-2.6.16-git19/include/asm-powerpc/eeh.h
===================================================================
--- linux-2.6.16-git19.orig/include/asm-powerpc/eeh.h 2006-03-19 23:53:29.000000000 -0600
+++ linux-2.6.16-git19/include/asm-powerpc/eeh.h 2006-03-31 11:47:35.000000000 -0600
@@ -60,24 +60,10 @@ void __init pci_addr_cache_build(void);
* device (including config space i/o). Call eeh_add_device_late
* to finish the eeh setup for this device.
*/
-void eeh_add_device_early(struct device_node *);
-void eeh_add_device_late(struct pci_dev *dev);
void eeh_add_device_tree_early(struct device_node *);
void eeh_add_device_tree_late(struct pci_bus *);
/**
- * eeh_remove_device - undo EEH setup for the indicated pci device
- * @dev: pci device to be removed
- *
- * This routine should be called when a device is removed from
- * a running system (e.g. by hotplug or dlpar). It unregisters
- * the PCI device from the EEH subsystem. I/O errors affecting
- * this device will no longer be detected after this call; thus,
- * i/o errors affecting this slot may leave this device unusable.
- */
-void eeh_remove_device(struct pci_dev *);
-
-/**
* eeh_remove_device_recursive - undo EEH for device & children.
* @dev: pci device to be removed
*
@@ -116,12 +102,6 @@ static inline int eeh_dn_check_failure(s
static inline void pci_addr_cache_build(void) { }
-static inline void eeh_add_device_early(struct device_node *dn) { }
-
-static inline void eeh_add_device_late(struct pci_dev *dev) { }
-
-static inline void eeh_remove_device(struct pci_dev *dev) { }
-
static inline void eeh_add_device_tree_early(struct device_node *dn) { }
static inline void eeh_add_device_tree_late(struct pci_bus *bus) { }
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Rick Jones @ 2006-03-31 17:36 UTC (permalink / raw)
Cc: netdev, linux-pci, linux-kernel, linuxppc-dev
In-Reply-To: <20060331170319.GV2172@austin.ibm.com>
> 2) What's wrong with taking deltas? Typical through-put performance
> measurement is done by pre-loading the pipes (i.e. running for
> a few minutes wihtout measuring, then starting the measurement).
> I'd think that snapshotting the numbers would be easier, and is
> trivially doable in user-space. I guess I don't understand why
> you need a new kernel featre to imlement this.
ftp://ftp.cup.hp.com/dist/networking/tools/beforeafter.tar.gz
Not my code, I've used it with success against ethtool -S output.
rick jones
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Jeff V. Merkey @ 2006-03-31 18:40 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331170319.GV2172@austin.ibm.com>
Linas Vepstas wrote:
>On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
>
>
>>Yes, we need one. The adapter needs to maintain these stats from the
>>registers in the kernel structure and not
>>its own local variables.
>>
>>
>
>Did you read the code to see what the adapter does with these stats?
>Among other things, it uses them to adaptively modulate transmit rates
>to avoid collisions. Just clearing the hardware-private stats will mess
>up that function.
>
>
>
I noticed that.
>>That way, when someone calls to clear the stats
>>for testing and analysis purposes,
>>they zero out and are reset.
>>
>>
>
>1) ifdown/ifup is guarenteed to to clear things. Try that.
>
>
No, not dynamic. I'll patch the driver locally, thanks.
Jeff
>2) What's wrong with taking deltas? Typical through-put performance
>measurement is done by pre-loading the pipes (i.e. running for
>a few minutes wihtout measuring, then starting the measurement).
>I'd think that snapshotting the numbers would be easier, and is
>trivially doable in user-space. I guess I don't understand why
>you need a new kernel featre to imlement this.
>
>--linas
>
>
>
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Linas Vepstas @ 2006-03-31 17:03 UTC (permalink / raw)
To: Jeffrey V. Merkey
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <442CACC0.1060308@wolfmountaingroup.com>
On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
> Yes, we need one. The adapter needs to maintain these stats from the
> registers in the kernel structure and not
> its own local variables.
Did you read the code to see what the adapter does with these stats?
Among other things, it uses them to adaptively modulate transmit rates
to avoid collisions. Just clearing the hardware-private stats will mess
up that function.
> That way, when someone calls to clear the stats
> for testing and analysis purposes,
> they zero out and are reset.
1) ifdown/ifup is guarenteed to to clear things. Try that.
2) What's wrong with taking deltas? Typical through-put performance
measurement is done by pre-loading the pipes (i.e. running for
a few minutes wihtout measuring, then starting the measurement).
I'd think that snapshotting the numbers would be easier, and is
trivially doable in user-space. I guess I don't understand why
you need a new kernel featre to imlement this.
--linas
^ permalink raw reply
* [PATCH] powerpc/pseries: EEH Cleanup
From: Nathan Fontenot @ 2006-03-31 16:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
This patch removes unnecessary exports, marks functions as static when
possible, and simplifies some list-related code.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Index: nfont/kernel/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- nfont.orig/kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-27
16:04:52.%N -0600
+++ nfont/kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 09:02:17.%N
-0600
@@ -865,7 +865,7 @@ void __init eeh_init(void)
* on the CEC architecture, type of the device, on earlier boot
* command-line arguments & etc.
*/
-void eeh_add_device_early(struct device_node *dn)
+static void eeh_add_device_early(struct device_node *dn)
{
struct pci_controller *phb;
struct eeh_early_enable_info info;
@@ -882,7 +882,6 @@ void eeh_add_device_early(struct device_
info.buid_lo = BUID_LO(phb->buid);
early_enable_eeh(dn, &info);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_early);
void eeh_add_device_tree_early(struct device_node *dn)
{
@@ -914,7 +913,7 @@ void eeh_add_device_tree_late(struct pci
* This routine must be used to complete EEH initialization for PCI
* devices that were added after system boot (e.g. hotplug, dlpar).
*/
-void eeh_add_device_late(struct pci_dev *dev)
+static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct pci_dn *pdn;
@@ -933,16 +932,18 @@ void eeh_add_device_late(struct pci_dev
pci_addr_cache_insert_device (dev);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_late);
/**
* eeh_remove_device - undo EEH setup for the indicated pci device
* @dev: pci device to be removed
*
- * This routine should be when a device is removed from a running
- * system (e.g. by hotplug or dlpar).
+ * This routine should be called when a device is removed from
+ * a running system (e.g. by hotplug or dlpar). It unregisters
+ * the PCI device from the EEH subsystem. I/O errors affecting
+ * this device will no longer be detected after this call; thus,
+ * i/o errors affecting this slot may leave this device unusable.
*/
-void eeh_remove_device(struct pci_dev *dev)
+static void eeh_remove_device(struct pci_dev *dev)
{
struct device_node *dn;
if (!dev || !eeh_subsystem_enabled)
@@ -958,22 +959,18 @@ void eeh_remove_device(struct pci_dev *d
PCI_DN(dn)->pcidev = NULL;
pci_dev_put (dev);
}
-EXPORT_SYMBOL_GPL(eeh_remove_device);
void eeh_remove_bus_device(struct pci_dev *dev)
{
+ struct pci_bus *bus = dev->subordinate;
+ struct pci_dev *child, *tmp;
+
eeh_remove_device(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *bus = dev->subordinate;
- struct list_head *ln;
- if (!bus)
- return;
- for (ln = bus->devices.next; ln != &bus->devices; ln =
ln->next) {
- struct pci_dev *pdev = pci_dev_b(ln);
- if (pdev)
- eeh_remove_bus_device(pdev);
- }
- }
+
+ if (bus && dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ list_for_each_entry_safe(child, tmp, &bus->devices, bus_list)
+ eeh_remove_bus_device(child);
+ }
}
EXPORT_SYMBOL_GPL(eeh_remove_bus_device);
Index: nfont/kernel/include/asm-powerpc/eeh.h
===================================================================
--- nfont.orig/kernel/include/asm-powerpc/eeh.h 2006-03-27 16:05:00.%N -0600
+++ nfont/kernel/include/asm-powerpc/eeh.h 2006-03-29 15:26:57.%N -0600
@@ -60,24 +60,10 @@ void __init pci_addr_cache_build(void);
* device (including config space i/o). Call eeh_add_device_late
* to finish the eeh setup for this device.
*/
-void eeh_add_device_early(struct device_node *);
-void eeh_add_device_late(struct pci_dev *dev);
void eeh_add_device_tree_early(struct device_node *);
void eeh_add_device_tree_late(struct pci_bus *);
/**
- * eeh_remove_device - undo EEH setup for the indicated pci device
- * @dev: pci device to be removed
- *
- * This routine should be called when a device is removed from
- * a running system (e.g. by hotplug or dlpar). It unregisters
- * the PCI device from the EEH subsystem. I/O errors affecting
- * this device will no longer be detected after this call; thus,
- * i/o errors affecting this slot may leave this device unusable.
- */
-void eeh_remove_device(struct pci_dev *);
-
-/**
* eeh_remove_device_recursive - undo EEH for device & children.
* @dev: pci device to be removed
*
@@ -116,12 +102,6 @@ static inline int eeh_dn_check_failure(s
static inline void pci_addr_cache_build(void) { }
-static inline void eeh_add_device_early(struct device_node *dn) { }
-
-static inline void eeh_add_device_late(struct pci_dev *dev) { }
-
-static inline void eeh_remove_device(struct pci_dev *dev) { }
-
static inline void eeh_add_device_tree_early(struct device_node *dn) { }
static inline void eeh_add_device_tree_late(struct pci_bus *bus) { }
^ permalink raw reply
* [PATCH Resend] misc lparcfg fixes
From: Will Schmidt @ 2006-03-31 15:07 UTC (permalink / raw)
To: linuxppc-dev, paulus, will_schmidt
Please apply...
(Resending with patch inline)
This patch fixed several problems with the lparcfg code. In case
someone gets a sense of deja-vu, part of this was submitted last Sep, I
thought the changes went in, but either got backed out, or just got
lost.
First, change the local_buffer declaration to be unsigned char *. We
had a bad-math problem in a 2.4 tree which was built with a
"-fsigned-char" parm. I dont believe we ever build with that parm
now-a-days, but to be safe, I'd prefer the declaration be explicit.
Second, fix a bad math calculation for splpar_strlen.
Third, on the rtas_call for get-system-parameter, pass in
RTAS_DATA_BUF_SIZE for the rtas_data_buf size, instead of letting random
data determine the size. Until recently, we've had a sufficiently
large 'random data' value get passed in, so the function just happens to
have worked OK. Now it's getting passed a '0', which causes the
rtas_call to return success, but no data shows up in the buffer.
(oops!). This was found by the LTC test org.
This is in a branch of code that only gets run on SPLPAR systems.
Tested on power5 Lpar.
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
---
diff -Naur 2.6/arch/powerpc/kernel/lparcfg.c 2.6.mar30/arch/powerpc/kernel/lparcfg.c
--- 2.6/arch/powerpc/kernel/lparcfg.c 2006-03-20 02:15:57.000000000 -0800
+++ 2.6.mar30/arch/powerpc/kernel/lparcfg.c 2006-03-30 12:06:34.323023840 -0800
@@ -37,7 +37,7 @@
#include <asm/prom.h>
#include <asm/vdso_datapage.h>
-#define MODULE_VERS "1.6"
+#define MODULE_VERS "1.7"
#define MODULE_NAME "lparcfg"
/* #define LPARCFG_DEBUG */
@@ -242,7 +242,7 @@
{
int call_status;
- char *local_buffer = kmalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
+ unsigned char *local_buffer = kmalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
if (!local_buffer) {
printk(KERN_ERR "%s %s kmalloc failure at line %d \n",
__FILE__, __FUNCTION__, __LINE__);
@@ -254,7 +254,8 @@
call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
NULL,
SPLPAR_CHARACTERISTICS_TOKEN,
- __pa(rtas_data_buf));
+ __pa(rtas_data_buf),
+ RTAS_DATA_BUF_SIZE);
memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
spin_unlock(&rtas_data_buf_lock);
@@ -275,7 +276,7 @@
#ifdef LPARCFG_DEBUG
printk(KERN_INFO "success calling get-system-parameter \n");
#endif
- splpar_strlen = local_buffer[0] * 16 + local_buffer[1];
+ splpar_strlen = local_buffer[0] * 256 + local_buffer[1];
local_buffer += 2; /* step over strlen value */
memset(workbuffer, 0, SPLPAR_MAXLENGTH);
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-31 14:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc, Alastair Poole
In-Reply-To: <1143547826.13615.24.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
Just FYI if anyone's thinking about using this:
> GPIO stuff.
Started, you can now turn on/off the lineout/speakers/headphones (note:
powerbooks have line out, not headphones despite the symbol on them),
but automatic switching isn't done yet.
Only on new machines with PMFs though.
> Clock setting.
Done except for master/slave switching.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: moving board support from arch/ppc/ to arch/powerpc
From: Kumar Gala @ 2006-03-31 14:39 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, linux kernel mailing list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467305790AEB@zch01exm40.ap.freescale.net>
On Mar 31, 2006, at 4:44 AM, Zang Roy-r61911 wrote:
> Hi,
> I am moving mpc7448 hpc2 support from arch/ppc to arch/powerpc and
> plan to summit it to open source tree future. Is there any good
> suggestion or reference?
> Thanks a lot!
All ports under arch/powerpc are required to use a flat device tree
to boot. Look at Documentation/powerpc/booting-without-of.txt
for details on how that is done. Beyond that there isn't too much
different from arch/ppc to arch/powerpc. Take a look at the 83xx or
85xx platforms for comparison examples between arch/ppc & arch/powerpc.
I'd suggest for working up your flat dev tree for the bridge on HPC2
and post that to the linuxppc-dev list for review and then go from
there.
- kumar
^ permalink raw reply
* mpc5200b and floating point
From: Sascha Hauer @ 2006-03-31 13:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm working with a mpc5200b custom board and I'm trying to run an
application with floating point. All floating point variables seem to
zero all the time. Since I'm not very familiar with powerpc it might be
something stupid I have overlooked.
Any hints?
Thank you,
Sascha Hauer
^ permalink raw reply
* Re: Bestcomm Firmware update
From: Andrey Volkov @ 2006-03-31 11:41 UTC (permalink / raw)
To: bennett78; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <442C5A75.7030107@digis.net>
Hello, Frank.
On Friday, March 31, 2006, bennett78 wrote:
> SoSoComm Dudes:
VERY, VERY BIG thanks to you :-))), finally we can do something more
sensible with it (like scatter-gather).
> I was able to contact Davide Santo, AN2604 "Introduction to BestComm".
> He admitted
> the short commings of his document in the area of Firmware instruction
> info and gave
> me a name of a guy, Ed in the ASIC design area in Austin. Ed has agreed
> to answer
> questions, push for resources to provide a support tool and provided me
> with a document
> from their head programmer "SmartDMA Hand-Assembly Guides" (see attached
> pdf).
> With this secret decoded ring I was able to put together a disassembler,
> see attached
> disasm.c. Cut and paste your favorite Task into fw[] array at the
> beginning,
> "cc -o d disasm.c ; d" It's not perfect, but useful- Enjoy. Sorry I'm not
> sure where or if you guys want to check this stuff into a git
> repository, somewhere
> and hope ozlabs is not fussy about attachments!
But it could be start point for a kernel compiler :).
> If we can formulate a list of questions Ed might be able to help, I'll
> start:
> o what does init=31 mean?
> AN2604 say init=0 means always requestor and 31 is reserved but
> referenced
> alot in the F/W comments
> o Need more info on how MORE works
> o Tell us about LCD levels. Only 2? (let's call a LCD indent a level)
> LCD seems to reset DRD to 1A. DRD2B1or2 follow a DRD2A (ext=1)?
> o LCD[28:23]orLCD[20:15] or LCD[11:6] what is extraN?
> drop 101nnn - extraN
> add 1nnnnn - indexN
> o how many DRD2B1[2] can be stacked up?
> o when is/can a LDC Literal used? and how?
I'll reread my drafts at next week too, so may be this list will be
extended.
--
Regards,
Andrey Volkov
^ permalink raw reply
* Re: pci-x
From: Vitaly Bordug @ 2006-03-31 11:50 UTC (permalink / raw)
To: Carlos Mitidieri; +Cc: linuxppc-embedded
In-Reply-To: <200603310852.29987.carlos.mitidieri@sysgo.com>
On Fri, 31 Mar 2006 08:52:28 +0200
Carlos Mitidieri <carlos.mitidieri@sysgo.com> wrote:
> Hi,
>
> I am using a Rev PILOT board, S/N:0251
> To my discernment, a Rev PILOT is lower than a Rev A.
> Is that correct?
>
> By the way, thank you very much.
>
Yes, that is correct.
There are some notes in u-boot documentation also, that might be interesting for you:
<citate>
1.0 Nomenclature
For some reason, the HW designers describe the switch settings
in terms of 0 and 1, and then map that to physical switches where
the label "On" refers to logic 0 and "Off" (unlabeled) is logic 1.
Luckily, we're SW types and virtual settings are handled daily.
The switches for the Rev A board are numbered differently than
for the Pilot board. Oh yeah.
Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
bits may contribute to signals that are numbered based at 0,
and some of those signals may be high-bit-number-0 too. Heed
well the names and labels and do not get confused.
"Off" == 1
"On" == 0
SW18 is switch 18 as silk-screened onto the board.
SW4[8] is the bit labled 8 on Switch 4.
SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2
SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3
1.1 For the MPC85xxADS Pilot Board
First, make sure the board default setting is consistent with the document
shipped with your board. Then apply the following changes:
SW3[1-6]="all OFF" (boot from 32bit flash, no boot sequence is used)
SW10[2-6]="all OFF" (turn on CPM SCC for serial port,works for 8540/8560)
SW11[2]='OFF for 8560, ON for 8540' (toggle 8540.8560 mode)
SW11[7]='ON' (rev2), 'OFF' (rev1)
SW4[7-8]="OFF OFF" (enable serial ports,I'm using the top serial connector)
SW22[1-4]="OFF OFF ON OFF"
SW5[1-10[="ON ON OFF OFF OFF OFF OFF OFF OFF OFF"
J1 = "Enable Prog" (Make sure your flash is programmable for development)
If you want to test PCI functionality with a 33Mhz PCI card, you will
have to change the system clock from the default 66Mhz to 33Mhz by
setting SW15[1]="OFF" and SW17[8]="OFF". After that you may also need
double your platform clock(SW6) because the system clock is now only
half of its original value. For example, if at 66MHz your system
clock showed SW6[0:1] = 01, then at 33MHz SW6[0:1] it should be 10.
SW17[8] ------+ SW6
SW15[1] ----+ | [0:1]
V V V V
33MHz 1 1 1 0
66MHz 0 0 0 1
Hmmm... That SW6 setting description is incomplete but it works.
1.3 For the MPC85xxADS Rev A Board
As shipped, the board should be a 33MHz PCI bus with a CPU Clock
rate of 825 +/- fuzz:
Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz
For 33MHz PCI, the switch settings should be like this:
SW18[7:1] = 0100001 = M==33 => 33MHz
SW18[8] = 1 => PWD Divider == 16
SW16[1:2] = 11 => N == 16 as PWD==1
Use the magical formula:
Fout (MHz) = 16 * M / N = 16 * 33 / 16 = 33 MHz
SW7[1:4] = 1010 = 10 => 10 x 33 = 330 CCB Sysclk
SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
For 66MHz PCI, the switch settings should be like this:
SW18[7:1] = 0100001 = M==33 => 33MHz
SW18[8] = 0 => PWD Divider == 1
SW16[1:2] = 01 => N == 8 as PWD == 0
Use the magical formula:
Fout (MHz) = 16 * M / N = 16 * 33 / 8 = 66 MHz
SW7[1:4] = 0101 = 5 => 5 x 66 = 330 CCB
Sysclk SW7[5:6] = 01 => 5:2 x 330 = 825 Core
clock
</citate>
> > Are you using a Rev A or higher board? PCI-X doesn't work on earlier
> > systems.
> >
> > Also, make sure your board is configured to run PCI at 66 MHz. PCI-X
> > doesn't work at 33 MHz.
> >
> >
> > Andy Fleming
>
> Best regards,
> --
> Carlos Mitidieri
> SYSGO AG - Office Ulm
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Johannes Berg @ 2006-03-31 9:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1143783444.28005.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Fri, 2006-03-31 at 16:37 +1100, Michael Ellerman wrote:
> OK, that sounds a little complicated. I'm just worried about having lots
> workarounds in the unflattening code, the code's hard enough to read as
> it is.
Yeah that's a good argument.
> I think it's preferable to do the workarounds in the code that
> needs the workaround, that way they're isolated in certain parts of the
> code rather than all in the unflattening.
I'd really prefer to have these nodes vanish from the complete node
chain so we don't have the workarounds cluttering up the rather high
levels with machine dependent code. I'll find a better place to put it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ 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