* [PATCH] WDT Driver for Book-E [2/2] Device driver part.
From: Takeharu KATO @ 2005-03-09 4:57 UTC (permalink / raw)
To: ppcembed, mporter, kumar.gala, jwboyer
Matt,Kurmar and Josh:
I post the device driver part with this mail.
Please apply.
Regards,
Signed-off-by: Takeharu KATO <kato.takeharu@jp.fujitsu.com>
--- linux-2.6.11/drivers/char/watchdog/Kconfig 2005-03-09 12:56:45.428165328 +0900
+++ linux-2.6.11-wdt/drivers/char/watchdog/Kconfig 2005-03-09 13:07:53.668577344 +0900
@@ -346,6 +346,13 @@ config 8xx_WDT
tristate "MPC8xx Watchdog Timer"
depends on WATCHDOG && 8xx
+config BOOKE_WDT
+ bool "Book E(PowerPC 4xx/e500) Watchdog Timer"
+ depends on WATCHDOG && ( 4xx || E500 )
+ ---help---
+ This is the driver for the watchdog timers on
+ PowerPC 4xx and PowerPC e500.
+
# MIPS Architecture
config INDYDOG
--- linux-2.6.11/drivers/char/watchdog/Makefile 2005-03-09 12:57:07.855755816 +0900
+++ linux-2.6.11-wdt/drivers/char/watchdog/Makefile 2005-03-09 13:07:53.681575368 +0900
@@ -39,3 +39,4 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.
obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
+obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
--- linux-2.6.11/drivers/char/watchdog/booke_wdt.c 1970-01-01 09:00:00.000000000 +0900
+++ linux-2.6.11-wdt/drivers/char/watchdog/booke_wdt.c 2005-03-09 13:07:53.684574912 +0900
@@ -0,0 +1,628 @@
+/*
+ * Copyright (c) 2005 Fujitsu Limited
+ *
+ * Module name: booke_wdt.c
+ * Author: Takeharu KATO<kato.takeharu@jp.fujitsu.com>
+ *
+ * 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.
+ *
+ * Neither Takeharu KATO nor Fujitsu Ltd. admit liability nor provide
+ * warranty for any of this software.
+ *
+ * Description:
+ * Watchdog driver for PowerPC Book E (PowerPC 4xx series processors and
+ * PowerPC e500 series processors).
+ * Derived from drivers/char/watchdog/wdt.c by Alan cox
+ * and drivers/char/watchdog/ppc405_wdt.c by Armin Kuster.
+ * PPC4xx WDT operation is driverd from Appendix of
+ * PowerPC Embedded Processors Application Note
+ * ``PowerPC 40x Watch Dog Timer'' published from IBM.
+ * This driver is written according to ``PowerPC e500 Core Complex
+ * Reference Manual'' for e500 part.
+ */
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/miscdevice.h>
+#include <linux/watchdog.h>
+#include <linux/fs.h>
+#include <linux/reboot.h>
+#include <linux/init.h>
+#include <linux/capability.h>
+#include <linux/string.h>
+#include <linux/ptrace.h>
+#include <asm/reg.h>
+#include <asm/uaccess.h>
+#include <asm/system.h>
+#include "booke_wdt.h"
+
+/* micro seconds per one milli-second(used to calculatewatchdog
+ * counter to be set). */
+#define US_PER_MS 1000
+/* Calculate watchdog count */
+#define calculate_wdt_count(t) ((((unsigned long)(t))*HZ)/1000)
+
+int wdt_enable=0; /* WDT start on boot */
+int wdt_period=WDT_TIMO; /* Time out in ms */
+
+#ifdef CONFIG_WATCHDOG_NOWAYOUT
+static int nowayout = 1;
+#else
+static int nowayout = 0;
+#endif
+
+/*
+ * Global variables
+ */
+static int wdt_count = 0; /* WDT intrrupt counter to be reloaded */
+static volatile int wdt_heartbeat_count = 0; /* WDT intrrupt counter(compatible mode)*/
+static unsigned long driver_state; /* Driver status (see: booke_wdt.h) */
+/*
+ * Identifier for this watchdog
+ */
+static struct watchdog_info ident = {
+ .options=WDIOF_SETTIMEOUT|WDIOF_KEEPALIVEPING|WDIOF_MAGICCLOSE,
+ .firmware_version = 0, /* This is filled with PVR in initialization. */
+ .identity = "Book E(PPC 4xx/e500) WDT",
+};
+
+/*
+ * PowerPC Linux common exception handler
+ */
+extern void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr);
+/* Panic notifier */
+extern struct notifier_block *panic_notifier_list;
+/*
+ * Watchdog operations on PPC4xx/e500 MPU
+ */
+/**
+ * __booke_wdt_setup_val
+ * Enable Watchdog, sets up passed in values for TCR[WP],
+ * TCR[WRC]
+ *
+ * @period: Input Watchdog Period - TCR[WP]
+ * 0...2^17(PPC405) or 2^21(PPC440/e500) clocks
+ * 1...2^21(PPC405) or 2^25(PPC440/e500) clocks
+ * 2...2^25(PPC405) or 2^29(PPC440/e500) clocks
+ * 3...2^25(PPC405) or 2^29(PPC440/e500) clocks
+ * @reset: Watchdog reset control - TCR[WRC]
+ * 0 = No reset
+ * 1 = PPC Core reset only
+ * 2 = PPC Chip reset
+ * 3 = System reset
+ * Note: The meaning of period number is differ PPC405 from PPC440.
+ * Current version assume that this function called with
+ * WRC_NONE as reset, if someone who want to remove this
+ * constraint, please note that when we disable WDT, we should
+ * set WRC with WRC_NONE and s/he should also modify
+ * disable/enable_wdt function.
+ *
+ */
+static __inline__ void
+__booke_wdt_setup_val(int period,int reset)
+{
+ unsigned long val;
+
+ /* Set up TCR */
+ val=wdt_calculate_tcr(period,reset)| mfspr(SPRN_TCR);
+ /* Disable WDT */
+ val &= ~(TCR_WIE);
+
+ mtspr(SPRN_TCR,val);
+}
+/**
+ * __booke_wdt_enable
+ * Enable Watchdog
+ */
+static __inline__ void
+__booke_wdt_enable(void)
+{
+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)|TCR_WIE));
+}
+/**
+ * __booke_wdt_disable
+ * Disable Watchdog
+ */
+static __inline__ void
+__booke_wdt_disable(void)
+{
+ mtspr(SPRN_TCR,(mfspr(SPRN_TCR)&(~(TCR_WIE))));
+}
+/**
+ * __booke_wdt_is_enabled
+ * Check whether Watchdog is enabled.
+ */
+static __inline__ int
+__booke_wdt_is_enabled(void)
+{
+ return (mfspr(SPRN_TCR) & TCR_WIE);
+}
+/**
+ * __booke_wdt_clear_init_stat
+ * Clear interrupt status of watchdog to ping it.
+ */
+static __inline__ void
+__booke_wdt_clear_int_stat(void)
+{
+ mtspr(SPRN_TSR, (TSR_ENW|TSR_WIS));
+}
+/**
+ * __booke_wdt_set_timeout:
+ * @t: the new time out value that needs to be set.
+ *
+ * Set a new time out value for the watchdog device.
+ *
+ */
+static __inline__ void
+__booke_wdt_set_timeout(int t)
+{
+ wdt_count=calculate_wdt_count(t);
+ return;
+}
+
+/*
+ * Driver specific functions
+ */
+
+/**
+ * booke_wdt_setup_options
+ * @cmd_line : a pointer to kernel command line.
+ *
+ */
+void
+booke_wdt_setup_options(char *cmd_line)
+{
+/*
+ * Look for wdt= option on command line
+ */
+ if (strstr(cmd_line, "wdt=")) {
+ int valid_wdt = 0;
+ char *p, *q;
+
+ for (q = cmd_line; (p = strstr(q, "wdt=")) != 0;) {
+ q = p + 4;
+ if (p > cmd_line && p[-1] != ' ')
+ continue;
+ wdt_period = simple_strtoul(q, &q, 0);
+ valid_wdt = 1;
+ ++q;
+ }
+ wdt_enable = valid_wdt;
+ }
+ return;
+}
+/**
+ * booke_wdt_heartbeat:
+ * Ping routine called from kernel.
+ */
+void
+booke_wdt_heartbeat(void)
+{
+ /* Disable watchdog */
+ __booke_wdt_disable();
+
+ /* Write a watchdog value */
+ __booke_wdt_clear_int_stat();
+
+ if (!wdt_enable)
+ goto out;
+
+ if (wdt_heartbeat_count > 0)
+ wdt_heartbeat_count--;
+ else
+ panic(booke_mkmsg("Initiating system reboot.\n"));
+
+ /* Enable watchdog */
+ __booke_wdt_enable();
+ out:
+ /* Reset count */
+ ppc_md.heartbeat_count = 0;
+}
+/**
+ * booke_wdt_exception:
+ * WatchDog Exception handler for PPC4xx/e500.
+ * @regs : A registers information.
+ */
+void
+booke_wdt_exception(struct pt_regs *regs)
+{
+
+ wdt_enable=0;
+ __booke_wdt_disable();
+ printk("WDT Exception at PC: %lx, MSR: %lx, vector=%lx %s\n",
+ regs->nip, regs->msr, regs->trap, print_tainted());
+ panic(booke_mkmsg("Initiating system reboot.\n"));
+}
+/*
+ * Driver Logic functions
+ */
+static __inline__ int
+booke_wdt_is_enabled(void)
+{
+ return __booke_wdt_is_enabled();
+}
+/**
+ * booke_wdt_start:
+ *
+ * Start the watchdog driver.
+ */
+static __inline__ int
+booke_wdt_start(void)
+{
+
+ __booke_wdt_enable();
+ return 0;
+}
+
+/**
+ * booke_wdt_stop:
+ *
+ * Stop the watchdog driver.
+ */
+static __inline__ int
+booke_wdt_stop (void)
+{
+
+ __booke_wdt_disable();
+ return 0;
+}
+/**
+ * booke_wdt_ping:
+ *
+ * Reload counter one with the watchdog heartbeat. We don't bother reloading
+ * the cascade counter.
+ */
+static __inline__ int
+booke_wdt_ping(void)
+{
+
+ /* Disable watchdog */
+ __booke_wdt_disable();
+ /* Write a watchdog value */
+ __booke_wdt_clear_int_stat();
+ /* Reset count */
+ wdt_heartbeat_count=wdt_count;
+ /* Enable watchdog */
+ __booke_wdt_enable();
+
+ return 0;
+}
+/**
+ * booke_wdt_set_timeout:
+ * @t: the new timeout value that needs to be set.
+ *
+ * Set a new time out value for the watchdog device.
+ * If the heartbeat value is incorrect we keep the old value
+ * and return -EINVAL. If successfull we return 0.
+ */
+static __inline__ int
+booke_wdt_set_timeout(int t)
+{
+
+ if ((t < WDT_HEARTBEAT_MIN) || (t > WDT_HEARTBEAT_MAX))
+ return -EINVAL;
+
+ wdt_period = t;
+ __booke_wdt_set_timeout(t);
+ wdt_heartbeat_count=wdt_count;
+ booke_wdt_dbg("The WDT counter set %d.\n",wdt_count);
+
+ return 0;
+}
+
+/**
+ * booke_wdt_get_status:
+ * @status: the new status.
+ *
+ * Return the enable/disable card status.
+ */
+static __inline__ int
+booke_wdt_get_status(int *status)
+{
+
+ if (wdt_enable)
+ *status = WDIOS_ENABLECARD;
+ else
+ *status = WDIOS_DISABLECARD;
+
+ return 0;
+}
+/*
+ * Kernel Interfaces
+ */
+/**
+ * booke_wdt_init_device:
+ *
+ * Initilize PowerPC 4xx/e500 family Watch Dog facility.
+ */
+static void
+booke_wdt_init_device(void)
+{
+
+ /* Hardware WDT provided by the processor.
+ * So, we set firmware version as processor version number.
+ */
+ ident.firmware_version=mfspr(PVR);
+ __booke_wdt_setup_val(WDT_WP,WRC_NONE);
+}
+/**
+ * booke_wdt_write:
+ * @file: file handle to the watchdog
+ * @buf: buffer to write (unused as data does not matter here
+ * @count: count of bytes
+ * @ppos: pointer to the position to write. No seeks allowed
+ *
+ * A write to a watchdog device is defined as a keepalive signal. Any
+ * write of data will do, as we we don't define content meaning expept
+ * 'V' character. It is performed as a sign to set stop-on-close mode.
+ */
+
+static ssize_t
+booke_wdt_write(struct file *file, const char *buf, size_t count, loff_t *ppos)
+{
+ size_t i;
+
+ if (!nowayout) {
+ /* In case it was set long ago */
+ clear_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+
+ for (i = 0; i < count; i++) {
+ char c;
+
+ if (get_user(c, buf + i))
+ return -EFAULT;
+
+ if (c == 'V') {
+ set_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+ }
+ }
+ }
+ booke_wdt_ping();
+
+ return count;
+}
+
+/**
+ * booke_wdt_ioctl:
+ * @inode: inode of the device
+ * @file: file handle to the device
+ * @cmd: watchdog command
+ * @arg: argument pointer
+ *
+ */
+static int
+booke_wdt_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ int new_timeout;
+ int status;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM; /* It may be too strict manner. */
+ switch(cmd)
+ {
+ default:
+ return -ENOIOCTLCMD;
+ case WDIOC_GETSUPPORT:
+ if (copy_to_user((struct watchdog_info *)arg, &ident, sizeof(struct watchdog_info)))
+ return -EFAULT;
+ else
+ break;
+ case WDIOC_GETSTATUS:
+ booke_wdt_get_status(&status);
+ return put_user(status,(int *)arg);
+ case WDIOC_KEEPALIVE:
+ booke_wdt_ping();
+ break;
+ case WDIOC_SETTIMEOUT:
+ if (get_user(new_timeout, (int *)arg))
+ return -EFAULT;
+ if (booke_wdt_set_timeout(new_timeout))
+ return -EINVAL;
+ booke_wdt_ping();
+ break;
+ case WDIOC_GETTIMEOUT:
+ return put_user(wdt_period, (int *)arg);
+ case WDIOC_SETOPTIONS:
+ if (get_user(status, (int *)arg))
+ return -EFAULT;
+ /* Return -EINVAL when the driver can not figure out
+ * what it should do. Unknown cases are just ignored.
+ */
+ if ( (status & (WDIOS_DISABLECARD|WDIOS_ENABLECARD))
+ == (WDIOS_DISABLECARD|WDIOS_ENABLECARD) )
+ return -EINVAL;
+ if (status & WDIOS_DISABLECARD) {
+ wdt_enable = 0;
+ booke_wdt_stop();
+ booke_wdt_info("Watchdog timer is disabled\n");
+ }
+ if (status & WDIOS_ENABLECARD) {
+ wdt_enable = 1;
+ booke_wdt_start();
+ booke_wdt_info("Watchdog timer is enabled\n");
+ }
+ break;
+ }
+ return 0;
+}
+/**
+ * booke_wdt_open:
+ * @inode: inode of device
+ * @file: file handle to device
+ *
+ * The watchdog device has been opened. The watchdog device is single
+ * open and start the WDT timer.
+ */
+static int
+booke_wdt_open(struct inode *inode, struct file *file)
+{
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ if (test_and_set_bit(WDT_STATE_OPEN, &driver_state))
+ return -EBUSY;
+ /*
+ * Activate
+ */
+ booke_wdt_start();
+ wdt_enable=1;
+
+ if (nowayout)
+ set_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state);
+
+ return 0;
+}
+
+/**
+ * booke_wdt_release:
+ * @inode: inode to board
+ * @file: file handle to board
+ *
+ */
+static int
+booke_wdt_release(struct inode *inode, struct file *file)
+{
+ if (test_bit(WDT_STATE_STOP_ON_CLOSE, &driver_state)) {
+ booke_wdt_info("WDT device is stopped.\n");
+ booke_wdt_stop();
+ wdt_enable=0;
+ } else {
+ if ( (booke_wdt_is_enabled()) && (!nowayout) ) {
+ booke_wdt_info("WDT device may be closed unexpectedly. WDT will not stop!\n");
+ booke_wdt_ping();
+ }
+ }
+ clear_bit(WDT_STATE_OPEN, &driver_state);
+
+ return 0;
+}
+/**
+ * notify_sys:
+ * @this: our notifier block
+ * @code: the event being reported
+ * @unused: unused
+ * Note: This function assume that the panic notifier is called with CODE=0
+ * (see panic function in kernel/panic.c).
+ */
+static int
+booke_wdt_notify_sys(struct notifier_block *this, unsigned long code,
+ void *unused)
+{
+
+ if (code != SYS_POWER_OFF) /* Turn the card off */
+ booke_wdt_stop();
+
+ return NOTIFY_DONE;
+}
+
+static struct file_operations booke_wdt_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .write = booke_wdt_write,
+ .ioctl = booke_wdt_ioctl,
+ .open = booke_wdt_open,
+ .release = booke_wdt_release,
+};
+
+static struct miscdevice booke_wdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &booke_wdt_fops,
+};
+
+/*
+ * The WDT card needs to know about shutdowns in order to
+ * turn WDT off.
+ */
+
+static struct notifier_block booke_wdt_notifier = {
+ .notifier_call = booke_wdt_notify_sys,
+};
+
+/**
+ * cleanup_module:
+ *
+ * If your watchdog is set to continue ticking on close and you unload
+ * it, well it keeps ticking. You just have to load a new
+ * module in 60 seconds or reboot.
+ * This behavior(more over the comments as above) is borrowed from
+ * Alan cox's driver.
+ */
+
+static void __exit
+booke_wdt_exit(void)
+{
+ misc_deregister(&booke_wdt_miscdev);
+ unregister_reboot_notifier(&booke_wdt_notifier);
+ notifier_chain_unregister(&panic_notifier_list,&booke_wdt_notifier);
+}
+
+/**
+ * booke_wdt_init:
+ *
+ * Set up the WDT relevant timer facility.
+ */
+
+static int __init
+booke_wdt_init(void)
+{
+ int ret;
+ unsigned long flags;
+
+ ret = register_reboot_notifier(&booke_wdt_notifier);
+ if(ret) {
+ booke_wdt_err("Cannot register reboot notifier (err=%d)\n", ret);
+ return ret;
+ }
+
+ /* Register panic notifier */
+ ret = notifier_chain_register(&panic_notifier_list,&booke_wdt_notifier);
+ if(ret) {
+ booke_wdt_err("Cannot register panic notifier (err=%d)\n", ret);
+ unregister_reboot_notifier(&booke_wdt_notifier);
+ return ret;
+ }
+
+ ret = 0;
+ booke_wdt_init_device();
+ /* Check that the heartbeat value is within it's range ; if not reset to the default */
+ if (booke_wdt_set_timeout(wdt_period)) {
+ if (wdt_period)
+ booke_wdt_info("The heartbeat value must be %d < wdt_period < %d, using %d\n",WDT_HEARTBEAT_MIN,WDT_HEARTBEAT_MAX,WDT_TIMO);
+ booke_wdt_set_timeout(WDT_TIMO);
+ }
+
+ local_irq_save(flags); /* Prevent timer interrupt */
+ ppc_md.heartbeat_count = 0;
+ ppc_md.heartbeat=booke_wdt_heartbeat;
+ local_irq_restore(flags);
+
+ booke_wdt_info("Book E(PPC 4xx/e500) Watchdog Driver. period=%d ms (nowayout=%d)\n",wdt_period, nowayout);
+
+ ret = misc_register(&booke_wdt_miscdev);
+ if (ret) {
+ booke_wdt_err("Cannot register miscdev on minor=%d (err=%d)\n",
+ WATCHDOG_MINOR, ret);
+ goto outmisc;
+ }
+
+ if (wdt_enable) {
+ booke_wdt_info("WDT start on boot.\n");
+ booke_wdt_start();
+ }
+out:
+ return ret;
+outmisc:
+ unregister_reboot_notifier(&booke_wdt_notifier);
+ local_irq_save(flags);
+ ppc_md.heartbeat=NULL;
+ ppc_md.heartbeat_count = 0;
+ local_irq_restore(flags);
+ goto out;
+}
+
+device_initcall(booke_wdt_init);
--- linux-2.6.11/drivers/char/watchdog/booke_wdt.h 1970-01-01 09:00:00.000000000 +0900
+++ linux-2.6.11-wdt/drivers/char/watchdog/booke_wdt.h 2005-03-09 13:07:53.685574760 +0900
@@ -0,0 +1,110 @@
+/*
+ *
+ * Copyright (c) 2004 Fujitsu Limited
+ *
+ * Module name: booke_wdt.h
+ * Author: Takeharu KATO<kato.takeharu@jp.fujitsu.com>
+ * Description:
+ * Header file for PowerPC Book E(PPC 4xx/e500) watchdog driver.
+ *
+ * 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.
+ *
+ * Neither Takeharu KATO nor Fujitsu Ltd. admit liability nor provide
+ * warranty for any of this software.
+ *
+ */
+#ifndef _DRIVERS_CHAR_WATCHDOG_BOOKE_WDT_H
+#define _DRIVERS_CHAR_WATCHDOG_BOOKE_WDT_H
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/ptrace.h>
+#include <linux/watchdog.h>
+#include <asm/reg_booke.h>
+
+/*
+ * Driver state flags(bit position)
+ */
+#define WDT_STATE_OPEN 0 /* driver is opend */
+#define WDT_STATE_STOP_ON_CLOSE 1 /* Stop with close is expected */
+/*
+ * Configurations
+ */
+#define WDT_TIMO 60000 /* Default timeout = 60000 ms(1min) */
+#define WDT_HEARTBEAT_MIN 100 /* Minimum timeout = 100 ms */
+#define WDT_HEARTBEAT_MAX 600000 /* Maximum timeout = 600000ms(1hour) */
+#ifdef __KERNEL__
+//#define BOOKE_WDT_DEBUG /* Debug switch */
+
+/* Watchdog timer periods can be set on PPC 4xx cpus. */
+#if defined(CONFIG_4xx)
+/*
+ * For PowerPC 4xx
+ */
+#define WDT_WP0 0
+#define WDT_WP1 1
+#define WDT_WP2 2
+#define WDT_WP3 3
+#define wdt_calculate_tcr(period,reset) ( TCR_WP(period) | TCR_WRC(reset) )
+#else
+#if defined(CONFIG_E500)
+/*
+ * For e500 CPU
+ * Actually, e500 can arbitrary periods can be set,
+ * But this driver uses fix period value as same as PPC440
+ * on purpose for simplicity.
+ * Following values split into WP and WP_EXT parts in booke_wdt.c.
+ */
+#define WDT_WP0 21
+#define WDT_WP1 25
+#define WDT_WP2 29
+#define WDT_WP3 33
+#define WDT_TCR_WP_BITLEN 2 /* 2bit length */
+#define WDT_TCR_WP_BITMSK ((1<<(WDT_TCR_WP_BITLEN))-1) /* mask */
+#define WDT_TCR_WPEXT_BITMSK 0xf /* 4bit length */
+#define WDT_TCR_WPEXT_SHIFT 17
+#define WDT_WPEXT_VAL(period) (((period)>>WDT_TCR_WP_BITLEN)& \
+ (WDT_TCR_WPEXT_BITMSK))
+#define wdt_calculate_tcr(period,reset) \
+ ( TCR_WP((period)&(WDT_TCR_WP_BITMSK)) |\
+ TCR_WRC((reset)) |\
+ ( WDT_WPEXT_VAL(period) << WDT_TCR_WPEXT_SHIFT))
+#else
+#error "Book E WDT detects invalid configuration(Unknown CPU)"
+#endif /* CONFIG_E500 */
+#endif /* CONFIG_4xx */
+/*
+ * WP relevant values used in our driver.
+ * Note:WDT period must be more than HZ(Timer ticks)
+ */
+#define WDT_WP WDT_WP3
+
+/*
+ * IOCTL commands for comaptiblity for old driver
+ */
+#define WDIOC_GETPERIOD WDIOC_GETTIMEOUT
+#define WDIOC_SETPERIOD WDIOC_SETTIMEOUT
+
+/*
+ * output messages
+ */
+#define __BOOKE_WDT_MSG "BookE-WDT : "
+#define booke_mkmsg(str) __BOOKE_WDT_MSG str
+#define booke_wdt_info(fmt,arg...) \
+ printk(KERN_INFO __BOOKE_WDT_MSG fmt,##arg)
+#define booke_wdt_note(fmt,arg...) \
+ printk(KERN_NOTICE __BOOKE_WDT_MSG fmt,##arg)
+#define booke_wdt_err(fmt,arg...) \
+ printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
+#if defined(BOOKE_WDT_DEBUG)
+#define booke_wdt_dbg(fmt,arg...) \
+ printk(KERN_ALERT __BOOKE_WDT_MSG fmt,##arg)
+#else
+#define booke_wdt_dbg(fmt,arg...) \
+ do{}while(0)
+#endif /* WDT_DEBUG */
+
+#endif /* __KERNEL__ */
+#endif /* _DRIVERS_CHAR_WATCHDOG_BOOKE_WDT_H */
^ permalink raw reply
* Re: mv643xx_eth SA_SHIRQ support patch
From: Sven Luther @ 2005-03-09 7:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Dale Farnsworth, sl, linuxppc-dev list, Nicolas DET,
linuxppc-embedd
In-Reply-To: <1110321086.13593.284.camel@gaston>
On Wed, Mar 09, 2005 at 09:31:26AM +1100, Benjamin Herrenschmidt wrote:
>
> > Ok, i should have something working. adding here both sven2-dale.diff which is
> > a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against
> > 2.6.11.
> >
> > There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c
> > especially with regard the headers, and also the proper copyright/attibution
> > of it (since dale wrote it and i just pasted it and did the detection stuff
> > benh mentioned above.
> >
> > I am unsure also about the :
> >
> > @@ -44,6 +44,9 @@
> > #include <asm/pgtable.h>
> > #include <asm/system.h>
> > #include <asm/delay.h>
> > +#ifdef PPC_MULTIPLATEFORM
> > +#include <mv64x60.h>
> > +#endif
> > #include "mv643xx_eth.h"
> >
> > /*
> >
> > hunk. dale can you check it ?
>
> Looks broken...
Yep, removed it.
> > Comments are welcome, in particular benh, i guess my detection code will beak
> > horribly if there is another host node prior to the marvell one in the OF
> > tree, which is not the case currently on pegasos though.
>
> Why are you looking at vid/did ? Isn't there some name string (model,
> compatible, whatever) you can use ? Or is your OF too bad to even give
> such info ?
>
> You can also iterate after the find_devices() using np->next
Well, I have this :
vendor-id 0x11AB (4523)
device-id 0x6460 (25696)
revision-id 0x3 (3)
class-code 0x60000 (393216)
subsystem-id 0x0 (0)
subsystem-vendor-id 0x0 (0)
.vendor-name "Marvell"
.part-number "MV6436x"
.description "System Controller for PowerPC Processors"
.class "Bridge Device"
.subclass "Host/PCI"
devsel-speed 0x0 (0)
min-grant 0x0 (0)
max-latency 0x0 (0)
name "host"
reg 0:0
assigned-addresses
In the /pci/host node, i also have :
model "Pegasos2"
In the root node, and in the new OF, we even have a /discovery2/port@1 or
something such, but it is unreleased yet.
The thing is not that there is no info, just to chose which info is best.
Christoph suggested to not do that though, but use the normal pci stuff and
match on the host pci id with pci_dev_present. This is what i was thinking of
doing too, and may be more logical, no ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: mv643xx_eth SA_SHIRQ support patch
From: Benjamin Herrenschmidt @ 2005-03-09 7:39 UTC (permalink / raw)
To: Sven Luther
Cc: linuxppc-dev list, Dale Farnsworth, sl, linuxppc-embedd,
Nicolas DET
In-Reply-To: <20050309071722.GA25622@pegasos>
On Wed, 2005-03-09 at 08:17 +0100, Sven Luther wrote:
> vendor-id 0x11AB (4523)
> device-id 0x6460 (25696)
> revision-id 0x3 (3)
> class-code 0x60000 (393216)
> subsystem-id 0x0 (0)
> subsystem-vendor-id 0x0 (0)
> .vendor-name "Marvell"
> .part-number "MV6436x"
> .description "System Controller for PowerPC Processors"
> .class "Bridge Device"
> .subclass "Host/PCI"
> devsel-speed 0x0 (0)
> min-grant 0x0 (0)
> max-latency 0x0 (0)
> name "host"
> reg 0:0
> assigned-addresses
Ok, teach them the interest in having a "model" and "compatible"
property in them for their next version...
> In the /pci/host node, i also have :
>
> model "Pegasos2"
>
> In the root node, and in the new OF, we even have a /discovery2/port@1 or
> something such, but it is unreleased yet.
Ugh ? What is that supposed to be ?
If it's an ethernet port, it should be called "ethernet".
> The thing is not that there is no info, just to chose which info is best.
>
> Christoph suggested to not do that though, but use the normal pci stuff and
> match on the host pci id with pci_dev_present. This is what i was thinking of
> doing too, and may be more logical, no ?
Yah, if there is no meaningful OF name, then probably.
Ben.
^ permalink raw reply
* Re: mv643xx_eth SA_SHIRQ support patch
From: Sven Luther @ 2005-03-09 7:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Dale Farnsworth, sl, linuxppc-dev list, Nicolas DET,
linuxppc-embedd
In-Reply-To: <1110353967.32524.83.camel@gaston>
On Wed, Mar 09, 2005 at 06:39:27PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 08:17 +0100, Sven Luther wrote:
>
> > vendor-id 0x11AB (4523)
> > device-id 0x6460 (25696)
> > revision-id 0x3 (3)
> > class-code 0x60000 (393216)
> > subsystem-id 0x0 (0)
> > subsystem-vendor-id 0x0 (0)
> > .vendor-name "Marvell"
> > .part-number "MV6436x"
> > .description "System Controller for PowerPC Processors"
> > .class "Bridge Device"
> > .subclass "Host/PCI"
> > devsel-speed 0x0 (0)
> > min-grant 0x0 (0)
> > max-latency 0x0 (0)
> > name "host"
> > reg 0:0
> > assigned-addresses
>
> Ok, teach them the interest in having a "model" and "compatible"
> property in them for their next version...
You mean a model in /pci/host, ok, i can add that.
> > In the /pci/host node, i also have :
> >
> > model "Pegasos2"
> >
> > In the root node, and in the new OF, we even have a /discovery2/port@1 or
> > something such, but it is unreleased yet.
>
> Ugh ? What is that supposed to be ?
As opposed to /ethernet/port1 as it is currently.
> If it's an ethernet port, it should be called "ethernet".
In fact, we already did it, it is /discovery2/ethernet@1, which should make
yaboot happy, i think. Not released though.
> > The thing is not that there is no info, just to chose which info is best.
> >
> > Christoph suggested to not do that though, but use the normal pci stuff and
> > match on the host pci id with pci_dev_present. This is what i was thinking of
> > doing too, and may be more logical, no ?
>
> Yah, if there is no meaningful OF name, then probably.
Well, if there is both, what is the best way to do this ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: MPC5200 kernel with IDE *and* FEC?
From: Sylvain Munaut @ 2005-03-09 8:02 UTC (permalink / raw)
To: Stephen Warren; +Cc: linuxppc-embedded
In-Reply-To: <DBFABB80F7FD3143A911F9E6CFD477B0056A92CC@hqemmail02.nvidia.com>
Stephen Warren wrote:
>From: Dale Farnsworth [mailto:dale@farnsworth.org]
>
>
>>On Tue, Mar 08, 2005 at 05:34:20PM +0000, Stephen Warren wrote:
>>
>>
>>>I looked at the 2.6.11 kernel.org kernel, and it has MPC5200 IDE
>>>support, but apparently no FEC driver support.
>>>
>>>
>>Are you sure it has MPC5200 IDE support? I have yet to see reliable
>>5200 IDE support and haven't seen a 5200 IDE driver for 2.6 at all.
>>
>>
>
>Not sure, no. Looking at "xconfig", I don't see an option for it. A
>colleague said it did.
>
>
No it doesn't. Or it's very well hidden ;)
But If you do write it, patches are welcomed.
>We've used IDE (for a DVD-ROM) using the Denx kernel. This didn't have
>DMA suppport, but Freescale gave us a derivate kernel that it, which
>seemed to work well. They said they were going to push this up through
>Denx into the main kernel. Didn't they bother to do this?
>
>
I guess they mean push it to Denx kernel which IS the main 2.4 kernel
for MPC5200.
No new platform support will be accepted for 2.4 now. And freescale probably
won't write driver for the tree I maintain since I'm not using the
official BestComm API.
Sylvain
^ permalink raw reply
* Re: [RFC][PATCH] combining header files
From: Geert Uytterhoeven @ 2005-03-09 9:40 UTC (permalink / raw)
To: Alan Modra; +Cc: ppc-dev, Stephen Rothwell, ppc64-dev
In-Reply-To: <20050309011929.GI15642@bubble.modra.org>
On Wed, 9 Mar 2005, Alan Modra wrote:
> On Wed, Mar 09, 2005 at 12:03:43PM +1100, Stephen Rothwell wrote:
> > I would just like to start a discussion about consolidating (some of) the
> > ppc and ppc64 header files.
>
> Marvellous! In case it isn't completely obvious, you can often share
> structure definitions between ppc32 and ppc64 by judicious selection of
> types. eg.
>
> struct stays_the_same {
> long long some_64bit_var;
> int some_32bit_var;
> }
If size matters, why not use an explicitly sized type like s64 to make it
explicit?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC][PATCH] combining header files
From: Alan Modra @ 2005-03-09 12:06 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: ppc-dev, Stephen Rothwell, ppc64-dev
In-Reply-To: <Pine.LNX.4.62.0503091038520.22598@numbat.sonytel.be>
On Wed, Mar 09, 2005 at 10:40:13AM +0100, Geert Uytterhoeven wrote:
> On Wed, 9 Mar 2005, Alan Modra wrote:
> > On Wed, Mar 09, 2005 at 12:03:43PM +1100, Stephen Rothwell wrote:
> > > I would just like to start a discussion about consolidating (some of) the
> > > ppc and ppc64 header files.
> >
> > Marvellous! In case it isn't completely obvious, you can often share
> > structure definitions between ppc32 and ppc64 by judicious selection of
> > types. eg.
> >
> > struct stays_the_same {
> > long long some_64bit_var;
> > int some_32bit_var;
> > }
>
> If size matters, why not use an explicitly sized type like s64 to make it
> explicit?
Sure, that's even better.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* RFC/Commit: New ocp id for CANbus devs
From: Andrey Volkov @ 2005-03-09 12:20 UTC (permalink / raw)
To: paulus, linuxppc-embedded
Hi Paul,
Pls. commit this patch, its needed for MPC5200 Can
Regards
Andrey Volkov
Signed-off-by: Andrey Volkov <avolkov@varma-el.com>
--
ChangeSet@1.2159, 2005-03-09 15:05:37+03:00, avolkov@varma-el.com
ocp_ids.h:
New number for onboard CANbus devs.
ocp_ids.h | 1 +
1 files changed, 1 insertion(+)
diff -Nru a/include/asm-ppc/ocp_ids.h b/include/asm-ppc/ocp_ids.h
--- a/include/asm-ppc/ocp_ids.h 2005-03-09 15:07:51 +03:00
+++ b/include/asm-ppc/ocp_ids.h 2005-03-09 15:07:51 +03:00
@@ -62,6 +62,7 @@
#define OCP_FUNC_RGMII 0x00D3
#define OCP_FUNC_TAH 0x00D4
#define OCP_FUNC_SEC2 0x00D5 /* Crypto/Security 2.0 */
+#define OCP_FUNC_CAN 0x00D6 /* CAN bus device */
/* Network 0x0200 - 0x02FF */
#define OCP_FUNC_EMAC 0x0200
^ permalink raw reply
* port linux to custom board
From: T T @ 2005-03-09 13:09 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]
Host computer: AMD ( I think K8 amd cpu which is i686)
target: custom board (XC2VP4 fpga that contains ppc405, and build around the ppc405 are peripherals UARTLITE, SPI controller, SDRAM controller, PLB (processor locus bus). I have used serial SPI flash from ST(M25P32). NO ETHERNET
GNU toolchain I build ==> binutils (2.10.1) gcc (2.95.3), glibc (2.2.1) includes 2.2.1 linuxthread.
I have follow instructions from "Building Embedded Linux Systems" book to build the kernel image. After I follow up to chapter to 5, the follow instructions that I did are
$make ARCH=ppc CROSS_COMPILE=powerpc-linux- clean dep
$make ARCH=ppc CROSS_COMPILE=powerpc-linux- zImage
$make ARCH=ppc CROSS_COMPILE=powerpc-linux- moudles
during step "installing the kernel" on page 167, I look under /arch/ppc/boot/zImage, and could not find the zImage. <== don't know why, I had seen the other files like system.map, vmlinux .config.
other questions I want to ask is seen I have use serial spi flash memory (ST M25P32) ==> how do I build the "Root file system" on this flash, how do I do with the MTD, and bootloader. I am new to this stuff, so I don't what to do.
thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: Type: text/html, Size: 1638 bytes --]
^ permalink raw reply
* RE: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cann ot read LXT971 PHY id
From: Balasaygun, Oray (Oray) @ 2005-03-09 13:35 UTC (permalink / raw)
To: 'Andrew Morton', Balasaygun, Oray (Oray)
Cc: linuxppc-dev, Nikoonezhad, Danesh (Danesh), netdev
[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]
Hi,
Attached please find the diff output of the fcc_enet.c that I am running with and the original 2.6.10 version of it.
There are 3 category of differences:
1. The fix for Bug 4310 that I reported: these are the last 6 lines of the diffout file.
2. The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently the 2.6 kernel no longer supports the schedule_task() and "struct tq_struct" to go with it. Lines 73 through and including 96 of the diffout file show the changes I made to port schedule_task() into tasklet_schedule(). I should have reported this as a bug too but I forgot about it.
3. The rest of the lines in the diffout file are for the purpose of customizing fcc_enet.c to work with my custom board. These changes are conditional on CONFIG_EON8260 being defined.
Oray Balasaygun
-----Original Message-----
From: Andrew Morton [mailto:akpm@osdl.org]
Sent: Tuesday, March 08, 2005 2:49 PM
To: oray@lucent.com
Cc: linuxppc-dev@ozlabs.org; netdev@oss.sgi.com
Subject: Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver
cannot read LXT971 PHY id
I'm not sure that we have a maintainer for fcc_enet.c. Could you
please send in a tested diff?
bugme-daemon@osdl.org wrote:
>
> http://bugme.osdl.org/show_bug.cgi?id=4310
>
> Summary: ppc 8260 fcc ethernet driver cannot read LXT971 PHY id
> Kernel Version: 2.6.10
> Status: NEW
> Severity: normal
> Owner: platform_ppc-32@kernel-bugs.osdl.org
> Submitter: oray@lucent.com
>
>
> Distribution: www.kernel.org
> Hardware Environment: Target: PowerPC 8260 custom board
> Software Environment: Red Hat 9 cross development using ELDK 3.1 distribution.
> Problem Description: Fast ethernet driver (fcc_enet.c) initialization fails to
> read a valid id from registers 2 and 3 of the LXT971 PHY device and calls the
> panic routine. The bug is in the mii_send_receive() function. During the read
> phase, per LXT971 data sheet, the device starts driving the MDIO line after the
> rising edge of the MDC clock and it could take up to 150ns before the data
> settles. The driver reads the MDIO line before waiting for the data to settle
> down and thus reads in garbage. I fixed the problem by moving the sampling of
> the MDIO line to after the MDC clock is taken low. The code snippet follows:
>
>
> for (i = 0, off = 15; i < 16; i++, off--)
> {
> #define FCC_8260_BUG
> FCC_PDATC_MDC(1);
> retval <<= 1;
> #ifndef FCC_8260_BUG
> if (io->iop_pdatc & fip->fc_mdio)
> retval++;
> udelay(1);
> FCC_PDATC_MDC(0);
> #else
> udelay(1);
> FCC_PDATC_MDC(0);
> if (io->iop_pdatc & fip->fc_mdio)
> retval++;
> #endif
> udelay(1);
> #undef FCC_8260_BUG
> }
>
>
> Steps to reproduce: Is likely to happen on an 8260 target with any kind of PHY,
> not just the LXT971, hooked up to the FCC port.
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
[-- Attachment #2: diffout --]
[-- Type: application/octet-stream, Size: 3517 bytes --]
180,227d179
< #ifdef CONFIG_EON8260
<
< #define MAKE_BITMASK(n) (1 << (31-n))
<
< #define PA8 MAKE_BITMASK(8)
< #define PA9 MAKE_BITMASK(9)
<
< #define PB18 MAKE_BITMASK(18)
< #define PB19 MAKE_BITMASK(19)
< #define PB20 MAKE_BITMASK(20)
< #define PB21 MAKE_BITMASK(21)
< #define PB22 MAKE_BITMASK(22)
< #define PB23 MAKE_BITMASK(23)
< #define PB24 MAKE_BITMASK(24)
< #define PB25 MAKE_BITMASK(25)
< #define PB26 MAKE_BITMASK(26)
< #define PB27 MAKE_BITMASK(27)
< #define PB28 MAKE_BITMASK(28)
< #define PB29 MAKE_BITMASK(29)
< #define PB30 MAKE_BITMASK(30)
< #define PB31 MAKE_BITMASK(31)
<
< #define PB2_TXER PB31
< #define PB2_RXDV PB30
< #define PB2_TXEN PB29
< #define PB2_RXER PB28
< #define PB2_COL PB27
< #define PB2_CRS PB26
< #define PB2_TXDAT (PB22 | PB23 | PB24 | PB25)
< #define PB2_RXDAT (PB18 | PB19 | PB20 | PB21)
< #define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | \
< PB2_RXER | PB2_RXDV | PB2_TXER)
< #define PB2_PSORB1 (PB2_TXEN)
< #define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV)
< #define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)
<
< /* CLK16 (PC16) is receive, CLK15 (PC17) is transmit */
<
< #define PC_F2RXCLK ((uint)0x00008000)
< #define PC_F2TXCLK ((uint)0x00004000)
<
< #define CMXFCR_TF2CS_CLK15 0x00060000 /* Transmit FCC2 Clock Source is CLK15 */
< #define CMXFCR_RF2CS_CLK16 0x00380000 /* Receive FCC2 Clock Source is CLK16 */
< #define CMX2_CLK_ROUTE (CMXFCR_RF2CS_CLK16 | CMXFCR_TF2CS_CLK15)
< #define CMX2_CLK_MASK ((uint)0x00ff0000)
<
< #else /* #ifdef CONFIG_EON8260 */
<
259,260d210
< #endif /* #ifdef CONFIG_EON8260 */
<
287,291c237
< #if defined (CONFIG_EON8260)
< /* EON8260 has MDIO and MDCK on PC31 and PC30 respectively */
< #define PC_MDIO ((uint)0x00000001)
< #define PC_MDCK ((uint)0x00000002)
< #elif defined (CONFIG_TQM8260)
---
> #ifdef CONFIG_TQM8260
325c271
< # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260)
---
> # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
334c280
< # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260)
---
> # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
345c291
< # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260)
---
> # if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
386c332
< struct tasklet_struct phy_task;
---
> struct tq_struct phy_task;
1303c1249
< fep->phy_task.func = (void *)mii_relink;
---
> fep->phy_task.routine = (void *)mii_relink;
1305c1251
< tasklet_schedule(&fep->phy_task);
---
> schedule_task(&fep->phy_task);
1312c1258
< fep->phy_task.func = (void *)mii_display_config;
---
> fep->phy_task.routine = (void *)mii_display_config;
1314c1260
< tasklet_schedule(&fep->phy_task);
---
> schedule_task(&fep->phy_task);
1521,1523d1466
< cep->phy_task.next = NULL;
< cep->phy_task.state = 0;
< cep->phy_task.count.counter = 0;
1758,1762d1700
< #if defined(CONFIG_EON8260)
< for (i=5; i>=0; i--) {
< *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i];
< }
< #else /* if defined(CONFIG_EON8260) */
1783d1720
< #endif /* if defined(CONFIG_EON8260) */
2006,2007d1942
< udelay(1);
< FCC_PDATC_MDC(0);
2010a1946,1947
> FCC_PDATC_MDC(0);
> udelay(1);
^ permalink raw reply
* Re: mv64x60 updates
From: Chris Friesen @ 2005-03-09 15:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Nicolas DET, Sven Luther, linuxppc-dev list
In-Reply-To: <1110333695.32556.15.camel@gaston>
Benjamin Herrenschmidt wrote:
> Welcome to the world of embedded people who use #ifdef's for their
> platforms :)
Yeah. And all the different vendor patches are mutually incompatible,
and are hardcoded to wrong values, and mangle common code, and....
Chris
^ permalink raw reply
* Re: RFC/Commit: New ocp id for CANbus devs
From: Kumar Gala @ 2005-03-09 17:16 UTC (permalink / raw)
To: Andrey Volkov; +Cc: paulus, linuxppc-embedded
In-Reply-To: <422EEA20.4050907@varma-el.com>
Is this for 2.6? If so, 5200 needs to be moved to using the new driver=20=
model and platform devices. Take a look at support for MPC85xx or=20
marvell (mv64x60) as examples.
- kumar
On Mar 9, 2005, at 6:20 AM, Andrey Volkov wrote:
> Hi Paul,
>
> Pls. commit this patch, its needed for MPC5200 Can
>
> Regards
> Andrey Volkov
>
> Signed-off-by: Andrey Volkov <avolkov@varma-el.com>
> --
> ChangeSet@1.2159, 2005-03-09 15:05:37+03:00, avolkov@varma-el.com
> =A0=A0 ocp_ids.h:
> =A0=A0=A0=A0 New number for onboard CANbus devs.
>
>
>
> =A0 ocp_ids.h |=A0=A0=A0 1 +
> =A0 1 files changed, 1 insertion(+)
>
>
>
> diff -Nru a/include/asm-ppc/ocp_ids.h b/include/asm-ppc/ocp_ids.h
> --- a/include/asm-ppc/ocp_ids.h 2005-03-09 15:07:51 +03:00
> +++ b/include/asm-ppc/ocp_ids.h 2005-03-09 15:07:51 +03:00
> @@ -62,6 +62,7 @@
> =A0 #define OCP_FUNC_RGMII=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =
0x00D3
> =A0 #define OCP_FUNC_TAH=A0 =A0=A0=A0=A0=A0=A0=A0 0x00D4
> =A0 #define OCP_FUNC_SEC2 =A0=A0=A0=A0=A0=A0=A0 0x00D5=A0 /* =
Crypto/Security 2.0 */
> +#define OCP_FUNC_CAN=A0=A0 =A0=A0=A0=A0=A0=A0=A0 0x00D6=A0 /* CAN =
bus device */
>
> =A0 /* Network 0x0200 - 0x02FF */
> =A0 #define OCP_FUNC_EMAC =A0=A0=A0=A0=A0=A0=A0 0x0200
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* PPC 440GX with NS DP83865 phy
From: Sanjay Bajaj @ 2005-03-09 17:11 UTC (permalink / raw)
To: linuxppc-embedded
Has anybody used PPC 440GX with NS DP83865 phy? If you have or have any =
information to set it up, please share.
Thanks,
Sanjay
^ permalink raw reply
* PPC 440GX with NS DP83865 phy?
From: Sanjay Bajaj @ 2005-03-09 17:10 UTC (permalink / raw)
To: linuxppc-dev
Has anybody used PPC 440GX with NS DP83865 phy? If you have or have any =
information to set it up, please share.
Thanks,
Sanjay
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Andy Fleming @ 2005-03-09 17:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <1110334456.32556.21.camel@gaston>
On Mar 8, 2005, at 20:14, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote:
>> I've finally gotten all of ebs's suggestions into the PHY code. Here
>> is the new version. It has the following improvements:
>>
>> * All PHYs now determine speed,duplex, etc using the same generic
>> code,
>> rather than PHY-specific registers.
>
> Some PHY are doing a better job with PHY specific registers I think ...
> The gigabit for example isn't standard, and some PHYs sort-of manage to
> deal with non-autoneg hubs in such a way that the "normal" aneg doesn't
> succeeds, but the phy specific stuff does work. At least from stuff
> I've
> been told a while ago, I have no direct experience here.
Ah, I should have been a little more clear. All the currently
implemented PHY drivers are just using the generic read_status
function. Different PHYs can assign their read_status function to be
PHY-specific
>
>> * The genphy driver works for gigabit PHYs now, as well. In theory,
>> if
>> your PHY isn't broken in some way (I've encountered a number that
>> are),
>> you should be able to just use genphy.
>
> Isn't the speed reporting of gigabit an implementation specific bit in
> lots of PHYs ?
Well, it looks like there are some standard bits which say whether the
PHY supports gigabit. I used those.
Andy
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Andy Fleming @ 2005-03-09 17:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, David S. Miller, linuxppc-embedded
In-Reply-To: <1110340214.32524.32.camel@gaston>
On Mar 8, 2005, at 21:50, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote:
>> On Wed, 09 Mar 2005 13:14:16 +1100
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>
>>> I'll have a closer look when I find some time, see if it makes sense
>>> to
>>> adapt sungem or not.
>>
>> Especially because of the Broadcom PHYs I bet it doesn't.
>>
>> Too many chips have to reset the MAC, or do other fancy stuff
>> when programming the PHY to make this genphy thing very useful.
>
> Oh, I think genphy is just a generic driver, but his layer has hooks
> for
> other PHY drivers (wasn't it based on sungem_phy in the first place ?)
Definitely. Much of this code was culled from the sungem and ibm_emac
drivers, with some input from mii.c. The genphy driver is just one of
the 6 PHY drivers in the patch I sent (the others are Marvell, Davicom,
Cicada, QS, LXT). Actually, several of those files have multiple
drivers in them. The genphy driver is the fallback driver. It exists
for those PHYs which never get a driver, but don't need special
attention.
>
> I discussed several steps of the design with Andy, the idea was to have
> something a bit like sungem_phy.c with addditional common library for
> doing the link polling & fallback stuff etc... that could be easily
> shared by drivers.
Yup. I look forward to your input on how well the code meshes with
what people need for their drivers.
^ permalink raw reply
* Re: RFC/Commit: New ocp id for CANbus devs
From: Andrey Volkov @ 2005-03-09 17:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: paulus, linuxppc-embedded
In-Reply-To: <d32d7ad858d3660f9d7fdf33003ca4cc@freescale.com>
Hi Kumar:
> Is this for 2.6?
Oh sorry, certainly for 2.6 (Sylvain's kernel more precisely).
But since, Sylvain not maintainer of ocp_ids.h, so I send
this patch to Paul (who create it, am I right?).
> If so, 5200 needs to be moved to using the new driver
> model and platform devices. Take a look at support for MPC85xx or
> marvell (mv64x60) as examples.
>
> - kumar
Kumar, please, more cleanly, what did you want to say? If you told about
board_ocp[] in lite5200.c (platform specific). Then yes, I use it, but
not mpc5200.c
--
Andrey
>
> On Mar 9, 2005, at 6:20 AM, Andrey Volkov wrote:
>
>> Hi Paul,
>>
>> Pls. commit this patch, its needed for MPC5200 Can
>>
>> Regards
>> Andrey Volkov
>>
>> Signed-off-by: Andrey Volkov <avolkov@varma-el.com>
>> --
>> ChangeSet@1.2159, 2005-03-09 15:05:37+03:00, avolkov@varma-el.com
>> ocp_ids.h:
>> New number for onboard CANbus devs.
>>
>>
>>
>> ocp_ids.h | 1 +
>> 1 files changed, 1 insertion(+)
>>
>>
>>
>> diff -Nru a/include/asm-ppc/ocp_ids.h b/include/asm-ppc/ocp_ids.h
>> --- a/include/asm-ppc/ocp_ids.h 2005-03-09 15:07:51 +03:00
>> +++ b/include/asm-ppc/ocp_ids.h 2005-03-09 15:07:51 +03:00
>> @@ -62,6 +62,7 @@
>> #define OCP_FUNC_RGMII 0x00D3
>> #define OCP_FUNC_TAH 0x00D4
>> #define OCP_FUNC_SEC2 0x00D5 /* Crypto/Security 2.0 */
>> +#define OCP_FUNC_CAN 0x00D6 /* CAN bus device */
>>
>> /* Network 0x0200 - 0x02FF */
>> #define OCP_FUNC_EMAC 0x0200
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* RE: Lots of memory on 826x
From: Rune Torgersen @ 2005-03-09 17:52 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
Yay... It worked....
Had to patch m8260_setup a bit.
In m8260_map_io() I changed
io_block_mapping(addr, addr, 0x10000000, _PAGE_IO);
into
io_block_mapping(addr, addr, 0xffffffff - addr + 1, _PAGE_IO);=20
So that I could change the IMMR address in my config file only, and the
mappings were still correct.
I could probably submit a proper patch.
> > -----Original Message-----
> > From: Matt Porter [mailto:mporter@kernel.crashing.org]=20
> > Sent: Tuesday, March 08, 2005 17:30
> > To: Rune Torgersen
> > Cc: Kumar Gala; linuxppc-embedded@ozlabs.org
> > Subject: Re: Lots of memory on 826x
>=20
> > Ahh, but early ioremaps (before mm is inited) grow down from=20
> > PKMAP_BASE,
> > so you will be overlapping the top of lowmem with those allocations.
> > It wants to be above vmalloc space. Set HIGHMEM_START to=20
> 0xF6000000,
> > IMMR/IO to 0xF8000000 and you then have vmalloc space between
> > 0xF1000000-0xF5FFFFFF.
>=20
> I'll try this tomorrow and see what happens.=20
> (Still need to make sure our board supports 2GB....:)
^ permalink raw reply
* Re: RFC/Commit: New ocp id for CANbus devs
From: Sylvain Munaut @ 2005-03-09 18:37 UTC (permalink / raw)
To: Andrey Volkov; +Cc: paulus, linuxppc-embedded
In-Reply-To: <422F34F9.1050607@varma-el.com>
Andrey Volkov wrote:
> Hi Kumar:
>
>> Is this for 2.6?
>
> Oh sorry, certainly for 2.6 (Sylvain's kernel more precisely).
> But since, Sylvain not maintainer of ocp_ids.h, so I send
> this patch to Paul (who create it, am I right?).
>
>> If so, 5200 needs to be moved to using the new driver model and
>> platform devices. Take a look at support for MPC85xx or marvell
>> (mv64x60) as examples.
>>
>> - kumar
>
> Kumar, please, more cleanly, what did you want to say? If you told about
> board_ocp[] in lite5200.c (platform specific). Then yes, I use it, but
> not mpc5200.c
>
No, what he said is that MPC5200 needs to be moved to use the platform
bus driver model.
I'll post the patch doing just that on Monday along with PCI and sparse
clean-ups. (Unless something goes wrong ...)
Sylvain
^ permalink raw reply
* Re: [PATCH] ppc32: trivial fix for e500 oprofile build
From: Greg KH @ 2005-03-09 18:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: akpm, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0503041303290.18551@blarg.somerset.sps.mot.com>
On Fri, Mar 04, 2005 at 01:09:18PM -0600, Kumar Gala wrote:
> Andrew, Greg
>
> Here is a patch for the new 2.6.11 release tree and for Linus.
>
> Fix for trivial fix for 2.6.11 oprofile compilation on e500 based ppc.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Added to the -stable queue, thanks.
greg k-h
^ permalink raw reply
* Re: RFC/Commit: New ocp id for CANbus devs
From: Kumar Gala @ 2005-03-09 19:24 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: paulus, linuxppc-embedded
In-Reply-To: <422F4284.1050806@246tNt.com>
Sylvain,
Thanks, the i2c driver that you used on the OCP side should work for=20
you on the platform device side as well. Also, do you plan on using=20
the ppc_sys stuff for this? Hopefully yes.
- kumar
On Mar 9, 2005, at 12:37 PM, Sylvain Munaut wrote:
> Andrey Volkov wrote:
>
> > Hi Kumar:
> >
> >> Is this for 2.6?=A0
> >
> > Oh sorry, certainly for 2.6 (Sylvain's kernel more precisely).
> > But since, Sylvain not maintainer of ocp_ids.h, so I send
> > this patch to Paul (who create it, am I right?).
> >
> >> If so, 5200 needs to be moved to using the new driver model and
> >> platform devices.=A0 Take a look at support for MPC85xx or marvell
> >> (mv64x60) as examples.
> >>
> >> - kumar
> >
> > Kumar, please, more cleanly, what did you want to say? If you told=20=
> about
> > board_ocp[] in lite5200.c (platform specific). Then yes, I use it,=20=
> but
> > not mpc5200.c
> >
> No, what he said is that MPC5200 needs to be moved to use the =
platform
> bus driver model.
>
> I'll post the patch doing just that on Monday along with PCI and =
sparse
> clean-ups. (Unless something goes wrong ...)
>
>
>
> =A0=A0=A0 Sylvain
^ permalink raw reply
* Re: [RFC][PATCH] combining header files
From: Linas Vepstas @ 2005-03-09 20:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc64-dev, ppc-dev
In-Reply-To: <20050309120343.0c22eb0f.sfr@canb.auug.org.au>
On Wed, Mar 09, 2005 at 12:03:43PM +1100, Stephen Rothwell was heard to remark:
> Hi all,
>
> I would just like to start a discussion about consolidating (some of) the
> ppc and ppc64 header files. As a starting point (am I am not saying that
> this is the right way to go) the following patch replaces (semantically)
> equivalent ppc64 headers files by just including the asm-ppc file.
Why not #include <asm-generic/whatever.h> instead?
> We *could* use this method to make the journey incremental until there
> are no nontrivial files left in asm-ppc64 ....
sounds good to me.
--linas
^ permalink raw reply
* Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver cann ot read LXT971 PHY id
From: Andrew Morton @ 2005-03-09 23:49 UTC (permalink / raw)
To: Balasaygun, Oray (Oray); +Cc: linuxppc-dev, dnikoonezhad, oray, netdev
In-Reply-To: <B99995113B318D44BBE87DC50092EDA913E1BC8D@nj7460exch006u.ho.lucent.com>
"Balasaygun, Oray (Oray)" <oray@lucent.com> wrote:
>
> Attached please find the diff output of the fcc_enet.c that I am running with and the original 2.6.10 version of it.
Patch looks reasonable, if unconvnetionally presented ;) Thanks.
I fixed a bit of whitespace and converted mii_display_config() and
mii_relink() to take an unsigned long arguments as they're now a tasklet
callback.
Perhaps you could retest this sometime, please?
From: "Balasaygun, Oray (Oray)" <oray@lucent.com>
- fix for Bug 4310
- The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently
the 2.6 kernel no longer supports the schedule_task() and "struct
tq_struct" to go with it. Lines 73 through and including 96 of the
diffout file show the changes I made to port schedule_task() into
tasklet_schedule(). I should have reported this as a bug too but I
forgot about it.
- customize fcc_enet.c to work with my custom board. These changes are
conditional on CONFIG_EON8260 being defined.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/arch/ppc/8260_io/fcc_enet.c | 91 ++++++++++++++++++++++++++++++------
1 files changed, 78 insertions(+), 13 deletions(-)
diff -puN arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id arch/ppc/8260_io/fcc_enet.c
--- 25/arch/ppc/8260_io/fcc_enet.c~ppc-8260-fcc-ethernet-driver-cannot-read-lxt971-phy-id 2005-03-09 15:40:26.000000000 -0800
+++ 25-akpm/arch/ppc/8260_io/fcc_enet.c 2005-03-09 15:47:23.000000000 -0800
@@ -177,6 +177,54 @@ static int fcc_enet_set_mac_address(stru
#define CMX1_CLK_MASK ((uint)0xff000000)
#endif
+#ifdef CONFIG_EON8260
+
+#define MAKE_BITMASK(n) (1 << (31-n))
+
+#define PA8 MAKE_BITMASK(8)
+#define PA9 MAKE_BITMASK(9)
+
+#define PB18 MAKE_BITMASK(18)
+#define PB19 MAKE_BITMASK(19)
+#define PB20 MAKE_BITMASK(20)
+#define PB21 MAKE_BITMASK(21)
+#define PB22 MAKE_BITMASK(22)
+#define PB23 MAKE_BITMASK(23)
+#define PB24 MAKE_BITMASK(24)
+#define PB25 MAKE_BITMASK(25)
+#define PB26 MAKE_BITMASK(26)
+#define PB27 MAKE_BITMASK(27)
+#define PB28 MAKE_BITMASK(28)
+#define PB29 MAKE_BITMASK(29)
+#define PB30 MAKE_BITMASK(30)
+#define PB31 MAKE_BITMASK(31)
+
+#define PB2_TXER PB31
+#define PB2_RXDV PB30
+#define PB2_TXEN PB29
+#define PB2_RXER PB28
+#define PB2_COL PB27
+#define PB2_CRS PB26
+#define PB2_TXDAT (PB22 | PB23 | PB24 | PB25)
+#define PB2_RXDAT (PB18 | PB19 | PB20 | PB21)
+#define PB2_PSORB0 (PB2_RXDAT | PB2_TXDAT | PB2_CRS | PB2_COL | \
+ PB2_RXER | PB2_RXDV | PB2_TXER)
+#define PB2_PSORB1 (PB2_TXEN)
+#define PB2_DIRB0 (PB2_RXDAT | PB2_CRS | PB2_COL | PB2_RXER | PB2_RXDV)
+#define PB2_DIRB1 (PB2_TXDAT | PB2_TXEN | PB2_TXER)
+
+/* CLK16 (PC16) is receive, CLK15 (PC17) is transmit */
+
+#define PC_F2RXCLK ((uint)0x00008000)
+#define PC_F2TXCLK ((uint)0x00004000)
+
+#define CMXFCR_TF2CS_CLK15 0x00060000 /* Transmit FCC2 Clock Source is CLK15 */
+#define CMXFCR_RF2CS_CLK16 0x00380000 /* Receive FCC2 Clock Source is CLK16 */
+#define CMX2_CLK_ROUTE (CMXFCR_RF2CS_CLK16 | CMXFCR_TF2CS_CLK15)
+#define CMX2_CLK_MASK ((uint)0x00ff0000)
+
+#else /* #ifdef CONFIG_EON8260 */
+
/* I/O Pin assignment for FCC2. I don't yet know the best way to do this,
* but there is little variation among the choices.
*/
@@ -208,6 +256,8 @@ static int fcc_enet_set_mac_address(stru
#define CMX2_CLK_MASK ((uint)0x00ff0000)
#endif
+#endif /* #ifdef CONFIG_EON8260 */
+
/* I/O Pin assignment for FCC3. I don't yet know the best way to do this,
* but there is little variation among the choices.
*/
@@ -234,7 +284,11 @@ static int fcc_enet_set_mac_address(stru
/* MII status/control serial interface.
*/
-#ifdef CONFIG_TQM8260
+#if defined (CONFIG_EON8260)
+/* EON8260 has MDIO and MDCK on PC31 and PC30 respectively */
+#define PC_MDIO ((uint)0x00000001)
+#define PC_MDCK ((uint)0x00000002)
+#elif defined (CONFIG_TQM8260)
/* TQM8260 has MDIO and MDCK on PC30 and PC31 respectively */
#define PC_MDIO ((uint)0x00000002)
#define PC_MDCK ((uint)0x00000001)
@@ -268,7 +322,7 @@ static fcc_info_t fcc_ports[] = {
#ifdef CONFIG_FCC1_ENET
{ 0, CPM_CR_FCC1_SBLOCK, CPM_CR_FCC1_PAGE, PROFF_FCC1, SIU_INT_FCC1,
(PC_F1RXCLK | PC_F1TXCLK), CMX1_CLK_ROUTE, CMX1_CLK_MASK,
-# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
+# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260)
PC_MDIO, PC_MDCK },
# else
0x00000004, 0x00000100 },
@@ -277,7 +331,7 @@ static fcc_info_t fcc_ports[] = {
#ifdef CONFIG_FCC2_ENET
{ 1, CPM_CR_FCC2_SBLOCK, CPM_CR_FCC2_PAGE, PROFF_FCC2, SIU_INT_FCC2,
(PC_F2RXCLK | PC_F2TXCLK), CMX2_CLK_ROUTE, CMX2_CLK_MASK,
-# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
+# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260)
PC_MDIO, PC_MDCK },
# elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260)
0x00400000, 0x00200000 },
@@ -288,7 +342,7 @@ static fcc_info_t fcc_ports[] = {
#ifdef CONFIG_FCC3_ENET
{ 2, CPM_CR_FCC3_SBLOCK, CPM_CR_FCC3_PAGE, PROFF_FCC3, SIU_INT_FCC3,
(PC_F3RXCLK | PC_F3TXCLK), CMX3_CLK_ROUTE, CMX3_CLK_MASK,
-# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
+# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272) || defined(CONFIG_EON8260)
PC_MDIO, PC_MDCK },
# else
0x00000001, 0x00000040 },
@@ -329,7 +383,7 @@ struct fcc_enet_private {
uint phy_id_done;
uint phy_status;
phy_info_t *phy;
- struct tq_struct phy_task;
+ struct tasklet_struct phy_task;
uint sequence_done;
@@ -1191,8 +1245,9 @@ static void mii_display_status(struct ne
printk(".\n");
}
-static void mii_display_config(struct net_device *dev)
+static void mii_display_config(unsigned long arg)
{
+ struct net_device *dev = (struct net_device *)arg;
volatile struct fcc_enet_private *fep = dev->priv;
uint s = fep->phy_status;
@@ -1222,8 +1277,9 @@ static void mii_display_config(struct ne
fep->sequence_done = 1;
}
-static void mii_relink(struct net_device *dev)
+static void mii_relink(unsigned long arg)
{
+ struct net_device *dev = (struct net_device *)arg;
struct fcc_enet_private *fep = dev->priv;
int duplex;
@@ -1246,18 +1302,18 @@ static void mii_queue_relink(uint mii_re
{
struct fcc_enet_private *fep = dev->priv;
- fep->phy_task.routine = (void *)mii_relink;
+ fep->phy_task.func = mii_relink;
fep->phy_task.data = dev;
- schedule_task(&fep->phy_task);
+ tasklet_schedule(&fep->phy_task);
}
static void mii_queue_config(uint mii_reg, struct net_device *dev)
{
struct fcc_enet_private *fep = dev->priv;
- fep->phy_task.routine = (void *)mii_display_config;
+ fep->phy_task.func = mii_display_config;
fep->phy_task.data = dev;
- schedule_task(&fep->phy_task);
+ tasklet_schedule(&fep->phy_task);
}
@@ -1464,6 +1520,9 @@ static int __init fec_enet_init(void)
return -ENOMEM;
cep = dev->priv;
+ cep->phy_task.next = NULL;
+ cep->phy_task.state = 0;
+ cep->phy_task.count.counter = 0;
spin_lock_init(&cep->lock);
cep->fip = fip;
@@ -1698,6 +1757,11 @@ init_fcc_param(fcc_info_t *fip, struct n
* non-static part of the address.
*/
eap = (unsigned char *)&(ep->fen_paddrh);
+#if defined(CONFIG_EON8260)
+ for (i = 5; i >=0 ; i--) {
+ *eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i];
+ }
+#else /* if defined(CONFIG_EON8260) */
for (i=5; i>=0; i--) {
#ifdef CONFIG_SBC82xx
if (i == 5) {
@@ -1718,6 +1782,7 @@ init_fcc_param(fcc_info_t *fip, struct n
*eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i];
}
}
+#endif /* if defined(CONFIG_EON8260) */
ep->fen_taddrh = 0;
ep->fen_taddrm = 0;
@@ -1940,10 +2005,10 @@ mii_send_receive(fcc_info_t *fip, uint c
{
FCC_PDATC_MDC(1);
retval <<= 1;
- if (io->iop_pdatc & fip->fc_mdio)
- retval++;
udelay(1);
FCC_PDATC_MDC(0);
+ if (io->iop_pdatc & fip->fc_mdio)
+ retval++;
udelay(1);
}
}
_
^ permalink raw reply
* Re: [RFC][PATCH] combining header files
From: Stephen Rothwell @ 2005-03-10 2:42 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <20050309200109.GG1220@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
On Wed, 9 Mar 2005 14:01:09 -0600 Linas Vepstas <linas@austin.ibm.com> wrote:
>
> Why not #include <asm-generic/whatever.h> instead?
Because I am talking about similarities between ppc and ppc64 not ppc64
and the generic code (though there may be some of those to be exploited as
well).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: boot time scheduling hile atomic
From: Takeharu KATO @ 2005-03-10 4:51 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev
In-Reply-To: <20050304075703.GA15637@Redstar.dorchain.net>
Hi
Joerg Dorchain wrote:
> On Thu, Mar 03, 2005 at 03:18:32PM +0100, Joerg Dorchain wrote:
>
>>>>scheduling while atomic: swapper/0x00000002/0
>>>>Call trace:
>>>> [c0007620] dump_stack+0x18/0x28
>>>> [c01de704] schedule+0x678/0x67c
>>>> [c0004500] syscall_exit_work+0x108/0x10c
>>>> [c02a97b4] proc_root_init+0x168/0x174
>>>> [ff847288] 0xff847288
>>>> [c02945e8] start_kernel+0x144/0x170
>>>> [00003a30] 0x3a30
>>
>>I'll do tonight.
>
> I am more wondering what in proc_root_init or immediately after it
> causes a call to the exit_work syscall.
>
This is not called by proc_root_init.
It seems be called by timer interrupt
(I confirmed it by viewing trap number in
interrupt context with ICE).
As long as I investigate the problem,
proc_root_init is called twice.
At first time, it's called from
start_kernel in init/main.c.
Second case, it seems to be called by some kind of
init call facility.
proc_root_init is not init_call function, I could not
figure out concretely why it called twice.
I will investigate the problem as long as I can.
I wishes this report to become your help.
Regards,
--
Takeharu KATO
Fujitsu Limited
Email:kato.takeharu at jp.fujitsu.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