* [PATCH 1/4] ppc32: platform_device conversion from OCP
From: Kumar Gala @ 2005-01-18 15:35 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, linuxppc-embedded
System platform_device description, discovery and management:
On most embedded PPC systems we either have a core CPU and chipset
(MPC10x, TSI10x, Marvell, etc.) or a system-on-chip device (4xx, 8xx,
82xx, 85xx, etc.). Some of these sub-archs have been using the On Chip
Peripheral (OCP) driver model. The functionality that OCP provide has
been replaced by the generic driver model and platform_device. Also, some
of these device may exist across a number of architectures (PPC, MIPS,
ARM) such that some information that is shared between the architecture
and driver needs to exist outside of either.
The ppc_sys changes add a standard way for PowerPC systems to describe the
devices and systems that exist in the sub-arch. Additionally, we are able
to discover which system we are and manage which devices are actually
registered and any platform specific fixups that may be needed.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/syslib/Makefile 2005-01-17 22:31:44 -06:00
@@ -92,7 +92,8 @@
obj-$(CONFIG_MPC10X_OPENPIC) += open_pic.o
obj-$(CONFIG_40x) += dcr.o
obj-$(CONFIG_BOOKE) += dcr.o
-obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o
+obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o \
+ ppc_sys.o
ifeq ($(CONFIG_85xx),y)
obj-$(CONFIG_PCI) += indirect_pci.o pci_auto.o
endif
diff -Nru a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/syslib/ppc_sys.c 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,103 @@
+/*
+ * arch/ppc/syslib/ppc_sys.c
+ *
+ * PPC System library functions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <asm/ppc_sys.h>
+
+int (*ppc_sys_device_fixup) (struct platform_device * pdev);
+
+static int ppc_sys_inited;
+
+void __init identify_ppc_sys_by_id(u32 id)
+{
+ unsigned int i = 0;
+ while (1) {
+ if ((ppc_sys_specs[i].mask & id) == ppc_sys_specs[i].value)
+ break;
+ i++;
+ }
+
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
+
+ return;
+}
+
+void __init identify_ppc_sys_by_name(char *name)
+{
+ /* TODO */
+ return;
+}
+
+/* Update all memory resources by paddr, call before platform_device_register */
+void __init
+ppc_sys_fixup_mem_resource(struct platform_device *pdev, phys_addr_t paddr)
+{
+ int i;
+ for (i = 0; i < pdev->num_resources; i++) {
+ struct resource *r = &pdev->resource[i];
+ if ((r->flags & IORESOURCE_MEM) == IORESOURCE_MEM) {
+ r->start += paddr;
+ r->end += paddr;
+ }
+ }
+}
+
+/* Get platform_data pointer out of platform device, call before platform_device_register */
+void *__init ppc_sys_get_pdata(enum ppc_sys_devices dev)
+{
+ return ppc_sys_platform_devices[dev].dev.platform_data;
+}
+
+void ppc_sys_device_remove(enum ppc_sys_devices dev)
+{
+ unsigned int i;
+
+ if (ppc_sys_inited) {
+ platform_device_unregister(&ppc_sys_platform_devices[dev]);
+ } else {
+ if (cur_ppc_sys_spec == NULL)
+ return;
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++)
+ if (cur_ppc_sys_spec->device_list[i] == dev)
+ cur_ppc_sys_spec->device_list[i] = -1;
+ }
+}
+
+static int __init ppc_sys_init(void)
+{
+ unsigned int i, dev_id, ret = 0;
+
+ BUG_ON(cur_ppc_sys_spec == NULL);
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ dev_id = cur_ppc_sys_spec->device_list[i];
+ if (dev_id != -1) {
+ if (ppc_sys_device_fixup != NULL)
+ ppc_sys_device_fixup(&ppc_sys_platform_devices
+ [dev_id]);
+ if (platform_device_register
+ (&ppc_sys_platform_devices[dev_id])) {
+ ret = 1;
+ printk(KERN_ERR
+ "unable to register device %d\n",
+ dev_id);
+ }
+ }
+ }
+
+ ppc_sys_inited = 1;
+ return ret;
+}
+
+subsys_initcall(ppc_sys_init);
diff -Nru a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/asm-ppc/ppc_sys.h 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,65 @@
+/*
+ * include/asm-ppc/ppc_sys.h
+ *
+ * PPC system definitions and library functions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_PPC_SYS_H
+#define __ASM_PPC_SYS_H
+
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/types.h>
+
+#if defined(CONFIG_85xx)
+#include <asm/mpc85xx.h>
+#else
+#error "need definition of ppc_sys_devices"
+#endif
+
+struct ppc_sys_spec {
+ /* PPC sys is matched via (ID & mask) == value, id could be
+ * PVR, SVR, IMMR, * etc. */
+ u32 mask;
+ u32 value;
+ u32 num_devices;
+ char *ppc_sys_name;
+ enum ppc_sys_devices *device_list;
+};
+
+/* describes all specific chips and which devices they have on them */
+extern struct ppc_sys_spec ppc_sys_specs[];
+extern struct ppc_sys_spec *cur_ppc_sys_spec;
+
+/* determine which specific SOC we are */
+extern void identify_ppc_sys_by_id(u32 id) __init;
+extern void identify_ppc_sys_by_name(char *name) __init;
+
+/* describes all devices that may exist in a given family of processors */
+extern struct platform_device ppc_sys_platform_devices[];
+
+/* allow any platform_device fixup to occur before device is registered */
+extern int (*ppc_sys_device_fixup) (struct platform_device * pdev);
+
+/* Update all memory resources by paddr, call before platform_device_register */
+extern void ppc_sys_fixup_mem_resource(struct platform_device *pdev,
+ phys_addr_t paddr) __init;
+
+/* Get platform_data pointer out of platform device, call before platform_device_register */
+extern void *ppc_sys_get_pdata(enum ppc_sys_devices dev) __init;
+
+/* remove a device from the system */
+extern void ppc_sys_device_remove(enum ppc_sys_devices dev);
+
+#endif /* __ASM_PPC_SYS_H */
+#endif /* __KERNEL__ */
diff -Nru a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/include/linux/fsl_devices.h 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,78 @@
+/*
+ * include/linux/fsl_devices.h
+ *
+ * Definitions for any platform device related flags or structures for
+ * Freescale processor devices
+ *
+ * Maintainer: Kumar Gala (kumar.gala@freescale.com)
+ *
+ * Copyright 2004 Freescale Semiconductor, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifdef __KERNEL__
+#ifndef _FSL_DEVICE_H_
+#define _FSL_DEVICE_H_
+
+#include <linux/types.h>
+
+/*
+ * Some conventions on how we handle peripherals on Freescale chips
+ *
+ * unique device: a platform_device entry in fsl_plat_devs[] plus
+ * associated device information in its platform_data structure.
+ *
+ * A chip is described by a set of unique devices.
+ *
+ * Each sub-arch has its own master list of unique devices and
+ * enumerates them by enum fsl_devices in a sub-arch specific header
+ *
+ * The platform data structure is broken into two parts. The
+ * first is device specific information that help identify any
+ * unique features of a peripheral. The second is any
+ * information that may be defined by the board or how the device
+ * is connected externally of the chip.
+ *
+ * naming conventions:
+ * - platform data structures: <driver>_platform_data
+ * - platform data device flags: FSL_<driver>_DEV_<FLAG>
+ * - platform data board flags: FSL_<driver>_BRD_<FLAG>
+ *
+ */
+
+struct gianfar_platform_data {
+ /* device specific information */
+ u32 device_flags;
+ u32 phy_reg_addr;
+
+ /* board specific information */
+ u32 board_flags;
+ u32 phyid;
+ u32 interruptPHY;
+ u8 mac_addr[6];
+};
+
+/* Flags related to gianfar device features */
+#define FSL_GIANFAR_DEV_HAS_GIGABIT 0x00000001
+#define FSL_GIANFAR_DEV_HAS_COALESCE 0x00000002
+#define FSL_GIANFAR_DEV_HAS_RMON 0x00000004
+#define FSL_GIANFAR_DEV_HAS_MULTI_INTR 0x00000008
+
+/* Flags in gianfar_platform_data */
+#define FSL_GIANFAR_BRD_HAS_PHY_INTR 0x00000001 /* if not set use a timer */
+
+struct fsl_i2c_platform_data {
+ /* device specific information */
+ u32 device_flags;
+};
+
+/* Flags related to I2C device features */
+#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
+#define FSL_I2C_DEV_CLOCK_5200 0x00000002
+
+#endif /* _FSL_DEVICE_H_ */
+#endif /* __KERNEL__ */
^ permalink raw reply
* [PATCH 4/4] ppc32: platform_device conversion from OCP
From: Kumar Gala @ 2005-01-18 15:35 UTC (permalink / raw)
To: torvalds, akpm, jgarzik; +Cc: netdev, linux-kernel, linuxppc-embedded
Convert gianfar ethernet driver from using an OCP to platform_device.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c
--- a/drivers/net/gianfar.c 2005-01-17 22:31:44 -06:00
+++ b/drivers/net/gianfar.c 2005-01-17 22:31:44 -06:00
@@ -26,7 +26,7 @@
* controllers on the Freescale 8540/8560 integrated processors,
* as well as the Fast Ethernet Controller on the 8540.
*
- * The driver is initialized through OCP. Structures which
+ * The driver is initialized through platform_device. Structures which
* define the configuration needed by the board are defined in a
* board structure in arch/ppc/platforms (though I do not
* discount the possibility that other architectures could one
@@ -85,6 +85,7 @@
#include <linux/skbuff.h>
#include <linux/spinlock.h>
#include <linux/mm.h>
+#include <linux/device.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -130,8 +131,8 @@
static void adjust_link(struct net_device *dev);
static void init_registers(struct net_device *dev);
static int init_phy(struct net_device *dev);
-static int gfar_probe(struct ocp_device *ocpdev);
-static void gfar_remove(struct ocp_device *ocpdev);
+static int gfar_probe(struct device *device);
+static int gfar_remove(struct device *device);
void free_skb_resources(struct gfar_private *priv);
static void gfar_set_multi(struct net_device *dev);
static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
@@ -148,45 +149,27 @@
MODULE_DESCRIPTION("Gianfar Ethernet Driver");
MODULE_LICENSE("GPL");
-/* Called by the ocp code to initialize device data structures
- * required for bringing up the device
- * returns 0 on success */
-static int gfar_probe(struct ocp_device *ocpdev)
+static int gfar_probe(struct device *device)
{
u32 tempval;
- struct ocp_device *mdiodev;
struct net_device *dev = NULL;
struct gfar_private *priv = NULL;
- struct ocp_gfar_data *einfo;
+ struct platform_device *pdev = to_platform_device(device);
+ struct gianfar_platform_data *einfo;
+ struct resource *r;
int idx;
int err = 0;
int dev_ethtool_ops = 0;
- einfo = (struct ocp_gfar_data *) ocpdev->def->additions;
+ einfo = (struct gianfar_platform_data *) pdev->dev.platform_data;
if (einfo == NULL) {
printk(KERN_ERR "gfar %d: Missing additional data!\n",
- ocpdev->def->index);
+ pdev->id);
return -ENODEV;
}
-
- /* get a pointer to the register memory which can
- * configure the PHYs. If it's different from this set,
- * get the device which has those regs */
- if ((einfo->phyregidx >= 0) &&
- (einfo->phyregidx != ocpdev->def->index)) {
- mdiodev = ocp_find_device(OCP_ANY_ID,
- OCP_FUNC_GFAR, einfo->phyregidx);
-
- /* If the device which holds the MDIO regs isn't
- * up, wait for it to come up */
- if (mdiodev == NULL)
- return -EAGAIN;
- } else {
- mdiodev = ocpdev;
- }
-
+
/* Create an ethernet device instance */
dev = alloc_etherdev(sizeof (*priv));
@@ -198,9 +181,19 @@
/* Set the info in the priv to the current info */
priv->einfo = einfo;
+ /* fill out IRQ fields */
+ if (einfo->device_flags & FSL_GIANFAR_DEV_HAS_MULTI_INTR) {
+ priv->interruptTransmit = platform_get_irq_byname(pdev, "tx");
+ priv->interruptReceive = platform_get_irq_byname(pdev, "rx");
+ priv->interruptError = platform_get_irq_byname(pdev, "error");
+ } else {
+ priv->interruptTransmit = platform_get_irq(pdev, 0);
+ }
+
/* get a pointer to the register memory */
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->regs = (struct gfar *)
- ioremap(ocpdev->def->paddr, sizeof (struct gfar));
+ ioremap(r->start, sizeof (struct gfar));
if (priv->regs == NULL) {
err = -ENOMEM;
@@ -209,7 +202,7 @@
/* Set the PHY base address */
priv->phyregs = (struct gfar *)
- ioremap(mdiodev->def->paddr, sizeof (struct gfar));
+ ioremap(einfo->phy_reg_addr, sizeof (struct gfar));
if (priv->phyregs == NULL) {
err = -ENOMEM;
@@ -218,7 +211,7 @@
spin_lock_init(&priv->lock);
- ocp_set_drvdata(ocpdev, dev);
+ dev_set_drvdata(device, dev);
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
@@ -255,7 +248,7 @@
dev->base_addr = (unsigned long) (priv->regs);
SET_MODULE_OWNER(dev);
- SET_NETDEV_DEV(dev, &ocpdev->dev);
+ SET_NETDEV_DEV(dev, device);
/* Fill in the dev structure */
dev->open = gfar_enet_open;
@@ -274,10 +267,10 @@
/* Index into the array of possible ethtool
* ops to catch all 4 possibilities */
- if((priv->einfo->flags & GFAR_HAS_RMON) == 0)
+ if((priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_RMON) == 0)
dev_ethtool_ops += 1;
- if((priv->einfo->flags & GFAR_HAS_COALESCE) == 0)
+ if((priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_COALESCE) == 0)
dev_ethtool_ops += 2;
dev->ethtool_ops = gfar_op_array[dev_ethtool_ops];
@@ -332,18 +325,21 @@
return -ENOMEM;
}
-static void gfar_remove(struct ocp_device *ocpdev)
+static int gfar_remove(struct device *device)
{
- struct net_device *dev = ocp_get_drvdata(ocpdev);
+ struct net_device *dev = dev_get_drvdata(device);
struct gfar_private *priv = netdev_priv(dev);
- ocp_set_drvdata(ocpdev, NULL);
+ dev_set_drvdata(device, NULL);
iounmap((void *) priv->regs);
iounmap((void *) priv->phyregs);
free_netdev(dev);
+
+ return 0;
}
+
/* Configure the PHY for dev.
* returns 0 if success. -1 if failure
*/
@@ -470,7 +466,7 @@
gfar_write(&priv->regs->rctrl, 0x00000000);
/* Zero out the rmon mib registers if it has them */
- if (priv->einfo->flags & GFAR_HAS_RMON) {
+ if (priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_RMON) {
memset((void *) &(priv->regs->rmon), 0,
sizeof (struct rmon_mib));
@@ -536,7 +532,7 @@
tempval &= ~(MACCFG1_RX_EN | MACCFG1_TX_EN);
gfar_write(®s->maccfg1, tempval);
- if (priv->einfo->flags & GFAR_HAS_PHY_INTR) {
+ if (priv->einfo->board_flags & FSL_GIANFAR_BRD_HAS_PHY_INTR) {
/* Clear any pending interrupts */
mii_clear_phy_interrupt(priv->mii_info);
@@ -548,15 +544,15 @@
spin_unlock_irqrestore(&priv->lock, flags);
/* Free the IRQs */
- if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) {
- free_irq(priv->einfo->interruptError, dev);
- free_irq(priv->einfo->interruptTransmit, dev);
- free_irq(priv->einfo->interruptReceive, dev);
+ if (priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_MULTI_INTR) {
+ free_irq(priv->interruptError, dev);
+ free_irq(priv->interruptTransmit, dev);
+ free_irq(priv->interruptReceive, dev);
} else {
- free_irq(priv->einfo->interruptTransmit, dev);
+ free_irq(priv->interruptTransmit, dev);
}
- if (priv->einfo->flags & GFAR_HAS_PHY_INTR) {
+ if (priv->einfo->board_flags & FSL_GIANFAR_BRD_HAS_PHY_INTR) {
free_irq(priv->einfo->interruptPHY, dev);
} else {
del_timer_sync(&priv->phy_info_timer);
@@ -727,41 +723,41 @@
/* If the device has multiple interrupts, register for
* them. Otherwise, only register for the one */
- if (priv->einfo->flags & GFAR_HAS_MULTI_INTR) {
+ if (priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_MULTI_INTR) {
/* Install our interrupt handlers for Error,
* Transmit, and Receive */
- if (request_irq(priv->einfo->interruptError, gfar_error,
+ if (request_irq(priv->interruptError, gfar_error,
0, "enet_error", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d\n",
- dev->name, priv->einfo->interruptError);
+ dev->name, priv->interruptError);
err = -1;
goto err_irq_fail;
}
- if (request_irq(priv->einfo->interruptTransmit, gfar_transmit,
+ if (request_irq(priv->interruptTransmit, gfar_transmit,
0, "enet_tx", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d\n",
- dev->name, priv->einfo->interruptTransmit);
+ dev->name, priv->interruptTransmit);
err = -1;
goto tx_irq_fail;
}
- if (request_irq(priv->einfo->interruptReceive, gfar_receive,
+ if (request_irq(priv->interruptReceive, gfar_receive,
0, "enet_rx", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d (receive0)\n",
- dev->name, priv->einfo->interruptReceive);
+ dev->name, priv->interruptReceive);
err = -1;
goto rx_irq_fail;
}
} else {
- if (request_irq(priv->einfo->interruptTransmit, gfar_interrupt,
+ if (request_irq(priv->interruptTransmit, gfar_interrupt,
0, "gfar_interrupt", dev) < 0) {
printk(KERN_ERR "%s: Can't get IRQ %d\n",
- dev->name, priv->einfo->interruptError);
+ dev->name, priv->interruptError);
err = -1;
goto err_irq_fail;
@@ -815,9 +811,9 @@
return 0;
rx_irq_fail:
- free_irq(priv->einfo->interruptTransmit, dev);
+ free_irq(priv->interruptTransmit, dev);
tx_irq_fail:
- free_irq(priv->einfo->interruptError, dev);
+ free_irq(priv->interruptError, dev);
err_irq_fail:
rx_skb_fail:
free_skb_resources(priv);
@@ -1490,7 +1486,7 @@
adjust_link(dev);
/* Reenable interrupts, if needed */
- if (priv->einfo->flags & GFAR_HAS_PHY_INTR)
+ if (priv->einfo->board_flags & FSL_GIANFAR_BRD_HAS_PHY_INTR)
mii_configure_phy_interrupt(priv->mii_info,
MII_INTERRUPT_ENABLED);
}
@@ -1547,7 +1543,7 @@
del_timer_sync(&priv->phy_info_timer);
/* Grab the PHY interrupt, if necessary/possible */
- if (priv->einfo->flags & GFAR_HAS_PHY_INTR) {
+ if (priv->einfo->board_flags & FSL_GIANFAR_BRD_HAS_PHY_INTR) {
if (request_irq(priv->einfo->interruptPHY,
phy_interrupt,
SA_SHIRQ,
@@ -1758,7 +1754,7 @@
/* Hmm... */
#if defined (BRIEF_GFAR_ERRORS) || defined (VERBOSE_GFAR_ERRORS)
printk(KERN_DEBUG "%s: error interrupt (ievent=0x%08x imask=0x%08x)\n",
- dev->name, events, gfar_read(priv->regs->imask));
+ dev->name, events, gfar_read(&priv->regs->imask));
#endif
/* Update the error counters */
@@ -1829,36 +1825,23 @@
}
/* Structure for a device driver */
-static struct ocp_device_id gfar_ids[] = {
- {.vendor = OCP_ANY_ID,.function = OCP_FUNC_GFAR},
- {.vendor = OCP_VENDOR_INVALID}
-};
-
-static struct ocp_driver gfar_driver = {
- .name = "gianfar",
- .id_table = gfar_ids,
-
+static struct device_driver gfar_driver = {
+ .name = "fsl-gianfar",
+ .bus = &platform_bus_type,
.probe = gfar_probe,
.remove = gfar_remove,
};
static int __init gfar_init(void)
{
- int rc;
-
- rc = ocp_register_driver(&gfar_driver);
- if (rc != 0) {
- ocp_unregister_driver(&gfar_driver);
- return -ENODEV;
- }
-
- return 0;
+ return driver_register(&gfar_driver);
}
static void __exit gfar_exit(void)
{
- ocp_unregister_driver(&gfar_driver);
+ driver_unregister(&gfar_driver);
}
module_init(gfar_init);
module_exit(gfar_exit);
+
diff -Nru a/drivers/net/gianfar.h b/drivers/net/gianfar.h
--- a/drivers/net/gianfar.h 2005-01-17 22:31:44 -06:00
+++ b/drivers/net/gianfar.h 2005-01-17 22:31:44 -06:00
@@ -37,6 +37,7 @@
#include <linux/skbuff.h>
#include <linux/spinlock.h>
#include <linux/mm.h>
+#include <linux/fsl_devices.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -47,7 +48,6 @@
#include <linux/workqueue.h>
#include <linux/ethtool.h>
#include <linux/netdevice.h>
-#include <asm/ocp.h>
#include "gianfar_phy.h"
/* The maximum number of packets to be handled in one call of gfar_poll */
@@ -510,7 +510,10 @@
unsigned int rxclean;
/* Info structure initialized by board setup code */
- struct ocp_gfar_data *einfo;
+ unsigned int interruptTransmit;
+ unsigned int interruptReceive;
+ unsigned int interruptError;
+ struct gianfar_platform_data *einfo;
struct gfar_mii_info *mii_info;
int oldspeed;
diff -Nru a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
--- a/drivers/net/gianfar_ethtool.c 2005-01-17 22:31:44 -06:00
+++ b/drivers/net/gianfar_ethtool.c 2005-01-17 22:31:44 -06:00
@@ -186,9 +186,11 @@
{
struct gfar_private *priv = netdev_priv(dev);
uint gigabit_support =
- priv->einfo->flags & GFAR_HAS_GIGABIT ? SUPPORTED_1000baseT_Full : 0;
+ priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT ?
+ SUPPORTED_1000baseT_Full : 0;
uint gigabit_advert =
- priv->einfo->flags & GFAR_HAS_GIGABIT ? ADVERTISED_1000baseT_Full: 0;
+ priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT ?
+ ADVERTISED_1000baseT_Full: 0;
cmd->supported = (SUPPORTED_10baseT_Half
| SUPPORTED_100baseT_Half
^ permalink raw reply
* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-18 20:09 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEEECGDAAA.joakim.tjernlund@lumentis.se>
On Fri, Jan 14, 2005 at 08:51:44PM +0100, Joakim Tjernlund wrote:
> BTW, there is a simpler fix to the TLB Miss problem.
> In the TLB Miss handlers, just move the 2: label a few instr. upwards to
> the same line as the "li r21, 0x00f0". That way you will force a
> TLB error. You can do this for both Data and Instr. Miss handlers.
> The code after where the 2: label used to be can be deleted.
Like this? Only lightly tested on my rpxlite on 2.6:
---
linux-2.6-current-trini/arch/ppc/kernel/head_8xx.S | 22 +--------------------
1 files changed, 2 insertions(+), 20 deletions(-)
diff -puN arch/ppc/kernel/head_8xx.S~ppc32-mpc8xx-itlbmiss-fix arch/ppc/kernel/head_8xx.S
--- linux-2.6-current/arch/ppc/kernel/head_8xx.S~ppc32-mpc8xx-itlbmiss-fix 2005-01-18 11:55:34.000000000 -0700
+++ linux-2.6-current-trini/arch/ppc/kernel/head_8xx.S 2005-01-18 11:57:11.000000000 -0700
@@ -343,7 +343,7 @@ InstructionTLBMiss:
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
- li r11, 0x00f0
+2: li r11, 0x00f0
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x2d80, r3)
mtspr MI_RPN, r10 /* Update TLB entry */
@@ -357,15 +357,6 @@ InstructionTLBMiss:
#endif
rfi
-2: mfspr r10, M_TW /* Restore registers */
- lwz r11, 0(r0)
- mtcr r11
- lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
- lwz r3, 8(r0)
-#endif
- b InstructionAccess
-
. = 0x1200
DataStoreTLBMiss:
#ifdef CONFIG_8xx_CPU6
@@ -419,7 +410,7 @@ DataStoreTLBMiss:
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
- li r11, 0x00f0
+2: li r11, 0x00f0
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr MD_RPN, r10 /* Update TLB entry */
@@ -433,15 +424,6 @@ DataStoreTLBMiss:
#endif
rfi
-2: mfspr r10, M_TW /* Restore registers */
- lwz r11, 0(r0)
- mtcr r11
- lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
- lwz r3, 8(r0)
-#endif
- b DataAccess
-
/* This is an instruction TLB error on the MPC8xx. This could be due
* to many reasons, such as executing guarded memory or illegal instruction
* addresses. There is nothing to do but handle a big time error fault.
_
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: John W. Linville @ 2005-01-18 20:29 UTC (permalink / raw)
To: Povolotsky, Alexander
Cc: 'Steven Blakeslee',
'linuxppc-embedded@ozlabs.org'
In-Reply-To: <313680C9A886D511A06000204840E1CF0A647502@whq-msgusr-02.pit.comms.marconi.com>
On Tue, Jan 18, 2005 at 02:08:19PM -0500, Povolotsky, Alexander wrote:
> My board is using:
>
> bd->bi_intfreq = 50000000;
> bd->bi_busfreq = 50000000;
>
> While RPX-Lite is using
>
> bd->bi_intfreq = 48000000;
> bd->bi_busfreq = 48000000;
>
> Is this what makes RPX-Lite work and my (MPC 880) not ?
That, of course, depends on which value is correct for your
board... :-)
When I mentioned in one of our (possibly off-line) exchanges that
_slightly_ incorrect clock speeds might explain how you get a few good
characters from the serial port before you get all that garbage, this
is the kind of descrepancy I was suggesting. There may be enough
"slop" in the timings of the relatively slow serial port to make
48MHz and 50MHz "close enough" for a few characters.
So, what is the correct number for your board? Do you know how to
identify an oscillator? They have a bit of a 'tin can' look to them.
Find the one closest to the CPU on the board, and see what number is
on it.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b d_info structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 20:28 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'; +Cc: 'Steven Blakeslee'
also in my embed_config(bd_t **bdp) function (in
arch/ppc/boot/simple/embed_config.c) I see
(and use, that is I have ported this from 2.4 to 2.6):
// timebase_period_ns = 1000000000 / bd->bi_tbfreq;
timebase_period_ns = 320; // value adjusted by hand
Could anyone knowledgeable make a guess why this was done (on 2.4) and would
it be OK to re-use on 2.6 ?
Thanks,
Alex
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, January 18, 2005 2:08 PM
To: 'John W. Linville'
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of
bd_info structure in the kernel booting code
My board is using:
bd->bi_intfreq = 50000000;
bd->bi_busfreq = 50000000;
While RPX-Lite is using
bd->bi_intfreq = 48000000;
bd->bi_busfreq = 48000000;
Is this what makes RPX-Lite work and my (MPC 880) not ?
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, January 18, 2005 1:53 PM
To: 'John W. Linville'
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: RE: Linux 2.6-10.rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
The "one, I am using" from my previous e-mail relates to 2.6.10-rc3
My processor is MPC880.
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, January 18, 2005 1:19 PM
To: 'John W. Linville'
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
>Aren't there still generic problems w/ 8xx and 2.6.x?
Allegedly - yes (with memory initialization) but ...
both Tom Rini and Steve Blakeslee were able to boot their
RPXLite Variant of 8xx on 2.6.10-rc3 (the one I am using)
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Tuesday, January 18, 2005 1:11 PM
To: Povolotsky, Alexander
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'
Subject: Re: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
On Tue, Jan 18, 2005 at 10:45:53AM -0500, Povolotsky, Alexander wrote:
> Forgot to mention - this board boots (and works) well with Linux 2.4.26
Aren't there still generic problems w/ 8xx and 2.6.x?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b d_in fo structure in the kernel booting code
From: Povolotsky, Alexander @ 2005-01-18 20:45 UTC (permalink / raw)
To: 'John W. Linville'
Cc: 'Steven Blakeslee',
'linuxppc-embedded@ozlabs.org'
On my board the oscillator is marked 50.000 and the 50000000 setting works
on my board with Linux 2.4 ...
but I meant to ask in my question: whether (may be) the current 8xx vs 2.6
kernel memory initialization problems
only showing themself at 50Mhz and not at 48Mhz (I am trying to find
explanation why 2.6 works on RPX-Lite -
per Tom and Steve).
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Tuesday, January 18, 2005 3:29 PM
To: Povolotsky, Alexander
Cc: 'Mark Chambers'; 'linuxppc-embedded@ozlabs.org'; 'Tom Rini'; 'Steven
Blakeslee'
Subject: Re: Linux 2.6.10-rc3 8xx: debugging (over-writing) content of b
d_in fo structure in the kernel booting code
On Tue, Jan 18, 2005 at 02:08:19PM -0500, Povolotsky, Alexander wrote:
> My board is using:
>
> bd->bi_intfreq = 50000000;
> bd->bi_busfreq = 50000000;
>
> While RPX-Lite is using
>
> bd->bi_intfreq = 48000000;
> bd->bi_busfreq = 48000000;
>
> Is this what makes RPX-Lite work and my (MPC 880) not ?
That, of course, depends on which value is correct for your
board... :-)
When I mentioned in one of our (possibly off-line) exchanges that
_slightly_ incorrect clock speeds might explain how you get a few good
characters from the serial port before you get all that garbage, this
is the kind of descrepancy I was suggesting. There may be enough
"slop" in the timings of the relatively slow serial port to make
48MHz and 50MHz "close enough" for a few characters.
So, what is the correct number for your board? Do you know how to
identify an oscillator? They have a bit of a 'tin can' look to them.
Find the one closest to the CPU on the board, and see what number is
on it.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-18 22:02 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050118200944.GN28724@smtp.west.cox.net>
>
> On Fri, Jan 14, 2005 at 08:51:44PM +0100, Joakim Tjernlund wrote:
>
> > BTW, there is a simpler fix to the TLB Miss problem.
> > In the TLB Miss handlers, just move the 2: label a few instr. upwards to
> > the same line as the "li r21, 0x00f0". That way you will force a
> > TLB error. You can do this for both Data and Instr. Miss handlers.
> > The code after where the 2: label used to be can be deleted.
>
> Like this? Only lightly tested on my rpxlite on 2.6:
Yes, that way you will load a zero pte, except for the bits that always must be ones
into the MMU and TLB error will follow.
You can also move beq 2f instr. 2 lines down and change it to beq- 2f to let branch
prediction do its thing.
Then all that is missing is my dcbX patch and support for 16K pages :)
Jocke
>
>
> ---
>
> linux-2.6-current-trini/arch/ppc/kernel/head_8xx.S | 22 +--------------------
> 1 files changed, 2 insertions(+), 20 deletions(-)
>
> diff -puN arch/ppc/kernel/head_8xx.S~ppc32-mpc8xx-itlbmiss-fix arch/ppc/kernel/head_8xx.S
> --- linux-2.6-current/arch/ppc/kernel/head_8xx.S~ppc32-mpc8xx-itlbmiss-fix 2005-01-18 11:55:34.000000000 -0700
> +++ linux-2.6-current-trini/arch/ppc/kernel/head_8xx.S 2005-01-18 11:57:11.000000000 -0700
> @@ -343,7 +343,7 @@ InstructionTLBMiss:
> * set. All other Linux PTE bits control the behavior
> * of the MMU.
> */
> - li r11, 0x00f0
> +2: li r11, 0x00f0
> rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
> DO_8xx_CPU6(0x2d80, r3)
> mtspr MI_RPN, r10 /* Update TLB entry */
> @@ -357,15 +357,6 @@ InstructionTLBMiss:
> #endif
> rfi
>
> -2: mfspr r10, M_TW /* Restore registers */
> - lwz r11, 0(r0)
> - mtcr r11
> - lwz r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> - lwz r3, 8(r0)
> -#endif
> - b InstructionAccess
> -
> . = 0x1200
> DataStoreTLBMiss:
> #ifdef CONFIG_8xx_CPU6
> @@ -419,7 +410,7 @@ DataStoreTLBMiss:
> * set. All other Linux PTE bits control the behavior
> * of the MMU.
> */
> - li r11, 0x00f0
> +2: li r11, 0x00f0
> rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
> DO_8xx_CPU6(0x3d80, r3)
> mtspr MD_RPN, r10 /* Update TLB entry */
> @@ -433,15 +424,6 @@ DataStoreTLBMiss:
> #endif
> rfi
>
> -2: mfspr r10, M_TW /* Restore registers */
> - lwz r11, 0(r0)
> - mtcr r11
> - lwz r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> - lwz r3, 8(r0)
> -#endif
> - b DataAccess
> -
> /* This is an instruction TLB error on the MPC8xx. This could be due
> * to many reasons, such as executing guarded memory or illegal instruction
> * addresses. There is nothing to do but handle a big time error fault.
> _
>
> --
> Tom Rini
> http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH 2/4] ppc32: platform_device conversion from OCP
From: Kumar Gala @ 2005-01-18 15:35 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, linuxppc-embedded
Infrastructure changes to MPC85xx sub-arch from OCP to platform_device:
* Described all devices available on current MPC85xx CPUs (mem & irq)
* Added cpu descriptions for the MPC8540, MPC8541, MPC8541, MPC8555,
MPC8555E, and MPC8560.
* Removed OCP usage from MPC85xx sub-arch
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/Kconfig 2005-01-17 22:31:44 -06:00
@@ -678,7 +678,7 @@
config CPM2
bool
- depends on 8260 || MPC8560
+ depends on 8260 || MPC8560 || MPC8555
default y
help
The CPM2 (Communications Processor Module) is a coprocessor on
diff -Nru a/arch/ppc/platforms/85xx/Kconfig b/arch/ppc/platforms/85xx/Kconfig
--- a/arch/ppc/platforms/85xx/Kconfig 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/Kconfig 2005-01-17 22:31:44 -06:00
@@ -62,11 +62,6 @@
depends on MPC8555_CDS
default y
-config FSL_OCP
- bool
- depends on 85xx
- default y
-
config PPC_GEN550
bool
depends on MPC8540 || SBC8560 || MPC8555
diff -Nru a/arch/ppc/platforms/85xx/Makefile b/arch/ppc/platforms/85xx/Makefile
--- a/arch/ppc/platforms/85xx/Makefile 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/Makefile 2005-01-17 22:31:44 -06:00
@@ -1,12 +1,9 @@
#
# Makefile for the PowerPC 85xx linux kernel.
#
+obj-$(CONFIG_85xx) += mpc85xx_sys.o mpc85xx_devices.o
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads_common.o mpc8540_ads.o
obj-$(CONFIG_MPC8555_CDS) += mpc85xx_cds_common.o
obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads_common.o mpc8560_ads.o
obj-$(CONFIG_SBC8560) += sbc85xx.o sbc8560.o
-
-obj-$(CONFIG_MPC8540) += mpc8540.o
-obj-$(CONFIG_MPC8555) += mpc8555.o
-obj-$(CONFIG_MPC8560) += mpc8560.o
diff -Nru a/arch/ppc/platforms/85xx/mpc8540.c b/arch/ppc/platforms/85xx/mpc8540.c
--- a/arch/ppc/platforms/85xx/mpc8540.c 2005-01-17 22:31:44 -06:00
+++ /dev/null Wed Dec 31 16:00:00 196900
@@ -1,97 +0,0 @@
-/*
- * arch/ppc/platforms/85xx/mpc8540.c
- *
- * MPC8540 I/O descriptions
- *
- * Maintainer: Kumar Gala <kumar.gala@freescale.com>
- *
- * Copyright 2004 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <asm/mpc85xx.h>
-#include <asm/ocp.h>
-
-/* These should be defined in platform code */
-extern struct ocp_gfar_data mpc85xx_tsec1_def;
-extern struct ocp_gfar_data mpc85xx_tsec2_def;
-extern struct ocp_gfar_data mpc85xx_fec_def;
-extern struct ocp_mpc_i2c_data mpc85xx_i2c1_def;
-
-/* We use offsets for paddr since we do not know at compile time
- * what CCSRBAR is, platform code should fix this up in
- * setup_arch
- *
- * Only the first IRQ is given even if a device has
- * multiple lines associated with ita
- */
-struct ocp_def core_ocp[] = {
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .paddr = MPC85xx_IIC1_OFFSET,
- .irq = MPC85xx_IRQ_IIC1,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_i2c1_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_16550,
- .index = 0,
- .paddr = MPC85xx_UART0_OFFSET,
- .irq = MPC85xx_IRQ_DUART,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_16550,
- .index = 1,
- .paddr = MPC85xx_UART1_OFFSET,
- .irq = MPC85xx_IRQ_DUART,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 0,
- .paddr = MPC85xx_ENET1_OFFSET,
- .irq = MPC85xx_IRQ_TSEC1_TX,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_tsec1_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 1,
- .paddr = MPC85xx_ENET2_OFFSET,
- .irq = MPC85xx_IRQ_TSEC2_TX,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_tsec2_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 2,
- .paddr = MPC85xx_ENET3_OFFSET,
- .irq = MPC85xx_IRQ_FEC,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_fec_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_DMA,
- .index = 0,
- .paddr = MPC85xx_DMA_OFFSET,
- .irq = MPC85xx_IRQ_DMA0,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_PERFMON,
- .index = 0,
- .paddr = MPC85xx_PERFMON_OFFSET,
- .irq = MPC85xx_IRQ_PERFMON,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_INVALID
- }
-};
diff -Nru a/arch/ppc/platforms/85xx/mpc8555.c b/arch/ppc/platforms/85xx/mpc8555.c
--- a/arch/ppc/platforms/85xx/mpc8555.c 2005-01-17 22:31:44 -06:00
+++ /dev/null Wed Dec 31 16:00:00 196900
@@ -1,95 +0,0 @@
-/*
- * arch/ppc/platform/85xx/mpc8555.c
- *
- * MPC8555 I/O descriptions
- *
- * Maintainer: Kumar Gala <kumar.gala@freescale.com>
- *
- * Copyright 2004 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <asm/mpc85xx.h>
-#include <asm/ocp.h>
-
-/* These should be defined in platform code */
-extern struct ocp_gfar_data mpc85xx_tsec1_def;
-extern struct ocp_gfar_data mpc85xx_tsec2_def;
-extern struct ocp_mpc_i2c_data mpc85xx_i2c1_def;
-
-/* We use offsets for paddr since we do not know at compile time
- * what CCSRBAR is, platform code should fix this up in
- * setup_arch
- *
- * Only the first IRQ is given even if a device has
- * multiple lines associated with ita
- */
-struct ocp_def core_ocp[] = {
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .paddr = MPC85xx_IIC1_OFFSET,
- .irq = MPC85xx_IRQ_IIC1,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_i2c1_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_16550,
- .index = 0,
- .paddr = MPC85xx_UART0_OFFSET,
- .irq = MPC85xx_IRQ_DUART,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_16550,
- .index = 1,
- .paddr = MPC85xx_UART1_OFFSET,
- .irq = MPC85xx_IRQ_DUART,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 0,
- .paddr = MPC85xx_ENET1_OFFSET,
- .irq = MPC85xx_IRQ_TSEC1_TX,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_tsec1_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 1,
- .paddr = MPC85xx_ENET2_OFFSET,
- .irq = MPC85xx_IRQ_TSEC2_TX,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_tsec2_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_DMA,
- .index = 0,
- .paddr = MPC85xx_DMA_OFFSET,
- .irq = MPC85xx_IRQ_DMA0,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_SEC2,
- .index = 0,
- .paddr = MPC85xx_SEC2_OFFSET,
- .irq = MPC85xx_IRQ_SEC2,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_PERFMON,
- .index = 0,
- .paddr = MPC85xx_PERFMON_OFFSET,
- .irq = MPC85xx_IRQ_PERFMON,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_INVALID
- }
-};
diff -Nru a/arch/ppc/platforms/85xx/mpc8560.c b/arch/ppc/platforms/85xx/mpc8560.c
--- a/arch/ppc/platforms/85xx/mpc8560.c 2005-01-17 22:31:44 -06:00
+++ /dev/null Wed Dec 31 16:00:00 196900
@@ -1,74 +0,0 @@
-/*
- * arch/ppc/platforms/85xx/mpc8560.c
- *
- * MPC8560 I/O descriptions
- *
- * Maintainer: Kumar Gala <kumar.gala@freescale.com>
- *
- * Copyright 2004 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <asm/mpc85xx.h>
-#include <asm/ocp.h>
-
-/* These should be defined in platform code */
-extern struct ocp_gfar_data mpc85xx_tsec1_def;
-extern struct ocp_gfar_data mpc85xx_tsec2_def;
-extern struct ocp_mpc_i2c_data mpc85xx_i2c1_def;
-
-/* We use offsets for paddr since we do not know at compile time
- * what CCSRBAR is, platform code should fix this up in
- * setup_arch
- *
- * Only the first IRQ is given even if a device has
- * multiple lines associated with ita
- */
-struct ocp_def core_ocp[] = {
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .paddr = MPC85xx_IIC1_OFFSET,
- .irq = MPC85xx_IRQ_IIC1,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_i2c1_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 0,
- .paddr = MPC85xx_ENET1_OFFSET,
- .irq = MPC85xx_IRQ_TSEC1_TX,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_tsec1_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_GFAR,
- .index = 1,
- .paddr = MPC85xx_ENET2_OFFSET,
- .irq = MPC85xx_IRQ_TSEC2_TX,
- .pm = OCP_CPM_NA,
- .additions = &mpc85xx_tsec2_def,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_DMA,
- .index = 0,
- .paddr = MPC85xx_DMA_OFFSET,
- .irq = MPC85xx_IRQ_DMA0,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_PERFMON,
- .index = 0,
- .paddr = MPC85xx_PERFMON_OFFSET,
- .irq = MPC85xx_IRQ_PERFMON,
- .pm = OCP_CPM_NA,
- },
- { .vendor = OCP_VENDOR_INVALID
- }
-};
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_devices.c b/arch/ppc/platforms/85xx/mpc85xx_devices.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/platforms/85xx/mpc85xx_devices.c 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,531 @@
+/*
+ * arch/ppc/platforms/85xx/mpc85xx_devices.c
+ *
+ * MPC85xx Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/fsl_devices.h>
+#include <asm/mpc85xx.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+/* We use offsets for IORESOURCE_MEM since we do not know at compile time
+ * what CCSRBAR is, will get fixed up by mach_mpc85xx_fixup
+ */
+
+static struct gianfar_platform_data mpc85xx_tsec1_pdata = {
+ .device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR,
+ .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+};
+
+static struct gianfar_platform_data mpc85xx_tsec2_pdata = {
+ .device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
+ FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
+ FSL_GIANFAR_DEV_HAS_MULTI_INTR,
+ .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+};
+
+static struct gianfar_platform_data mpc85xx_fec_pdata = {
+ .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+};
+
+static struct fsl_i2c_platform_data mpc85xx_fsl_i2c_pdata = {
+ .device_flags = FSL_I2C_DEV_SEPARATE_DFSRR,
+};
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC85xx_TSEC1] = {
+ .name = "fsl-gianfar",
+ .id = 1,
+ .dev.platform_data = &mpc85xx_tsec1_pdata,
+ .num_resources = 4,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET1_OFFSET,
+ .end = MPC85xx_ENET1_OFFSET +
+ MPC85xx_ENET1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "tx",
+ .start = MPC85xx_IRQ_TSEC1_TX,
+ .end = MPC85xx_IRQ_TSEC1_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "rx",
+ .start = MPC85xx_IRQ_TSEC1_RX,
+ .end = MPC85xx_IRQ_TSEC1_RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "error",
+ .start = MPC85xx_IRQ_TSEC1_ERROR,
+ .end = MPC85xx_IRQ_TSEC1_ERROR,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_TSEC2] = {
+ .name = "fsl-gianfar",
+ .id = 2,
+ .dev.platform_data = &mpc85xx_tsec2_pdata,
+ .num_resources = 4,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET2_OFFSET,
+ .end = MPC85xx_ENET2_OFFSET +
+ MPC85xx_ENET2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "tx",
+ .start = MPC85xx_IRQ_TSEC2_TX,
+ .end = MPC85xx_IRQ_TSEC2_TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "rx",
+ .start = MPC85xx_IRQ_TSEC2_RX,
+ .end = MPC85xx_IRQ_TSEC2_RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = "error",
+ .start = MPC85xx_IRQ_TSEC2_ERROR,
+ .end = MPC85xx_IRQ_TSEC2_ERROR,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_FEC] = {
+ .name = "fsl-gianfar",
+ .id = 3,
+ .dev.platform_data = &mpc85xx_fec_pdata,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_ENET3_OFFSET,
+ .end = MPC85xx_ENET3_OFFSET +
+ MPC85xx_ENET3_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+
+ },
+ {
+ .start = MPC85xx_IRQ_FEC,
+ .end = MPC85xx_IRQ_FEC,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_IIC1] = {
+ .name = "fsl-i2c",
+ .id = 1,
+ .dev.platform_data = &mpc85xx_fsl_i2c_pdata,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_IIC1_OFFSET,
+ .end = MPC85xx_IIC1_OFFSET +
+ MPC85xx_IIC1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_IIC1,
+ .end = MPC85xx_IRQ_IIC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA0] = {
+ .name = "fsl-dma",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA0_OFFSET,
+ .end = MPC85xx_DMA0_OFFSET +
+ MPC85xx_DMA0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA0,
+ .end = MPC85xx_IRQ_DMA0,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA1] = {
+ .name = "fsl-dma",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA1_OFFSET,
+ .end = MPC85xx_DMA1_OFFSET +
+ MPC85xx_DMA1_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA1,
+ .end = MPC85xx_IRQ_DMA1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA2] = {
+ .name = "fsl-dma",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA2_OFFSET,
+ .end = MPC85xx_DMA2_OFFSET +
+ MPC85xx_DMA2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA2,
+ .end = MPC85xx_IRQ_DMA2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_DMA3] = {
+ .name = "fsl-dma",
+ .id = 3,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_DMA3_OFFSET,
+ .end = MPC85xx_DMA3_OFFSET +
+ MPC85xx_DMA3_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_DMA3,
+ .end = MPC85xx_IRQ_DMA3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_PERFMON] = {
+ .name = "fsl-perfmon",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_PERFMON_OFFSET,
+ .end = MPC85xx_PERFMON_OFFSET +
+ MPC85xx_PERFMON_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_PERFMON,
+ .end = MPC85xx_IRQ_PERFMON,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_SEC2] = {
+ .name = "fsl-sec2",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC85xx_SEC2_OFFSET,
+ .end = MPC85xx_SEC2_OFFSET +
+ MPC85xx_SEC2_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC85xx_IRQ_SEC2,
+ .end = MPC85xx_IRQ_SEC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+#ifdef CONFIG_CPM2
+ [MPC85xx_CPM_FCC1] = {
+ .name = "fsl-cpm-fcc",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91300,
+ .end = 0x9131F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 0x91380,
+ .end = 0x9139F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_FCC1,
+ .end = SIU_INT_FCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_FCC2] = {
+ .name = "fsl-cpm-fcc",
+ .id = 2,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91320,
+ .end = 0x9133F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 0x913A0,
+ .end = 0x913CF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_FCC2,
+ .end = SIU_INT_FCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_FCC3] = {
+ .name = "fsl-cpm-fcc",
+ .id = 3,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91340,
+ .end = 0x9135F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 0x913D0,
+ .end = 0x913FF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_FCC3,
+ .end = SIU_INT_FCC3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_I2C] = {
+ .name = "fsl-cpm-i2c",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91860,
+ .end = 0x918BF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_I2C,
+ .end = SIU_INT_I2C,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SCC1] = {
+ .name = "fsl-cpm-scc",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91A00,
+ .end = 0x91A1F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC1,
+ .end = SIU_INT_SCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SCC2] = {
+ .name = "fsl-cpm-scc",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91A20,
+ .end = 0x91A3F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC2,
+ .end = SIU_INT_SCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SCC3] = {
+ .name = "fsl-cpm-scc",
+ .id = 3,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91A40,
+ .end = 0x91A5F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC3,
+ .end = SIU_INT_SCC3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SCC4] = {
+ .name = "fsl-cpm-scc",
+ .id = 4,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91A60,
+ .end = 0x91A7F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC4,
+ .end = SIU_INT_SCC4,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SPI] = {
+ .name = "fsl-cpm-spi",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91AA0,
+ .end = 0x91AFF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SPI,
+ .end = SIU_INT_SPI,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_MCC1] = {
+ .name = "fsl-cpm-mcc",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91B30,
+ .end = 0x91B3F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_MCC1,
+ .end = SIU_INT_MCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_MCC2] = {
+ .name = "fsl-cpm-mcc",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91B50,
+ .end = 0x91B5F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_MCC2,
+ .end = SIU_INT_MCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SMC1] = {
+ .name = "fsl-cpm-smc",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91A80,
+ .end = 0x91A8F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SMC1,
+ .end = SIU_INT_SMC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_SMC2] = {
+ .name = "fsl-cpm-smc",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91A90,
+ .end = 0x91A9F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SMC2,
+ .end = SIU_INT_SMC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC85xx_CPM_USB] = {
+ .name = "fsl-cpm-usb",
+ .id = 2,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x91B60,
+ .end = 0x91B7F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_USB,
+ .end = SIU_INT_USB,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+#endif /* CONFIG_CPM2 */
+};
+
+static int __init mach_mpc85xx_fixup(struct platform_device *pdev)
+{
+ ppc_sys_fixup_mem_resource(pdev, CCSRBAR);
+ return 0;
+}
+
+static int __init mach_mpc85xx_init(void)
+{
+ ppc_sys_device_fixup = mach_mpc85xx_fixup;
+ return 0;
+}
+
+postcore_initcall(mach_mpc85xx_init);
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_sys.c b/arch/ppc/platforms/85xx/mpc85xx_sys.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/platforms/85xx/mpc85xx_sys.c 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,118 @@
+/*
+ * arch/ppc/platforms/85xx/mpc85xx_sys.c
+ *
+ * MPC85xx System descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <asm/ppc_sys.h>
+
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ {
+ .ppc_sys_name = "MPC8540",
+ .mask = 0xFFFF0000,
+ .value = 0x80300000,
+ .num_devices = 9,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_FEC, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ MPC85xx_PERFMON,
+ },
+ },
+ {
+ .ppc_sys_name = "MPC8560",
+ .mask = 0xFFFF0000,
+ .value = 0x80700000,
+ .num_devices = 19,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ MPC85xx_PERFMON,
+ MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
+ MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3, MPC85xx_CPM_SCC4,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_MCC1, MPC85xx_CPM_MCC2,
+ },
+ },
+ {
+ .ppc_sys_name = "MPC8541",
+ .mask = 0xFFFF0000,
+ .value = 0x80720000,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ MPC85xx_PERFMON,
+ MPC85xx_CPM_SPI, MPC85xx_CPM_I2C,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
+ },
+ },
+ {
+ .ppc_sys_name = "MPC8541E",
+ .mask = 0xFFFF0000,
+ .value = 0x807A0000,
+ .num_devices = 13,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ MPC85xx_PERFMON, MPC85xx_SEC2,
+ MPC85xx_CPM_SPI, MPC85xx_CPM_I2C,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
+ },
+ },
+ {
+ .ppc_sys_name = "MPC8555",
+ .mask = 0xFFFF0000,
+ .value = 0x80710000,
+ .num_devices = 19,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ MPC85xx_PERFMON,
+ MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
+ MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
+ MPC85xx_CPM_USB,
+ },
+ },
+ {
+ .ppc_sys_name = "MPC8555E",
+ .mask = 0xFFFF0000,
+ .value = 0x80790000,
+ .num_devices = 20,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
+ MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
+ MPC85xx_PERFMON, MPC85xx_SEC2,
+ MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
+ MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
+ MPC85xx_CPM_USB,
+ },
+ },
+ { /* default match */
+ .ppc_sys_name = "",
+ .mask = 0x00000000,
+ .value = 0x00000000,
+ },
+};
diff -Nru a/arch/ppc/syslib/ppc85xx_common.c b/arch/ppc/syslib/ppc85xx_common.c
--- a/arch/ppc/syslib/ppc85xx_common.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/syslib/ppc85xx_common.c 2005-01-17 22:31:44 -06:00
@@ -20,7 +20,6 @@
#include <asm/mpc85xx.h>
#include <asm/mmu.h>
-#include <asm/ocp.h>
/* ************************************************************************ */
/* Return the value of CCSRBAR for the current board */
@@ -29,18 +28,6 @@
get_ccsrbar(void)
{
return BOARD_CCSRBAR;
-}
-
-/* ************************************************************************ */
-/* Update the 85xx OCP tables paddr field */
-void
-mpc85xx_update_paddr_ocp(struct ocp_device *dev, void *arg)
-{
- phys_addr_t ccsrbar;
- if (arg) {
- ccsrbar = *(phys_addr_t *)arg;
- dev->def->paddr += ccsrbar;
- }
}
EXPORT_SYMBOL(get_ccsrbar);
diff -Nru a/arch/ppc/syslib/ppc85xx_common.h b/arch/ppc/syslib/ppc85xx_common.h
--- a/arch/ppc/syslib/ppc85xx_common.h 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/syslib/ppc85xx_common.h 2005-01-17 22:31:44 -06:00
@@ -18,12 +18,8 @@
#include <linux/config.h>
#include <linux/init.h>
-#include <asm/ocp.h>
/* Provide access to ccsrbar for any modules, etc */
phys_addr_t get_ccsrbar(void);
-
-/* Update the 85xx OCP tables paddr field */
-void mpc85xx_update_paddr_ocp(struct ocp_device *dev, void *ccsrbar);
#endif /* __PPC_SYSLIB_PPC85XX_COMMON_H */
diff -Nru a/arch/ppc/syslib/ppc85xx_setup.c b/arch/ppc/syslib/ppc85xx_setup.c
--- a/arch/ppc/syslib/ppc85xx_setup.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/syslib/ppc85xx_setup.c 2005-01-17 22:31:44 -06:00
@@ -27,7 +27,6 @@
#include <asm/mpc85xx.h>
#include <asm/immap_85xx.h>
#include <asm/mmu.h>
-#include <asm/ocp.h>
#include <asm/kgdb.h>
#include <syslib/ppc85xx_setup.h>
diff -Nru a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
--- a/include/asm-ppc/irq.h 2005-01-17 22:31:44 -06:00
+++ b/include/asm-ppc/irq.h 2005-01-17 22:31:44 -06:00
@@ -199,6 +199,7 @@
#define SIU_INT_RISC ((uint)0x03+CPM_IRQ_OFFSET)
#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
+#define SIU_INT_USB ((uint)0x0b+CPM_IRQ_OFFSET)
#define SIU_INT_TIMER1 ((uint)0x0c+CPM_IRQ_OFFSET)
#define SIU_INT_TIMER2 ((uint)0x0d+CPM_IRQ_OFFSET)
#define SIU_INT_TIMER3 ((uint)0x0e+CPM_IRQ_OFFSET)
diff -Nru a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
--- a/include/asm-ppc/mpc85xx.h 2005-01-17 22:31:44 -06:00
+++ b/include/asm-ppc/mpc85xx.h 2005-01-17 22:31:44 -06:00
@@ -103,6 +103,14 @@
#define MPC85xx_CPM_SIZE (0x40000)
#define MPC85xx_DMA_OFFSET (0x21000)
#define MPC85xx_DMA_SIZE (0x01000)
+#define MPC85xx_DMA0_OFFSET (0x21100)
+#define MPC85xx_DMA0_SIZE (0x00080)
+#define MPC85xx_DMA1_OFFSET (0x21180)
+#define MPC85xx_DMA1_SIZE (0x00080)
+#define MPC85xx_DMA2_OFFSET (0x21200)
+#define MPC85xx_DMA2_SIZE (0x00080)
+#define MPC85xx_DMA3_OFFSET (0x21280)
+#define MPC85xx_DMA3_SIZE (0x00080)
#define MPC85xx_ENET1_OFFSET (0x24000)
#define MPC85xx_ENET1_SIZE (0x01000)
#define MPC85xx_ENET2_OFFSET (0x25000)
@@ -138,6 +146,34 @@
#else
#define CCSRBAR BOARD_CCSRBAR
#endif
+
+enum ppc_sys_devices {
+ MPC85xx_TSEC1,
+ MPC85xx_TSEC2,
+ MPC85xx_FEC,
+ MPC85xx_IIC1,
+ MPC85xx_DMA0,
+ MPC85xx_DMA1,
+ MPC85xx_DMA2,
+ MPC85xx_DMA3,
+ MPC85xx_DUART,
+ MPC85xx_PERFMON,
+ MPC85xx_SEC2,
+ MPC85xx_CPM_SPI,
+ MPC85xx_CPM_I2C,
+ MPC85xx_CPM_USB,
+ MPC85xx_CPM_SCC1,
+ MPC85xx_CPM_SCC2,
+ MPC85xx_CPM_SCC3,
+ MPC85xx_CPM_SCC4,
+ MPC85xx_CPM_FCC1,
+ MPC85xx_CPM_FCC2,
+ MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_MCC1,
+ MPC85xx_CPM_MCC2,
+ MPC85xx_CPM_SMC1,
+ MPC85xx_CPM_SMC2,
+};
#endif /* CONFIG_85xx */
#endif /* __ASM_MPC85xx_H__ */
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-19 0:30 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050118200944.GN28724@smtp.west.cox.net>
> On Fri, Jan 14, 2005 at 08:51:44PM +0100, Joakim Tjernlund wrote:
>
> > BTW, there is a simpler fix to the TLB Miss problem.
> > In the TLB Miss handlers, just move the 2: label a few instr. upwards to
> > the same line as the "li r21, 0x00f0". That way you will force a
> > TLB error. You can do this for both Data and Instr. Miss handlers.
> > The code after where the 2: label used to be can be deleted.
>
> Like this? Only lightly tested on my rpxlite on 2.6:
Something related I wonder about. Is it necessary to update the ACCESSED
ori r10, r10, _PAGE_ACCESSED
stw r10, 0(r11)
bit in the pte? 2 instr. and a cache line write will be saved in each TLB Miss handler
if this step can be omitted. Any MM gurus around?
Jocke
^ permalink raw reply
* Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls
From: Tolunay Orkun @ 2005-01-18 17:39 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <93780AB0-696D-11D9-81BE-003065F9B7DC@embeddededge.com>
Dan Malek wrote:
>
> On Jan 18, 2005, at 11:15 AM, Tom Rini wrote:
>
>> On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>
>
>>> There are 2 reasons to not use the ppc_md.get_rtc_time() et. al.
>>> interfaces:
>>> 1) They are called before the i2c driver is initialized and even loaded
>>> if its a module.
>
>
> There are three reasons. You don't want to use an I2c rtc clock at
> all in these functions because they get can get called from the
> clock interrupt to update the time in the rtc. If it does happen to work,
> it creates long latencies in the timer interrupt. If the i2c requires an
> interrupt, they system will crash or hang.
>
> A system using an I2C RTC should find some way to access the
> clock from application space as a standard I2C device and manage
> time/clock from the application, not from the kernel.
This is exactly what I've done for our PPC405GP based Linux port
(2.4.25). I've written a clone of hwclock utility using /dev/i2c0 to
access Dallas RTC chip with I2C interface. I setthe system clock from
RTC within /etc/rcS (Busybox). It is less than perfect as early logs
have the date wrong but it was the direction of least resistance.
Still, I think there should be a better standardized RTC interface to
help deal with I2C/SMBus based RTC chips.
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Andreas Schwab @ 2005-01-19 1:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds
In-Reply-To: <1106011958.4533.25.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Hi !
>
> This patch updates the PowerMac sleep support. The ability to sleep is now broken
> into 2 different flags, one, "may sleep" is set for all motherboards that we know
> how to put to sleep and wakeup. It gets turned into "can sleep" upon a call from
> the video driver indicating the ability to wakeup the video card. This doesn't
> deal with head-less machines, but this can be improved later. It also adds better
> cache flush code, which improves stability with cpufreq as well as sleep.
>
> This patch actually breaks sleep support until the video drivers for the affected
> machines have been updated. This will come as separate patches.
With all your patches applied I'm getting an oops during wakeup inside
pci_bus_read_config_word on my iBook/G3. Call trace: pci_set_master,
pci_device_resume, resume_device, dpm_resume, device_resume,
pmac_wakeup_devices, pmu_ioctl, sys_ioctl.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: Benjamin Herrenschmidt @ 2005-01-19 2:04 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds
In-Reply-To: <je7jmaurl0.fsf@sykes.suse.de>
On Wed, 2005-01-19 at 02:37 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Hi !
> >
> > This patch updates the PowerMac sleep support. The ability to sleep is now broken
> > into 2 different flags, one, "may sleep" is set for all motherboards that we know
> > how to put to sleep and wakeup. It gets turned into "can sleep" upon a call from
> > the video driver indicating the ability to wakeup the video card. This doesn't
> > deal with head-less machines, but this can be improved later. It also adds better
> > cache flush code, which improves stability with cpufreq as well as sleep.
> >
> > This patch actually breaks sleep support until the video drivers for the affected
> > machines have been updated. This will come as separate patches.
>
> With all your patches applied I'm getting an oops during wakeup inside
> pci_bus_read_config_word on my iBook/G3. Call trace: pci_set_master,
> pci_device_resume, resume_device, dpm_resume, device_resume,
> pmac_wakeup_devices, pmu_ioctl, sys_ioctl.
It would be useful to get some more infos, what is the actual oops text
(what error), and if you could add some printk's to figure out what is
the culprit PCI device, that would be useful as well...
Ben.
^ permalink raw reply
* Re: [PATCH] raid6: altivec support
From: Benjamin Herrenschmidt @ 2005-01-19 4:11 UTC (permalink / raw)
To: David Woodhouse
Cc: linuxppc-dev list, Linus Torvalds, H. Peter Anvin,
Linux Kernel list
In-Reply-To: <1105956993.26551.327.camel@hades.cambridge.redhat.com>
On Mon, 2005-01-17 at 10:16 +0000, David Woodhouse wrote:
> On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering wrote:
> >
> > > ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, hpa@zytor.com
> > >
> > > [PATCH] raid6: altivec support
> > >
> > > This patch adds Altivec support for RAID-6, if appropriately configured on
> > > the ppc or ppc64 architectures. Note that it changes the compile flags for
> > > ppc64 in order to handle -maltivec correctly; this change was vetted on the
> > > ppc64 mailing list and OK'd by paulus.
> >
> > This fails to compile on ppc, enable_kernel_altivec() is an exported but
> > undeclared function. cpu_features is also missing.
> >
I sent Linus & Andrew a patch fixing the enable_kernel_altivec() thing
yesterday. cpu_features isn't missing, it's defined differently.
> > drivers/md/raid6altivec1.c: In function `raid6_altivec1_gen_syndrome':
> > drivers/md/raid6altivec1.c:99: warning: implicit declaration of function `enable_kernel_altivec'
> > drivers/md/raid6altivec1.c: In function `raid6_have_altivec':
> > drivers/md/raid6altivec1.c:111: error: request for member `cpu_features' in something not a structure or union
> > drivers/md/raid6altivec2.c: In function `raid6_altivec2_gen_syndrome':
> > drivers/md/raid6altivec2.c:110: warning: implicit declaration of function `enable_kernel_altivec'
>
> This makes it compile on PPC, but highlights the difference between
> 'cur_cpu_spec' on ppc32 and ppc64. Why is 'cur_cpu_spec' an array on
> ppc32? Isn't 'cur' supposed to imply 'current'?
It's history. When I wrote that on ppc in the first place, I decided to
leave room for having slightly different CPUs so I defined it as an
array of NR_CPUs.
When we ported this to ppc64, we figured out we never actually used that
"feature", and that the way the dynamic patching works with CPU features
makes it mandatory to have identical feature sets anyway.
We should probably "backport" that simplification to ppc32...
Ben.
^ permalink raw reply
* How to initialize the extended ROM/Flash interface of MPC8245?
From: chao yu @ 2005-01-19 5:57 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
Hi,all
I have a CPLD connected to the RCS3 of MPC 8245 processor.
Does the initialization of MPC8245's extended rom interface follow the two steps below?
1. Set the Bit 21 of MCCR registers with 1 to enable the extended rom/falsh interface?
2. Set the ERCR2 register(0xD4) and ERCR4 register(0xDC).
Any extra steps must be go? Thx.
Regards,
Yu.Chao
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: Type: text/html, Size: 778 bytes --]
^ permalink raw reply
* Re: [linux-usb-devel] USB host on Freescale MPC880
From: Pantelis Antoniou @ 2005-01-19 6:53 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-embedded, Dayton, Dean, linux-usb-devel
In-Reply-To: <41ED478A.6020303@europlex.ie>
Bryan O'Donoghue wrote:
> Dayton, Dean wrote:
>
>> I need to provide a USB host interface on a propietary board using a
>> Freescale (Motorola) MPC880. The MPC880 has a USB implemented in the
>> CPM, but I haven't found any Linux support for it. Can anyone point me
>> to existing drivers? Does anyone know of any problems that would/should
>> prevent me from using the MPC880's USB interface?
>>
>> Thanks
>
>
> Greetings Dean *list*.
>
> There are some propiatery drivers... but... it's an oxymoron, to pay
> licensing fees for Linux... I'd sooner eat nails then use the propiatery
> offerings, to be quite honest, I'd have to quit my job before being
> associated with such a thing.
>
> Right now the Freescale 870-885 has minimal support in Linux, but, I do
> have some patches for a 2.4.x which map out this family of chip's memory
> map as per the specification and I have a very primitive USB loopback
> tester working for this architecture. Said patches are not really ready
> for public consumption, not to mention only being usable on a 2.4.
>
> A propiatery board being developed by my company wants USB host
> support... and I'm fairly confident I can do that... and hopefully I can
> get some serious development work done on this over the next three to
> four months and release a patch/(s) for public consumption.
>
> I estimate it will take another four months to get USB host working
> properly and perhaps a month to get USB-device support working properly
> (touch wood on both counts), I'm not sure about the required development
> time on that to be honest... but, if I don't get it finished in time for
> our propiatery board, the powers that be in my company will use a
> propiatery Linux offering... and I'll have to resign on the grounds of
> being an Open Source Evangalist ! I need to eat/pay rent... so I really
> need to get this board + USB working. *grin*.
>
> Are you guys planning on devoting any development effort to hardware
> support of this freescale part ? If so, would it be prudent to
> co-ordinate the development effort ?
>
> Bryan
>
I have a fairly hacked over version of the original USB host driver that
works for 87x/88x.
Are you interested?
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH] raid6: altivec support
From: David Woodhouse @ 2005-01-19 7:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Linus Torvalds, H. Peter Anvin,
Linux Kernel list
In-Reply-To: <1106107876.4534.163.camel@gaston>
On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> We should probably "backport" that simplification to ppc32...
Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
like mips/parisc/s390. Or would that get vetoed on the basis that we
don't have all that horrid non-OF platform support in ppc64 yet, and
we're still kidding ourselves that all those embedded vendors will
either not notice ppc64 or will use OF?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] raid6: altivec support
From: Paul Mackerras @ 2005-01-19 9:41 UTC (permalink / raw)
To: David Woodhouse
Cc: Linux Kernel list, linuxppc-dev list, Linus Torvalds,
H. Peter Anvin
In-Reply-To: <1106120622.10851.42.camel@baythorne.infradead.org>
David Woodhouse writes:
> Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> like mips/parisc/s390. Or would that get vetoed on the basis that we
> don't have all that horrid non-OF platform support in ppc64 yet, and
> we're still kidding ourselves that all those embedded vendors will
> either not notice ppc64 or will use OF?
I'm going to insist that every new ppc64 platform supplies a device
tree. They don't have to have OF but they do need to have the booter
or wrapper supply a flattened device tree (which is just a few kB of
binary data as far as the booter/wrapper is concerned). It doesn't
have to include all the
As for merging ppc32 and ppc64, I think it would end up an awful ifdef
mess, but if you can see a clean way to do it, send me a patch. :)
Paul.
^ permalink raw reply
* Re: [linux-usb-devel] USB host on Freescale MPC880
From: Bryan O'Donoghue @ 2005-01-19 10:12 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded, Dayton, Dean, linux-usb-devel
In-Reply-To: <41EE03FF.3040609@intracom.gr>
> I have a fairly hacked over version of the original USB host driver that
> works for 87x/88x.
>
> Are you interested?
>
> Regards
>
> Pantelis
Hmm... do you have handy sources available somewhere ?
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. Imetrex Technologies Ltd shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Imetrex Technologies Ltd does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. This communication does not create or modify any contract, and unless otherwise stated, is not intended to be contractually binding. Views or opinions expressed in this e-mail message are those of the author only.
^ permalink raw reply
* nvram driver not possible as a module
From: Joerg Dorchain @ 2005-01-19 10:14 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
Hi,
KConfig says CONFIG_NVRAM is possible as a module. Loading the module
fails because of an unknown symbol __alloc_bootmem. __alloc_bootmem is
marked __init. The obvious workaround is to compile the driver not as a
module, but how can this get really fixed?
Bye,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Dump Page Cache state for out of memory
From: Steffen Rumler @ 2005-01-19 10:45 UTC (permalink / raw)
To: linuxppc
Hi,
I'm using the following code in order to
dump the state concerning the Page Cache
related to filesystem I/O, from out_of_memory().
Steffen
--
oo_kill.c:
...
typedef struct {
unsigned long locked; /* number locked pages */
unsigned long clean; /* number clean pages */
unsigned long dirty; /* number dirty pages */
struct super_block *sb; /* related superblock */
} dump_page_cache_entry_t;
static dump_page_cache_entry_t dump_page_cache_arr[16];
static dump_page_cache_entry_t *
get_dump_cache_entry (struct super_block *sb)
{
int i;
for(i=0; i < 16; i++){
if(dump_page_cache_arr[i].sb == sb) return &dump_page_cache_arr[i];
if(dump_page_cache_arr[i].sb == NULL){
dump_page_cache_arr[i].sb = sb;
return &dump_page_cache_arr[i];
}
}
return &dump_page_cache_arr[15];
}
/* dump page cache state
*/
static void dump_page_cache (void)
{
int i;
struct page **p = page_hash_table;
struct page *q;
unsigned long flags;
unsigned long total = 0;
dump_page_cache_entry_t *ep;
struct super_block *sb;
for(i=0; i<PAGE_HASH_SIZE; i++){
for(q=*p;q;q=q->next_hash){
total++;
if(q->mapping && q->mapping->host && (sb=q->mapping->host->i_sb)){
flags = q->flags;
ep = get_dump_cache_entry(sb);
if((flags & (1 << PG_locked))){
ep->locked++;
}else{
if((flags & (1 << PG_dirty))){
if(flags & (1 << PG_uptodate)){
ep->dirty++;
}
}else{
ep->clean++;
}
}
}
}
p++;
}
printk(KERN_EMERG "%s (%d) %s(): Page Cache Status:\n", __FILE__, __LINE__, __func__);
for(i=0; i<16; i++){
dump_page_cache_entry_t *ce = &dump_page_cache_arr[i];
if(ce->sb){
printk(KERN_EMERG "%14s clean: %-10d locked: %-10d dirty: %d\n",
ce->sb->s_type ? ce->sb->s_type->name : "???",
ce->clean, ce->locked, ce->dirty);
}else{
break;
}
}
printk("%14s %d\n", "total", total);
}
...
void out_of_memory(void)
{
...
dump_page_cache();
...
}
^ permalink raw reply
* consistent_alloc() on PPC
From: Sachin P @ 2005-01-19 11:53 UTC (permalink / raw)
To: Linuxppc-dev
Hi ,
I am facing some problems porting my drivers to the PPC platform . Am
currently using consistent_alloc() and consistent_free() to
allocate/free (non-cached) DMA ble memory.
Is there any function/patch/macro, equivalent to
phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?
Regards
sachin
^ permalink raw reply
* consistent_alloc() on PPC
From: Sachin P @ 2005-01-19 11:53 UTC (permalink / raw)
To: Linuxppc-embedded
Hi ,
I am facing some problems porting my drivers to the PPC platform . Am
currently using consistent_alloc() and consistent_free() to
allocate/free (non-cached) DMA ble memory.
Is there any function/patch/macro, equivalent to
phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?
Regards
sachin
^ permalink raw reply
* FW: cpm_spi.c under kernel 2.6
From: Christian-Hoffmann @ 2005-01-19 11:47 UTC (permalink / raw)
To: linuxppc-embedded
> -----Original Message-----
> From: Hoffmann Christian Com ESY HD 652
> Sent: Dienstag, 18. Januar 2005 11:55
> To: 'linuxppc-dev@ozlabs.org'
> Subject: cpm_spi.c under kernel 2.6
>
> hi,
>
> has anybody already ported the spi driver available in kernel 2.4.24
> (arch/ppc/8260_io/cpm_spi.c) to kernel 2.6 (2.6.8.1) ?
> if so, where can i get it ?
>
> regards
>
> christian
^ permalink raw reply
* 8250 FCC in half-duplex mode transmit timed out
From: Wojciech Kromer @ 2005-01-19 13:11 UTC (permalink / raw)
To: linuxppc-embedded
hello again,
after few month of silence, i found this group here :)
thx for getting it back to live
i have new problem with 8250 FCC in ethernet mode,
it works fine in FDX, but after some time of heavy transmit all BD-s
become busy
the only way to continue is to reset FCC, but ituation repeats after
10-30 seconds
any sollution?
i've tried out CPM11,CPM112 and CPM119 microcode pathes from freescale,
no success with this stuff
by the way: does anyone know how to apply muiltiple patches at same time?
^ permalink raw reply
* Re: [PATCH] ppc32: pmac sleep support update
From: David Woodhouse @ 2005-01-19 13:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1106011958.4533.25.camel@gaston>
On Tue, 2005-01-18 at 12:32 +1100, Benjamin Herrenschmidt wrote:
> This patch updates the PowerMac sleep support. The ability to sleep is now broken
> into 2 different flags, one, "may sleep" is set for all motherboards that we know
> how to put to sleep and wakeup. It gets turned into "can sleep" upon a call from
> the video driver indicating the ability to wakeup the video card.
Why do it like this? Drivers already have the ability to veto sleep
requests, surely?
--
dwmw2
^ 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