* Re: [RFC: PATCH 08/13] powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
From: Dave Kleikamp @ 2010-03-05 13:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Torez Smith, Hollis Blanchard
In-Reply-To: <C84D9A35-C618-47FB-A95C-73B8B940BC7C@kernel.crashing.org>
On Fri, 2010-03-05 at 03:15 -0600, Kumar Gala wrote:
> On Mar 4, 2010, at 11:06 AM, Hollis Blanchard wrote:
>
> > On Mon, Mar 1, 2010 at 11:13 AM, Dave Kleikamp <shaggy@linux.vnet.ibm.com> wrote:
> > powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
> >
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > There are still some unstable bits on the DD1 and DD1.1 cores. Don't use
> > the FPU or the tlbivax operation. Define CPU_FTR_476_DD1 and
> > CPU_FTR_476_DD1_1 for additional workarounds in later patches.
> >
> > The DD1 core requires workarounds triggered by both CPU_FTR_476_DD1
> > and CPU_FTR_476_DD1_1. the DD1.1 core only needs CPU_FTR_476_DD1_1
> > defined.
> >
> > Isn't the policy generally not to commit workarounds for
> early/errataful hardware which will not be seen in the real world?
> Otherwise, every new half-broken core could burn a bunch of feature
> bits...
> >
> > -Hollis
>
> I'm with Hollis. Cluttering the code with non-production errata could
> get very ugly as well as burning feature bits up like made.
Ben's going to make the decision on whether or not these patches should
be included into mainline. I'd be happy maintaining them separately if
not. I'm separating out the DD1 workaround from the others, since it's
less likely that one will be needed long-term.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Joakim Tjernlund @ 2010-03-05 10:40 UTC (permalink / raw)
To: hs; +Cc: Scott Wood, linuxppc-dev, Wolfgang Denk
In-Reply-To: <4B8FE00F.4030405@denx.de>
Heiko Schocher <hs@denx.de> wrote on 2010/03/04 17:30:07:
>
> Hello Joakim,
>
> Joakim Tjernlund wrote:
> > Wolfgang Denk <wd@denx.de> wrote on 2010/03/04 13:16:56:
> >> From: Wolfgang Denk <wd@denx.de>
> >> To: hs@denx.de
> >> Cc: Joakim Tjernlund <joakim.tjernlund@transmode.se>, Klaus-J=FCrg=
en
> >> <heydeck@kieback-peter.de>, linuxppc-dev@ozlabs.org, Scott Wood
> >> <scottwood@freescale.com>
> >> Date: 2010/03/04 13:17
> >> Subject: Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
> >>
> >> Dear Heiko,
> >>
> >> thanks for running the tests.
> >>
> >> In message <4B8F8BB4.6070201@denx.de> you wrote:
> >>> here the results:
> >>>
> >>> run version
> >>>
> >>> 1-4 2.6.33-rc6 without your patches
> >>> 5-8 2.6.33-rc6 with all your patches
> >>> 9-12 2.6.33-rc6 with patches 1,2 and 4 (without 8xx: Don't touc=
h ACCESSED
> >> when no SWAP)
> >>> 13-16 2.6.33-rc6 with all your patches and CONFIG_PIN_TLB=3Dy
> >> So CONFIG_PIN_TLB imroves the performance as expected, while the o=
ther
> >> patches don;t show any measurable improvememt - or am I reading th=
e
> >> results incorrectly?
> >
> > Close but not quite. What stands out most is:
> >
> > Memory latencies in nanoseconds - smaller is better
> > (WARNING - may not be correct, check graphs)
> > -------------------------------------------------------------------=
-----------
> > Host OS Mhz L1 $ L2 $ Main mem Rand mem=
Guesses
> > --------- ------------- --- ---- ---- -------- --------=
-------
> > tqm8xx Linux 2.6.33- 66 31.8 141.0 184.0 1165.7=
> > tqm8xx Linux 2.6.33- 66 31.8 141.2 184.2 1165.3=
> > tqm8xx Linux 2.6.33- 66 31.8 141.3 184.3 1165.6=
> > tqm8xx Linux 2.6.33- 66 31.8 141.3 184.2 1166.2=
> >
> > tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1100.5=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1102.5=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.7=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.6=
No L2 cache?
> >
> > tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.1=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.0=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.7=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.2=
No L2 cache?
> >
> > tqm8xx Linux 2.6.33- 66 31.8 171.1 171.7 1099.8=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.8 171.1 171.6 1100.5=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.7 171.0 171.7 1101.0=
No L2 cache?
> > tqm8xx Linux 2.6.33- 66 31.8 171.0 171.6 1101.3=
No L2 cache?
> >
> >
> > Besides the numbers, note how the first group doesn't have a Guesse=
s entry.
> > Is there something odd with the results for the first group?
>
> Hmm.. just to be safe, I made this test again, but it shows also no e=
ntry in
> "Guesses" ... Hardware, Linux Source, rootFS, lmbench sources, all th=
e
> same ...
OK
>
> > Also, since you are using MODULES, patch 2 is nullified.
> > Patch 1 is very minor and should not show I think.
> > This leaves patches 3 & 4.
> > There appears to be something funny with patch 3,Don't touch ACCESS=
ED when no SWAP, as
> > it yields bad numbers for Prot Fault so perhaps I am missing someth=
ing that
> needs ACCESSED
> > even if NO_SWAP. Perhaps a someone that knows MM in Linux knows?
> > Is there any messages in the kernel log(dmesg)?
>
> I couldn;t find something in the output with dmesg ... but if you
> want this output, I can send it to you.
No, if you can't find anything in there, I won't either.
What would be interesting is to skip patch 3 and turn off
MODULES add PIN_TLB and compare that against your unpatched .33 but
with MODULES off and PIN_TLB on
Jocke=
^ permalink raw reply
* Re: JFFS2 warnings
From: Vijay Nikam @ 2010-03-05 10:06 UTC (permalink / raw)
To: Ron Madrid; +Cc: linuxppc-dev
In-Reply-To: <248783.45498.qm@web83507.mail.sp1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Hello,
I too facing the same problems. I too have mpc8313 based customized board.
Would you please let me know, if you know how to resolve these messages.
Kindly please acknowledge, thank you
Kind Regards,
Vijay Nikam
On Tue, Mar 2, 2010 at 12:13 AM, Ron Madrid <ron_madrid@sbcglobal.net>wrote:
> I'm getting a bunch of these after I 'reboot' or 'poweroff'
> several times.
>
> Empty flash at 0x0056205c ends at 0x00562800
> Empty flash at 0x00565334 ends at 0x00565800
> Empty flash at 0x00576104 ends at 0x00576800
>
> JFFS2 notice: (848) check_node_data: wrong data CRC
> in data node at 0x00577034: read 0xe6adad18, calculated
> 0x202a305c.
> JFFS2 notice: (848) check_node_data: wrong data CRC
> in data node at 0x00575768: read 0xe6adad18, calculated
> 0xfc64f8a3.
>
> I'm not too sure why I'm getting these, but recently
> they seem to have caused a few problems with parts of
> my filesystem (i.e. programs not running correctly).
>
> Can someone tell me what these are or what could be
> causing them?
>
> I'm using 2.6.33rc1 and this is on an mpc8313 based board.
> Not sure what other info would be useful.
>
> Thanks,
>
> Ron
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 1873 bytes --]
^ permalink raw reply
* Re: Strange OOPS in 2.6.33
From: Joakim Tjernlund @ 2010-03-05 9:58 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <OFCCEB0071.2A524538-ONC12576DC.00390771-C12576DC.0039ACAE@transmode.se>
>
>
> Got this OOPS a few times after coldstarting out
> board a few times:
>
> Unable to handle kernel paging request for unknown fault
> Faulting instruction address: 0xc020e2b4
> Oops: Kernel access of bad area, sig: 11 [#1]
> TMCUTU
> Modules linked in:
> NIP: c020e2b4 LR: c020e274 CTR: 00000000
> REGS: c7a41b40 TRAP: 0600 Not tainted (2.6.33)
> MSR: 00009032 <EE,ME,IR,DR> CR: 28002424 XER: 00000000
> DAR: 09f52312, DSISR: 00000120
> TASK = c7889940[420] 'syslogd' THREAD: c7a40000
> GPR00: 09f52312 c7a41bf0 c7889940 00000000 00000002 c7a41c40 c02734ac c78acc68
> GPR08: c7a41c00 c78acc00 00000000 09f5214b c796e3d4 1001f444 00000000 bfe78700
> GPR16: bfe77400 bfe77ee0 bfe773f8 00000021 0ffef130 00000000 c7a41df0 00000000
> GPR24: 00000000 c7a41cf0 c7a41c70 00000011 7f000001 09f5214a c034a5cc c7a41c00
> NIP [c020e2b4] ip_dev_find+0x90/0xf0
> LR [c020e274] ip_dev_find+0x50/0xf0
> Call Trace:
> [c7a41bf0] [c020e274] ip_dev_find+0x50/0xf0 (unreliable)
> [c7a41c60] [c01dd86c] __ip_route_output_key+0x8d4/0xb00
> [c7a41d50] [c01ddab8] ip_route_output_flow+0x1c/0xa0
> [c7a41d60] [c01ff8a0] ip4_datagram_connect+0x17c/0x2b8
> [c7a41e30] [c020a75c] inet_dgram_connect+0x5c/0xa8
> [c7a41e50] [c01a5030] sys_connect+0x7c/0xcc
> [c7a41f00] [c01a6008] sys_socketcall+0x128/0x214
> [c7a41f40] [c0011800] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff6e004
> LR = 0xfe2dac0
> Instruction dump:
> bb810060 38210070 7c0803a6 4e800020 88010052 2f800002 409e0028 81210054
> 83a90068 2f9d0000 419e0018 381d01c8 <7d200028> 31290001 7d20012d 40a2fff4
> ---[ end trace 0824e85bac28e7e4 ]---
>
> gdb says:
> (gdb) list *0xc020e2b4
> 0xc020e2b4 is in ip_dev_find (/usr/local/src/BUILD/trunk/os2kernel/arch/
> powerpc/include/asm/atomic.h:106).
> 101
> 102 static __inline__ void atomic_inc(atomic_t *v)
> 103 {
> 104 int t;
> 105
> 106 __asm__ __volatile__(
> 107 "1: lwarx %0,0,%2 # atomic_inc\n\
> 108 addic %0,%0,1\n"
> 109 PPC405_ERR77(0,%2)
> 110 " stwcx. %0,0,%2 \n\
>
> gdb) disass 0xc020e2b4 0xc020e2c4
> Dump of assembler code from 0xc020e2b4 to 0xc020e2c4:
> 0xc020e2b4 <ip_dev_find+144>: lwarx r9,0,r0
> 0xc020e2b8 <ip_dev_find+148>: addic r9,r9,1
> 0xc020e2bc <ip_dev_find+152>: stwcx. r9,0,r0
> 0xc020e2c0 <ip_dev_find+156>: bne- 0xc020e2b4 <ip_dev_find+144>
>
> This is on a MPC8321 CPU
> gcc 3.4.6
>
> Any ideas?
Got a bit further, turn out that the dev ptr returned from
dev = FIB_RES_DEV(res) is bogus in ip_dev_find:
struct net_device * ip_dev_find(struct net *net, __be32 addr)
{
struct flowi fl = { .nl_u = { .ip4_u = { .daddr = addr } } };
struct fib_result res;
struct net_device *dev = NULL;
struct fib_table *local_table;
#ifdef CONFIG_IP_MULTIPLE_TABLES
res.r = NULL;
#endif
local_table = fib_get_table(net, RT_TABLE_LOCAL);
if (!local_table || fib_table_lookup(local_table, &fl, &res))
return NULL;
if (res.type != RTN_LOCAL)
goto out;
dev = FIB_RES_DEV(res);
if (dev)
dev_hold(dev);
out:
fib_res_put(&res);
return dev;
}
I have no idea how to proceed from here. Problem happens when user space
makes its first access to eth0, in this case ntpdate. It is very hard to repeat
the problem so it feels like a race somewhere in interface bringup
Jocke
^ permalink raw reply
* Re: [RFC: PATCH 08/13] powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
From: Kumar Gala @ 2010-03-05 9:15 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list, Torez Smith, Dave Kleikamp
In-Reply-To: <fb412d761003040906i57842fc3t48693d5e5e777176@mail.gmail.com>
On Mar 4, 2010, at 11:06 AM, Hollis Blanchard wrote:
> On Mon, Mar 1, 2010 at 11:13 AM, Dave Kleikamp =
<shaggy@linux.vnet.ibm.com> wrote:
> powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
>=20
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>=20
> There are still some unstable bits on the DD1 and DD1.1 cores. Don't =
use
> the FPU or the tlbivax operation. Define CPU_FTR_476_DD1 and
> CPU_FTR_476_DD1_1 for additional workarounds in later patches.
>=20
> The DD1 core requires workarounds triggered by both CPU_FTR_476_DD1
> and CPU_FTR_476_DD1_1. the DD1.1 core only needs CPU_FTR_476_DD1_1
> defined.
>=20
> Isn't the policy generally not to commit workarounds for =
early/errataful hardware which will not be seen in the real world? =
Otherwise, every new half-broken core could burn a bunch of feature =
bits...
>=20
> -Hollis
I'm with Hollis. Cluttering the code with non-production errata could =
get very ugly as well as burning feature bits up like made.
- k=
^ permalink raw reply
* [PATCH V2] powerpc/mpc512x: Add gpio driver
From: Matthias Fuchs @ 2010-03-05 8:29 UTC (permalink / raw)
To: linuxppc-dev
This patch adds a gpio driver for MPC512X PowerPCs.
It has been tested on our CAN-CBX-CPU5201 module that
uses a MPC5121 CPU. This platform comes with a couple of
LEDs and configuration switches that have been used for testing.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
---
v2: - move driver to arch/powerpc/platforms/512x directory
- Kconfig changes are now in arch/powerpc/platform/512x/Kconfig
- put struct mpc512x_gpio_regs in driver's .c file
- rename GPIO_MASK into MPC512x_GPIO_MASK
- use shadow registers instead of r/m/w-operations
- don't use arch_initcall but call mpc512x_add_gpiochips()
from mpc512x platform setup code.
arch/powerpc/platforms/512x/Kconfig | 9 ++
arch/powerpc/platforms/512x/Makefile | 1 +
arch/powerpc/platforms/512x/mpc512x.h | 3 +
arch/powerpc/platforms/512x/mpc512x_gpio.c | 198 ++++++++++++++++++++++++++
arch/powerpc/platforms/512x/mpc512x_shared.c | 3 +
5 files changed, 214 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/mpc512x_gpio.c
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index 4dac9b0..840c6b4 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -10,6 +10,15 @@ config PPC_MPC5121
bool
select PPC_MPC512x
+config MPC512x_GPIO
+ bool "MPC512x GPIO support"
+ depends on PPC_MPC512x
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ MPC512x GPIOs.
+
config MPC5121_ADS
bool "Freescale MPC5121E ADS"
depends on 6xx
diff --git a/arch/powerpc/platforms/512x/Makefile b/arch/powerpc/platforms/512x/Makefile
index 90be2f5..12518e3 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -4,3 +4,4 @@
obj-y += clock.o mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC5121_GENERIC) += mpc5121_generic.o
+obj-$(CONFIG_MPC512x_GPIO) += mpc512x_gpio.o
diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platforms/512x/mpc512x.h
index b2daca0..4c67990 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -16,4 +16,7 @@ extern void __init mpc512x_init(void);
extern int __init mpc5121_clk_init(void);
void __init mpc512x_declare_of_platform_devices(void);
extern void mpc512x_restart(char *cmd);
+#ifdef CONFIG_MPC512x_GPIO
+extern int __init mpc512x_add_gpiochips(void);
+#endif
#endif /* __MPC512X_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_gpio.c b/arch/powerpc/platforms/512x/mpc512x_gpio.c
new file mode 100644
index 0000000..fc6ad82
--- /dev/null
+++ b/arch/powerpc/platforms/512x/mpc512x_gpio.c
@@ -0,0 +1,198 @@
+/*
+ * MPC512x gpio driver
+ *
+ * Copyright (c) 2010 Matthias Fuchs <matthias.fuchs@esd.eu>, esd gmbh
+ *
+ * derived from ppc4xx gpio driver
+ *
+ * Copyright (c) 2008 Harris Corporation
+ * Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Steve Falco <sfalco@harris.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio.h>
+#include <linux/types.h>
+
+#define MPC512x_GPIO_MASK(gpio) (0x80000000 >> (gpio))
+
+struct mpc512x_gpio_regs {
+ u32 gpdir;
+ u32 gpodr;
+ u32 gpdat;
+ u32 gpier;
+ u32 gpimr;
+ u32 gpicr1;
+ u32 gpicr2;
+};
+
+struct mpc512x_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadow registers */
+ u32 dat;
+ u32 odr;
+ u32 dir;
+};
+
+/*
+ * GPIO LIB API implementation for GPIOs
+ *
+ * There are a maximum of 32 gpios in each gpio controller.
+ */
+static inline struct mpc512x_chip *
+to_mpc512x_gpiochip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct mpc512x_chip, mm_gc);
+}
+
+static int mpc512x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+
+ return in_be32(®s->gpdat) & MPC512x_GPIO_MASK(gpio);
+}
+
+static inline void
+__mpc512x_gpio_set(struct of_mm_gpio_chip *mm_gc, unsigned int gpio, int val)
+{
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+
+
+ if (val)
+ chip->dat |= MPC512x_GPIO_MASK(gpio);
+ else
+ chip->dat &= ~MPC512x_GPIO_MASK(gpio);
+
+ out_be32(®s->gpdat, chip->dat);
+}
+
+static void
+mpc512x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ __mpc512x_gpio_set(mm_gc, gpio, val);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+}
+
+static int mpc512x_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ /* Disable open-drain function */
+ chip->odr &= ~MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpodr, chip->odr);
+
+ /* Float the pin */
+ chip->dir &= ~MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpdir, chip->dir);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ return 0;
+}
+
+static int
+mpc512x_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct mpc512x_chip *chip = to_mpc512x_gpiochip(mm_gc);
+ struct mpc512x_gpio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&chip->lock, flags);
+
+ /* First set initial value */
+ __mpc512x_gpio_set(mm_gc, gpio, val);
+
+ /* Disable open-drain function */
+ chip->odr &= ~MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpodr, chip->odr);
+
+ /* Drive the pin */
+ chip->dir |= MPC512x_GPIO_MASK(gpio);
+ out_be32(®s->gpdir, chip->dir);
+
+ spin_unlock_irqrestore(&chip->lock, flags);
+
+ pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+void __init mpc512x_add_gpiochips(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,mpc5121-gpio") {
+ int ret;
+ struct mpc512x_chip *chip;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ chip = kzalloc(sizeof(*chip), GFP_KERNEL);
+ if (!chip) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ spin_lock_init(&chip->lock);
+
+ mm_gc = &chip->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ gc->ngpio = 32;
+ gc->direction_input = mpc512x_gpio_dir_in;
+ gc->direction_output = mpc512x_gpio_dir_out;
+ gc->get = mpc512x_gpio_get;
+ gc->set = mpc512x_gpio_set;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+ continue;
+err:
+ pr_err("%s: registration failed with status %d\n",
+ np->full_name, ret);
+ kfree(chip);
+ /* try others anyway */
+ }
+}
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index b7f518a..42320ab 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -100,4 +100,7 @@ void __init mpc512x_init(void)
mpc512x_declare_of_platform_devices();
mpc5121_clk_init();
mpc512x_restart_init();
+#ifdef CONFIG_MPC512x_GPIO
+ mpc512x_add_gpiochips();
+#endif
}
--
1.6.1
^ permalink raw reply related
* Re: [PATCH 7/7] powerpc/85xx: Fix the RapidIO maintenance access functions
From: tmo @ 2010-03-05 6:00 UTC (permalink / raw)
To: Micha Nelissen
Cc: Bounine, Alexandre, Alexandre Bounine, linuxppc-dev, thomas.moll
In-Reply-To: <4B86CD7C.6070201@neli.hopto.org>
Quoting "Micha Nelissen" <micha@neli.hopto.org>:
> Bounine, Alexandre wrote:
>> Hi Micha,
>>
>> I tested it on my setup - it works.
>> Maybe Thomas may give more details on this change.
>
> Did you (for fun) try once to decrease the maintenance window to =20
> say, 4 kB? Then you really need these "high" bits to work properly.
We have never changed the configuration of the window size in Linux, =20
but we have an test application that uses these 4kb window setting.
With the current window configuration in Linux, I expect problems when =20
someone tries to read a register that is located at offset > 512KB. I =20
have currently no equipment to verify this behaviour.
>
> Or did you try with some register at offset > 4MB? The Tundra's have =20
> registers going up to 0x14000 or so? So don't need 16MB addressing =20
> for that.
We have devices that requires access to registers that are located at =20
offset > 15MB.
>
> Thanks, Micha
>
>
>>> -----Original Message-----
>>> From: Micha Nelissen [mailto:micha@neli.hopto.org]
>>> Sent: Wednesday, February 24, 2010 3:21 PM
>>> To: Alexandre Bounine
>>> Subject: Re: [PATCH 7/7] powerpc/85xx: Fix the RapidIO maintenance
>> access functions
>>> Alexandre Bounine wrote:
>>>> =09out_be32(&priv->maint_atmu_regs->rowtar,
>>>> -=09=09 (destid << 22) | (hopcount << 12) | ((offset & ~0x3) >>
>> 9));
>>>> +=09=09 (destid << 22) | (hopcount << 12) | (offset >> 12));
>>>> +=09out_be32(&priv->maint_atmu_regs->rowtear, (destid >> 10));
>>> Did this actually work for you? The (offset >> 12) is due to the 4MB
>>> window size right?
>>>
>>> Micha
>>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] perf_event: e500 support
From: Paul Mackerras @ 2010-03-05 0:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <42FC542D-2B8A-4AB6-866D-9CBCCE62C3CC@kernel.crashing.org>
On Thu, Mar 04, 2010 at 10:48:03AM -0600, Kumar Gala wrote:
> Paul do you intend to Ack this or don't care?
Sorry, thought I had.
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Michael Neuling @ 2010-03-04 22:28 UTC (permalink / raw)
To: Peter Zijlstra
Cc: ego, linux-kernel, Christopher Yeoh, Ingo Molnar, linuxppc-dev
In-Reply-To: <1267541076.25158.60.camel@laptop>
In message <1267541076.25158.60.camel@laptop> you wrote:
> On Sat, 2010-02-27 at 21:21 +1100, Michael Neuling wrote:
> > In message <11927.1267010024@neuling.org> you wrote:
> > > > > If there's less the group will normally be balanced and we fall out a
nd
> > > > > end up in check_asym_packing().
> > > > >
> > > > > So what I tried doing with that loop is detect if there's a hole in t
he
> > > > > packing before busiest. Now that I think about it, what we need to ch
eck
> > > > > is if this_cpu (the removed cpu argument) is idle and less than busie
st.
> > > > >
> > > > > So something like:
> > > > >
> > > > > static int check_asym_pacing(struct sched_domain *sd,
> > > > > struct sd_lb_stats *sds,
> > > > > int this_cpu, unsigned long *imbalance)
> > > > > {
> > > > > int busiest_cpu;
> > > > >
> > > > > if (!(sd->flags & SD_ASYM_PACKING))
> > > > > return 0;
> > > > >
> > > > > if (!sds->busiest)
> > > > > return 0;
> > > > >
> > > > > busiest_cpu = group_first_cpu(sds->busiest);
> > > > > if (cpu_rq(this_cpu)->nr_running || this_cpu > busiest_cpu)
> > > > > return 0;
> > > > >
> > > > > *imbalance = (sds->max_load * sds->busiest->cpu_power) /
> > > > > SCHED_LOAD_SCALE;
> > > > > return 1;
> > > > > }
> > > > >
> > > > > Does that make sense?
> > > >
> > > > I think so.
> > > >
> > > > I'm seeing check_asym_packing do the right thing with the simple SMT2
> > > > with 1 process case. It marks cpu0 as imbalanced when cpu0 is idle and
> > > > cpu1 is busy.
> > > >
> > > > Unfortunately the process doesn't seem to be get migrated down though.
> > > > Do we need to give *imbalance a higher value?
> > >
> > > So with ego help, I traced this down a bit more.
> > >
> > > In my simple test case (SMT2, t0 idle, t1 active) if f_b_g() hits our
> > > new case in check_asym_packing(), load_balance then runs f_b_q().
> > > f_b_q() has this:
> > >
> > > if (capacity && rq->nr_running == 1 && wl > imbalance)
> > > continue;
> > >
> > > when check_asym_packing() hits, wl = 1783 and imbalance = 1024, so we
> > > continue and busiest remains NULL.
> > >
> > > load_balance then does "goto out_balanced" and it doesn't attempt to
> > > move the task.
> > >
> > > Based on this and on egos suggestion I pulled in Suresh Siddha patch
> > > from: http://lkml.org/lkml/2010/2/12/352. This fixes the problem. The
> > > process is moved down to t0.
> > >
> > > I've only tested SMT2 so far.
> >
> > I'm finding this SMT2 result to be unreliable. Sometimes it doesn't work
> > for the simple 1 process case. It seems to change boot to boot.
> > Sometimes it works as expected with t0 busy and t1 idle, but other times
> > it's the other way around.
> >
> > When it doesn't work, check_asym_packing() is still marking processes to
> > be pulled down but only gets run about 1 in every 4 calls to
> > load_balance().
> >
> > For 2 of the other calls to load_balance, idle is CPU_NEWLY_IDLE and
> > hence check_asym_packing() doesn't get called. This results in
> > sd->nr_balance_failed being reset. When load_balance is next called and
> > check_asym_packing() hits, need_active_balance() returns 0 as
> > sd->nr_balance_failed is too small. This means the migration thread on
> > t1 is not woken and the process remains there.
> >
> > So why does thread0 change from NEWLY_IDLE to IDLE and visa versa, when
> > there is nothing running on it? Is this expected?
>
> Ah, yes, you should probably allow both those.
>
> NEWLY_IDLE is when we are about to schedule the idle thread, IDLE is
> when a tick hits the idle thread.
>
> I'm thinking that NEWLY_IDLE should also solve the NO_HZ case, since
> we'll have passed through that before we enter tickless state, just make
> sure SD_BALANCE_NEWIDLE is set on the relevant levels (should already be
> so).
OK, thanks.
There seems to be a regression in Linus' latest tree (also -next) where
new processes usually end up on the thread 1 rather than 0 (when in SMT2
mode).
This only seems to happen with newly created processes. If you pin a
process to t0 and then unpin it, it stays on t0. Also if a process is
migrated to another core, it can end up on t0.
This happens with a vanilla linus or -next tree on ppc64
pseries_defconfig - NO_HZ. I've not tried with NO_HZ.
Anyway, this regression seems to be causing problems when we apply our
patch. We are trying to pull down to T0 which works, but we immediately
get pulled back upto t1 due to the above regression. This happens over
and over, causing process to ping-pong every few sched ticks.
We've not tried to bisect this problem but that's the next step unless
someone has some insights to the problem.
Also, we had to change the following to get the pull down to work
correctly in the original patch:
@@ -2618,8 +2618,8 @@ static int check_asym_packing(struct sch
if (this_cpu > busiest_cpu)
return 0;
- *imbalance = (sds->max_load * sds->busiest->cpu_power) /
- SCHED_LOAD_SCALE;
+ *imbalance = DIV_ROUND_CLOSEST(sds->max_load * sds->busiest->cpu_power,
+ SCHED_LOAD_SCALE);
return 1;
We found that imbalance = 1023.8 which got rounded down to 1023 which
ended up being compared to a wl of 1024 in find_busiest_queue and
failing. The closest round fixes this.
Mikey
^ permalink raw reply
* [Patch v.3] mpc5200b/uart: improve baud rate calculation (reach high baud rates, better accuracy)
From: Albrecht Dreß @ 2010-03-04 19:00 UTC (permalink / raw)
To: Linux PPC Development, Likely, Grant
On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general. This is done by
selecting the appropriate prescaler (/4 or /32). As to keep the code clean=
,
the getuartclk method has been dropped, and all calculations are done in a
new set_baudrate method.
Notes: only "fsl,mpc5200b-psc-uart" compatible devices benefit from these
improvements.
The 512x may or may not work; the patch keeps the current implementation
(using a /16 prescaler), but according to the data sheet, this is plain
wrong. See the comment in mpc512x_psc_set_baudrate(). Any insight and
testing of the code would be appreciated.
Tested on a custom 5200B based board, from 110 baud up to 3 MBaud, and with
both "fsl,mpc5200b-psc-uart" and "fsl,mpc5200-psc-uart" devices.
Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
---
Changes vs. v.2: Pick up Grant's comments by shifting the calculations to t=
he
new set_baudrate method.
--- linux-2.6.33-orig/drivers/serial/mpc52xx_uart.c 2010-02-24 19:52:17.000=
000000 +0100
+++ linux-2.6.33/drivers/serial/mpc52xx_uart.c 2010-03-04 17:13:47.00000000=
0 +0100
@@ -144,9 +144,21 @@ struct psc_ops {
unsigned char (*read_char)(struct uart_port *port);
void (*cw_disable_ints)(struct uart_port *port);
void (*cw_restore_ints)(struct uart_port *port);
- unsigned long (*getuartclk)(void *p);
+ unsigned int (*set_baudrate)(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old);
};
=20
+/* setting the prescaler and divisor reg is common for all chips */
+static inline void mpc52xx_set_divisor(struct mpc52xx_psc __iomem *psc,
+ u16 prescaler, unsigned int divisor)
+{
+ /* select prescaler */
+ out_be16(&psc->mpc52xx_psc_clock_select, prescaler);
+ out_8(&psc->ctur, divisor >> 8);
+ out_8(&psc->ctlr, divisor & 0xff);
+}
+
#ifdef CONFIG_PPC_MPC52xx
#define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
static void mpc52xx_psc_fifo_init(struct uart_port *port)
@@ -154,9 +166,6 @@ static void mpc52xx_psc_fifo_init(struct
struct mpc52xx_psc __iomem *psc =3D PSC(port);
struct mpc52xx_psc_fifo __iomem *fifo =3D FIFO_52xx(port);
=20
- /* /32 prescaler */
- out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00);
-
out_8(&fifo->rfcntl, 0x00);
out_be16(&fifo->rfalarm, 0x1ff);
out_8(&fifo->tfcntl, 0x07);
@@ -245,15 +254,47 @@ static void mpc52xx_psc_cw_restore_ints(
out_be16(&PSC(port)->mpc52xx_psc_imr, port->read_status_mask);
}
=20
-/* Search for bus-frequency property in this node or a parent */
-static unsigned long mpc52xx_getuartclk(void *p)
-{
- /*
- * 5200 UARTs have a / 32 prescaler
- * but the generic serial code assumes 16
- * so return ipb freq / 2
- */
- return mpc5xxx_get_bus_frequency(p) / 2;
+static unsigned int mpc5200_psc_set_baudrate(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ unsigned int divisor;
+
+ /* The 5200 has a fixed /32 prescaler, uartclk contains the ipb freq */
+ baud =3D uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0xffff) + 1,
+ port->uartclk / 32);
+ divisor =3D (port->uartclk + 16 * baud) / (32 * baud);
+
+ /* enable the /32 prescaler and set the divisor */
+ mpc52xx_set_divisor(PSC(port), 0xdd00, divisor);
+ return baud;
+}
+
+static unsigned int mpc5200b_psc_set_baudrate(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ unsigned int divisor;
+ u16 prescaler;
+
+ /* The 5200B has a selectable /4 or /32 prescaler, uartclk contains the
+ * ipb freq */
+ baud =3D uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0xffff) + 1,
+ port->uartclk / 4);
+ divisor =3D (port->uartclk + 2 * baud) / (4 * baud);
+
+ /* select the proper prescaler and set the divisor */
+ if (divisor > 0xffff) {
+ divisor =3D (divisor + 4) / 8;
+ prescaler =3D 0xdd00; /* /32 */
+ } else
+ prescaler =3D 0xff00; /* /4 */
+ mpc52xx_set_divisor(PSC(port), prescaler, divisor);
+ return baud;
}
=20
static struct psc_ops mpc52xx_psc_ops =3D {
@@ -272,7 +313,26 @@ static struct psc_ops mpc52xx_psc_ops =3D=20
.read_char =3D mpc52xx_psc_read_char,
.cw_disable_ints =3D mpc52xx_psc_cw_disable_ints,
.cw_restore_ints =3D mpc52xx_psc_cw_restore_ints,
- .getuartclk =3D mpc52xx_getuartclk,
+ .set_baudrate =3D mpc5200_psc_set_baudrate,
+};
+
+static struct psc_ops mpc5200b_psc_ops =3D {
+ .fifo_init =3D mpc52xx_psc_fifo_init,
+ .raw_rx_rdy =3D mpc52xx_psc_raw_rx_rdy,
+ .raw_tx_rdy =3D mpc52xx_psc_raw_tx_rdy,
+ .rx_rdy =3D mpc52xx_psc_rx_rdy,
+ .tx_rdy =3D mpc52xx_psc_tx_rdy,
+ .tx_empty =3D mpc52xx_psc_tx_empty,
+ .stop_rx =3D mpc52xx_psc_stop_rx,
+ .start_tx =3D mpc52xx_psc_start_tx,
+ .stop_tx =3D mpc52xx_psc_stop_tx,
+ .rx_clr_irq =3D mpc52xx_psc_rx_clr_irq,
+ .tx_clr_irq =3D mpc52xx_psc_tx_clr_irq,
+ .write_char =3D mpc52xx_psc_write_char,
+ .read_char =3D mpc52xx_psc_read_char,
+ .cw_disable_ints =3D mpc52xx_psc_cw_disable_ints,
+ .cw_restore_ints =3D mpc52xx_psc_cw_restore_ints,
+ .set_baudrate =3D mpc5200b_psc_set_baudrate,
};
=20
#endif /* CONFIG_MPC52xx */
@@ -388,9 +448,44 @@ static void mpc512x_psc_cw_restore_ints(
out_be32(&FIFO_512x(port)->rximr, port->read_status_mask & 0x7f);
}
=20
-static unsigned long mpc512x_getuartclk(void *p)
+static unsigned int mpc512x_psc_set_baudrate(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old)
{
- return mpc5xxx_get_bus_frequency(p);
+ unsigned int baud;
+ unsigned int divisor;
+
+ /*
+ * FIXME -
+ * since ages, the code calculates with a /16 prescaler, but
+ * never configures it explicitly. The "MPC5121e Microcontroller
+ * Reference Manual, Rev. 3" says on pg. 30-10 that the chip supports a
+ * /32 and a /10 prescaler. Furthermore, it states that "After reset,
+ * the prescaler by 10 for the UART mode is selected", but the reset
+ * register value is 0x0000 which means a /32 prescaler...
+ *
+ * Thus, using /16 for the calculation might actually be wrong.
+ *
+ * However, U-Boot (in the file cpu/mpc512x/serial.c) also uses a /16
+ * prescaler, activated by 0xdd00 in the csr.
+ *
+ * **Confusion Alert**
+ *
+ * Unfortunately, I don't have a 512x system, so I cannot say what
+ * happens in reality...
+ *
+ * Albrecht Dre=DF <albrecht.dress@arcor.de>, 2010-MAR-04
+ */
+
+ /* uartclk contains the ips freq */
+ baud =3D uart_get_baud_rate(port, new, old,
+ port->uartclk / (16 * 0xffff) + 1,
+ port->uartclk / 16);
+ divisor =3D (port->uartclk + 8 * baud) / (16 * baud);
+
+ /* FIXME - see above, shamelessly stolen from U-Boot */
+ mpc52xx_set_divisor(PSC(port), 0xdd00, divisor);
+ return baud;
}
=20
static struct psc_ops mpc512x_psc_ops =3D {
@@ -409,7 +504,7 @@ static struct psc_ops mpc512x_psc_ops =3D=20
.read_char =3D mpc512x_psc_read_char,
.cw_disable_ints =3D mpc512x_psc_cw_disable_ints,
.cw_restore_ints =3D mpc512x_psc_cw_restore_ints,
- .getuartclk =3D mpc512x_getuartclk,
+ .set_baudrate =3D mpc512x_psc_set_baudrate,
};
#endif
=20
@@ -564,8 +659,8 @@ mpc52xx_uart_set_termios(struct uart_por
struct mpc52xx_psc __iomem *psc =3D PSC(port);
unsigned long flags;
unsigned char mr1, mr2;
- unsigned short ctr;
- unsigned int j, baud, quot;
+ unsigned int j;
+ unsigned int baud;
=20
/* Prepare what we're gonna write */
mr1 =3D 0;
@@ -602,16 +697,9 @@ mpc52xx_uart_set_termios(struct uart_por
mr2 |=3D MPC52xx_PSC_MODE_TXCTS;
}
=20
- baud =3D uart_get_baud_rate(port, new, old, 0, port->uartclk/16);
- quot =3D uart_get_divisor(port, baud);
- ctr =3D quot & 0xffff;
-
/* Get the lock */
spin_lock_irqsave(&port->lock, flags);
=20
- /* Update the per-port timeout */
- uart_update_timeout(port, new->c_cflag, baud);
-
/* Do our best to flush TX & RX, so we don't lose anything */
/* But we don't wait indefinitely ! */
j =3D 5000000; /* Maximum wait */
@@ -635,8 +723,10 @@ mpc52xx_uart_set_termios(struct uart_por
out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
out_8(&psc->mode, mr1);
out_8(&psc->mode, mr2);
- out_8(&psc->ctur, ctr >> 8);
- out_8(&psc->ctlr, ctr & 0xff);
+ baud =3D psc_ops->set_baudrate(port, new, old);
+
+ /* Update the per-port timeout */
+ uart_update_timeout(port, new->c_cflag, baud);
=20
if (UART_ENABLE_MS(port, new->c_cflag))
mpc52xx_uart_enable_ms(port);
@@ -1007,7 +1097,7 @@ mpc52xx_console_setup(struct console *co
return ret;
}
=20
- uartclk =3D psc_ops->getuartclk(np);
+ uartclk =3D mpc5xxx_get_bus_frequency(np);
if (uartclk =3D=3D 0) {
pr_debug("Could not find uart clock frequency!\n");
return -EINVAL;
@@ -1090,6 +1180,7 @@ static struct uart_driver mpc52xx_uart_d
=20
static struct of_device_id mpc52xx_uart_of_match[] =3D {
#ifdef CONFIG_PPC_MPC52xx
+ { .compatible =3D "fsl,mpc5200b-psc-uart", .data =3D &mpc5200b_psc_ops, }=
,
{ .compatible =3D "fsl,mpc5200-psc-uart", .data =3D &mpc52xx_psc_ops, },
/* binding used by old lite5200 device trees: */
{ .compatible =3D "mpc5200-psc-uart", .data =3D &mpc52xx_psc_ops, },
@@ -1122,7 +1213,10 @@ mpc52xx_uart_of_probe(struct of_device *
pr_debug("Found %s assigned to ttyPSC%x\n",
mpc52xx_uart_nodes[idx]->full_name, idx);
=20
- uartclk =3D psc_ops->getuartclk(op->node);
+ /* set the uart clock to the input clock of the psc, the different
+ * prescalers are taken into account in the set_baudrate() methods
+ * of the respective chip */
+ uartclk =3D mpc5xxx_get_bus_frequency(op->node);
if (uartclk =3D=3D 0) {
dev_dbg(&op->dev, "Could not find uart clock frequency!\n");
return -EINVAL;
^ permalink raw reply
* Re: [RFC: PATCH 08/13] powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
From: Hollis Blanchard @ 2010-03-04 17:06 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev list, Torez Smith
In-Reply-To: <20100301191351.20987.49730.sendpatchset@norville.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
On Mon, Mar 1, 2010 at 11:13 AM, Dave Kleikamp <shaggy@linux.vnet.ibm.com>wrote:
> powerpc/476: define specific cpu table entry for DD1 and DD1.1 cores
>
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> There are still some unstable bits on the DD1 and DD1.1 cores. Don't use
> the FPU or the tlbivax operation. Define CPU_FTR_476_DD1 and
> CPU_FTR_476_DD1_1 for additional workarounds in later patches.
>
> The DD1 core requires workarounds triggered by both CPU_FTR_476_DD1
> and CPU_FTR_476_DD1_1. the DD1.1 core only needs CPU_FTR_476_DD1_1
> defined.
>
> Isn't the policy generally not to commit workarounds for early/errataful
hardware which will not be seen in the real world? Otherwise, every new
half-broken core could burn a bunch of feature bits...
-Hollis
[-- Attachment #2: Type: text/html, Size: 1162 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/booke: Fix a couple typos in the advanced ptrace code
From: Kumar Gala @ 2010-03-04 16:52 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linuxppc-dev list
In-Reply-To: <1266954197.11207.20.camel@norville.austin.ibm.com>
On Feb 23, 2010, at 1:43 PM, Dave Kleikamp wrote:
> powerpc/booke: Fix a couple typos in the advanced ptrace code
>
> Found and fixed a couple typos in the advanced ptrace patches.
> (These patches are currently in benh's next tree.)
>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: linuxppc-dev list <Linuxppc-dev@ozlabs.org>
>
> ---
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [PATCH 2/2] perf_event: e500 support
From: Kumar Gala @ 2010-03-04 16:48 UTC (permalink / raw)
To: Scott Wood; +Cc: paulus, linuxppc-dev
In-Reply-To: <20100226000945.GA17094@loki.buserror.net>
On Feb 25, 2010, at 6:09 PM, Scott Wood wrote:
> This implements perf_event support for the Freescale embedded =
performance
> monitor, based on the existing perf_event.c that supports =
server/classic
> chips.
>=20
> Some limitations:
> - Performance monitor interrupts are regular EE interrupts, and thus =
you
> can't profile places with interrupts disabled. We may want to =
implement
> soft IRQ-disabling, with perfmon interrupts exempted and treated as =
NMIs.
> - When trying to schedule multiple event groups at once, and using
> restricted events, situations could arise where scheduling fails even
> though it would be possible. Consider three groups, each with two =
events.
> One group has restricted events, the others don't. The two =
non-restricted
> groups are scheduled, then one is removed, which happens to occupy =
the two
> counters that can't do restricted events. The remaining =
non-restricted
> group will not be moved to the non-restricted-capable counters to =
make
> room if the restricted group tries to be scheduled.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Changes from previous version:
> - Factored out callchain makefile patch
> - Split up header files
> - Renamed pmu struct
> - Added threshold support
>=20
> arch/powerpc/include/asm/perf_event.h | 133 +----
> arch/powerpc/include/asm/perf_event_fsl_emb.h | 50 ++
> .../asm/{perf_event.h =3D> perf_event_server.h} | 4 +-
> arch/powerpc/include/asm/reg_fsl_emb.h | 2 +-
> arch/powerpc/kernel/Makefile | 4 +
> arch/powerpc/kernel/cputable.c | 2 +-
> arch/powerpc/kernel/e500-pmu.c | 129 ++++
> arch/powerpc/kernel/perf_event_fsl_emb.c | 654 =
++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype | 10 +
> 9 files changed, 874 insertions(+), 114 deletions(-)
> rewrite arch/powerpc/include/asm/perf_event.h (92%)
> create mode 100644 arch/powerpc/include/asm/perf_event_fsl_emb.h
> rename arch/powerpc/include/asm/{perf_event.h =3D> =
perf_event_server.h} (98%)
> create mode 100644 arch/powerpc/kernel/e500-pmu.c
> create mode 100644 arch/powerpc/kernel/perf_event_fsl_emb.c
Paul do you intend to Ack this or don't care?
- k
^ permalink raw reply
* Re: [PATCH 1/2] perf_event: Build callchain code regardless of hardware event support.
From: Kumar Gala @ 2010-03-04 16:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20100226000948.GA7706@brick.ozlabs.ibm.com>
On Feb 25, 2010, at 6:09 PM, Paul Mackerras wrote:
> On Thu, Feb 25, 2010 at 06:04:33PM -0600, Scott Wood wrote:
>> It's also useful for software events, as well as future support for
>> other types of hardware counters.
>>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> Acked-by: Paul Mackerras <paulus@samba.org>
applied to next
- k
^ permalink raw reply
* Re: [PATCH 44/66] arch/powerpc/sysdev/cpm2_pic.h: Checkpatch cleanup
From: Kumar Gala @ 2010-03-04 16:45 UTC (permalink / raw)
To: Andrea Gelmini; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1267289508-31031-45-git-send-email-andrea.gelmini@gelma.net>
On Feb 27, 2010, at 10:51 AM, Andrea Gelmini wrote:
> arch/powerpc/sysdev/cpm2_pic.h:6: ERROR: "(foo*)" should be "(foo *)"
>
> Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
> ---
> arch/powerpc/sysdev/cpm2_pic.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Renaming following split of GE Fanuc joint venture
From: Kumar Gala @ 2010-03-04 16:45 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20100301144159.23431.18196.stgit@ES-J7S4D2J.amer.consind.ge.com>
On Mar 1, 2010, at 8:41 AM, Martyn Welch wrote:
> This patch renames GE Fanuc boards following the split-up of the GE =
Fanuc joint venture. These boards are now made by GE Intelligent =
platorms.
>=20
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>=20
> arch/powerpc/boot/dts/gef_ppc9a.dts | 4 ++--
> arch/powerpc/boot/dts/gef_sbc310.dts | 4 ++--
> arch/powerpc/boot/dts/gef_sbc610.dts | 4 ++--
> arch/powerpc/platforms/86xx/Kconfig | 12 ++++++------
> arch/powerpc/platforms/86xx/gef_gpio.c | 10 +++++-----
> arch/powerpc/platforms/86xx/gef_pic.c | 6 +++---
> arch/powerpc/platforms/86xx/gef_ppc9a.c | 12 ++++++------
> arch/powerpc/platforms/86xx/gef_sbc310.c | 12 ++++++------
> arch/powerpc/platforms/86xx/gef_sbc610.c | 12 ++++++------
> 9 files changed, 38 insertions(+), 38 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] gianfar: Fix TX ring processing on SMP machines
From: Kumar Gala @ 2010-03-04 16:34 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev list, Netdev, Martyn Welch, Paul Gortmaker,
Sandeep Gopalpet, David Miller
In-Reply-To: <20100304.004157.18721737.davem@davemloft.net>
On Mar 4, 2010, at 2:41 AM, David Miller wrote:
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Date: Wed, 3 Mar 2010 21:18:58 +0300
>=20
>> Starting with commit a3bc1f11e9b867a4f49505 ("gianfar: Revive SKB
>> recycling") gianfar driver sooner or later stops transmitting any
>> packets on SMP machines.
>>=20
>> start_xmit() prepares new skb for transmitting, generally it does
>> three things:
>>=20
>> 1. sets up all BDs (marks them ready to send), except the first one.
>> 2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
>> would cleanup it later.
>> 3. sets up the first BD, i.e. marks it ready.
>>=20
>> Here is what clean_tx_ring() does:
>>=20
>> 1. reads skbs from tx_queue->tx_skbuff
>> 2. checks if the *last* BD is ready. If it's still ready [to send]
>> then it it isn't transmitted, so clean_tx_ring() returns.
>> Otherwise it actually cleanups BDs. All is OK.
>>=20
>> Now, if there is just one BD, code flow:
>>=20
>> - start_xmit(): stores skb into tx_skbuff. Note that the first BD
>> (which is also the last one) isn't marked as ready, yet.
>> - clean_tx_ring(): sees that skb is not null, *and* its lstatus
>> says that it is NOT ready (like if BD was sent), so it cleans
>> it up (bad!)
>> - start_xmit(): marks BD as ready [to send], but it's too late.
>>=20
>> We can fix this simply by reordering lstatus/tx_skbuff writes.
>>=20
>> Reported-by: Martyn Welch <martyn.welch@ge.com>
>> Bisected-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> Tested-by: Martyn Welch <martyn.welch@ge.com>
>=20
> Applied.
Anton,
Once this makes it into Linus's tree can you make sure we get it added =
to -stable.
- k=
^ permalink raw reply
* Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Heiko Schocher @ 2010-03-04 16:30 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev, Wolfgang Denk
In-Reply-To: <OF22F52BE0.FB3F104E-ONC12576DC.00469DB5-C12576DC.004808C4@transmode.se>
Hello Joakim,
Joakim Tjernlund wrote:
> Wolfgang Denk <wd@denx.de> wrote on 2010/03/04 13:16:56:
>> From: Wolfgang Denk <wd@denx.de>
>> To: hs@denx.de
>> Cc: Joakim Tjernlund <joakim.tjernlund@transmode.se>, Klaus-Jürgen
>> <heydeck@kieback-peter.de>, linuxppc-dev@ozlabs.org, Scott Wood
>> <scottwood@freescale.com>
>> Date: 2010/03/04 13:17
>> Subject: Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
>>
>> Dear Heiko,
>>
>> thanks for running the tests.
>>
>> In message <4B8F8BB4.6070201@denx.de> you wrote:
>>> here the results:
>>>
>>> run version
>>>
>>> 1-4 2.6.33-rc6 without your patches
>>> 5-8 2.6.33-rc6 with all your patches
>>> 9-12 2.6.33-rc6 with patches 1,2 and 4 (without 8xx: Don't touch ACCESSED
>> when no SWAP)
>>> 13-16 2.6.33-rc6 with all your patches and CONFIG_PIN_TLB=y
>> So CONFIG_PIN_TLB imroves the performance as expected, while the other
>> patches don;t show any measurable improvememt - or am I reading the
>> results incorrectly?
>
> Close but not quite. What stands out most is:
>
> Memory latencies in nanoseconds - smaller is better
> (WARNING - may not be correct, check graphs)
> ------------------------------------------------------------------------------
> Host OS Mhz L1 $ L2 $ Main mem Rand mem Guesses
> --------- ------------- --- ---- ---- -------- -------- -------
> tqm8xx Linux 2.6.33- 66 31.8 141.0 184.0 1165.7
> tqm8xx Linux 2.6.33- 66 31.8 141.2 184.2 1165.3
> tqm8xx Linux 2.6.33- 66 31.8 141.3 184.3 1165.6
> tqm8xx Linux 2.6.33- 66 31.8 141.3 184.2 1166.2
>
> tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1100.5 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1102.5 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.7 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.6 No L2 cache?
>
> tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.1 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.0 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.7 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.2 No L2 cache?
>
> tqm8xx Linux 2.6.33- 66 31.8 171.1 171.7 1099.8 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.8 171.1 171.6 1100.5 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.7 171.0 171.7 1101.0 No L2 cache?
> tqm8xx Linux 2.6.33- 66 31.8 171.0 171.6 1101.3 No L2 cache?
>
>
> Besides the numbers, note how the first group doesn't have a Guesses entry.
> Is there something odd with the results for the first group?
Hmm.. just to be safe, I made this test again, but it shows also no entry in
"Guesses" ... Hardware, Linux Source, rootFS, lmbench sources, all the
same ...
> Also, since you are using MODULES, patch 2 is nullified.
> Patch 1 is very minor and should not show I think.
> This leaves patches 3 & 4.
> There appears to be something funny with patch 3,Don't touch ACCESSED when no SWAP, as
> it yields bad numbers for Prot Fault so perhaps I am missing something that needs ACCESSED
> even if NO_SWAP. Perhaps a someone that knows MM in Linux knows?
> Is there any messages in the kernel log(dmesg)?
I couldn;t find something in the output with dmesg ... but if you
want this output, I can send it to you.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [Patch v.2] mpc5200b/uart: improve baud rate calculation (reach high baud rates, better accuracy)
From: Grant Likely @ 2010-03-04 13:27 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <16827431.1267696606015.JavaMail.ngmail@webmail13.arcor-online.net>
On Thu, Mar 4, 2010 at 2:56 AM, Albrecht Dre=DF <albrecht.dress@arcor.de> w=
rote:
>> That way each set_divisor() can do whatever makes the most sense for
>> the divisors available to it. =A0The 5121 for example has both a /10 and
>> a /32 divisor, plus it can use an external clock.
>
> Ouch. =A0I don't have a 512x, but isn't the current code plain wrong then=
? =A0It uses mpc5xxx_get_bus_frequency() as input for the baud rate calcula=
tion, and if the serial code assumes /16 instead of /10, the result must be=
terribly off. =A0Or did I miss something here?
If you are, then I'm missing the same thing. Do you best to keep the
5121 calculation work out to the same value it uses now. We'll ask
someone with a 5121 to test it out before I add the patch to my -next
branch.
g.
^ permalink raw reply
* Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Joakim Tjernlund @ 2010-03-04 13:06 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, hs
In-Reply-To: <20100304121656.6758A28BBC@gemini.denx.de>
Wolfgang Denk <wd@denx.de> wrote on 2010/03/04 13:16:56:
> From: Wolfgang Denk <wd@denx.de>
> To: hs@denx.de
> Cc: Joakim Tjernlund <joakim.tjernlund@transmode.se>, Klaus-J=FCrgen
> <heydeck@kieback-peter.de>, linuxppc-dev@ozlabs.org, Scott Wood
> <scottwood@freescale.com>
> Date: 2010/03/04 13:17
> Subject: Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
>
> Dear Heiko,
>
> thanks for running the tests.
>
> In message <4B8F8BB4.6070201@denx.de> you wrote:
> >
> > here the results:
> >
> > run version
> >
> > 1-4 2.6.33-rc6 without your patches
> > 5-8 2.6.33-rc6 with all your patches
> > 9-12 2.6.33-rc6 with patches 1,2 and 4 (without 8xx: Don't touch =
ACCESSED
> when no SWAP)
> > 13-16 2.6.33-rc6 with all your patches and CONFIG_PIN_TLB=3Dy
>
> So CONFIG_PIN_TLB imroves the performance as expected, while the othe=
r
> patches don;t show any measurable improvememt - or am I reading the
> results incorrectly?
Close but not quite. What stands out most is:
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
-----------------------------------------------------------------------=
-------
Host OS Mhz L1 $ L2 $ Main mem Rand mem =
Guesses
--------- ------------- --- ---- ---- -------- -------- =
-------
tqm8xx Linux 2.6.33- 66 31.8 141.0 184.0 1165.7
tqm8xx Linux 2.6.33- 66 31.8 141.2 184.2 1165.3
tqm8xx Linux 2.6.33- 66 31.8 141.3 184.3 1165.6
tqm8xx Linux 2.6.33- 66 31.8 141.3 184.2 1166.2
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1100.5 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1102.5 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.7 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.6 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.1 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.0 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.7 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.2 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 171.1 171.7 1099.8 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 171.1 171.6 1100.5 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.7 171.0 171.7 1101.0 =
No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 171.0 171.6 1101.3 =
No L2 cache?
Besides the numbers, note how the first group doesn't have a Guesses en=
try.
Is there something odd with the results for the first group?
Also, since you are using MODULES, patch 2 is nullified.
Patch 1 is very minor and should not show I think.
This leaves patches 3 & 4.
There appears to be something funny with patch 3,Don't touch ACCESSED w=
hen no SWAP, as
it yields bad numbers for Prot Fault so perhaps I am missing something =
that needs ACCESSED
even if NO_SWAP. Perhaps a someone that knows MM in Linux knows?
Is there any messages in the kernel log(dmesg)?
Jocke=
^ permalink raw reply
* Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Wolfgang Denk @ 2010-03-04 12:16 UTC (permalink / raw)
To: hs; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <4B8F8BB4.6070201@denx.de>
Dear Heiko,
thanks for running the tests.
In message <4B8F8BB4.6070201@denx.de> you wrote:
>
> here the results:
>
> run version
>
> 1-4 2.6.33-rc6 without your patches
> 5-8 2.6.33-rc6 with all your patches
> 9-12 2.6.33-rc6 with patches 1,2 and 4 (without 8xx: Don't touch ACCESSED when no SWAP)
> 13-16 2.6.33-rc6 with all your patches and CONFIG_PIN_TLB=y
So CONFIG_PIN_TLB imroves the performance as expected, while the other
patches don;t show any measurable improvememt - or am I reading the
results incorrectly?
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
And now remains That we find out the cause of this effect, Or rather
say, the cause of this defect... -- Hamlet, Act II, Scene 2
^ permalink raw reply
* Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
From: Heiko Schocher @ 2010-03-04 10:30 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev, Wolfgang Denk
In-Reply-To: <OF1C3DEF4A.B7A4D572-ONC12576DB.003876E8-C12576DB.003A7EEF@transmode.se>
Hello Joakim,
Joakim Tjernlund wrote:
> Could you try reverting patch:
> 8xx: Don't touch ACCESSED when no SWAP.
> and see if that makes a difference?
[...]
> Turning on pinned TLBs(you must turn on ADVANCED_OPTIONS first) could be an improvement,
> regardless of my patches.
here the results:
run version
1-4 2.6.33-rc6 without your patches
5-8 2.6.33-rc6 with all your patches
9-12 2.6.33-rc6 with patches 1,2 and 4 (without 8xx: Don't touch ACCESSED when no SWAP)
13-16 2.6.33-rc6 with all your patches and CONFIG_PIN_TLB=y
> Turning on pinned TLBs(you must turn on ADVANCED_OPTIONS first) could be an improvement,
> regardless of my patches.
make[1]: Entering directory `/home/hs/lmbench-3.0-a9/results'
L M B E N C H 3 . 0 S U M M A R Y
------------------------------------
(Alpha software, do not distribute)
Basic system parameters
------------------------------------------------------------------------------
Host OS Description Mhz tlb cache mem scal
pages line par load
bytes
--------- ------------- ----------------------- ---- ----- ----- ------ ----
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 7 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 7 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 7 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 7 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0100 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 32 16 1.0100 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 28 16 1.1700 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 7 16 1.0100 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 28 16 1.0400 1
tqm8xx Linux 2.6.33- powerpc-linux-gnu 66 7 16 1.0400 1
Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host OS Mhz null null open slct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
tqm8xx Linux 2.6.33- 66 2.97 10.3 129. 1377 272. 21.8 91.3 6949 29.K 89.K
tqm8xx Linux 2.6.33- 66 3.06 10.5 124. 1375 273. 21.8 91.3 7136 30.K 89.K
tqm8xx Linux 2.6.33- 66 3.06 10.6 129. 1365 272. 21.2 96.6 6889 29.K 89.K
tqm8xx Linux 2.6.33- 66 3.06 10.5 124. 1309 272. 21.8 101. 6896 29.K 89.K
tqm8xx Linux 2.6.33- 66 2.97 8.86 126. 1336 273. 21.7 84.2 6785 29.K 88.K
tqm8xx Linux 2.6.33- 66 3.06 8.90 130. 1343 263. 21.3 84.7 7080 29.K 88.K
tqm8xx Linux 2.6.33- 66 3.52 8.97 129. 1339 270. 22.4 84.4 6823 29.K 88.K
tqm8xx Linux 2.6.33- 66 2.97 8.99 127. 1333 261. 22.4 87.0 7037 29.K 87.K
tqm8xx Linux 2.6.33- 66 3.06 8.83 128. 1355 269. 20.7 89.2 6927 29.K 87.K
tqm8xx Linux 2.6.33- 66 3.05 8.84 127. 1344 271. 21.6 90.5 6868 29.K 88.K
tqm8xx Linux 2.6.33- 66 3.06 8.84 131. 1376 260. 21.4 88.1 7119 29.K 87.K
tqm8xx Linux 2.6.33- 66 3.05 8.90 122. 1342 272. 21.4 88.6 6847 29.K 88.K
tqm8xx Linux 2.6.33- 66 3.19 9.10 122. 1205 265. 20.9 90.3 6358 27.K 83.K
tqm8xx Linux 2.6.33- 66 3.28 9.10 124. 1208 270. 20.9 95.2 6217 27.K 82.K
tqm8xx Linux 2.6.33- 66 3.19 8.98 125. 1210 270. 21.1 87.9 6364 27.K 83.K
tqm8xx Linux 2.6.33- 66 3.19 8.86 124. 1237 262. 21.3 90.7 6311 27.K 84.K
Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host OS intgr intgr intgr intgr intgr
bit add mul div mod
--------- ------------- ------ ------ ------ ------ ------
tqm8xx Linux 2.6.33- 15.7 18.0 1.5600 124.2 203.1
tqm8xx Linux 2.6.33- 15.7 17.4 1.5800 121.1 202.8
tqm8xx Linux 2.6.33- 15.2 17.9 1.6200 124.2 202.7
tqm8xx Linux 2.6.33- 15.2 17.9 1.6000 125.0 204.0
tqm8xx Linux 2.6.33- 15.7 18.1 1.5600 124.7 204.4
tqm8xx Linux 2.6.33- 15.7 18.1 1.5800 124.2 202.8
tqm8xx Linux 2.6.33- 15.7 17.9 1.5500 124.2 203.2
tqm8xx Linux 2.6.33- 15.7 18.1 1.5500 124.5 202.0
tqm8xx Linux 2.6.33- 15.7 18.1 1.5500 124.5 202.6
tqm8xx Linux 2.6.33- 15.7 18.1 1.5500 121.0 196.5
tqm8xx Linux 2.6.33- 15.7 17.9 1.5500 121.0 202.5
tqm8xx Linux 2.6.33- 15.7 18.1 1.5500 125.1 196.4
tqm8xx Linux 2.6.33- 15.7 17.9 1.5500 124.2 202.1
tqm8xx Linux 2.6.33- 15.7 17.9 1.5500 124.2 203.4
tqm8xx Linux 2.6.33- 15.7 17.9 1.5500 124.2 196.4
tqm8xx Linux 2.6.33- 15.7 17.9 1.5500 124.2 196.5
Basic uint64 operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host OS int64 int64 int64 int64 int64
bit add mul div mod
--------- ------------- ------ ------ ------ ------ ------
tqm8xx Linux 2.6.33- 15. 13.3 1952.2 1838.2
tqm8xx Linux 2.6.33- 15. 13.2 1951.5 1837.8
tqm8xx Linux 2.6.33- 15. 13.2 1886.7 1907.8
tqm8xx Linux 2.6.33- 15. 13.2 1951.5 1838.2
tqm8xx Linux 2.6.33- 15. 13.3 1887.0 1902.2
tqm8xx Linux 2.6.33- 15. 13.3 1887.4 1901.5
tqm8xx Linux 2.6.33- 15. 13.3 1886.7 1893.0
tqm8xx Linux 2.6.33- 15. 13.3 1950.0 1900.4
tqm8xx Linux 2.6.33- 15. 13.3 1955.2 1906.7
tqm8xx Linux 2.6.33- 15. 13.2 1943.7 1900.7
tqm8xx Linux 2.6.33- 15. 13.3 1958.2 1910.4
tqm8xx Linux 2.6.33- 15. 13.3 1886.7 1900.7
tqm8xx Linux 2.6.33- 15. 13.3 1943.7 1837.4
tqm8xx Linux 2.6.33- 15. 13.2 1944.1 1837.4
tqm8xx Linux 2.6.33- 15. 13.2 1944.4 1906.1
tqm8xx Linux 2.6.33- 15. 13.2 1957.8 1894.8
Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host OS float float float float
add mul div bogo
--------- ------------- ------ ------ ------ ------
tqm8xx Linux 2.6.33- 1008.9 1629.2 5527.0 9895.0
tqm8xx Linux 2.6.33- 1008.9 1628.9 5495.0 9892.0
tqm8xx Linux 2.6.33- 1007.8 1622.0 5499.0 9886.0
tqm8xx Linux 2.6.33- 1016.5 1628.6 5319.0 9940.0
tqm8xx Linux 2.6.33- 1008.0 1628.3 5497.0 9879.0
tqm8xx Linux 2.6.33- 1007.6 1577.4 5495.0 9881.0
tqm8xx Linux 2.6.33- 1014.8 1627.1 5493.0 9889.0
tqm8xx Linux 2.6.33- 1004.6 1627.7 5487.0 9881.0
tqm8xx Linux 2.6.33- 1003.8 1627.1 5490.0 9875.0
tqm8xx Linux 2.6.33- 977.2 1628.0 5318.0 9924.0
tqm8xx Linux 2.6.33- 1007.4 1627.7 5490.0 9882.0
tqm8xx Linux 2.6.33- 1004.7 1628.0 5495.0 9891.0
tqm8xx Linux 2.6.33- 1011.6 1630.1 5484.0 9855.0
tqm8xx Linux 2.6.33- 977.0 1621.4 5469.0 9856.0
tqm8xx Linux 2.6.33- 1011.4 1621.4 5471.0 9856.0
tqm8xx Linux 2.6.33- 1004.9 1577.1 5470.0 9866.0
Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host OS double double double double
add mul div bogo
--------- ------------- ------ ------ ------ ------
tqm8xx Linux 2.6.33- 1562.4 2782.8 3730.7 12.6K
tqm8xx Linux 2.6.33- 1556.1 2781.5 3724.3 12.6K
tqm8xx Linux 2.6.33- 1513.9 2801.0 3726.4 12.8K
tqm8xx Linux 2.6.33- 1556.1 2780.9 3611.4 12.6K
tqm8xx Linux 2.6.33- 1570.5 2772.6 3742.1 12.6K
tqm8xx Linux 2.6.33- 1560.1 2703.0 3611.4 12.7K
tqm8xx Linux 2.6.33- 1560.4 2779.5 3760.7 12.7K
tqm8xx Linux 2.6.33- 1559.8 2773.0 3742.1 12.6K
tqm8xx Linux 2.6.33- 1564.7 2699.0 3722.1 12.6K
tqm8xx Linux 2.6.33- 1560.7 2790.0 3725.7 12.7K
tqm8xx Linux 2.6.33- 1565.0 2780.0 3749.3 12.7K
tqm8xx Linux 2.6.33- 1560.4 2700.0 3767.1 12.8K
tqm8xx Linux 2.6.33- 1555.5 2772.1 3747.9 12.6K
tqm8xx Linux 2.6.33- 1513.5 2772.5 3725.7 12.6K
tqm8xx Linux 2.6.33- 1557.0 2772.5 3725.7 12.7K
tqm8xx Linux 2.6.33- 1514.1 2773.5 3719.3 12.7K
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
tqm8xx Linux 2.6.33- 92.6 109.6 110.9 137.5 173.8 151.8 199.3
tqm8xx Linux 2.6.33- 95.8 108.5 104.7 137.1 172.7 150.9 194.7
tqm8xx Linux 2.6.33- 95.8 118.8 97.5 146.4 162.0 160.8 190.1
tqm8xx Linux 2.6.33- 92.9 111.9 101.0 138.1 166.6 152.3 192.0
tqm8xx Linux 2.6.33- 90.8 108.5 116.2 134.3 171.8 147.1 210.0
tqm8xx Linux 2.6.33- 100.1 111.4 105.0 136.4 173.1 148.3 200.8
tqm8xx Linux 2.6.33- 98.7 111.3 111.8 135.7 172.5 147.9 200.9
tqm8xx Linux 2.6.33- 92.0 117.9 109.9 141.6 170.4 154.9 196.4
tqm8xx Linux 2.6.33- 96.9 112.4 95.4 138.3 165.1 152.2 196.4
tqm8xx Linux 2.6.33- 100.6 115.8 109.3 138.5 173.3 150.9 199.2
tqm8xx Linux 2.6.33- 102.2 114.3 109.4 140.9 175.5 153.2 202.0
tqm8xx Linux 2.6.33- 99.1 114.5 106.5 138.2 174.7 151.7 199.9
tqm8xx Linux 2.6.33- 69.5 80.5 88.9 119.6 147.3 130.4 178.7
tqm8xx Linux 2.6.33- 85.8 97.6 79.1 122.3 154.1 132.6 180.1
tqm8xx Linux 2.6.33- 89.4 93.8 125.7 120.8 178.4 129.5 206.1
tqm8xx Linux 2.6.33- 88.1 101.8 91.2 121.4 162.8 131.6 191.4
*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
tqm8xx Linux 2.6.33- 92.6 338.4 581. 720.1 1047. 2749
tqm8xx Linux 2.6.33- 95.8 334.0 595. 725.0 1051. 2754
tqm8xx Linux 2.6.33- 95.8 330.9 574. 720.1 1047. 2772
tqm8xx Linux 2.6.33- 92.9 338.8 574. 714.3 1046. 2742
tqm8xx Linux 2.6.33- 90.8 322.1 576. 734.9 1012. 2706
tqm8xx Linux 2.6.33- 100.1 326.0 565. 719.5 1027. 2702
tqm8xx Linux 2.6.33- 98.7 322.8 571. 713.8 1028. 2711
tqm8xx Linux 2.6.33- 92.0 328.1 549. 714.1 1022. 2696
tqm8xx Linux 2.6.33- 96.9 327.0 573. 722.3 1036. 2721
tqm8xx Linux 2.6.33- 100.6 330.4 561. 723.8 1024. 2726
tqm8xx Linux 2.6.33- 102.2 331.4 590. 728.6 1040. 2753
tqm8xx Linux 2.6.33- 99.1 330.1 585. 723.5 1023. 2750
tqm8xx Linux 2.6.33- 69.5 265.9 447. 632.6 909.0 2431
tqm8xx Linux 2.6.33- 85.8 267.0 492. 650.6 909.4 2455
tqm8xx Linux 2.6.33- 89.4 295.6 493. 643.0 908.8 2453
tqm8xx Linux 2.6.33- 88.1 301.0 494. 645.1 907.9 2451
*Remote* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host OS UDP RPC/ TCP RPC/ TCP
UDP TCP conn
--------- ------------- ----- ----- ----- ----- ----
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
tqm8xx Linux 2.6.33-
File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page 100fd
Create Delete Create Delete Latency Fault Fault selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
tqm8xx Linux 2.6.33- 5917.2 3968.3 31.2K 4329.0 4147.0 18.8 34.1 135.2
tqm8xx Linux 2.6.33- 5714.3 3937.0 32.3K 6060.6 4210.0 14.2 34.5 131.4
tqm8xx Linux 2.6.33- 5747.1 4000.0 31.2K 4329.0 4114.0 7.692 34.0 133.1
tqm8xx Linux 2.6.33- 5747.1 4081.6 30.3K 4273.5 4100.0 18.2 34.2 135.0
tqm8xx Linux 2.6.33- 5714.3 3952.6 31.2K 4273.5 4130.0 33.5 35.1 136.1
tqm8xx Linux 2.6.33- 5714.3 3906.2 31.2K 6060.6 4105.0 25.7 35.5 135.9
tqm8xx Linux 2.6.33- 5681.8 3921.6 32.3K 4255.3 4144.0 23.5 35.0 134.9
tqm8xx Linux 2.6.33- 5649.7 3937.0 30.3K 4237.3 4116.0 21.6 35.3 135.3
tqm8xx Linux 2.6.33- 5747.1 3921.6 32.3K 4329.0 4107.0 17.7 35.6 131.2
tqm8xx Linux 2.6.33- 5952.4 3937.0 31.2K 4273.5 4119.0 25.4 35.8 136.4
tqm8xx Linux 2.6.33- 5848.0 3937.0 32.3K 4484.3 4223.0 14.3 35.4 135.1
tqm8xx Linux 2.6.33- 6172.8 3984.1 35.7K 4291.8 4210.0 14.4 36.0 135.0
tqm8xx Linux 2.6.33- 5291.0 3610.1 31.2K 4065.0 3836.0 1.389 30.0 135.7
tqm8xx Linux 2.6.33- 5524.9 3649.6 29.4K 3906.2 3867.0 14.9 29.8 137.7
tqm8xx Linux 2.6.33- 5319.1 3649.6 29.4K 4048.6 3873.0 13.3 30.3 135.9
tqm8xx Linux 2.6.33- 5347.6 3623.2 32.3K 3921.6 3894.0 13.3 30.4 135.8
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
tqm8xx Linux 2.6.33- 14.8 15.6 10.1 21.0 55.5 32.3 34.5 55.6 53.0
tqm8xx Linux 2.6.33- 14.8 15.6 10.7 21.0 55.5 32.3 34.5 55.6 53.0
tqm8xx Linux 2.6.33- 14.8 15.7 12.7 21.0 55.5 32.3 34.5 55.6 53.0
tqm8xx Linux 2.6.33- 14.8 15.6 13.9 21.0 55.5 32.3 34.5 55.6 53.0
tqm8xx Linux 2.6.33- 14.8 15.8 12.9 21.0 55.7 32.5 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 14.8 15.7 14.0 21.0 55.7 32.4 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 14.8 15.8 12.9 21.0 55.7 32.5 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 14.8 15.8 13.0 21.0 55.7 32.5 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 14.8 15.7 14.0 21.0 55.6 32.4 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 14.7 15.7 12.8 21.0 55.6 32.4 34.6 55.7 53.1
tqm8xx Linux 2.6.33- 14.6 15.7 12.8 21.0 55.6 32.4 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 14.8 15.7 12.8 21.0 55.6 32.4 34.6 55.8 53.1
tqm8xx Linux 2.6.33- 15.0 16.0 13.2 21.3 55.8 32.5 34.7 55.9 53.2
tqm8xx Linux 2.6.33- 15.0 16.0 13.4 21.3 55.8 32.5 34.7 55.8 53.2
tqm8xx Linux 2.6.33- 15.0 16.0 13.9 21.3 55.8 32.5 34.7 55.9 53.2
tqm8xx Linux 2.6.33- 15.0 16.0 13.2 21.2 55.8 32.5 34.6 55.9 53.2
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Rand mem Guesses
--------- ------------- --- ---- ---- -------- -------- -------
tqm8xx Linux 2.6.33- 66 31.8 141.0 184.0 1165.7
tqm8xx Linux 2.6.33- 66 31.8 141.2 184.2 1165.3
tqm8xx Linux 2.6.33- 66 31.8 141.3 184.3 1165.6
tqm8xx Linux 2.6.33- 66 31.8 141.3 184.2 1166.2
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1100.5 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1102.5 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.7 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.0 171.8 1101.6 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.1 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 141.1 173.4 1149.0 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.7 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.7 141.1 173.4 1148.2 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 171.1 171.7 1099.8 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 171.1 171.6 1100.5 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.7 171.0 171.7 1101.0 No L2 cache?
tqm8xx Linux 2.6.33- 66 31.8 171.0 171.6 1101.3 No L2 cache?
make[1]: Leaving directory `/home/hs/lmbench-3.0-a9/results'
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Strange OOPS in 2.6.33
From: Joakim Tjernlund @ 2010-03-04 10:29 UTC (permalink / raw)
To: linuxppc-dev
Got this OOPS a few times after coldstarting out
board a few times:
Unable to handle kernel paging request for unknown fault
Faulting instruction address: 0xc020e2b4
Oops: Kernel access of bad area, sig: 11 [#1]
TMCUTU
Modules linked in:
NIP: c020e2b4 LR: c020e274 CTR: 00000000
REGS: c7a41b40 TRAP: 0600 Not tainted (2.6.33)
MSR: 00009032 <EE,ME,IR,DR> CR: 28002424 XER: 00000000
DAR: 09f52312, DSISR: 00000120
TASK = c7889940[420] 'syslogd' THREAD: c7a40000
GPR00: 09f52312 c7a41bf0 c7889940 00000000 00000002 c7a41c40 c02734ac c78acc68
GPR08: c7a41c00 c78acc00 00000000 09f5214b c796e3d4 1001f444 00000000 bfe78700
GPR16: bfe77400 bfe77ee0 bfe773f8 00000021 0ffef130 00000000 c7a41df0 00000000
GPR24: 00000000 c7a41cf0 c7a41c70 00000011 7f000001 09f5214a c034a5cc c7a41c00
NIP [c020e2b4] ip_dev_find+0x90/0xf0
LR [c020e274] ip_dev_find+0x50/0xf0
Call Trace:
[c7a41bf0] [c020e274] ip_dev_find+0x50/0xf0 (unreliable)
[c7a41c60] [c01dd86c] __ip_route_output_key+0x8d4/0xb00
[c7a41d50] [c01ddab8] ip_route_output_flow+0x1c/0xa0
[c7a41d60] [c01ff8a0] ip4_datagram_connect+0x17c/0x2b8
[c7a41e30] [c020a75c] inet_dgram_connect+0x5c/0xa8
[c7a41e50] [c01a5030] sys_connect+0x7c/0xcc
[c7a41f00] [c01a6008] sys_socketcall+0x128/0x214
[c7a41f40] [c0011800] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff6e004
LR = 0xfe2dac0
Instruction dump:
bb810060 38210070 7c0803a6 4e800020 88010052 2f800002 409e0028 81210054
83a90068 2f9d0000 419e0018 381d01c8 <7d200028> 31290001 7d20012d 40a2fff4
---[ end trace 0824e85bac28e7e4 ]---
gdb says:
(gdb) list *0xc020e2b4
0xc020e2b4 is in ip_dev_find (/usr/local/src/BUILD/trunk/os2kernel/arch/powerpc/include/asm/atomic.h:106).
101
102 static __inline__ void atomic_inc(atomic_t *v)
103 {
104 int t;
105
106 __asm__ __volatile__(
107 "1: lwarx %0,0,%2 # atomic_inc\n\
108 addic %0,%0,1\n"
109 PPC405_ERR77(0,%2)
110 " stwcx. %0,0,%2 \n\
gdb) disass 0xc020e2b4 0xc020e2c4
Dump of assembler code from 0xc020e2b4 to 0xc020e2c4:
0xc020e2b4 <ip_dev_find+144>: lwarx r9,0,r0
0xc020e2b8 <ip_dev_find+148>: addic r9,r9,1
0xc020e2bc <ip_dev_find+152>: stwcx. r9,0,r0
0xc020e2c0 <ip_dev_find+156>: bne- 0xc020e2b4 <ip_dev_find+144>
This is on a MPC8321 CPU
gcc 3.4.6
Any ideas?
Jocke
^ permalink raw reply
* Re: [Patch v.2] mpc5200b/uart: improve baud rate calculation (reach high baud rates, better accuracy)
From: Albrecht Dreß @ 2010-03-04 9:56 UTC (permalink / raw)
To: grant.likely, albrecht.dress; +Cc: linuxppc-dev
In-Reply-To: <fa686aa41003031307j79e004cfk49297e419a65f5da@mail.gmail.com>
Hi Grant:
Thanks a lot for your input!
[snip]
> Save yourself some duplicated code here. The above 14 lines can be
> shared between the 512x, 52xx and 5200b versions. Create yourself an
> internal __mpc5xxx_psc_set_divisor() function that is passed the *psc,
> the divisor, and the clock select register setting (both the 5200 and
> the 5121 have the clock select register).
Hmm, yes, that's true. Will look into that.
[snip]
> > @@ -604,7 +676,6 @@ mpc52xx_uart_set_termios(struct uart_por
> >
> > =A0 =A0 =A0 =A0baud =3D uart_get_baud_rate(port, new, old, 0, port->uar=
tclk/16);
>=20
> I'm probably nitpicking, because I don't know if the io pin will
> handle this speed but uartclk/16 is no longer the maximum baudrate if
> a /4 prescaler is used.
Yes, you are right. Must of course be fixed.
[snip]
> > @@ -635,8 +706,7 @@ mpc52xx_uart_set_termios(struct uart_por
> > =A0 =A0 =A0 =A0out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
> > =A0 =A0 =A0 =A0out_8(&psc->mode, mr1);
> > =A0 =A0 =A0 =A0out_8(&psc->mode, mr2);
> > - =A0 =A0 =A0 out_8(&psc->ctur, ctr >> 8);
> > - =A0 =A0 =A0 out_8(&psc->ctlr, ctr & 0xff);
> > + =A0 =A0 =A0 psc_ops->set_divisor(port, quot);
>=20
> Hmmm. The divisor calculations have some tricky bits to them. I
> would consider changing the set_divisor() function to accept a baud
> rate, and modify the set_divisor function to call uart_get_divisor().
That sounds like a good idea to me. I will change the code that way.
> That way each set_divisor() can do whatever makes the most sense for
> the divisors available to it. The 5121 for example has both a /10 and
> a /32 divisor, plus it can use an external clock.
Ouch. I don't have a 512x, but isn't the current code plain wrong then? I=
t uses mpc5xxx_get_bus_frequency() as input for the baud rate calculation, =
and if the serial code assumes /16 instead of /10, the result must be terri=
bly off. Or did I miss something here?
Best, Albrecht.
Tolle Dekollet=E9s oder scharfe Tatoos? Vote jetzt ... oder mach selbst mit=
und zeige Deine Schokoladenseite
bei Topp oder Hopp von Arcor: http://www.arcor.de/rd/footer.toh
^ permalink raw reply
* Re: [PATCH] gianfar: Fix TX ring processing on SMP machines
From: David Miller @ 2010-03-04 8:41 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, netdev, martyn.welch, paul.gortmaker, Sandeep.Kumar
In-Reply-To: <20100303181858.GA458@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed, 3 Mar 2010 21:18:58 +0300
> Starting with commit a3bc1f11e9b867a4f49505 ("gianfar: Revive SKB
> recycling") gianfar driver sooner or later stops transmitting any
> packets on SMP machines.
>
> start_xmit() prepares new skb for transmitting, generally it does
> three things:
>
> 1. sets up all BDs (marks them ready to send), except the first one.
> 2. stores skb into tx_queue->tx_skbuff so that clean_tx_ring()
> would cleanup it later.
> 3. sets up the first BD, i.e. marks it ready.
>
> Here is what clean_tx_ring() does:
>
> 1. reads skbs from tx_queue->tx_skbuff
> 2. checks if the *last* BD is ready. If it's still ready [to send]
> then it it isn't transmitted, so clean_tx_ring() returns.
> Otherwise it actually cleanups BDs. All is OK.
>
> Now, if there is just one BD, code flow:
>
> - start_xmit(): stores skb into tx_skbuff. Note that the first BD
> (which is also the last one) isn't marked as ready, yet.
> - clean_tx_ring(): sees that skb is not null, *and* its lstatus
> says that it is NOT ready (like if BD was sent), so it cleans
> it up (bad!)
> - start_xmit(): marks BD as ready [to send], but it's too late.
>
> We can fix this simply by reordering lstatus/tx_skbuff writes.
>
> Reported-by: Martyn Welch <martyn.welch@ge.com>
> Bisected-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Tested-by: Martyn Welch <martyn.welch@ge.com>
Applied.
^ 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