* Re: mpc 860 boot linux2.6.23 problem
From: Wolfgang Denk @ 2007-10-15 23:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <4713A08C.3060204@freescale.com>
In message <4713A08C.3060204@freescale.com> you wrote:
> keng_629 wrote:
> >
> > i am proting linux2.63.23 to mpc860t board with uboot1.1.4 as bootloader.
> > my bootargs is root=/dev/ram rw init=/linuxrc.
> > i use debugger to see the regedits, find pc is run in the cpu_idle().
> > what is wrong with my kernel, plese give me some advice.thank you .
>
> Posting the same thing over and over again isn't going to change the
> response. Try head-of-Linus's-git, make sure you're using arch/powerpc,
> and post the device tree you're using. Without more information, we
> can't help you.
Just to point out the obvious: U-Boot 1.1.4 is *way* too old to
support any device-tree based kernel, so the fist step is to update
U-Boot to a somewhat recent version (i. e. 1.3.0-rcX).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Faith: not *wanting* to know what is true." - Friedrich Nietzsche
^ permalink raw reply
* Re: can and mpc5200b
From: Wolfgang Denk @ 2007-10-15 23:36 UTC (permalink / raw)
To: S. Fricke; +Cc: linuxppc-dev
In-Reply-To: <20071015133233.GB4859@sfrouter>
In message <20071015133233.GB4859@sfrouter> you wrote:
>
> what is the reasonable can-driver for a mpc5200b?
socket-can.
> I have seen for the peak-3.17 driver a port for the mpc5200 from denx on their
> website, but with kernel 2.6.23 I dont have a chance to use this?
No, but socket-can is part of our kernel tree already, and of the
kernel.org tree in 2.6.24
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The human mind ordinarily operates at only ten percent of its capaci-
ty - the rest is overhead for the operating system.
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Wolfgang Denk @ 2007-10-15 23:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <7DBC0977-0367-40F5-8A30-ACA02FD4E9FA@kernel.crashing.org>
Dear Kumar,
in message <7DBC0977-0367-40F5-8A30-ACA02FD4E9FA@kernel.crashing.org> you wrote:
>
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
...
> * TQM 85xx
...
We definitely care about the TQM8xx{L,M,D}, TQM5200, TQM82xx, TQM834x,
TQM85xx and TQM86xx boards.
> I'm willing to look into doing the port over, but would need some
> help testing.
Ah! Excellent!
As for 85xx, I can test any time on TQM8540, TQM8541, TQM8555 and
TQM8560.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The hottest places in Hell are reserved for those who, in times of
moral crisis, preserved their neutrality." - Dante
^ permalink raw reply
* RE: Override timer interrupt
From: Paul Mackerras @ 2007-10-15 23:30 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded, linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B037D4F05@ismail.innsys.innovsys.com>
Rune Torgersen writes:
> The main couse is that our main bus frequency cannort be divided into
> 1kHz evently by the decrementer.
> Main bus freq = 99532800 Hz.
> Decrementer then becomes 24883, which gives us 999991.9624485600nsec per
> jiffy.
> That is not a number easilly converted into time without drift.
That shouldn't be a problem any more with the CONFIG_GENERIC_TIME
stuff. What happens is that update_wall_time will accumulate
clock->xtime_interval to xtime for every clock->cycle_interval
timebase ticks. The clock->xtime_interval is in units of 2^-22
nanoseconds, so it is very accurate. It is computed from
clock->cycle_interval and clock->mult in
clocksource_calculate_interval() (in include/linux/clocksource.h).
Paul.
^ permalink raw reply
* Re: [PATCH 1/5] Update ibm_newemac to use dcr_host_t.base
From: Michael Ellerman @ 2007-10-15 23:22 UTC (permalink / raw)
To: benh; +Cc: Paul Mackerras, Jeff Garzik, linuxppc-dev
In-Reply-To: <1192481682.11795.23.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Tue, 2007-10-16 at 06:54 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-15 at 14:34 -0400, Jeff Garzik wrote:
> > Michael Ellerman wrote:
> > > Now that dcr_host_t contains the base address, we can use that in the
> > > ibm_newemac code, rather than storing it separately.
> > >
> > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > > ---
> > > drivers/net/ibm_newemac/mal.c | 9 +++++----
> > > drivers/net/ibm_newemac/mal.h | 5 ++---
> > > 2 files changed, 7 insertions(+), 7 deletions(-)
> >
> > applied 1-5
>
> Those patches have been around for some time now, they didn't make
> paulus initial merge for reasons I'm not sure about but I think they
> should go into 2.6.24. Now the question is via Jeff or via Paulus ? :-)
The first three went in already, these are the following cleanups. I
wanted to wait for the newemac driver to go into Linus' tree via Jeff. I
have no opinion on who's tree they should go through from here.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* boards in arch/ppc -> arch/powerpc for 85xx
From: Kumar Gala @ 2007-10-15 23:07 UTC (permalink / raw)
To: Stefan Roese, Dan Malek, David Woodhouse; +Cc: linuxppc-dev list
Guys,
I was wondering if you cared about the following boards existing in
arch/powerpc:
* STX GP3
* TQM 85xx
* SBC 8560
I'm told WR doesn't care about the SBC 8560, so I'll see if David does.
I'm willing to look into doing the port over, but would need some
help testing.
- k
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Benjamin Herrenschmidt @ 2007-10-15 23:02 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel,
Steven Rostedt
In-Reply-To: <4713AC4E.4050002@ru.mvista.com>
On Mon, 2007-10-15 at 22:07 +0400, Sergei Shtylyov wrote:
> > Proper approach is to rip off what is altready in -rt there and
> replace
> > it with Tony patch set.
>
> Tony's patchset is broken at places compared to what is in -rt. So
> that
> would be proper *double standard* approach. :-/
Rather than tony patchset, can you look at what paulus has been
submitting, which should fix a few issues in tony initial patch and is
working, and tell us if you think something is still broken ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-15 22:47 UTC (permalink / raw)
To: benh; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <1192482323.11795.38.camel@pasglop>
On Tue, 2007-10-16 at 07:05 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote:
> > I would ideally like a single active patch generator (even if they
> > are
> > merely reviewed others work sometimes).
> >
> > Outside of that, I'm hoping you and the other people listed making
> > changes will self-organize without my help :)
>
> Josh, do you want to be the central point / maintainer for it or do you
> want me to do it ? There's a lot of code from me in there and I did this
> fork in the first place so I have a pretty good idea of what's going on
> in this driver and what still needs to be done :-)
As always, you're welcome to it. You probably don't want to own it long
term, but I'd appreciate the help for the time being.
josh
^ permalink raw reply
* Re: [PATCH v2] pasemi: process i2c device tree entries at boot
From: Scott Wood @ 2007-10-15 22:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071015224932.GA23875@lixom.net>
Olof Johansson wrote:
> Setup i2c_board_info based on device tree contents. This has to be
> a device_initcall since we need PCI to be probed by the time we
> run it, but before the actual driver is initialized.
Can we factor at least some of this stuff out into common code?
We certainly shouldn't need more than one translation table, and this loop:
> +static int __init pasemi_register_i2c_devices(void)
> +{
> + struct pci_dev *pdev;
> + struct device_node *adap_node;
> + struct device_node *node;
> +
> + pdev = NULL;
> + while ((pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa003, pdev))) {
> + adap_node = pci_device_to_OF_node(pdev);
Should be in the pasemi code, and pass a bus number and device node to
generic code that does this:
> + node = NULL;
> + while ((node = of_get_next_child(adap_node, node))) {
-Scott
^ permalink raw reply
* [PATCH v2] pasemi: process i2c device tree entries at boot
From: Olof Johansson @ 2007-10-15 22:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071015015232.GA4641@lixom.net>
Setup i2c_board_info based on device tree contents. This has to be
a device_initcall since we need PCI to be probed by the time we
run it, but before the actual driver is initialized.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Turns out some old firmwares don't create the device node for the
second and third function, so we need to check for it.
Index: k.org/arch/powerpc/platforms/pasemi/Makefile
===================================================================
--- k.org.orig/arch/powerpc/platforms/pasemi/Makefile
+++ k.org/arch/powerpc/platforms/pasemi/Makefile
@@ -1,4 +1,4 @@
-obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o
+obj-y += setup.o pci.o time.o idle.o powersave.o iommu.o misc.o
obj-$(CONFIG_PPC_PASEMI_MDIO) += gpio_mdio.o
obj-$(CONFIG_ELECTRA_IDE) += electra_ide.o
obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += cpufreq.o
Index: k.org/arch/powerpc/platforms/pasemi/misc.c
===================================================================
--- /dev/null
+++ k.org/arch/powerpc/platforms/pasemi/misc.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (C) 2007 PA Semi, Inc
+ *
+ * Parts based on arch/powerpc/sysdev/fsl_soc.c:
+ *
+ * 2006 (c) MontaVista Software, 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/errno.h>
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/of.h>
+#include <linux/i2c.h>
+
+#ifdef CONFIG_I2C_BOARDINFO
+/* The below is from fsl_soc.c. It's copied because since there are no
+ * official bus bindings at this time it doesn't make sense to share across
+ * the platforms, even though they happen to be common.
+ */
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_driver;
+ char *i2c_type;
+};
+
+static struct i2c_driver_device i2c_devices[] __initdata = {
+ {"dallas,ds1338", "rtc-ds1307", "ds1338"},
+};
+
+static int __init find_i2c_driver(struct device_node *node,
+ struct i2c_board_info *info)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
+ KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
+ strlcpy(info->type, i2c_devices[i].i2c_type,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
+ return 0;
+ }
+ return -ENODEV;
+}
+
+static int __init pasemi_register_i2c_devices(void)
+{
+ struct pci_dev *pdev;
+ struct device_node *adap_node;
+ struct device_node *node;
+
+ pdev = NULL;
+ while ((pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa003, pdev))) {
+ adap_node = pci_device_to_OF_node(pdev);
+
+ if (!adap_node)
+ continue;
+
+ node = NULL;
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info = {};
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) ||
+ *addr > (1 << 10) - 1) {
+ printk(KERN_WARNING
+ "pasemi_register_i2c_devices: "
+ "invalid i2c device entry\n");
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ if (find_i2c_driver(node, &info) < 0)
+ continue;
+
+ info.addr = *addr;
+
+ i2c_register_board_info(PCI_FUNC(pdev->devfn), &info,
+ 1);
+ }
+ }
+ return 0;
+}
+device_initcall(pasemi_register_i2c_devices);
+#endif
^ permalink raw reply
* FW: Override timer interrupt
From: Rune Torgersen @ 2007-10-15 22:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linuxppc-embedded
> From: Benjamin Herrenschmidt =20
> > Things have changed a lot since I last delved deep into=20
> > this to try to
> > ge an accurate freerunning clock (2.6.12).
>=20
> Hrm... 2.6.18 doesn't have clock sources in the first place,=20
> what kernel
> are you using ?
>=20
2.6.18
And I'm starting at the clocksource code right now...
>From jiffies.c:
static int __init init_jiffies_clocksource(void)
{
return clocksource_register(&clocksource_jiffies);
}
module_init(init_jiffies_clocksource);
from: kernel/timer.c
/*
* update_wall_time - Uses the current clocksource to increment the wall
time
*
* Called from the timer interrupt, must hold a write on xtime_lock.
*/
static void update_wall_time(void)
{
cycle_t offset;
/* Make sure we're fully resumed: */
if (unlikely(timekeeping_suspended))
return;
#ifdef CONFIG_GENERIC_TIME
offset =3D (clocksource_read(clock) - clock->cycle_last) &
clock->mask;
#else
offset =3D clock->cycle_interval;
#endif
clock->xtime_nsec +=3D (s64)xtime.tv_nsec << clock->shift;
/* normally this loop will run just once, however in the
* case of lost or late ticks, it will accumulate correctly.
*/
while (offset >=3D clock->cycle_interval) {
/* accumulate one interval */
clock->xtime_nsec +=3D clock->xtime_interval;
clock->cycle_last +=3D clock->cycle_interval;
offset -=3D clock->cycle_interval;
if (clock->xtime_nsec >=3D (u64)NSEC_PER_SEC <<
clock->shift) {
clock->xtime_nsec -=3D (u64)NSEC_PER_SEC <<
clock->shift;
xtime.tv_sec++;
second_overflow();
}
/* interpolator bits */
time_interpolator_update(clock->xtime_interval
>> clock->shift);
/* increment the NTP state machine */
update_ntp_one_tick();
/* accumulate error between NTP and clock interval */
clock->error +=3D current_tick_length();
clock->error -=3D clock->xtime_interval <<
(TICK_LENGTH_SHIFT - clock->shift);
}
/* correct the clock when NTP error is too big */
clocksource_adjust(clock, offset);
/* store full nanoseconds into xtime */
xtime.tv_nsec =3D (s64)clock->xtime_nsec >> clock->shift;
clock->xtime_nsec -=3D (s64)xtime.tv_nsec << clock->shift;
/* check to see if there is a new clocksource to use */
if (change_clocksource()) {
clock->error =3D 0;
clock->xtime_nsec =3D 0;
clocksource_calculate_interval(clock, tick_nsec);
}
}
^ permalink raw reply
* RE: Override timer interrupt
From: Benjamin Herrenschmidt @ 2007-10-15 21:58 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B037D5152@ismail.innsys.innovsys.com>
On Mon, 2007-10-15 at 16:50 -0500, Rune Torgersen wrote:
> Huh? Not in 2.6.18/arch/ppc at least, unless I'm completely
> misundrstanding the code.
> ppc/powerpc seems to be using clocksource_jiffies as the clock source,
> and teh gettimeofday gets xtime + a offset from last jiffie, and xtime
> is updated with a fixed amount per tick.
>
> Things have changed a lot since I last delved deep into this to try to
> ge an accurate freerunning clock (2.6.12).
Hrm... 2.6.18 doesn't have clock sources in the first place, what kernel
are you using ?
Ben.
^ permalink raw reply
* RE: Override timer interrupt
From: Rune Torgersen @ 2007-10-15 21:50 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <1192481753.11795.25.camel@pasglop>
> From: Benjamin Herrenschmidt>=20
> > The TB register is only ued for offsets from the last=20
> jiffie, not as a
> > continous offset, so then it works out pretty good.
>
> The date is derived from the absolute TB value though...
Huh? Not in 2.6.18/arch/ppc at least, unless I'm completely
misundrstanding the code.
ppc/powerpc seems to be using clocksource_jiffies as the clock source,
and teh gettimeofday gets xtime + a offset from last jiffie, and xtime
is updated with a fixed amount per tick.
Things have changed a lot since I last delved deep into this to try to
ge an accurate freerunning clock (2.6.12).
^ permalink raw reply
* Re: [patch 12/13] fb: Move and rename extern declaration for global_mode_option
From: Andrew Morton @ 2007-10-15 21:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert.Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
adaplas
In-Reply-To: <20071012145130.867069000@pademelon.sonytel.be>
On Fri, 12 Oct 2007 16:51:04 +0200
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> - if (mode_option || (mode_option = global_mode_option)) {
> + if (mode_option || (mode_option = fb_mode_option)) {
I guess that equals-which-looks-like-it-should-be-equals-equals really
is intended to be an assignment?
I guess. After staring at it for a while. It's a pretty obnoxious way
of coding it, especially in kernel context where such things are unexpected...
^ permalink raw reply
* [PATCH] Hook compat_sys_nanosleep up to high res timer code
From: Anton Blanchard @ 2007-10-15 21:13 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Thomas Gleixner, mingo, linux-kernel
In-Reply-To: <200710150928.56916.arnd@arndb.de>
Now we have high res timers on ppc64 I thought Id test them. It turns
out compat_sys_nanosleep hasnt been converted to the hrtimer code and so
is limited to HZ resolution.
The follow patch converts compat_sys_nanosleep to use high res timers.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/kernel/compat.c b/kernel/compat.c
index 3bae374..252a446 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -40,62 +40,27 @@ int put_compat_timespec(const struct timespec *ts, struct compat_timespec __user
__put_user(ts->tv_nsec, &cts->tv_nsec)) ? -EFAULT : 0;
}
-static long compat_nanosleep_restart(struct restart_block *restart)
-{
- unsigned long expire = restart->arg0, now = jiffies;
- struct compat_timespec __user *rmtp;
-
- /* Did it expire while we handled signals? */
- if (!time_after(expire, now))
- return 0;
-
- expire = schedule_timeout_interruptible(expire - now);
- if (expire == 0)
- return 0;
-
- rmtp = (struct compat_timespec __user *)restart->arg1;
- if (rmtp) {
- struct compat_timespec ct;
- struct timespec t;
-
- jiffies_to_timespec(expire, &t);
- ct.tv_sec = t.tv_sec;
- ct.tv_nsec = t.tv_nsec;
- if (copy_to_user(rmtp, &ct, sizeof(ct)))
- return -EFAULT;
- }
- /* The 'restart' block is already filled in */
- return -ERESTART_RESTARTBLOCK;
-}
-
asmlinkage long compat_sys_nanosleep(struct compat_timespec __user *rqtp,
- struct compat_timespec __user *rmtp)
+ struct compat_timespec __user *rmtp)
{
- struct timespec t;
- struct restart_block *restart;
- unsigned long expire;
+ struct timespec tu, rmt;
+ long ret;
- if (get_compat_timespec(&t, rqtp))
+ if (get_compat_timespec(&tu, rqtp))
return -EFAULT;
- if ((t.tv_nsec >= 1000000000L) || (t.tv_nsec < 0) || (t.tv_sec < 0))
+ if (!timespec_valid(&tu))
return -EINVAL;
- expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
- expire = schedule_timeout_interruptible(expire);
- if (expire == 0)
- return 0;
+ ret = hrtimer_nanosleep(&tu, rmtp ? &rmt : NULL, HRTIMER_MODE_REL,
+ CLOCK_MONOTONIC);
- if (rmtp) {
- jiffies_to_timespec(expire, &t);
- if (put_compat_timespec(&t, rmtp))
+ if (ret && rmtp) {
+ if (put_compat_timespec(&rmt, rmtp))
return -EFAULT;
}
- restart = ¤t_thread_info()->restart_block;
- restart->fn = compat_nanosleep_restart;
- restart->arg0 = jiffies + expire;
- restart->arg1 = (unsigned long) rmtp;
- return -ERESTART_RESTARTBLOCK;
+
+ return ret;
}
static inline long get_compat_itimerval(struct itimerval *o,
^ permalink raw reply related
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Benjamin Herrenschmidt @ 2007-10-15 21:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <4713B9C1.5010001@garzik.org>
On Mon, 2007-10-15 at 15:04 -0400, Jeff Garzik wrote:
> I would ideally like a single active patch generator (even if they
> are
> merely reviewed others work sometimes).
>
> Outside of that, I'm hoping you and the other people listed making
> changes will self-organize without my help :)
Josh, do you want to be the central point / maintainer for it or do you
want me to do it ? There's a lot of code from me in there and I did this
fork in the first place so I have a pretty good idea of what's going on
in this driver and what still needs to be done :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 4/7] bestcomm: core bestcomm support for Freescale MPC5200
From: Grant Likely @ 2007-10-15 21:06 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, paulus, domen.puncer
In-Reply-To: <4713D35A.9080200@genesi-usa.com>
On 10/15/07, Matt Sealey <matt@genesi-usa.com> wrote:
>
> Grant Likely wrote:
> > On 10/15/07, Matt Sealey <matt@genesi-usa.com> wrote:
> >> My nits:
> >>
> >> Grant Likely wrote:
> >>> From: Sylvain Munaut <tnt@246tNt.com>
> >>> +static int __devinit
> >>> +bcom_engine_init(void)
> >> Why "bcom" and not "bestcomm"?
> >
> > I can type 'bcom' twice as fast. :-) bcom is a suitable shortening;
> > I'm not concerned about it.
>
> I hate acronyms and shortening for the sake of it.
>
> My IDE highlights known symbols from includes and lets me tab complete them :D
>
> After all once all these APIs are fixed and most of the drivers are implemented
> (most of them are, already, anyway, and have been from TaskSomething to sdma_
> to bcom_ changes and major API reworks), I wonder why we have to constantly
> cut every function definition down to 4 characters rhp_bjz_ywh_moo_purr()
>
> I'd level the same thing at bcom_eng (what's an Eng when it's at home? English?
> Engraved? Surely Engine but.. come on :)
>
> There's no real good need to shorten the names of things except when those
> shortenings are also used in the documentation - after all, PSC is what Freescale
> call a PSC, we wouldn't be making structures called mpc52xx_programmable_serial_controller,
> that's redundant, I don't think calling it "bestcomm" (which is it's name) over
> "bcom" (which isn't) works to anyone's advantage here.
bcom is used consistently within this file and its use is unambiguous.
It doesn't need to be changed for this submission.
>
> >>> + /* Disable COMM Bus Prefetch, apparently it's not reliable yet */
> >>> + /* FIXME: This should be done on 5200 and not 5200B ... */
> >>> + out_be16(&bcom_eng->regs->PtdCntrl, in_be16(&bcom_eng->regs->PtdCntrl) | 1);
> >> This really, really shouldn't even be here, could it be moved to a platform
> >> init, or switched on a PVR/SVR here?
> >
> > I think I'd like to leave it here for getting this series merged; it
> > may not be good to have it here; but it's not dangerous either. I'm
> > trying to keep churn on this series down to a minimum.
>
> Why not just accept the churn, and remove those two lines, and someone will
> submit a patch to make it work on the 5200 in the appropriate place later?
Simple; it's not my series. I'm taking the viewpoint of only changing
what is critical to change to get the code in. Those 2 lines may be
sub-optimal; but they are not *bad* or *dangerous* and they're easily
removed later. I'm pushing this change with my maintainer hat on; not
as the device driver developer and as such only making necessary
changes. My view is that it is *safe* and *good* to merge this driver
as is so that the FEC and other drivers can finally get unblocked.
Send me a patch to change it.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Rework hrtimer_nanosleep to make sys_compat_nanosleep easier
From: Anton Blanchard @ 2007-10-15 21:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Thomas Gleixner, mingo, linux-kernel
In-Reply-To: <200710150928.56916.arnd@arndb.de>
Hi,
> If it's common to call sys_nanosleep with a NULL rmtp argument, we could
> save a few cycles using
>
> return hrtimer_nanosleep(&tu, rmtp ? &rmp : NULL, HRTIMER_MODE_REL,
> CLOCK_MONOTONIC);
Good idea, patches updated.
> I think it would be better here to propagate the move to a kernel *rmtp
> down to sys_clock_nanosleep so we get the same optimization in
> compat_sys_clock_nanosleep. That should probably also be a separate
> patch. I can do one if you don't do it first.
I can get to this later in the week, if you feel the urge in the
meantime go for it :)
Anton
--
Pull the copy_to_user out of hrtimer_nanosleep and into the callers
(common_nsleep, sys_nanosleep) in preparation for converting
compat_sys_nanosleep to use hrtimers.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 540799b..7a9398e 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -300,7 +300,7 @@ hrtimer_forward(struct hrtimer *timer, ktime_t now, ktime_t interval);
/* Precise sleep: */
extern long hrtimer_nanosleep(struct timespec *rqtp,
- struct timespec __user *rmtp,
+ struct timespec *rmtp,
const enum hrtimer_mode mode,
const clockid_t clockid);
extern long hrtimer_nanosleep_restart(struct restart_block *restart_block);
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index dc8a445..b2b2c2b 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1286,8 +1286,7 @@ static int __sched do_nanosleep(struct hrtimer_sleeper *t, enum hrtimer_mode mod
long __sched hrtimer_nanosleep_restart(struct restart_block *restart)
{
struct hrtimer_sleeper t;
- struct timespec __user *rmtp;
- struct timespec tu;
+ struct timespec *rmtp;
ktime_t time;
restart->fn = do_no_restart_syscall;
@@ -1298,14 +1297,12 @@ long __sched hrtimer_nanosleep_restart(struct restart_block *restart)
if (do_nanosleep(&t, HRTIMER_MODE_ABS))
return 0;
- rmtp = (struct timespec __user *) restart->arg1;
+ rmtp = (struct timespec *)restart->arg1;
if (rmtp) {
time = ktime_sub(t.timer.expires, t.timer.base->get_time());
if (time.tv64 <= 0)
return 0;
- tu = ktime_to_timespec(time);
- if (copy_to_user(rmtp, &tu, sizeof(tu)))
- return -EFAULT;
+ *rmtp = ktime_to_timespec(time);
}
restart->fn = hrtimer_nanosleep_restart;
@@ -1314,12 +1311,11 @@ long __sched hrtimer_nanosleep_restart(struct restart_block *restart)
return -ERESTART_RESTARTBLOCK;
}
-long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
+long hrtimer_nanosleep(struct timespec *rqtp, struct timespec *rmtp,
const enum hrtimer_mode mode, const clockid_t clockid)
{
struct restart_block *restart;
struct hrtimer_sleeper t;
- struct timespec tu;
ktime_t rem;
hrtimer_init(&t.timer, clockid, mode);
@@ -1335,9 +1331,7 @@ long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
rem = ktime_sub(t.timer.expires, t.timer.base->get_time());
if (rem.tv64 <= 0)
return 0;
- tu = ktime_to_timespec(rem);
- if (copy_to_user(rmtp, &tu, sizeof(tu)))
- return -EFAULT;
+ *rmtp = ktime_to_timespec(rem);
}
restart = ¤t_thread_info()->restart_block;
@@ -1353,7 +1347,8 @@ long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
asmlinkage long
sys_nanosleep(struct timespec __user *rqtp, struct timespec __user *rmtp)
{
- struct timespec tu;
+ struct timespec tu, rmt;
+ int ret;
if (copy_from_user(&tu, rqtp, sizeof(tu)))
return -EFAULT;
@@ -1361,7 +1356,15 @@ sys_nanosleep(struct timespec __user *rqtp, struct timespec __user *rmtp)
if (!timespec_valid(&tu))
return -EINVAL;
- return hrtimer_nanosleep(&tu, rmtp, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+ ret = hrtimer_nanosleep(&tu, rmtp ? &rmt : NULL, HRTIMER_MODE_REL,
+ CLOCK_MONOTONIC);
+
+ if (ret && rmtp) {
+ if (copy_to_user(rmtp, &rmt, sizeof(*rmtp)))
+ return -EFAULT;
+ }
+
+ return ret;
}
/*
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index 57efe04..56b3d86 100644
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -980,9 +980,20 @@ sys_clock_getres(const clockid_t which_clock, struct timespec __user *tp)
static int common_nsleep(const clockid_t which_clock, int flags,
struct timespec *tsave, struct timespec __user *rmtp)
{
- return hrtimer_nanosleep(tsave, rmtp, flags & TIMER_ABSTIME ?
- HRTIMER_MODE_ABS : HRTIMER_MODE_REL,
- which_clock);
+ struct timespec rmt;
+ int ret;
+
+ ret = hrtimer_nanosleep(tsave, rmtp ? &rmt : NULL,
+ flags & TIMER_ABSTIME ?
+ HRTIMER_MODE_ABS : HRTIMER_MODE_REL,
+ which_clock);
+
+ if (ret && rmtp) {
+ if (copy_to_user(rmtp, &rmt, sizeof(*rmtp)))
+ return -EFAULT;
+ }
+
+ return ret;
}
asmlinkage long
^ permalink raw reply related
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Benjamin Herrenschmidt @ 2007-10-15 21:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Roland Dreier, linuxppc-dev
In-Reply-To: <4713B726.6080404@garzik.org>
On Mon, 2007-10-15 at 14:53 -0400, Jeff Garzik wrote:
> Roland Dreier (2):
> ibm_new_emac: Nuke SET_MODULE_OWNER() use
> ibm_emac: Convert to use napi_struct independent of struct
> net_device
>
Wow, I'd have loved to be CCed at least on the last one since I was
about to do just that ... Heh.
Ben.
^ permalink raw reply
* Re: [PATCH] NEW EMAC Fix RGMII build error: use of_device_is_compatible
From: Benjamin Herrenschmidt @ 2007-10-15 21:01 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071012130445.GA14704@ru.mvista.com>
On Fri, 2007-10-12 at 17:04 +0400, Valentine Barshak wrote:
> Fix build RGMII error: use of_device_is_compatible()
> insteadof now deprecated device_is_compatible() function.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/net/ibm_newemac/rgmii.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c linux-2.6/drivers/net/ibm_newemac/rgmii.c
> --- linux-2.6.orig/drivers/net/ibm_newemac/rgmii.c 2007-10-12 16:02:41.000000000 +0400
> +++ linux-2.6/drivers/net/ibm_newemac/rgmii.c 2007-10-12 16:49:07.000000000 +0400
> @@ -251,7 +251,7 @@ static int __devinit rgmii_probe(struct
> }
>
> /* Check for RGMII type */
> - if (device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
> + if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
> dev->type = RGMII_AXON;
> else
> dev->type = RGMII_STANDARD;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] PowerPC: Add NEW EMAC driver support to 440EPx Sequoia board.
From: Benjamin Herrenschmidt @ 2007-10-15 20:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071015122616.08250b54@weaponx.rchland.ibm.com>
On Mon, 2007-10-15 at 12:26 -0500, Josh Boyer wrote:
> On Fri, 12 Oct 2007 17:03:05 +0400
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> > This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> > and adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>
> Could you send the phy part to Jeff Garzik and the netdev list by
> itself? That way it will get picked up and we'll update the Kconfig
> with a later patch.
Oh and please CC me :-)
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC: Add NEW EMAC driver support to 440EPx Sequoia board.
From: Benjamin Herrenschmidt @ 2007-10-15 21:01 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071012130305.GA14682@ru.mvista.com>
On Fri, 2007-10-12 at 17:03 +0400, Valentine Barshak wrote:
> This patch enables NEW EMAC support for PowerPC 440EPx Sequoia board
> and adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
> arch/powerpc/platforms/44x/Kconfig | 7 ++----
> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> --- linux.orig/arch/powerpc/platforms/44x/Kconfig 2007-07-30 15:05:50.000000000 +0400
> +++ linux/arch/powerpc/platforms/44x/Kconfig 2007-07-30 17:59:05.000000000 +0400
> @@ -48,10 +48,9 @@
> config 440EPX
> bool
> select PPC_FPU
> -# Disabled until the new EMAC Driver is merged.
> -# select IBM_NEW_EMAC_EMAC4
> -# select IBM_NEW_EMAC_RGMII
> -# select IBM_NEW_EMAC_ZMII
> + select IBM_NEW_EMAC_EMAC4
> + select IBM_NEW_EMAC_RGMII
> + select IBM_NEW_EMAC_ZMII
>
> config 440GP
> bool
> --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
> +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
> @@ -306,8 +306,47 @@
> .ops = &cis8201_phy_ops
> };
>
> +static struct mii_phy_def bcm5248_phy_def = {
> +
> + .phy_id = 0x0143bc00,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "BCM5248 10/100 SMII Ethernet",
> + .ops = &generic_phy_ops
> +};
> +
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> + phy_write(phy, 0x14, 0x0ce3);
> + phy_write(phy, 0x18, 0x4101);
> + phy_write(phy, 0x09, 0x0e00);
> + phy_write(phy, 0x04, 0x01e1);
> + phy_write(phy, 0x00, 0x9140);
> + phy_write(phy, 0x00, 0x1140);
> +
> + return 0;
> +}
> +
> +static struct mii_phy_ops m88e1111_phy_ops = {
> + .init = m88e1111_init,
> + .setup_aneg = genmii_setup_aneg,
> + .setup_forced = genmii_setup_forced,
> + .poll_link = genmii_poll_link,
> + .read_link = genmii_read_link
> +};
> +
> +static struct mii_phy_def m88e1111_phy_def = {
> +
> + .phy_id = 0x01410CC0,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "Marvell 88E1111 Ethernet",
> + .ops = &m88e1111_phy_ops,
> +};
> +
> static struct mii_phy_def *mii_phy_table[] = {
> &cis8201_phy_def,
> + &bcm5248_phy_def,
> + &m88e1111_phy_def,
> &genmii_phy_def,
> NULL
> };
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: Override timer interrupt
From: Benjamin Herrenschmidt @ 2007-10-15 20:55 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B037D4F05@ismail.innsys.innovsys.com>
On Mon, 2007-10-15 at 11:49 -0500, Rune Torgersen wrote:
>
> The main couse is that our main bus frequency cannort be divided into
> 1kHz evently by the decrementer.
> Main bus freq = 99532800 Hz.
> Decrementer then becomes 24883, which gives us 999991.9624485600nsec
> per
> jiffy.
> That is not a number easilly converted into time without drift.
>
> Changing HZ to 100 fixes it, but is for varous reasons not an option
> right now.
>
> What I did do is change the timer interrupt to be called by an
> ecxternal
> 1kHz interrupt source instead of the decrementer.
>
> The TB register is only ued for offsets from the last jiffie, not as a
> continous offset, so then it works out pretty good.
> There is a discontinuity in the sub ms resolution of the clock that I
> can live with. msec and up are dead accurate.
The date is derived from the absolute TB value though...
Ben.
^ permalink raw reply
* Re: [PATCH 1/5] Update ibm_newemac to use dcr_host_t.base
From: Benjamin Herrenschmidt @ 2007-10-15 20:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4713B2A1.4000503@pobox.com>
On Mon, 2007-10-15 at 14:34 -0400, Jeff Garzik wrote:
> Michael Ellerman wrote:
> > Now that dcr_host_t contains the base address, we can use that in the
> > ibm_newemac code, rather than storing it separately.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > ---
> > drivers/net/ibm_newemac/mal.c | 9 +++++----
> > drivers/net/ibm_newemac/mal.h | 5 ++---
> > 2 files changed, 7 insertions(+), 7 deletions(-)
>
> applied 1-5
Those patches have been around for some time now, they didn't make
paulus initial merge for reasons I'm not sure about but I think they
should go into 2.6.24. Now the question is via Jeff or via Paulus ? :-)
Ben.
^ permalink raw reply
* Re: [PATCH v2 4/7] bestcomm: core bestcomm support for Freescale MPC5200
From: Matt Sealey @ 2007-10-15 20:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, domen.puncer
In-Reply-To: <4713D35A.9080200@genesi-usa.com>
Matt Sealey wrote:
> call a PSC, we wouldn't be making structures called mpc52xx_programmable_serial_controller,
> that's redundant, I don't think calling it "bestcomm" (which is it's name) over
> "bcom" (which isn't) works to anyone's advantage here.
Disadvantage, even. Damn autocorrecting :(
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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