* [patch 5/5] [v2] powerpc: PA Semi PWRficient MAINTAINER entry
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
Maintainer entry for PWRficient
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/MAINTAINERS
===================================================================
--- merge.orig/MAINTAINERS
+++ merge/MAINTAINERS
@@ -1783,6 +1783,13 @@ W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+LINUX FOR POWERPC PA SEMI PWRFICIENT
+P: Olof Johansson
+M: olof@lixom.net
+W: http://www.pasemi.com/
+L: linuxppc-dev@ozlabs.org
+S: Supported
+
LLC (802.2)
P: Arnaldo Carvalho de Melo
M: acme@conectiva.com.br
^ permalink raw reply
* [patch 4/5] [v2] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
Base patch for PA6T and PA6T-1682M. This introduces the
arch/powerpc/platform/pasemi directory, together with basic
implementations for various setup.
Much of this was based on other platform code, i.e. Maple, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/arch/powerpc/Kconfig
===================================================================
--- merge.orig/arch/powerpc/Kconfig
+++ merge/arch/powerpc/Kconfig
@@ -413,6 +413,17 @@ config PPC_MAPLE
This option enables support for the Maple 970FX Evaluation Board.
For more informations, refer to <http://www.970eval.com>
+config PPC_PASEMI
+ depends on PPC_MULTIPLATFORM && PPC64
+ bool "PA Semi SoC-based platforms"
+ default n
+ select MPIC
+ select PPC_UDBG_16550
+ select GENERIC_TBSYNC
+ help
+ This option enables support for PA Semi's PWRficient line
+ of SoC processors, including PA6T-1682M
+
config PPC_CELL
bool
default n
Index: merge/arch/powerpc/platforms/Makefile
===================================================================
--- merge.orig/arch/powerpc/platforms/Makefile
+++ merge/arch/powerpc/platforms/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_PPC_86xx) += 86xx/
obj-$(CONFIG_PPC_PSERIES) += pseries/
obj-$(CONFIG_PPC_ISERIES) += iseries/
obj-$(CONFIG_PPC_MAPLE) += maple/
+obj-$(CONFIG_PPC_PASEMI) += pasemi/
obj-$(CONFIG_PPC_CELL) += cell/
obj-$(CONFIG_EMBEDDED6xx) += embedded6xx/
Index: merge/arch/powerpc/platforms/pasemi/Makefile
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/Makefile
@@ -0,0 +1 @@
+obj-y += setup.o pci.o time.o
Index: merge/arch/powerpc/platforms/pasemi/pci.c
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/pci.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Authors: Kip Walker, PA Semi
+ * Olof Johansson, PA Semi
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on arch/powerpc/platforms/maple/pci.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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. 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+
+#include <asm/pci-bridge.h>
+#include <asm/machdep.h>
+
+#include <asm/ppc-pci.h>
+
+#define PA_PXP_CFA(bus, devfn, off) (((bus) << 20) | ((devfn) << 12) | (off))
+
+#define CONFIG_OFFSET_VALID(off) ((off) < 4096)
+
+static unsigned long pa_pxp_cfg_addr(struct pci_controller *hose,
+ u8 bus, u8 devfn, int offset)
+{
+ return ((unsigned long)hose->cfg_data) + PA_PXP_CFA(bus, devfn, offset);
+}
+
+static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val)
+{
+ struct pci_controller *hose;
+ unsigned long addr;
+
+ hose = pci_bus_to_host(bus);
+ if (!hose)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!CONFIG_OFFSET_VALID(offset))
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+
+ addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
+
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ switch (len) {
+ case 1:
+ *val = in_8((u8 *)addr);
+ break;
+ case 2:
+ *val = in_le16((u16 *)addr);
+ break;
+ default:
+ *val = in_le32((u32 *)addr);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int pa_pxp_write_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 val)
+{
+ struct pci_controller *hose;
+ unsigned long addr;
+
+ hose = pci_bus_to_host(bus);
+ if (!hose)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!CONFIG_OFFSET_VALID(offset))
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+
+ addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
+
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ switch (len) {
+ case 1:
+ out_8((u8 *)addr, val);
+ (void) in_8((u8 *)addr);
+ break;
+ case 2:
+ out_le16((u16 *)addr, val);
+ (void) in_le16((u16 *)addr);
+ break;
+ default:
+ out_le32((u32 *)addr, val);
+ (void) in_le32((u32 *)addr);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops pa_pxp_ops = {
+ pa_pxp_read_config,
+ pa_pxp_write_config,
+};
+
+static void __init setup_pa_pxp(struct pci_controller *hose)
+{
+ hose->ops = &pa_pxp_ops;
+ hose->cfg_data = ioremap(0xe0000000, 0x1000000);
+}
+
+static int __init add_bridge(struct device_node *dev)
+{
+ int len;
+ struct pci_controller *hose;
+ const int *bus_range;
+
+ pr_debug("Adding PCI host bridge %s\n", dev->full_name);
+
+ bus_range = get_property(dev, "bus-range", &len);
+ if (!bus_range || len < 2 * sizeof(int)) {
+ printk(KERN_WARNING "Can't get bus-range for %s, assume bus 0\n",
+ dev->full_name);
+ }
+
+ hose = pcibios_alloc_controller(dev);
+ if (!hose)
+ return -ENOMEM;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ setup_pa_pxp(hose);
+
+ printk(KERN_INFO "Found PA-PXP PCI host bridge. "
+ "Firmware bus number: %d->%d\n",
+ hose->first_busno, hose->last_busno);
+
+ /* Interpret the "ranges" property */
+ /* This also maps the I/O region and sets isa_io/mem_base */
+ pci_process_bridge_OF_ranges(hose, dev, 1);
+ pci_setup_phb_io(hose, 1);
+
+ return 0;
+}
+
+
+void __init pas_pcibios_fixup(void)
+{
+ struct pci_dev *dev = NULL;
+
+ for_each_pci_dev(dev)
+ pci_read_irq_line(dev);
+}
+
+static void __init pas_fixup_phb_resources(void)
+{
+ struct pci_controller *hose, *tmp;
+
+ list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
+ unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
+ hose->io_resource.start += offset;
+ hose->io_resource.end += offset;
+ printk(KERN_INFO "PCI Host %d, io start: %lx; io end: %lx\n",
+ hose->global_number,
+ hose->io_resource.start, hose->io_resource.end);
+ }
+}
+
+
+void __init pas_pci_init(void)
+{
+ struct device_node *np, *root;
+
+ root = of_find_node_by_path("/");
+ if (!root) {
+ printk(KERN_CRIT "pas_pci_init: can't find root "
+ "of device tree\n");
+ return;
+ }
+
+ for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
+ if (np->name && !strcmp(np->name, "pxp") && !add_bridge(np))
+ of_node_get(np);
+
+ of_node_put(root);
+
+ pas_fixup_phb_resources();
+
+ /* Setup the linkage between OF nodes and PHBs */
+ pci_devs_phb_init();
+
+ /* Use the common resource allocation mechanism */
+ pci_probe_only = 1;
+}
Index: merge/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/setup.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Authors: Kip Walker, PA Semi
+ * Olof Johansson, PA Semi
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on arch/powerpc/platforms/maple/setup.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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. 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/config.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/console.h>
+
+#include <asm/prom.h>
+#include <asm/system.h>
+#include <asm/iommu.h>
+#include <asm/machdep.h>
+#include <asm/mpic.h>
+#include <asm/smp.h>
+#include <asm/time.h>
+
+#include "pasemi.h"
+
+static void pas_restart(char *cmd)
+{
+ printk("restart unimplemented, looping...\n");
+ for (;;) ;
+}
+
+static void pas_power_off(void)
+{
+ printk("power off unimplemented, looping...\n");
+ for (;;) ;
+}
+
+static void pas_halt(void)
+{
+ pas_power_off();
+}
+
+#ifdef CONFIG_SMP
+struct smp_ops_t pas_smp_ops = {
+ .probe = smp_mpic_probe,
+ .message_pass = smp_mpic_message_pass,
+ .kick_cpu = smp_generic_kick_cpu,
+ .setup_cpu = smp_mpic_setup_cpu,
+ .give_timebase = smp_generic_give_timebase,
+ .take_timebase = smp_generic_take_timebase,
+};
+#endif /* CONFIG_SMP */
+
+void __init pas_setup_arch(void)
+{
+#ifdef CONFIG_SMP
+ /* Setup SMP callback */
+ smp_ops = &pas_smp_ops;
+#endif
+ /* Lookup PCI hosts */
+ pas_pci_init();
+
+#ifdef CONFIG_DUMMY_CONSOLE
+ conswitchp = &dummy_con;
+#endif
+
+ printk(KERN_DEBUG "Using default idle loop\n");
+}
+
+static void iommu_dev_setup_null(struct pci_dev *dev) { }
+static void iommu_bus_setup_null(struct pci_bus *bus) { }
+
+static void __init pas_init_early(void)
+{
+ /* No iommu code yet */
+ ppc_md.iommu_dev_setup = iommu_dev_setup_null;
+ ppc_md.iommu_bus_setup = iommu_bus_setup_null;
+ pci_direct_iommu_init();
+}
+
+/* No legacy IO on our parts */
+static int pas_check_legacy_ioport(unsigned int baseport)
+{
+ return -ENODEV;
+}
+
+static __init void pas_init_IRQ(void)
+{
+ struct device_node *np;
+ struct device_node *root, *mpic_node;
+ unsigned long openpic_addr;
+ const unsigned int *opprop;
+ int naddr, opplen;
+ struct mpic *mpic;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (!np) {
+ printk(KERN_ERR "No interrupt controller in device tree.\n");
+ return;
+ }
+ mpic_node = of_node_get(np);
+
+ /* Find address list in /platform-open-pic */
+ root = of_find_node_by_path("/");
+ naddr = prom_n_addr_cells(root);
+ opprop = get_property(root, "platform-open-pic", &opplen);
+ if (!opprop) {
+ printk(KERN_ERR "No platform-open-pic property.\n");
+ of_node_put(root);
+ return;
+ }
+ openpic_addr = of_read_number(opprop, naddr);
+ printk(KERN_DEBUG "OpenPIC addr: %lx\n", openpic_addr);
+ of_node_put(root);
+
+ mpic = mpic_alloc(mpic_node, openpic_addr, MPIC_PRIMARY, 0, 0,
+ " PAS-OPIC ");
+ BUG_ON(!mpic);
+
+ mpic_assign_isu(mpic, 0, openpic_addr + 0x10000);
+ mpic_init(mpic);
+ of_node_put(mpic_node);
+ of_node_put(root);
+}
+
+static void __init pas_progress(char *s, unsigned short hex)
+{
+ printk("[%04x] : %s\n", hex, s ? s : "");
+}
+
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init pas_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "PA6T-1682M"))
+ return 0;
+
+ hpte_init_native();
+
+ return 1;
+}
+
+define_machine(pas) {
+ .name = "PA Semi PA6T-1682M",
+ .probe = pas_probe,
+ .setup_arch = pas_setup_arch,
+ .init_early = pas_init_early,
+ .init_IRQ = pas_init_IRQ,
+ .get_irq = mpic_get_irq,
+ .pcibios_fixup = pas_pcibios_fixup,
+ .restart = pas_restart,
+ .power_off = pas_power_off,
+ .halt = pas_halt,
+ .get_boot_time = pas_get_boot_time,
+ .calibrate_decr = generic_calibrate_decr,
+ .check_legacy_ioport = pas_check_legacy_ioport,
+ .progress = pas_progress,
+};
Index: merge/arch/powerpc/platforms/pasemi/time.c
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/time.c
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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. 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/config.h>
+#include <linux/time.h>
+
+#include <asm/time.h>
+
+unsigned long __init pas_get_boot_time(void)
+{
+ /* Let's just return a fake date right now */
+ return mktime(2006, 1, 1, 12, 0, 0);
+}
Index: merge/arch/powerpc/platforms/pasemi/pasemi.h
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/pasemi.h
@@ -0,0 +1,8 @@
+#ifndef _PASEMI_PASEMI_H
+#define _PASEMI_PASEMI_H
+
+extern unsigned long pas_get_boot_time(void);
+extern void pas_pci_init(void);
+extern void pas_pcibios_fixup(void);
+
+#endif /* _PASEMI_PASEMI_H */
^ permalink raw reply
* [patch 3/5] [v2] powerpc: PA6T cputable entry, PVR value
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>
Introduce PWRficient PA6T cputable entries and feature bits.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/arch/powerpc/kernel/cputable.c
===================================================================
--- merge.orig/arch/powerpc/kernel/cputable.c
+++ merge/arch/powerpc/kernel/cputable.c
@@ -58,6 +58,9 @@ extern void __restore_cpu_ppc970(void);
#define COMMON_USER_POWER6 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_05 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
PPC_FEATURE_TRUE_LE)
+#define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\
+ PPC_FEATURE_TRUE_LE | \
+ PPC_FEATURE_HAS_ALTIVEC_COMP)
#define COMMON_USER_BOOKE (PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
PPC_FEATURE_BOOKE)
@@ -286,6 +289,17 @@ struct cpu_spec cpu_specs[] = {
.dcache_bsize = 128,
.platform = "ppc-cell-be",
},
+ { /* PA Semi PA6T */
+ .pvr_mask = 0x7fff0000,
+ .pvr_value = 0x00900000,
+ .cpu_name = "PA6T",
+ .cpu_features = CPU_FTRS_PA6T,
+ .cpu_user_features = COMMON_USER_PA6T,
+ .icache_bsize = 64,
+ .dcache_bsize = 64,
+ .num_pmcs = 6,
+ .platform = "pa6t",
+ },
{ /* default match */
.pvr_mask = 0x00000000,
.pvr_value = 0x00000000,
Index: merge/include/asm-powerpc/reg.h
===================================================================
--- merge.orig/include/asm-powerpc/reg.h
+++ merge/include/asm-powerpc/reg.h
@@ -592,6 +592,7 @@
#define PV_630p 0x0041
#define PV_970MP 0x0044
#define PV_BE 0x0070
+#define PV_PA6T 0x0090
/*
* Number of entries in the SLB. If this ever changes we should handle
Index: merge/include/asm-powerpc/cputable.h
===================================================================
--- merge.orig/include/asm-powerpc/cputable.h
+++ merge/include/asm-powerpc/cputable.h
@@ -23,6 +23,7 @@
#define PPC_FEATURE_SMT 0x00004000
#define PPC_FEATURE_ICACHE_SNOOP 0x00002000
#define PPC_FEATURE_ARCH_2_05 0x00001000
+#define PPC_FEATURE_PA6T 0x00000800
#define PPC_FEATURE_TRUE_LE 0x00000002
#define PPC_FEATURE_PPC_LE 0x00000001
@@ -332,6 +333,10 @@ extern void do_cpu_ftr_fixups(unsigned l
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
+#define CPU_FTRS_PA6T (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+ CPU_FTR_ALTIVEC_COMP | CPU_FTR_CI_LARGE_PAGE | \
+ CPU_FTR_PURR | CPU_FTR_REAL_LE)
#define CPU_FTRS_COMPATIBLE (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2)
#endif
@@ -340,7 +345,7 @@ extern void do_cpu_ftr_fixups(unsigned l
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 | \
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
- CPU_FTRS_CELL | CPU_FTR_CI_LARGE_PAGE)
+ CPU_FTRS_CELL | CPU_FTRS_PA6T)
#else
enum {
CPU_FTRS_POSSIBLE =
@@ -379,7 +384,7 @@ enum {
#define CPU_FTRS_ALWAYS \
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 & \
CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 & \
- CPU_FTRS_CELL & CPU_FTRS_POSSIBLE)
+ CPU_FTRS_CELL & CPU_FTRS_PA6T & CPU_FTRS_POSSIBLE)
#else
enum {
CPU_FTRS_ALWAYS =
^ permalink raw reply
* Re: [POWERPC] merge iSeries i/o operations with the rest
From: Stephen Rothwell @ 2006-09-05 23:19 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev, paulus
In-Reply-To: <20060905164146.GA7139@austin.ibm.com>
Hi Linas,
On Tue, 5 Sep 2006 11:41:46 -0500 linas@austin.ibm.com (Linas Vepstas) wrote:
>
> On Tue, Sep 05, 2006 at 12:08:17PM +1000, Stephen Rothwell wrote:
> > @@ -273,25 +234,30 @@ #define iobarrier_w() eieio()
> > + *
> > + * For some of these, we force the target/source register to be
> > + * r0 to ease decoding on iSeries.
>
> ???
> Why?
Because we were considering runtime patching of the i/o instruction on
iSeries and it seemed it would be simpler. I have a new patch (coming
soon) the removes the forcing of r0.
> > - int ret;
> > + register unsigned int ret __asm__("r0");
>
> Such as here .. why is this being forced ??
See above.
> > - __asm__ __volatile__("lbz%U1%X1 %0,%1; twi 0,%0,0; isync"
> > - : "=r" (ret) : "m" (*addr));
> > + __asm__ __volatile__("lbzx %0,0,%1; twi 0,%0,0; isync"
> > + : "=r" (ret) : "r" (addr));
>
> Why make this change? The old code allows the compiler to optimize
> better than the new code. One might argue that, in the grand scheme of
> things, i/o is very slow, so a few cycles here doesn't matter much.
> But still, I don't understand why this change is needed.
Because the original could produce any of 4 (?) different instructions
that we would have to emulate. Interestingly the change actually made
my pSeries kernel slightly smaller (though I don't know if it was more or
less efficient). But I will think a bit more about this.
> > +static inline void memset_io(volatile void __iomem *addr, int c,
> > + unsigned long n)
> > +{
> > + if (firmware_has_feature(FW_FEATURE_ISERIES))
> > + iSeries_memset_io(addr, c, n);
> > + else
> > + eeh_memset_io(addr, c, n);
> > +}
>
> !! I think it would be much better to have this be a compile-time
> check rather than a run-time check. No only does it save cycles,
> but it makes the iSeries kernel smaller (by not needing eeh code
> in it) and the p-series code smaller (by not compiling iseries
> code into it.
On a kernel built for only iSeries, firmware_has_feature(FW_FEATURE_ISERIES)
evaluates to a compile time 1 so the eeh code is not required as the
compiler elides the call. Similarly, on a kernel that does not include
iSeries support at all, firmware_has_feature(FW_FEATURE_ISERIES)
evaluates to a compiler time 0, so the iSeries code is not required. The
only time this is a run time check is if you compile a MULTIPLATFORM
kernel incluing iSeries support (which is currently impossible but is
what we are aiming for as a possibility).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: where can I find MPC8245 assembler reference?
From: Becky Bruce @ 2006-09-05 22:30 UTC (permalink / raw)
To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450609051522i572697f8nb252ea58e7f60ae@mail.gmail.com>
MPC8245 refers to the integrated product (core + peripherals, all on
one chip). The MPC8245 has a powerpc 603e core (also known as the
G2). That's a classic 32-bit powerpc, so the assembler reference you
want is:
http://www.freescale.com/files/product/doc/MPCFPE32B.pdf
Hope this helps,
Becky
On Sep 5, 2006, at 5:22 PM, Reeve Yang wrote:
> Could anyone point me to online document for MPC8245 assembler
> reference? I couldn't find it anywhere but the command list in user
> manual. Thanks!
>
> - Reeve
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* where can I find MPC8245 assembler reference?
From: Reeve Yang @ 2006-09-05 22:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 156 bytes --]
Could anyone point me to online document for MPC8245 assembler reference? I
couldn't find it anywhere but the command list in user manual. Thanks!
- Reeve
[-- Attachment #2: Type: text/html, Size: 168 bytes --]
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 22:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1157491909.22705.143.camel@localhost.localdomain>
On Wed, 06 Sep 2006 07:31:49 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Overall, looks good, some bits tho:
Thanks! See below.
>
> > +static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
> > + int offset, int len, u32 *val)
> > +{
> > + struct pci_controller *hose;
> > + unsigned long addr;
>
> .../...
>
> You don't seem to encode support for extended config space (offsets >
> 256). If it's PCIe, you should have it (flush the 4 top bits of the
> offste in the 4 top bits of the cfg address in general). In any case,
> you should check the passed-in offset and error out if it is above your
> max offset (256 or 4096 depending if you implement extended config space
> support) or the kernel might get confused.
I'll take a look at this, thanks for pointing it out.
> > + of_prop = alloc_bootmem(sizeof(struct property) +
> > + sizeof(hose->global_number));
> > + if (of_prop) {
> > + memset(of_prop, 0, sizeof(struct property));
> > + of_prop->name = "linux,pci-domain";
> > + of_prop->length = sizeof(hose->global_number);
> > + of_prop->value = (unsigned char *)&of_prop[1];
> > + memcpy(of_prop->value, &hose->global_number, sizeof(hose->global_number));
> > + prom_add_property(dev, of_prop);
> > + }
>
> Just kill that... nobody cares about that property.
Done
> > + if (device_is_compatible(dev, "pa-pxp"))
> > + setup_pa_pxp(hose);
>
> And if not ? You have a non-initialized hose without config space access
> methods ? Hrm...
True. Just a leftover from forking off the maple setup code.
> > + printk(KERN_INFO "Found PA-PXP PCI host bridge. Firmware bus number: %d->%d\n",
> > + hose->first_busno, hose->last_busno);
> > +
> > + /* Interpret the "ranges" property */
> > + /* This also maps the I/O region and sets isa_io/mem_base */
> > + pci_process_bridge_OF_ranges(hose, dev, 1);
> > + pci_setup_phb_io(hose, 1);
> > +
> > + return 0;
> > +}
> > +
> > +
> > +void __init pas_pcibios_fixup(void)
> > +{
> > + struct pci_dev *dev = NULL;
> > +
> > + for_each_pci_dev(dev)
> > + pci_read_irq_line(dev);
> > +}
> > +
> > +static void __init pas_fixup_phb_resources(void)
> > +{
> > + struct pci_controller *hose, *tmp;
> > +
> > + list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> > + unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
> > + hose->io_resource.start += offset;
> > + hose->io_resource.end += offset;
> > + printk(KERN_INFO "PCI Host %d, io start: %lx; io end: %lx\n",
> > + hose->global_number,
> > + hose->io_resource.start, hose->io_resource.end);
> > + }
> > +}
>
> There is no generic code for the above ? (I have to double check). If
> not, we shall fix that ;)
Didn't see anything, but then I didn't look that long. I'll follow up with a
separate patch if it doesn't exist, since other platforms can use it too.
>
> > +#ifdef CONFIG_SMP
> > +struct smp_ops_t pas_smp_ops = {
> > + .probe = smp_mpic_probe,
> > + .message_pass = smp_mpic_message_pass,
> > + .kick_cpu = smp_generic_kick_cpu,
> > + .setup_cpu = smp_mpic_setup_cpu,
> > + .give_timebase = smp_generic_give_timebase,
> > + .take_timebase = smp_generic_take_timebase,
> > +};
>
> You don't have a HW timebase sync facility ? Is this the board or the
> processor doesn't have a pin to freeze the timebase ? Either way, that
> is bad ! Time to use the cluebat !
See comment to Arnd in another email: We have hardware support for it, just
not including it at this time.
>
> > +#endif /* CONFIG_SMP */
> > +
> > +void __init pas_setup_arch(void)
> > +{
> > + /* init to some ~sane value until calibrate_delay() runs */
> > + loops_per_jiffy = 50000000;
>
> That value still makes any sense with the new tb based delays ? I know
> we still have it here or there, I'm wondering tho...
I haven't tried doing without it, I'll take a look.
-Olof
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 21:48 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <200609052337.11557.arnd@arndb.de>
On Tue, 5 Sep 2006 23:37:10 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 05 September 2006 19:29, Olof Johansson wrote:
> > Base patch for PA6T and PA6T-1682M. This introduces the
> > arch/powerpc/platform/pasemi directory, together with basic
> > implementations for various setup.
> >
> > Much of this was based on other platform code, i.e. Maple, etc.
>
> Very nice patch set, as expected ;-)
>
> See below for the mandatory nitpicking.
Thanks Arnd, good feedback, see some comments below.
>
>
> > Index: merge/arch/powerpc/Kconfig
> > ===================================================================
> > --- merge.orig/arch/powerpc/Kconfig
> > +++ merge/arch/powerpc/Kconfig
> > @@ -413,6 +409,17 @@ config PPC_MAPLE
> > This option enables support for the Maple 970FX Evaluation Board.
> > For more informations, refer to <http://www.970eval.com>
> >
> > +config PPC_PASEMI
> > + depends on PPC_MULTIPLATFORM && PPC64
> > + bool "PA Semi SoC-based platforms"
> > + default n
> > + select MPIC
> > + select PPC_UDBG_16550
> > + select GENERIC_TBSYNC
> > + help
> > + This option enables support for PA Semi's PWRficient line
> > + of SoC processors, including PA6T-1682M
>
> IIRC, the GENERIC_TBSYNC code is really inefficient. Don't you
> have any other way of implementing that?
Yes, we do. It'll be submitted in a later patch for various reasons. We'll use
the generic sync for now.
> > +
> > +#undef DEBUG
> > +
>
> I know that this is done in other places as well, but it seems
> rather pointless, and it provides setting DEBUG from EXTRA_CFLAGS
> in the Makefile.
Yes, mostly leftovers from older debug code. I've taken a few out already,
will go through and take care of the rest.
> > +static struct pci_ops pa_pxp_ops =
> > +{
> > + pa_pxp_read_config,
> > + pa_pxp_write_config
> > +};
>
> spacing: '{' after '=', and ',' after the final member.
>
> > +
> > +static void __init setup_pa_pxp(struct pci_controller* hose)
> > +{
> > + hose->ops = &pa_pxp_ops;
> > + hose->cfg_data = ioremap(0xe0000000, 0x1000000);
> > +}
>
> Shouldn't that be in the device tree?
I was torn between using device tree and hardcoded values here, and went with
hardcoded since that's what maple uses. They're not movable on the chip, but
for future versions I guess device tree makes more sense (if it for some
reason will move).
>
> > + bus_range = (int *) get_property(dev, "bus-range", &len);
>
> Unneeded cast
>
> > + if (bus_range == NULL || len < 2 * sizeof(int)) {
> > + printk(KERN_WARNING "Can't get bus-range for %s, assume bus 0\n",
> > + dev->full_name);
> > + }
>
> if (!bus_range || len < 2 * sizeof(int)) {
>
> > +
> > + hose = pcibios_alloc_controller(dev);
> > + if (hose == NULL)
> > + return -ENOMEM;
>
> if (!hose)
>
> > + if (root == NULL) {
>
> if (!root)
> > +#undef DEBUG
>
> remove
>
> > +extern int pas_set_rtc_time(struct rtc_time *tm);
> > +extern void pas_get_rtc_time(struct rtc_time *tm);
> > +extern unsigned long pas_get_boot_time(void);
> > +extern void pas_pci_init(void);
> > +extern void pas_pcibios_fixup(void);
>
> Extern declarations should never be in a source file, please
> move them to a header
>
> > +static void iommu_dev_setup_null(struct pci_dev *dev) { }
> > +static void iommu_bus_setup_null(struct pci_bus *bus) { }
> > +
> > +static void __init pas_init_early(void)
> > +{
> > + /* No iommu code yet */
> > + ppc_md.iommu_dev_setup = iommu_dev_setup_null;
> > + ppc_md.iommu_bus_setup = iommu_bus_setup_null;
> > + pci_direct_iommu_init();
> > +}
> > +
> > +/* No legacy IO on our parts */
> > +static int pas_check_legacy_ioport(unsigned int baseport)
> > +{
> > + return -ENODEV;
> > +}
>
> Should we maybe change the default behavior so that you don't need
> to provide nops for these functions?
Good point, most platforms no longer implement this anyway. I'll code that up
as a separate patch and submit later.
>
> > +
> > +static __init void pas_init_IRQ(void)
> > +{
> > + struct device_node *np = NULL;
> > + struct device_node *root, *mpic_node = NULL;
> > + unsigned long openpic_addr = 0;
>
> These three should not be initialized.
>
>
> > + BUG_ON(mpic == NULL);
>
> BUG_ON(!mpic);
>
> > +
> > +#undef DEBUG
>
> remove
>
> > +void pas_get_rtc_time(struct rtc_time *tm)
> > +{
> > +}
> > +
> > +int pas_set_rtc_time(struct rtc_time *tm)
> > +{
> > + return -ENODEV;
> > +}
>
> again, it probably makes sense to not have to provide these.
Yep, I could take out the #if 0 as well. It's all a big placeholder anyway.
-Olof
^ permalink raw reply
* Re: [PATCH] Unwire set/get_robust_list
From: David Woodhouse @ 2006-09-05 21:41 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jeodtvfn4x.fsf@sykes.suse.de>
On Mon, 2006-09-04 at 21:27 +0200, Andreas Schwab wrote:
> The syscalls set/get_robust_list must not be wired up until
> futex_atomic_cmpxchg_inatomic is implemented. Otherwise the kernel
> will hang in handle_futex_death.
Either Andreas' or my patch ought to go into 2.6.18, since
[gs]et_robust_list() are otherwise broken there.
--
dwmw2
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Arnd Bergmann @ 2006-09-05 21:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, paulus, anton
In-Reply-To: <20060905122956.2cebd36d@localhost.localdomain>
On Tuesday 05 September 2006 19:29, Olof Johansson wrote:
> Base patch for PA6T and PA6T-1682M. This introduces the
> arch/powerpc/platform/pasemi directory, together with basic
> implementations for various setup.
>
> Much of this was based on other platform code, i.e. Maple, etc.
Very nice patch set, as expected ;-)
See below for the mandatory nitpicking.
> Index: merge/arch/powerpc/Kconfig
> ===================================================================
> --- merge.orig/arch/powerpc/Kconfig
> +++ merge/arch/powerpc/Kconfig
> @@ -413,6 +409,17 @@ config PPC_MAPLE
> This option enables support for the Maple 970FX Evaluation Board.
> For more informations, refer to <http://www.970eval.com>
>
> +config PPC_PASEMI
> + depends on PPC_MULTIPLATFORM && PPC64
> + bool "PA Semi SoC-based platforms"
> + default n
> + select MPIC
> + select PPC_UDBG_16550
> + select GENERIC_TBSYNC
> + help
> + This option enables support for PA Semi's PWRficient line
> + of SoC processors, including PA6T-1682M
IIRC, the GENERIC_TBSYNC code is really inefficient. Don't you
have any other way of implementing that?
> +
> +#undef DEBUG
> +
I know that this is done in other places as well, but it seems
rather pointless, and it provides setting DEBUG from EXTRA_CFLAGS
in the Makefile.
> +static struct pci_ops pa_pxp_ops =
> +{
> + pa_pxp_read_config,
> + pa_pxp_write_config
> +};
spacing: '{' after '=', and ',' after the final member.
> +
> +static void __init setup_pa_pxp(struct pci_controller* hose)
> +{
> + hose->ops = &pa_pxp_ops;
> + hose->cfg_data = ioremap(0xe0000000, 0x1000000);
> +}
Shouldn't that be in the device tree?
> + bus_range = (int *) get_property(dev, "bus-range", &len);
Unneeded cast
> + if (bus_range == NULL || len < 2 * sizeof(int)) {
> + printk(KERN_WARNING "Can't get bus-range for %s, assume bus 0\n",
> + dev->full_name);
> + }
if (!bus_range || len < 2 * sizeof(int)) {
> +
> + hose = pcibios_alloc_controller(dev);
> + if (hose == NULL)
> + return -ENOMEM;
if (!hose)
> + if (root == NULL) {
if (!root)
> +#undef DEBUG
remove
> +extern int pas_set_rtc_time(struct rtc_time *tm);
> +extern void pas_get_rtc_time(struct rtc_time *tm);
> +extern unsigned long pas_get_boot_time(void);
> +extern void pas_pci_init(void);
> +extern void pas_pcibios_fixup(void);
Extern declarations should never be in a source file, please
move them to a header
> +static void iommu_dev_setup_null(struct pci_dev *dev) { }
> +static void iommu_bus_setup_null(struct pci_bus *bus) { }
> +
> +static void __init pas_init_early(void)
> +{
> + /* No iommu code yet */
> + ppc_md.iommu_dev_setup = iommu_dev_setup_null;
> + ppc_md.iommu_bus_setup = iommu_bus_setup_null;
> + pci_direct_iommu_init();
> +}
> +
> +/* No legacy IO on our parts */
> +static int pas_check_legacy_ioport(unsigned int baseport)
> +{
> + return -ENODEV;
> +}
Should we maybe change the default behavior so that you don't need
to provide nops for these functions?
> +
> +static __init void pas_init_IRQ(void)
> +{
> + struct device_node *np = NULL;
> + struct device_node *root, *mpic_node = NULL;
> + unsigned long openpic_addr = 0;
These three should not be initialized.
> + BUG_ON(mpic == NULL);
BUG_ON(!mpic);
> +
> +#undef DEBUG
remove
> +void pas_get_rtc_time(struct rtc_time *tm)
> +{
> +}
> +
> +int pas_set_rtc_time(struct rtc_time *tm)
> +{
> + return -ENODEV;
> +}
again, it probably makes sense to not have to provide these.
Arnd <><
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Benjamin Herrenschmidt @ 2006-09-05 21:31 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905122853.4da8d0fe@localhost.localdomain>
Overall, looks good, some bits tho:
> +static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
> + int offset, int len, u32 *val)
> +{
> + struct pci_controller *hose;
> + unsigned long addr;
.../...
You don't seem to encode support for extended config space (offsets >
256). If it's PCIe, you should have it (flush the 4 top bits of the
offste in the 4 top bits of the cfg address in general). In any case,
you should check the passed-in offset and error out if it is above your
max offset (256 or 4096 depending if you implement extended config space
support) or the kernel might get confused.
> + of_prop = alloc_bootmem(sizeof(struct property) +
> + sizeof(hose->global_number));
> + if (of_prop) {
> + memset(of_prop, 0, sizeof(struct property));
> + of_prop->name = "linux,pci-domain";
> + of_prop->length = sizeof(hose->global_number);
> + of_prop->value = (unsigned char *)&of_prop[1];
> + memcpy(of_prop->value, &hose->global_number, sizeof(hose->global_number));
> + prom_add_property(dev, of_prop);
> + }
Just kill that... nobody cares about that property.
> + if (device_is_compatible(dev, "pa-pxp"))
> + setup_pa_pxp(hose);
And if not ? You have a non-initialized hose without config space access
methods ? Hrm...
> + printk(KERN_INFO "Found PA-PXP PCI host bridge. Firmware bus number: %d->%d\n",
> + hose->first_busno, hose->last_busno);
> +
> + /* Interpret the "ranges" property */
> + /* This also maps the I/O region and sets isa_io/mem_base */
> + pci_process_bridge_OF_ranges(hose, dev, 1);
> + pci_setup_phb_io(hose, 1);
> +
> + return 0;
> +}
> +
> +
> +void __init pas_pcibios_fixup(void)
> +{
> + struct pci_dev *dev = NULL;
> +
> + for_each_pci_dev(dev)
> + pci_read_irq_line(dev);
> +}
> +
> +static void __init pas_fixup_phb_resources(void)
> +{
> + struct pci_controller *hose, *tmp;
> +
> + list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> + unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
> + hose->io_resource.start += offset;
> + hose->io_resource.end += offset;
> + printk(KERN_INFO "PCI Host %d, io start: %lx; io end: %lx\n",
> + hose->global_number,
> + hose->io_resource.start, hose->io_resource.end);
> + }
> +}
There is no generic code for the above ? (I have to double check). If
not, we shall fix that ;)
.../...
> +#ifdef CONFIG_SMP
> +struct smp_ops_t pas_smp_ops = {
> + .probe = smp_mpic_probe,
> + .message_pass = smp_mpic_message_pass,
> + .kick_cpu = smp_generic_kick_cpu,
> + .setup_cpu = smp_mpic_setup_cpu,
> + .give_timebase = smp_generic_give_timebase,
> + .take_timebase = smp_generic_take_timebase,
> +};
You don't have a HW timebase sync facility ? Is this the board or the
processor doesn't have a pin to freeze the timebase ? Either way, that
is bad ! Time to use the cluebat !
> +#endif /* CONFIG_SMP */
> +
> +void __init pas_setup_arch(void)
> +{
> + /* init to some ~sane value until calibrate_delay() runs */
> + loops_per_jiffy = 50000000;
That value still makes any sense with the new tb based delays ? I know
we still have it here or there, I'm wondering tho...
^ permalink raw reply
* Re: pci error recovery procedure
From: Benjamin Herrenschmidt @ 2006-09-05 21:19 UTC (permalink / raw)
To: Linas Vepstas
Cc: Zhang, Yanmin, Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev,
linux-pci maillist
In-Reply-To: <20060905185020.GD7139@austin.ibm.com>
On Tue, 2006-09-05 at 13:50 -0500, Linas Vepstas wrote:
> On Mon, Sep 04, 2006 at 07:03:12PM +1000, Benjamin Herrenschmidt wrote:
> >
> > > As you know, all functions of a device share the same bus number and 5 bit dev number.
> > > They just have different 3 bit function number. We could deduce if functions are in the same
> > > device (slot).
> >
> > Until you have a P2P bridge ...
>
> And this is not theoretical: for example, the matrox graphics cards:
>
> 0000:c8:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 13)
> 0000:c9:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85)
It's also very common with multiple ports network cards
Ben.
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 20:15 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <ada4pvmf60c.fsf@cisco.com>
On Tue, 05 Sep 2006 12:49:39 -0700 Roland Dreier <rdreier@cisco.com> wrote:
> Are all of these really needed? Seems rather crazy, considering there
> are only 145 lines after this in the file...
Yeah, it's crazy. I'll clean it up.
Thanks,
-Olof
^ permalink raw reply
* Wireless Linux(802.11) for Embedded PowerPC
From: wei.li4 @ 2006-09-05 20:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Where is the best access point for this topic? Did anyone work on this
with MPC8xx? Thanks.
Wei
^ permalink raw reply
* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Roland Dreier @ 2006-09-05 19:49 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905122956.2cebd36d@localhost.localdomain>
> +#include <linux/config.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/sched.h>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +#include <linux/stddef.h>
> +#include <linux/unistd.h>
> +#include <linux/ptrace.h>
> +#include <linux/slab.h>
> +#include <linux/user.h>
> +#include <linux/a.out.h>
> +#include <linux/tty.h>
> +#include <linux/string.h>
> +#include <linux/delay.h>
> +#include <linux/ioport.h>
> +#include <linux/major.h>
> +#include <linux/initrd.h>
> +#include <linux/vt_kern.h>
> +#include <linux/console.h>
> +#include <linux/ide.h>
> +#include <linux/pci.h>
> +#include <linux/adb.h>
> +#include <linux/cuda.h>
> +#include <linux/pmu.h>
> +#include <linux/irq.h>
> +#include <linux/seq_file.h>
> +#include <linux/root_dev.h>
> +#include <linux/serial.h>
> +#include <linux/smp.h>
> +
> +#include <asm/processor.h>
> +#include <asm/sections.h>
> +#include <asm/prom.h>
> +#include <asm/system.h>
> +#include <asm/pgtable.h>
> +#include <asm/bitops.h>
> +#include <asm/io.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/iommu.h>
> +#include <asm/machdep.h>
> +#include <asm/dma.h>
> +#include <asm/cputable.h>
> +#include <asm/time.h>
> +#include <asm/of_device.h>
> +#include <asm/lmb.h>
> +#include <asm/mpic.h>
> +#include <asm/smp.h>
> +#include <asm/udbg.h>
> +#include <asm/serial.h>
Are all of these really needed? Seems rather crazy, considering there
are only 145 lines after this in the file...
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-05 19:17 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157348850.20092.304.camel@ymzhang-perf.sh.intel.com>
On Mon, Sep 04, 2006 at 01:47:30PM +0800, Zhang, Yanmin wrote:
> >
> > Again, consider the multi-function cards. On pSeries, I can only enable
> > DMA on a per-slot basis, not a per-function basis. So if one driver
> > enables DMA before some other driver has reset appropriately, everything
> > breaks.
> Does here 'reset' mean hardware slot reset?
I should have said: If one driver of a multi-function card enables DMA before
another driver has stabilized its harware, then everything breaks.
> Then, if the slot is always reset, there will be no the problem.
But that assumes that a hardware #RST will always be done. The API
was designed to get away from this requirement.
> If mmio_enabled is not used currently, I think we could delete it firstly. Later on,
> if a platform really need it, we could add it, so we could keep the simplied codes.
It would be very difficult to add it later. And it would be especially
silly, given that someone would find this discussion in the mailing list
archives.
> Thanks. Now I understand why you specified mmio_enabled and slot_reset. They are just
> to map to pSeries platform hardware operation steps. I know little about pSeries hardware,
The hardware was designed that way because the hardware engineers
thought that this is what the device driver writers would need.
Thay are there to map to actual recovery steps that actual device
drivers might want to do.
> but is it possible to merge such hardware steps from software point of view?
The previous email explained why this would be a bad idea.
> > The platform. By "electrical reset", I mean "dropping the #RST pin low
> > for 200mS". Only the platform can do this.
> Thanks for your explanation. I assume after the electrical reset, all device
> functions of the device slot will go back to the initial status before
> attaching their drivers.
Maybe. Depends on what yur BIOS does. On pSeries, I also need to
set up the adress BARs
> I found a problem of e1000 driver when testing its error handlers. After the NIC is resumed,
> its RX/TX packets numbers are crazy.
Hmm. There is a patch to prevent this from happening. I thought
it was applied a long time ago. e1000_update_stats() should include the
lines:
if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
return;
which is enough to prevent crazy stats on my machine.
--linas
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-05 19:01 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev, linux-pci maillist
In-Reply-To: <1157423528.20092.365.camel@ymzhang-perf.sh.intel.com>
On Tue, Sep 05, 2006 at 10:32:08AM +0800, Zhang, Yanmin wrote:
> Is it the exclusive reason to have multi-steps?
I don't understand the question. A previous email explained the reason
to have mutiple steps.
> 1) Here link reset and hard reset are hardware operations, not the
> link_reset and slot_reset callback in pci_error_handlers.
I don't understand the comment.
> 2) Callback error_detected will notify drivers there is PCI errors. Drivers
> shouldn't do any I/O in error_detected.
It shouldn't matter. If it is truly important for a particular platform
to make sure that there is no i/o, then the low-level i/o routines
could be modified to drop any accidentally issued i/o on the floor.
This doesn't require a change to either the API or the policy.
> 3) If both the link and slot are reset after all error_detected are called,
> the device should go back to initial status and all DMA should be stopped
> automatically. Why does the driver still need a chance to stop DMA?
As explained previously, not all drivers may want to have a full
electrical device reset.
> The
> error_detected of the drivers in the latest kernel who support err handlers
> always returns PCI_ERS_RESULT_NEED_RESET. They are typical examples.
Just because the current drivers do it this way does not mean that this is
the best way to do things. A full reset is time-consuming. Some drivers
may want to implement a faster and quicker reset.
--linas
^ permalink raw reply
* Re: [2.6.19 PATCH 1/7] ehea: interface to network stack
From: Francois Romieu @ 2006-09-05 18:58 UTC (permalink / raw)
To: Thomas Klein
Cc: Jan-Bernd Themann, netdev, linux-kernel, Christoph Raisch,
linux-ppc, Marcus Eder
In-Reply-To: <44FD931A.3080107@de.ibm.com>
Thomas Klein <osstklei@de.ibm.com> :
[...]
> Somehow I don't get your point concerning the usage of 'k'. We need another
> iterator as the for loops using 'k' use 'i' as their terminating condition.
Something like the code below perhaps (with more local variables maybe):
static int ehea_reg_interrupts(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
struct ehea_port_res *pr;
int i, ret;
for (i = 0; i < port->num_def_qps; i++) {
pr = &port->port_res[i];
snprintf(pr->int_recv_name, EHEA_IRQ_NAME_SIZE - 1
, "%s-recv%d", dev->name, i);
ret = ibmebus_request_irq(NULL, pr->recv_eq->attr.ist1,
ehea_recv_irq_handler, SA_INTERRUPT,
pr->int_recv_name, pr);
if (ret) {
ehea_error("failed registering irq for ehea_recv_int:"
"port_res_nr:%d, ist=%X", i,
pr->recv_eq->attr.ist1);
goto err_free_irq_recv_eq_0;
}
if (netif_msg_ifup(port))
ehea_info("irq_handle 0x%X for funct ehea_recv_int %d "
"registered", pr->recv_eq->attr.ist1, i);
}
snprintf(port->int_aff_name, EHEA_IRQ_NAME_SIZE - 1,
"%s-aff", dev->name);
ret = ibmebus_request_irq(NULL, port->qp_eq->attr.ist1,
ehea_qp_aff_irq_handler,
SA_INTERRUPT, port->int_aff_name, port);
if (ret) {
ehea_error("failed registering irq for qp_aff_irq_handler:"
" ist=%X", port->qp_eq->attr.ist1);
goto err_free_irq_recv_eq_0;
}
if (netif_msg_ifup(port))
ehea_info("irq_handle 0x%X for function qp_aff_irq_handler "
"registered", port->qp_eq->attr.ist1);
for (i = 0; i < port->num_def_qps + port->num_add_tx_qps; i++) {
pr = &port->port_res[i];
snprintf(pr->int_send_name, EHEA_IRQ_NAME_SIZE - 1,
"%s-send%d", dev->name, i);
ret = ibmebus_request_irq(NULL, pr->send_eq->attr.ist1,
ehea_send_irq_handler, SA_INTERRUPT,
pr->int_send_name, pr);
if (ret) {
ehea_error("failed registering irq for ehea_send"
" port_res_nr:%d, ist=%X", i,
pr->send_eq->attr.ist1);
goto err_free_irq_send_eq_1;
}
if (netif_msg_ifup(port))
ehea_info("irq_handle 0x%X for function ehea_send_int "
"%d registered", pr->send_eq->attr.ist1, i);
}
out:
return ret;
err_free_irq_send_eq_1:
// Post-dec works with unsigned int too.
while (i-- > 0) {
u32 ist = port->port_res[i].send_eq->attr.ist1;
ibmebus_free_irq(NULL, ist, &port->port_res[i]);
}
ibmebus_free_irq(NULL, port->qp_eq->attr.ist1, port);
i = port->num_def_qps;
err_free_irq_recv_eq_0:
while (i-- > 0) {
u32 ist = port->port_res[i].recv_eq->attr.ist1;
ibmebus_free_irq(NULL, ist, &port->port_res[k]);
}
goto out;
}
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-05 18:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Zhang, Yanmin, Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev,
linux-pci maillist
In-Reply-To: <1157360592.22705.46.camel@localhost.localdomain>
On Mon, Sep 04, 2006 at 07:03:12PM +1000, Benjamin Herrenschmidt wrote:
>
> > As you know, all functions of a device share the same bus number and 5 bit dev number.
> > They just have different 3 bit function number. We could deduce if functions are in the same
> > device (slot).
>
> Until you have a P2P bridge ...
And this is not theoretical: for example, the matrox graphics cards:
0000:c8:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 13)
0000:c9:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85)
Now, I could have sworn there was another device behind this bridge,
some serial or joystick controller or something, although this
particular card doesn't seem to have it.
------
It's not clear to me what hardware may show up in the future.
For example, someone may build a 32x PCI-E card that will act
as a bridge to a drawer with half-a-dozen ordinary PCI-X slots
in it. This is perhaps a bit hypothetical, but changing the API
will make it harder to implement eror recovery for such a system.
FWIW, there is at least one pSeries system in the lab which has
several hundred PCI slots attached to it, although I've never
done testing on it. Hmm. Maybe its time I did ...
--linas
^ permalink raw reply
* Re: MPC8245 reset register
From: Reeve Yang @ 2006-09-05 18:49 UTC (permalink / raw)
To: Jon Scully; +Cc: linuxppc-embedded
In-Reply-To: <53107f6e0609021647l1f1cd84du496e3cd7219b603@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
Hi Jon,
Could you elaborate it a bit? I wrote 0x1 to PI register, but CPU hangs
without resetting. I'm kind of curious what's the proper way to reset the
8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
Thanks a lot.
- Reeve
On 9/2/06, Jon Scully <jonscully@gmail.com> wrote:
>
> On 9/2/06, Reeve Yang <yang.reeve@gmail.com> wrote:
> > Can anyone tell me which register should I use to do soft reset on
> MPC8241/5
> > CPU? I searched its manuall but only find EPIC to send SRESET exception
> on
> > offset 0x41090.
> >
> > Thanks.
> >
> > - Reeve
> >
>
> Use the reset instruction (RST in assembly).
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 1319 bytes --]
^ permalink raw reply
* Re: Serial problem with MPC8241-based board
From: Mark A. Greer @ 2006-09-05 18:49 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0609032112260.3944@poirot.grange>
On Sun, Sep 03, 2006 at 09:58:25PM +0200, Guennadi Liakhovetski wrote:
Hi Guennadi,
> Mark, may I use this opportunity to ask you for your current consistent
> snapshot of both powerpc/boot and powerpc/platforms and whatever others? I
> can compile a kernel with ARCH=powerpc for linkstation, now I have to find
> a way to boot it. My choices are kexec or u-boot. Neither will run
> out-of-the-box, so...
I'm in the middle of making a bunch of changes to the bootwrapper
patches so I don't have a good set of patches for you.
Hopefully in a day or two at which time I'll be happy to share them with you.
> BTW, I would be greatful for any help with setting up kexec.
I can't help you there. You could try asking Milton Miller.
Mark
^ permalink raw reply
* Re: [3/5] powerpc: PA6T cputable entry, PVR value
From: Michael Neuling @ 2006-09-05 18:43 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905122808.36c0c88d@localhost.localdomain>
> #define PV_630p 0x0041
> #define PV_970MP 0x0044
> #define PV_BE 0x0070
> +#define PV_PA6T 0x0090
> +
>
> /*
> * Number of entries in the SLB. If this ever changes we should handle
Should be a space not a tab after the #define. Also extra new line is
not required.
Mikey "White space king" Neuling
^ permalink raw reply
* Compile Error
From: wei.li4 @ 2006-09-05 18:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am working on linux-2.6.18-rc2-g73a589b5.tar.bz2 for MPC875, the
cross-tools are from ELDK 4.0. After configuration and do 'make
zImage', I got these error:
CC arch/ppc/boot/simple/m8xx_tty.o
arch/ppc/boot/simple/m8xx_tty.c:32: error: static declaration of 'cpmp'
follows non-static declaration
include/asm/commproc.h:74: error: previous declaration of 'cpmp' was here
make[2]: *** [arch/ppc/boot/simple/m8xx_tty.o] Error 1
I also got these errors if I used these tools on Linux 2.6.13, but
there is no error if I use tools from ELDK 3.1.1, can anyone help me
figure it out? Thanks.
^ permalink raw reply
* Re: [U-Boot-Users] OT: Re: Status of OF in TQM8540 and linux-2.6.17.11
From: Clemens Koller @ 2006-09-05 18:06 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <20060905153925.F1384353A15@atlas.denx.de>
Hi, Wolfgang!
Success!
>> The upper defines need to reside in the board-specific code for tqm as well as for other boards
>> utilizing such scheme (see platforms/85xx/mpc85xx_ads_common.h for instance).
>
>
> Thanks for pointing out.
>
> Clemens, plese try again (commit id cd4ebbc9b95434977e5f182b9a22d7d1de0748ce)
Jup, that works!
Just for the records: As of Sept 05 2006,
U-Boot 1.1.4-gf60ba0d3 and linux-2.6-denx-cd4ebbc9b (aka: 2.6.18-rc5-git)
is known to boot on the TQM8540 + STK85XX in the default configurations.
Thank you!
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* [5/5] powerpc: PA Semi PWRficient MAINTAINER entry
From: Olof Johansson @ 2006-09-05 17:30 UTC (permalink / raw)
To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060904175742.5472a6fa@localhost.localdomain>
Maintainer entry for PWRficient
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: merge/MAINTAINERS
===================================================================
--- merge.orig/MAINTAINERS
+++ merge/MAINTAINERS
@@ -1777,6 +1777,13 @@ W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
+LINUX FOR POWERPC PA SEMI PWRFICIENT
+P: Olof Johansson
+M: olof@lixom.net
+W: http://www.pasemi.com/
+L: linuxppc-dev@ozlabs.org
+S: Supported
+
LLC (802.2)
P: Arnaldo Carvalho de Melo
M: acme@conectiva.com.
^ 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