* Re: [PATCH 10/13] powerpc/5200: LocalPlus driver: fix problem caused by unpredictable IRQ order
From: Roman Fietze @ 2010-01-12 7:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa41001111219r23e0adc4gd6daf70096771f91@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1021 bytes --]
Hello Grant,
On Monday 11 January 2010 21:19:14 Grant Likely wrote:
> I'm really not convinced.
At least you made me think about that some more. And of course, you
are right, the order must be fixed, one way using TX, the other way
using RX.
I think delayed BCOM IRQs in TX direction, caused by a high FEC or ATA
BCOM load, could cause starting the next job with a not yet cleand up
BD ring.
Please give me another change to come up with a hopefully much cleaner
design, esp. after some tests under low and high load with alternating
transfer directions. Probably we can stay with the original design,
and only take some extra effort when the transfer directions changes.
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
Amtsgericht Ulm HRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 03/13] mpc52xx: add SCLPC register bit definitions
From: Roman Fietze @ 2010-01-12 7:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa41001111121u5c943fc7p789c0ec0b41af883@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1229 bytes --]
Hello Grant,
On Monday 11 January 2010 20:21:22 Grant Likely wrote:
> Unrelated whitespace change?
My fault, as with some other white space changes. My Emacs is
configured using some older setup found in a 2.4
Documentation/CodingStyle. Before saving a file my spine is used to
reformat the whole source file, which then causes those artefacts.
I'll fix the Emacs setup and try to fix my spine, and double check
before commits.
BTW: no Emacs users amongst the kernel coders any more? At least I
have to read "So, you can either get rid of GNU emacs, or ...".
> I prefer the (1<<n) style myself.
Ok. Looking at it a second time you and Wolfgang are definitively
right. And I prefer the (1<<n) style a lot more than the 0x0080 style.
> Why is the list head being removed?
Not used at all, except in initialization?
Of course a seperate patch would have been needed.
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
Amtsgericht Ulm HRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix decrementer setup on 1GHz boards
From: Stefan Roese @ 2010-01-12 8:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Detlev Zundel
We noticed that recent kernels didn't boot on our 1GHz Canyonlands 460EX
boards anymore. As it seems, patch 8d165db1 [powerpc: Improve
decrementer accuracy] introduced this problem. The routine div_sc()
overflows with shift = 32 resulting in this incorrect setup:
time_init: decrementer frequency = 1000.000012 MHz
time_init: processor frequency = 1000.000012 MHz
clocksource: timebase mult[400000] shift[22] registered
clockevent: decrementer mult[33] shift[32] cpu[0]
This patch now introduces a local div_dc64() version of this function
so that this overflow doesn't happen anymore.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Detlev Zundel <dzu@denx.de>
---
arch/powerpc/kernel/time.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 92dc844..3ad729f 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -882,12 +882,21 @@ static void decrementer_set_mode(enum clock_event_mode mode,
decrementer_set_next_event(DECREMENTER_MAX, dev);
}
+static inline uint64_t div_sc64(unsigned long ticks, unsigned long nsec,
+ int shift)
+{
+ uint64_t tmp = ((uint64_t)ticks) << shift;
+
+ do_div(tmp, nsec);
+ return tmp;
+}
+
static void __init setup_clockevent_multiplier(unsigned long hz)
{
u64 mult, shift = 32;
while (1) {
- mult = div_sc(hz, NSEC_PER_SEC, shift);
+ mult = div_sc64(hz, NSEC_PER_SEC, shift);
if (mult && (mult >> 32UL) == 0UL)
break;
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH] 8xx: fix user space TLB walk in dcbX fixup
From: Benjamin Herrenschmidt @ 2010-01-12 8:44 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OFB21A02C2.A1F50F94-ONC12576A9.00270097-C12576A9.00272133@transmode.se>
On Tue, 2010-01-12 at 08:07 +0100, Joakim Tjernlund wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 12/01/2010 03:40:45:
> >
> > On Fri, 2010-01-08 at 17:46 +0100, Joakim Tjernlund wrote:
> > > The newly added fixup for buggy dcbX insn's has
> > > a bug that always trigger a kernel TLB walk so a user space
> > > dcbX insn will cause a Kernel Machine Check if it hits DTLB error.
> > >
> > > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > > ---
> > >
> > > I found this problem in 2.4 and forward ported it to 2.6. I
> > > cannot test it so I cannot be 100% sure I got it right.
> > >
> > > arch/powerpc/kernel/head_8xx.S | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > Do you have something to make sure that TASK_SIZE is never bigger than
> > 2G ? Else userspace could be all the way to 0xbfffffff ...
>
> No, but this is 8xx :) The TLB handlers has the same "limitation" and has always
> been so.
You should send a patch to express that limitation in KConfig :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC,PATCH 0/7 v2] Common struct clk implementation
From: Russell King - ARM Linux @ 2010-01-12 9:13 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <1263279511.160127.576969496193.0.gpush@pororo>
On Tue, Jan 12, 2010 at 05:58:31PM +1100, Jeremy Kerr wrote:
> The first two patches are for the architecture-independent kernel code,
> introducing the common clk API. The remaining patches are specific to
> the ARM 'versatile' and 'realview' platforms.
You're still only touching the "easy" platforms (as I pointed out
previously). This is no real test of the new implementation. To make
a decision on this based upon the easy implementations would be
completely wreckless.
As I said previously:
> Having struct clk be a set of function pointers gets really expensive on
> some platforms due to the shere number of struct clks - about 900; this
> will be a bar to them adopting this not only due to the size but the
> problems of ensuring correct initialisation.
>
> Conversely, having those platforms use a pointer to a set of clk operations
> structures is also prohibitive - some operations such as enable and disable
> can be common, but the rest are extremely variable.
The 900 figure was the result of a bad grep - it's more around 220
for one OMAP CPU - if you include all OMAP CPUs which share the same
implementation then its around 600 clk structures that need to be
changed.
But the point I was trying to convey is that OMAP doesn't work with
_either_ a pure operations struct _or_ a bunch of per-clock function
pointers - it currently uses a mixture of the two.
Maybe this is because there was no proper classing of clocks (to
separate clock masking from clock muxing from PLLs, etc.) The result
of this is that with a pure operations struct, you're likely to end
up with as many operations structures as there are clocks on OMAP.
The answer "OMAP shouldn't use this then" is not one I want to hear;
as I've already pointed out, OMAP is one of the platforms which should
use it.
^ permalink raw reply
* Re: [RFC,PATCH 1/7 v2] Add a common struct clk
From: Russell King - ARM Linux @ 2010-01-12 9:01 UTC (permalink / raw)
To: Francesco VIRLINZI
Cc: Jeremy Kerr, linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <4B4C376C.6080705@st.com>
On Tue, Jan 12, 2010 at 09:48:44AM +0100, Francesco VIRLINZI wrote:
> Hi Jeremy
> In November I already sent a proposal on
> a generic linux clk framework.
> On that I would suggest:
>
>>
>> +struct clk {
>> + const struct clk_operations *ops;
>>
> spinlock_t lock;
> const char *name;
> int id;
Name and ID are totally pointless, unless you insist on using the clk
API in the wrong way (like S3C does.)
^ permalink raw reply
* Re: [PATCH] 8xx: fix user space TLB walk in dcbX fixup
From: Joakim Tjernlund @ 2010-01-12 9:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1263285849.724.199.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 12/01/2010 09:44:09:
>
> On Tue, 2010-01-12 at 08:07 +0100, Joakim Tjernlund wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 12/01/2010 03:40:45:
> > >
> > > On Fri, 2010-01-08 at 17:46 +0100, Joakim Tjernlund wrote:
> > > > The newly added fixup for buggy dcbX insn's has
> > > > a bug that always trigger a kernel TLB walk so a user space
> > > > dcbX insn will cause a Kernel Machine Check if it hits DTLB error.
> > > >
> > > > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > > > ---
> > > >
> > > > I found this problem in 2.4 and forward ported it to 2.6. I
> > > > cannot test it so I cannot be 100% sure I got it right.
> > > >
> > > > arch/powerpc/kernel/head_8xx.S | 4 ++--
> > > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > Do you have something to make sure that TASK_SIZE is never bigger than
> > > 2G ? Else userspace could be all the way to 0xbfffffff ...
> >
> > No, but this is 8xx :) The TLB handlers has the same "limitation" and has always
> > been so.
>
> You should send a patch to express that limitation in KConfig :-)
Yeah, but this is nothing new to 8xx users.
The TLB handlers (and possible other parts too) has always had this limitation.
I don't think anyone cares since this is a small embedded CPU.
Jocke
^ permalink raw reply
* Re: [RFC,PATCH 1/7 v2] Add a common struct clk
From: Francesco VIRLINZI @ 2010-01-12 8:48 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <1263279511.160551.332624337260.1.gpush@pororo>
Hi Jeremy
In November I already sent a proposal on
a generic linux clk framework.
On that I would suggest:
>
> +struct clk {
> + const struct clk_operations *ops;
>
spinlock_t lock;
const char *name;
int id;
unsigned long rate;
> +};
> +
> +struct clk_operations {
>
int (*init)(struc clk *);
> + int (*enable)(struct clk *);
> + void (*disable)(struct clk *);
> + unsigned long (*get_rate)(struct clk *);
> + void (*put)(struct clk *);
> + long (*round_rate)(struct clk *, unsigned long);
> + int (*set_rate)(struct clk *, unsigned long);
> + int (*set_parent)(struct clk *, struct clk *);
> + struct clk* (*get_parent)(struct clk *);
> +};
>
+static inline int clk_enable(struct clk *clk)
+{
unsigned long flags;
int ret = 0;
+ if (clk->ops->enable) {
spinlock_irq_save(&clk->lock, flags);
+ ret = clk->ops->enable(clk);
spinlock_irq_restore(&clk->lock, flags);
}
+ return 0;
+}
Something similar in the other function...
> +
> +static inline unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (clk->ops->get_rate)
> + return clk->ops->get_rate(clk);
>
> return clk->rate;
> +}
>
>
Moreover if you support .set_parent and .get_parent a .parent field in
the struct clk
is useful.
As
struct clk {
const struct clk_operations *ops;
spinlock_t lock;
const char *name;
int id;
unsigned long rate;
struct clk *parent;
};
Regards
Francesco
^ permalink raw reply
* [PATCH] qe: Update the SNUM table for MPC8569 Rev2.0
From: Liu Yu @ 2010-01-12 10:04 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Liu Yu
From: Dave Liu <daveliu@freescale.com>
The MPC8569 Rev2.0 has the correct SNUM table as QE
Reference Manual, we must follow it.
However the Rev1.0 silicon need the old SNUM table
as workaround due to Rev1.0 silicon SNUM erratum.
So, we support both snum table, and choose the one FDT tell us.
And u-boot will fixup FDT according to SPRN_SVR.
Signed-off-by: Liu Yu <yu.liu@freescale.com>
Signed-off-by: Dave Liu <daveliu@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 22 ++++++++++++++++++++--
drivers/net/ucc_geth.c | 4 ++--
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 149393c..c13aede 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006 Freescale Semicondutor, Inc. All rights reserved.
+ * Copyright (C) 2006-2010 Freescale Semicondutor, Inc. All rights reserved.
*
* Authors: Shlomi Gridish <gridish@freescale.com>
* Li Yang <leoli@freescale.com>
@@ -266,7 +266,19 @@ EXPORT_SYMBOL(qe_clock_source);
static void qe_snums_init(void)
{
int i;
- static const u8 snum_init[] = {
+ static const u8 snum_init_76[] = {
+ 0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
+ 0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89,
+ 0x98, 0x99, 0xA8, 0xA9, 0xB8, 0xB9, 0xC8, 0xC9,
+ 0xD8, 0xD9, 0xE8, 0xE9, 0x44, 0x45, 0x4C, 0x4D,
+ 0x54, 0x55, 0x5C, 0x5D, 0x64, 0x65, 0x6C, 0x6D,
+ 0x74, 0x75, 0x7C, 0x7D, 0x84, 0x85, 0x8C, 0x8D,
+ 0x94, 0x95, 0x9C, 0x9D, 0xA4, 0xA5, 0xAC, 0xAD,
+ 0xB4, 0xB5, 0xBC, 0xBD, 0xC4, 0xC5, 0xCC, 0xCD,
+ 0xD4, 0xD5, 0xDC, 0xDD, 0xE4, 0xE5, 0xEC, 0xED,
+ 0xF4, 0xF5, 0xFC, 0xFD,
+ };
+ static const u8 snum_init_46[] = {
0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89,
0x98, 0x99, 0xA8, 0xA9, 0xB8, 0xB9, 0xC8, 0xC9,
@@ -274,9 +286,15 @@ static void qe_snums_init(void)
0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
};
+ static const u8 *snum_init;
qe_num_of_snum = qe_get_num_of_snums();
+ if (qe_num_of_snum == 76)
+ snum_init = snum_init_76;
+ else
+ snum_init = snum_init_46;
+
for (i = 0; i < qe_num_of_snum; i++) {
snums[i].num = snum_init[i];
snums[i].state = QE_SNUM_STATE_FREE;
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index afaf088..750d86d 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3863,11 +3863,11 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
ug_info->uf_info.utftt = UCC_GETH_UTFTT_GIGA_INIT;
ug_info->numThreadsTx = UCC_GETH_NUM_OF_THREADS_4;
- /* If QE's snum number is 46 which means we need to support
+ /* If QE's snum number is 46/76 which means we need to support
* 4 UECs at 1000Base-T simultaneously, we need to allocate
* more Threads to Rx.
*/
- if (qe_get_num_of_snums() == 46)
+ if (qe_get_num_of_snums() == 76 || qe_get_num_of_snums() == 46)
ug_info->numThreadsRx = UCC_GETH_NUM_OF_THREADS_6;
else
ug_info->numThreadsRx = UCC_GETH_NUM_OF_THREADS_4;
--
1.6.4
^ permalink raw reply related
* [PATCH] powerpc: Mark some variables in the page fault path __read_mostly
From: Anton Blanchard @ 2010-01-12 10:50 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Using perf to trace L1 dcache misses and dumping data addresses I found a few
variables taking a lot of misses. Since they are almost never written, they
should go into the __read_mostly section.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-cpumask/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/xmon/xmon.c 2010-01-12 14:40:35.436777033 +1100
+++ linux-cpumask/arch/powerpc/xmon/xmon.c 2010-01-12 14:41:30.576726874 +1100
@@ -61,7 +61,7 @@ static int xmon_owner;
static int xmon_gate;
#endif /* CONFIG_SMP */
-static unsigned long in_xmon = 0;
+static unsigned long in_xmon __read_mostly = 0;
static unsigned long adrs;
static int size = 1;
Index: linux-cpumask/arch/powerpc/kernel/traps.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/traps.c 2010-01-12 14:40:29.614225983 +1100
+++ linux-cpumask/arch/powerpc/kernel/traps.c 2010-01-12 14:41:30.576726874 +1100
@@ -60,13 +60,13 @@
#endif
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
-int (*__debugger)(struct pt_regs *regs);
-int (*__debugger_ipi)(struct pt_regs *regs);
-int (*__debugger_bpt)(struct pt_regs *regs);
-int (*__debugger_sstep)(struct pt_regs *regs);
-int (*__debugger_iabr_match)(struct pt_regs *regs);
-int (*__debugger_dabr_match)(struct pt_regs *regs);
-int (*__debugger_fault_handler)(struct pt_regs *regs);
+int (*__debugger)(struct pt_regs *regs) __read_mostly;
+int (*__debugger_ipi)(struct pt_regs *regs) __read_mostly;
+int (*__debugger_bpt)(struct pt_regs *regs) __read_mostly;
+int (*__debugger_sstep)(struct pt_regs *regs) __read_mostly;
+int (*__debugger_iabr_match)(struct pt_regs *regs) __read_mostly;
+int (*__debugger_dabr_match)(struct pt_regs *regs) __read_mostly;
+int (*__debugger_fault_handler)(struct pt_regs *regs) __read_mostly;
EXPORT_SYMBOL(__debugger);
EXPORT_SYMBOL(__debugger_ipi);
^ permalink raw reply
* [PATCH] powerpc: Reduce footprint of irq_stat
From: Anton Blanchard @ 2010-01-12 10:56 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
PowerPC is currently using asm-generic/hardirq.h which statically allocates an
NR_CPUS irq_stat array. Switch to an arch specific implementation which uses
per cpu data:
On a kernel with NR_CPUS=1024, this saves quite a lot of memory:
text data bss dec hex filename
8767938 2944132 1636796 13348866 cbb002 vmlinux.baseline
8767779 2944260 1505724 13217763 c9afe3 vmlinux.irq_cpustat
A saving of around 128kB.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-cpumask/arch/powerpc/include/asm/hardirq.h
===================================================================
--- linux-cpumask.orig/arch/powerpc/include/asm/hardirq.h 2010-01-06 16:24:31.220084536 +1100
+++ linux-cpumask/arch/powerpc/include/asm/hardirq.h 2010-01-06 17:45:25.219563704 +1100
@@ -1 +1,22 @@
-#include <asm-generic/hardirq.h>
+#ifndef _ASM_POWERPC_HARDIRQ_H
+#define _ASM_POWERPC_HARDIRQ_H
+
+#include <linux/threads.h>
+#include <linux/irq.h>
+
+typedef struct {
+ unsigned int __softirq_pending;
+} ____cacheline_aligned irq_cpustat_t;
+
+DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
+
+#define __ARCH_IRQ_STAT
+
+#define local_softirq_pending() __get_cpu_var(irq_stat).__softirq_pending
+
+static inline void ack_bad_irq(unsigned int irq)
+{
+ printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
+}
+
+#endif /* _ASM_POWERPC_HARDIRQ_H */
Index: linux-cpumask/arch/powerpc/kernel/irq.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/kernel/irq.c 2010-01-06 16:29:31.370083802 +1100
+++ linux-cpumask/arch/powerpc/kernel/irq.c 2010-01-06 16:48:04.210086075 +1100
@@ -73,6 +73,9 @@
#define CREATE_TRACE_POINTS
#include <asm/trace.h>
+DEFINE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
+EXPORT_PER_CPU_SYMBOL(irq_stat);
+
int __irq_offset_value;
static int ppc_spurious_interrupts;
^ permalink raw reply
* [PATCH] powerpc: Reduce footprint of xics_ipi_struct
From: Anton Blanchard @ 2010-01-12 10:58 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20100112105642.GI12666@kryten>
Right now we allocate a cacheline sized NR_CPUS array for xics IPI
communication. Since irq_stat is now PowerPC specific and using
DECLARE_PER_CPU_SHARED_ALIGNED (which should mean remote writes to
this should not conflict with other per cpu data), we can put it in there.
On a kernel with NR_CPUS=1024, this saves quite a lot of memory:
text data bss dec hex filename
8767779 2944260 1505724 13217763 c9afe3 vmlinux.irq_cpustat
8767555 2813444 1505724 13086723 c7b003 vmlinux.xics
A saving of around 128kB.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-cpumask/arch/powerpc/include/asm/hardirq.h
===================================================================
--- linux-cpumask.orig/arch/powerpc/include/asm/hardirq.h 2010-01-12 12:36:47.174226189 +1100
+++ linux-cpumask/arch/powerpc/include/asm/hardirq.h 2010-01-12 12:36:47.432976459 +1100
@@ -6,6 +6,9 @@
typedef struct {
unsigned int __softirq_pending;
+#if defined(CONFIG_XICS) && defined(CONFIG_SMP)
+ unsigned long xics_ipi;
+#endif
} ____cacheline_aligned irq_cpustat_t;
DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
Index: linux-cpumask/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-cpumask.orig/arch/powerpc/platforms/pseries/xics.c 2010-01-12 12:36:46.905477650 +1100
+++ linux-cpumask/arch/powerpc/platforms/pseries/xics.c 2010-01-12 12:40:54.782975198 +1100
@@ -514,15 +514,12 @@ static void __init xics_init_host(void)
/*
* XICS only has a single IPI, so encode the messages per CPU
*/
-struct xics_ipi_struct {
- unsigned long value;
- } ____cacheline_aligned;
-
-static struct xics_ipi_struct xics_ipi_message[NR_CPUS] __cacheline_aligned;
static inline void smp_xics_do_message(int cpu, int msg)
{
- set_bit(msg, &xics_ipi_message[cpu].value);
+ unsigned long *tgt = &(per_cpu(irq_stat, cpu).xics_ipi);
+
+ set_bit(msg, tgt);
mb();
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_qirr_info(cpu, IPI_PRIORITY);
@@ -548,25 +545,23 @@ void smp_xics_message_pass(int target, i
static irqreturn_t xics_ipi_dispatch(int cpu)
{
+ unsigned long *tgt = &(per_cpu(irq_stat, cpu).xics_ipi);
+
WARN_ON(cpu_is_offline(cpu));
mb(); /* order mmio clearing qirr */
- while (xics_ipi_message[cpu].value) {
- if (test_and_clear_bit(PPC_MSG_CALL_FUNCTION,
- &xics_ipi_message[cpu].value)) {
+ while (*tgt) {
+ if (test_and_clear_bit(PPC_MSG_CALL_FUNCTION, tgt)) {
smp_message_recv(PPC_MSG_CALL_FUNCTION);
}
- if (test_and_clear_bit(PPC_MSG_RESCHEDULE,
- &xics_ipi_message[cpu].value)) {
+ if (test_and_clear_bit(PPC_MSG_RESCHEDULE, tgt)) {
smp_message_recv(PPC_MSG_RESCHEDULE);
}
- if (test_and_clear_bit(PPC_MSG_CALL_FUNC_SINGLE,
- &xics_ipi_message[cpu].value)) {
+ if (test_and_clear_bit(PPC_MSG_CALL_FUNC_SINGLE, tgt)) {
smp_message_recv(PPC_MSG_CALL_FUNC_SINGLE);
}
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
- if (test_and_clear_bit(PPC_MSG_DEBUGGER_BREAK,
- &xics_ipi_message[cpu].value)) {
+ if (test_and_clear_bit(PPC_MSG_DEBUGGER_BREAK, tgt)) {
smp_message_recv(PPC_MSG_DEBUGGER_BREAK);
}
#endif
^ permalink raw reply
* Re: PCI-PCI bridge scanning broken on 460EX
From: Felix Radensky @ 2010-01-12 11:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Stef van Os, Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <1263250414.724.161.camel@pasglop>
Hi Ben
Benjamin Herrenschmidt wrote:
> On Tue, 2010-01-12 at 00:48 +0200, Felix Radensky wrote:
>
>> Maybe because the bus behind root P2P bridge is bus 0, and type 1
>> cycles are
>> needed for bus numbers greater than 0. That's what 460EX manual says.
>>
>
> Well, no... the bus behind the root P2P is bus 1 ... the root P2P itself
> is on bus 0... but then, it's some trick in the way they implemented it
> I suppose.
>
>
>> You are correct, the log is from older version, without Stef's fix. I
>> don't have access to a
>> system with devices behind PLX, and the guy who did the testing used
>> wrong kernel.
>> I'll make sure he uses the correct one and get back to you. Maybe
>> everything works after all :)
>> I'm really sorry for confusion.
>>
>
> No worries :-) Feel free to send a proper patch to fix that problem
> upstream too !
>
>
The kernel with Stef's fix works fine, and recognizes both PLX and
device behind it.
Stef, do want to provide a patch for upstream kernel, or do you want me
to do that on
your behalf ?
Thanks a lot everyone for you help !
Felix.
Felix.
^ permalink raw reply
* RE: PCI-PCI bridge scanning broken on 460EX
From: Stef van Os @ 2010-01-12 11:14 UTC (permalink / raw)
To: Felix Radensky, Benjamin Herrenschmidt
Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <4B4C56D5.6020008@embedded-sol.com>
Hello=20Felix,
Glad=20to=20know=20this=20is=20working=20for=20you!
I'll=20try=20to=20send=20out=20a=20patch=20later=20today.=20The=20same=20=
change=20should=20also=20be
applied=20to=20the=20"ppc4xx_probe_pci_bridge"=20function,=20as=20it=20al=
so
initialises=20PCI=20without=20type=201=20transactions.
With=20kind=20regards=20/=20Met=20vriendelijke=20groet,
Stef=20van=20Os
Prodrive=20B.V.=20
-----Original=20Message-----
From:=20Felix=20Radensky=20[mailto:felix@embedded-sol.com]=20
Sent:=20dinsdag=2012=20januari=202010=2012:03
To:=20Benjamin=20Herrenschmidt
Cc:=20Stef=20van=20Os;=20Stefan=20Roese;=20Feng=20Kan;=20linuxppc-dev@ozl=
abs.org
Subject:=20Re:=20PCI-PCI=20bridge=20scanning=20broken=20on=20460EX
Hi=20Ben
Benjamin=20Herrenschmidt=20wrote:
>=20On=20Tue,=202010-01-12=20at=2000:48=20+0200,=20Felix=20Radensky=20wro=
te:
>=20=20=20
>>=20Maybe=20because=20the=20bus=20behind=20root=20P2P=20bridge=20is=20bu=
s=200,=20and=20type=201=20
>>=20cycles=20are=20needed=20for=20bus=20numbers=20greater=20than=200.=20=
That's=20what=20460EX=20
>>=20manual=20says.
>>=20=20=20=20=20
>
>=20Well,=20no...=20the=20bus=20behind=20the=20root=20P2P=20is=20bus=201=
=20...=20the=20root=20P2P=20
>=20itself=20is=20on=20bus=200...=20but=20then,=20it's=20some=20trick=20i=
n=20the=20way=20they=20
>=20implemented=20it=20I=20suppose.
>
>=20=20=20
>>=20You=20are=20correct,=20the=20log=20is=20from=20older=20version,=20wi=
thout=20Stef's=20fix.=20I
>>=20don't=20have=20access=20to=20a=20system=20with=20devices=20behind=20=
PLX,=20and=20the=20guy=20
>>=20who=20did=20the=20testing=20used=20wrong=20kernel.
>>=20I'll=20make=20sure=20he=20uses=20the=20correct=20one=20and=20get=20b=
ack=20to=20you.=20Maybe=20
>>=20everything=20works=20after=20all=20:)=20I'm=20really=20sorry=20for=
=20confusion.
>>=20=20=20=20=20
>
>=20No=20worries=20:-)=20Feel=20free=20to=20send=20a=20proper=20patch=20t=
o=20fix=20that=20problem=20
>=20upstream=20too=20!
>
>=20=20=20
The=20kernel=20with=20Stef's=20fix=20works=20fine,=20and=20recognizes=20b=
oth=20PLX=20and
device=20behind=20it.
Stef,=20=20do=20want=20to=20provide=20a=20patch=20for=20upstream=20kernel=
,=20or=20do=20you=20want=20me
to=20do=20that=20on=20your=20behalf=20?
Thanks=20a=20lot=20everyone=20for=20you=20help=20!
Felix.
Felix.
Disclaimer:=20The=20information=20contained=20in=20this=20email,=20includ=
ing=20any=20attachments=20is=20
confidential=20and=20is=20for=20the=20sole=20use=20of=20the=20intended=20=
recipient(s).=20Any=20unauthorized=20
review,=20use,=20disclosure=20or=20distribution=20is=20prohibited.=20If=
=20you=20are=20not=20the=20intended=20
recipient,=20please=20notify=20the=20sender=20immediately=20by=20replying=
=20to=20this=20message=20and=20
destroy=20all=20copies=20of=20this=20message=20and=20any=20attachments.
^ permalink raw reply
* Re: [PATCH 03/31] hvc_console: make the ops pointer const.
From: Rusty Russell @ 2010-01-12 11:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Amit Shah, linuxppc-dev, virtualization
In-Reply-To: <1263262906.724.175.camel@pasglop>
On Tue, 12 Jan 2010 12:51:46 pm Benjamin Herrenschmidt wrote:
> On Tue, 2009-12-22 at 20:04 +0530, Amit Shah wrote:
> > From: Rusty Russell <rusty@rustcorp.com.au>
> >
> > This is nicer for modern R/O protection. And noone needs it non-const, so
> > constify the callers as well.
>
> Rusty, do you want me to take these via powerpc ?
Sure, thanks.
Rusty.
^ permalink raw reply
* Re: [PATCH]: powerpc: Fix build breakage due to incorrect location of autoconf.h
From: Joakim Tjernlund @ 2010-01-12 11:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Roel Kluin, linuxppc-dev, Richard Purdie, Anton Blanchard,
Andrew Morton, David Woodhouse
In-Reply-To: <20100112140136.c8ccc357.sfr@canb.auug.org.au>
>
> Hi Anton,
>
> On Tue, 12 Jan 2010 13:21:51 +1100 Anton Blanchard <anton@samba.org> wrote:
> >
> > commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when
> > copying direct from output) referenced include/linux/autoconf.h which
> > is now called include/generated/autoconf.h.
>
> Even with this fix, you cannot build with a separate object directory.
> See my other posting "linux-next: origin tree build failure" ...
> --
How does this work for you?
>From 044f40d169bf5fe189d5cb058f56b7cd72675ca4 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 12 Jan 2010 11:20:36 +0100
Subject: [PATCH] powerpc: Fix build breakage due to incorrect location of autoconf.h
commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 (zlib: optimize inffast when
copying direct from output) referenced include/linux/autoconf.h which
is now called include/generated/autoconf.h.
Also, -I include paths needs to be prefixed with $(srctree)
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/boot/Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 826a30a..79ebd6f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -34,8 +34,8 @@ BOOTCFLAGS += -fno-stack-protector
endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-BOOTCFLAGS += -include include/linux/autoconf.h -Iarch/powerpc/include
-BOOTCFLAGS += -Iinclude
+BOOTCFLAGS += -include include/generated/autoconf.h
+BOOTCFLAGS += -I$(srctree)/arch/powerpc/include -I$(srctree)/include
DTS_FLAGS ?= -p 1024
--
1.6.4.4
^ permalink raw reply related
* Re: linux-next: origin tree build failure
From: Joakim Tjernlund @ 2010-01-12 12:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-kernel, Linus, linux-next, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <20100112105805.50e39a77.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote on 12/01/2010 00:58:05:
>
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> cc1: error: include/linux/autoconf.h: No such file or directory
>
> (while building the boot wrappers - lots more of the same)
>
> Caused by commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib:
> optimize inffast when copying direct from output"). autoconf.h moved
> from include/linux to include/generated in commit
> 264a26838056fc2d759f58bec2e720e01fcb1bdb ("kbuild: move autoconf.h to
> include/generated") which was in linux-next since 14 Dec 2009 and in
> Linus' tree since 18 Dec 2009.
>
[SNIP]
>
> This latter build problem is probably only noticed if you build with a
> separate object directory (i.e. with O=.. on the make command). The
> previous PowerPC maintainer tells me that defining __KERNEL__ in the
> BOOTFLAGS is wrong and should have been noticed.
Is this any better w.r.t __KERNEL__?
>From 1a79993a42e17be665d3488663d81c0513b8bbfe Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 12 Jan 2010 13:31:58 +0100
Subject: [PATCH] powerpc: move __KERNEL__ define in bootwrapper.
Apparently using -D__KERNEL__ in BOOTCFLAGS is a bad thing.
Move __KERNEL__ into inffast.c where it is needed.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/boot/Makefile | 2 +-
lib/zlib_inflate/inffast.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 79ebd6f..766fb88 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -20,7 +20,7 @@
all: $(obj)/zImage
BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
- -fno-strict-aliasing -Os -msoft-float -pipe -D__KERNEL__\
+ -fno-strict-aliasing -Os -msoft-float -pipe \
-fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-isystem $(shell $(CROSS32CC) -print-file-name=include)
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
index 05e1559..919c162 100644
--- a/lib/zlib_inflate/inffast.c
+++ b/lib/zlib_inflate/inffast.c
@@ -2,7 +2,9 @@
* Copyright (C) 1995-2004 Mark Adler
* For conditions of distribution and use, see copyright notice in zlib.h
*/
-
+#ifndef __KERNEL__
+#define __KERNEL__
+#endif
#include <linux/zutil.h>
#include <asm/unaligned.h>
#include <asm/byteorder.h>
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 03/13] mpc52xx: add SCLPC register bit definitions
From: Grant Likely @ 2010-01-12 14:07 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <201001120855.59122.roman.fietze@telemotive.de>
On Tue, Jan 12, 2010 at 12:55 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> Hello Grant,
>
> On Monday 11 January 2010 20:21:22 Grant Likely wrote:
>
>> Unrelated whitespace change?
>
> My fault, as with some other white space changes. My Emacs is
> configured using some older setup found in a 2.4
> Documentation/CodingStyle. Before saving a file my spine is used to
> reformat the whole source file, which then causes those artefacts.
> I'll fix the Emacs setup and try to fix my spine, and double check
> before commits.
>
> BTW: no Emacs users amongst the kernel coders any more? At least I
> have to read "So, you can either get rid of GNU emacs, or ...".
I believe there are lots of emacs using kernel hackers. emacs is fine
and most of the style changes you were making were valid, but they
were unrelated and unimportant. Unless emacs is making automatic
changes to the files, it sounds like your emacs config is just fine.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/4xx: Add support for type 1 pci transactions on 4xx boards
From: Stef van Os @ 2010-01-12 14:09 UTC (permalink / raw)
To: Felix Radensky, Benjamin Herrenschmidt
Cc: linuxppc-dev, Stefan Roese, Feng Kan
This=20patch=20adds=20type=201=20PCI=20transactions=20to=204xx=20PCI=20co=
de,=20enabling=20the
discovery=20of
devices=20behind=20a=20PCI=20bridge.
Signed-off-by:=20Stef=20van=20Os=20<stef.van.os@gmail.com>
---
=20arch/powerpc/sysdev/ppc4xx_pci.c=20|=20=20=20=206=20++++--
=201=20files=20changed,=204=20insertions(+),=202=20deletions(-)
diff=20--git=20a/arch/powerpc/sysdev/ppc4xx_pci.c
b/arch/powerpc/sysdev/ppc4xx_pci.c
index=206ff9d71..370cc1c=20100644
---=20a/arch/powerpc/sysdev/ppc4xx_pci.c
+++=20b/arch/powerpc/sysdev/ppc4xx_pci.c
@@=20-363,7=20+363,8=20@@=20static=20void=20__init=20ppc4xx_probe_pci_bri=
dge(struct
device_node=20*np)
=20=20=20=20=20=20=20=20hose->last_busno=20=3D=20bus_range=20?=20bus_rang=
e[1]=20:=200xff;
=20=20=20=20=20=20=20=20/*=20Setup=20config=20space=20*/
-=20=20=20=20=20=20=20setup_indirect_pci(hose,=20rsrc_cfg.start,=20rsrc_c=
fg.start=20+=200x4,
0);
+=20=20=20=20=20=20=20setup_indirect_pci(hose,=20rsrc_cfg.start,=20rsrc_c=
fg.start=20+=200x4,
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PPC_INDIRECT_TYPE_SET_CFG_TY=
PE);
=20=20=20=20=20=20=20=20/*=20Disable=20all=20windows=20*/
=20=20=20=20=20=20=20=20writel(0,=20reg=20+=20PCIL0_PMM0MA);
@@=20-569,7=20+570,8=20@@=20static=20void=20__init=20ppc4xx_probe_pcix_br=
idge(struct
device_node=20*np)
=20=20=20=20=20=20=20=20hose->last_busno=20=3D=20bus_range=20?=20bus_rang=
e[1]=20:=200xff;
=20=20=20=20=20=20=20=20/*=20Setup=20config=20space=20*/
-=20=20=20=20=20=20=20setup_indirect_pci(hose,=20rsrc_cfg.start,=20rsrc_c=
fg.start=20+=200x4,
0);
+=20=20=20=20=20=20=20setup_indirect_pci(hose,=20rsrc_cfg.start,=20rsrc_c=
fg.start=20+=200x4,
+=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20PPC_INDIRECT_TYPE_SET_CFG_TY=
PE);
=20=20=20=20=20=20=20=20/*=20Disable=20all=20windows=20*/
=20=20=20=20=20=20=20=20writel(0,=20reg=20+=20PCIX0_POM0SA);
Disclaimer:=20The=20information=20contained=20in=20this=20email,=20includ=
ing=20any=20attachments=20is=20
confidential=20and=20is=20for=20the=20sole=20use=20of=20the=20intended=20=
recipient(s).=20Any=20unauthorized=20
review,=20use,=20disclosure=20or=20distribution=20is=20prohibited.=20If=
=20you=20are=20not=20the=20intended=20
recipient,=20please=20notify=20the=20sender=20immediately=20by=20replying=
=20to=20this=20message=20and=20
destroy=20all=20copies=20of=20this=20message=20and=20any=20attachments.
^ permalink raw reply
* Re: kernel panic on MPC8323 custom board
From: Dario Presti @ 2010-01-12 14:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4B476ABA.7050000@freescale.com>
Scott Wood-2 wrote:
>
>
> Turn off that mapping driver, and turn on CONFIG_MTD_PHYSMAP_OF. This
> stuff was very new in 2.6.20, though, so there may be issues. I'd
> upgrade if you can.
>
I rebuilded another kernel version 2.6.20.6 whit LTIB and u-boot 1.3.2 (I
don't have the corresponding source file of my images).
I turned on CONFIG_MTD_PHYSMAP_OF, here there is part of config file:
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_PLATRAM is not set
But still hte mapping is not showed on boot, it seems to not read yet the
blob node. The boot-log is:
U-Boot 1.3.2 (Jan 8 2010 - 12:57:17) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c2, MPC8321E, Rev: 11 at 333.333 MHz, CSB: 133 MHz
Board: Freescale MPC8323ERDB
I2C: ready
DRAM: 64 MB
FLASH: 64 MB
In: serial
Out: serial
Err: serial
Net: FSL UEC0, FSL UEC1
Hit any key to stop autoboot: 0
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
_____________________________________________________________
00.00.00 0x1957 0x00a6 Processor 0x20
## Booting image at fc100000 ...
Image Name: Linux-2.6.20.6-rt8
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1495894 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0xfc080000
Loading Device Tree to 00785000, end 007ff11f ... OK
Using MPC832x RDB machine description
Linux version 2.6.20.6-rt8 (cubit@cubit-laptop) (gcc version 4.2.3 (Sourcery
G++ Lite 4.2-171)) #9 PREEMPT Tue Jan 12 14:53:56 CET 2010
setup_arch: bootmem
mpc832x_rdb_setup_arch()
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number:
0->0
pio-handle not available
arch: exit
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/mtdblock4 rootfstype=jffs2 rw console=ttyS0,
38400
WARNING: experimental RCU implementation.
IPIC (128 IRQ sources) at fdefb700
QEIC (64 IRQ sources) at fdefa080
PID hash table entries: 256 (order: 8, 1024 bytes)
Using MPC832x RDB machine description
Linux version 2.6.20.6-rt8 (cubit@cubit-laptop) (gcc version 4.2.3 (Sourcery
G++ Lite 4.2-171)) #9 PREEMPT Tue Jan 12 14:53:56 CET 2010
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number:
0->0
pio-handle not available
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
early_node_map[1] active PFN ranges
0: 0 -> 16384
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists. Total pages: 16256
Kernel command line: root=/dev/mtdblock4 rootfstype=jffs2 rw console=ttyS0,
38400
WARNING: experimental RCU implementation.
IPIC (128 IRQ sources) at fdefb700
QEIC (64 IRQ sources) at fdefa080
PID hash table entries: 256 (order: 8, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 61200k/65536k available (2836k kernel code, 4268k reserved, 180k
data, 110k bss, 132k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 4, 65536 bytes)
TCP bind hash table entries: 1024 (order: 2, 28672 bytes)
TCP: Hash tables configured (established 2048 bind 1024)
TCP reno registered
NTFS driver 2.1.28 [Flags: R/O].
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
fuse init (API version 7.8)
JFS: nTxBlock = 478, nTxLock = 3829
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
WDT driver for MPC83xx initialized. mode:reset timeout=65535 (32 seconds)
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
ucc_tdm: Freescale QE UCC TDM Driver
config_tdm Delay for Legerity!
tdm_start 16-bit linear pcm mode active with slots 0 & 2
tdm_start UCC based TDM enabled
ucc_tdm_probe UCC based tdm module installed
UCC Ethernet Controller MII Bus: probed
ucc_geth: QE UCC Gigabit Ethernet Controller
ucc_geth: UCC2 at 0xe0103000 (irq = 20)
eth0: MTU=1500 (frame
size=1518,rx_buffer_size=1536,truesize=1792,sk_buff=160)
ucc_geth: UCC3 at 0xe0102200 (irq = 34)
eth1: MTU=1500 (frame
size=1518,rx_buffer_size=1536,truesize=1792,sk_buff=160)
SKB Handler initialized(max=64)
ICPlus IP175C: Registered new driver
block2mtd: version $Revision: 1.30 $
e01004c0.spi: MPC83xx SPI Controller driver at 0xc50aa4c0 (irq = 21)
usbmon: debugfs is not available
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
No filesystem could mount root, tried: <6>Time: timebase clocksource has
been installed.
jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Call Trace:
[C03B5E70] [C000819C] (unreliable)
[C03B5EB0] [C0026AB0]
[C03B5F00] [C02A4B98]
[C03B5F50] [C02A4DEC]
[C03B5F70] [C0003B04]
[C03B5FF0] [C00102BC]
<0>Rebooting in 180 seconds..
Do I miss to turn on something or kernel version do not support device tree?
Has u-boot 1.3.2 mtdparts command? When I try to use it an 'unknown
command' occur.
Thanks
Dario
--
View this message in context: http://old.nabble.com/kernel-panic-on-MPC8323-custom-board-tp27059752p27128312.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC,PATCH 1/7 v2] Add a common struct clk
From: Ben Dooks @ 2010-01-12 14:30 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <1263279511.160551.332624337260.1.gpush@pororo>
On Tue, Jan 12, 2010 at 05:58:31PM +1100, Jeremy Kerr wrote:
> We currently have 21 definitions of struct clk in the ARM architecture,
> each defined on a per-platform basis. This makes it difficult to define
> platform- (or architecture-) independent clock sources without making
> assumptions about struct clk.
>
> This change is an effort to unify struct clk where possible, by defining
> a common struct clk, containing a set of clock operations. Different
> clock implementations can set their own operations, and have a standard
> interface for generic code. The callback interface is exposed to the
> kernel proper, while the clock implementations only need to be seen by
> the platform internals.
>
> This allows us to share clock code among platforms, and makes it
> possible to dynamically create clock devices in platform-independent
> code.
>
> Platforms can enable the generic struct clock through
> CONFIG_USE_COMMON_STRUCT_CLK.
>
> The common clock definitions are based on a development patch from Ben
> Herrenschmidt <benh@kernel.crashing.org>.
>
> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
>
> ---
> arch/Kconfig | 3
> include/linux/clk.h | 134 +++++++++++++++++++++++++++++++++++---------
> 2 files changed, 110 insertions(+), 27 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 9d055b4..cefc026 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -140,4 +140,7 @@ config HAVE_HW_BREAKPOINT
> config HAVE_USER_RETURN_NOTIFIER
> bool
>
> +config USE_COMMON_STRUCT_CLK
> + bool
> +
> source "kernel/gcov/Kconfig"
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1d37f42..1a6199e 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -11,36 +11,101 @@
> #ifndef __LINUX_CLK_H
> #define __LINUX_CLK_H
>
> -struct device;
> +#include <linux/err.h>
>
> -/*
> - * The base API.
> +#ifdef CONFIG_USE_COMMON_STRUCT_CLK
> +
> +/* If we're using the common struct clk, we define the base clk object here,
> + * which will be 'subclassed' by device-specific implementations. For example:
> + *
> + * struct clk_foo {
> + * struct clk;
> + * [device specific fields]
> + * };
> + *
> + * We define the common clock API through a set of static inlines that call the
> + * corresponding clk_operations. The API is exactly the same as that documented
> + * in the !CONFIG_USE_COMMON_STRUCT_CLK case.
> */
>
> +struct clk {
> + const struct clk_operations *ops;
> +};
> +
> +struct clk_operations {
> + int (*enable)(struct clk *);
Personaly I'd leave the enable/disable as one call which takes
(struct clk *, bool on). these code paths tend to be pretty much the
same read/modify/write with only the modify changing depending on the
on parameter.
> + void (*disable)(struct clk *);
> + unsigned long (*get_rate)(struct clk *);
> + void (*put)(struct clk *);
> + long (*round_rate)(struct clk *, unsigned long);
> + int (*set_rate)(struct clk *, unsigned long);
> + int (*set_parent)(struct clk *, struct clk *);
> + struct clk* (*get_parent)(struct clk *);
> +};
> +
> +static inline int clk_enable(struct clk *clk)
> +{
> + if (clk->ops->enable)
> + return clk->ops->enable(clk);
> + return 0;
> +}
> +
> +static inline void clk_disable(struct clk *clk)
> +{
> + if (clk->ops->disable)
> + clk->ops->disable(clk);
> +}
> +
> +static inline unsigned long clk_get_rate(struct clk *clk)
> +{
> + if (clk->ops->get_rate)
> + return clk->ops->get_rate(clk);
> + return 0;
> +}
> +
> +static inline void clk_put(struct clk *clk)
> +{
> + if (clk->ops->put)
> + clk->ops->put(clk);
> +}
> +
> +static inline long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk->ops->round_rate)
> + return clk->ops->round_rate(clk, rate);
> + return -ENOSYS;
> +}
> +
> +static inline int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + if (clk->ops->set_rate)
> + return clk->ops->set_rate(clk, rate);
> + return -ENOSYS;
> +}
> +
> +static inline int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + if (clk->ops->set_parent)
> + return clk->ops->set_parent(clk, parent);
> + return -ENOSYS;
> +}
> +
> +static inline struct clk *clk_get_parent(struct clk *clk)
> +{
> + if (clk->ops->get_parent)
> + return clk->ops->get_parent(clk);
> + return ERR_PTR(-ENOSYS);
> +}
In the Samsung impelemtnations, the clk keeps a parent pointer and
we just return that as the esult of the clk_get_parent nless the clock
wants to override it.
> +
> +#else /* !CONFIG_USE_COMMON_STRUCT_CLK */
>
> /*
> - * struct clk - an machine class defined object / cookie.
> + * Global clock object, actual structure is declared per-machine
> */
> struct clk;
>
> /**
> - * clk_get - lookup and obtain a reference to a clock producer.
> - * @dev: device for clock "consumer"
> - * @id: clock comsumer ID
> - *
> - * Returns a struct clk corresponding to the clock producer, or
> - * valid IS_ERR() condition containing errno. The implementation
> - * uses @dev and @id to determine the clock consumer, and thereby
> - * the clock producer. (IOW, @id may be identical strings, but
> - * clk_get may return different clock producers depending on @dev.)
> - *
> - * Drivers must assume that the clock source is not enabled.
> - *
> - * clk_get should not be called from within interrupt context.
> - */
> -struct clk *clk_get(struct device *dev, const char *id);
> -
> -/**
> * clk_enable - inform the system when the clock source should be running.
> * @clk: clock source
> *
> @@ -83,12 +148,6 @@ unsigned long clk_get_rate(struct clk *clk);
> */
> void clk_put(struct clk *clk);
>
> -
> -/*
> - * The remaining APIs are optional for machine class support.
> - */
> -
> -
> /**
> * clk_round_rate - adjust a rate to the exact rate a clock can provide
> * @clk: clock source
> @@ -125,6 +184,27 @@ int clk_set_parent(struct clk *clk, struct clk *parent);
> */
> struct clk *clk_get_parent(struct clk *clk);
>
> +#endif /* !CONFIG_USE_COMMON_STRUCT_CLK */
> +
> +struct device;
> +
> +/**
> + * clk_get - lookup and obtain a reference to a clock producer.
> + * @dev: device for clock "consumer"
> + * @id: clock comsumer ID
> + *
> + * Returns a struct clk corresponding to the clock producer, or
> + * valid IS_ERR() condition containing errno. The implementation
> + * uses @dev and @id to determine the clock consumer, and thereby
> + * the clock producer. (IOW, @id may be identical strings, but
> + * clk_get may return different clock producers depending on @dev.)
> + *
> + * Drivers must assume that the clock source is not enabled.
> + *
> + * clk_get should not be called from within interrupt context.
> + */
> +struct clk *clk_get(struct device *dev, const char *id);
> +
> /**
> * clk_get_sys - get a clock based upon the device name
> * @dev_id: device name
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* Re: [PATCH 03/13] mpc52xx: add SCLPC register bit definitions
From: Grant Likely @ 2010-01-12 14:29 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <201001120855.59122.roman.fietze@telemotive.de>
On Tue, Jan 12, 2010 at 12:55 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> On Monday 11 January 2010 20:21:22 Grant Likely wrote:
>> Why is the list head being removed?
>
> Not used at all, except in initialization?
>
> Of course a seperate patch would have been needed.
For the record, I put the list_head in when writing the driver so that
requests can get queued up instead of the one-at-a-time model
currently used. It is still my intention to implement request queuing
but as with so many things I haven't got to it yet. :-/
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 02/13] powerpc/5200: LocalPlus driver: use SCLPC register structure
From: Grant Likely @ 2010-01-12 14:33 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <201001120806.03728.roman.fietze@telemotive.de>
On Tue, Jan 12, 2010 at 12:06 AM, Roman Fietze
<roman.fietze@telemotive.de> wrote:
> Hello Grant,
>
> On Monday 11 January 2010 20:15:58 Grant Likely wrote:
>
>> No patch description? =A0Very few patches are sufficiently described by
>> the subject line alone. =A0Tell me what the problem is, what the patch
>> changes, and why.
>
> And a lot of other information. Thank you very much for the effort you
> put into those patches. I almost knew that you will criticize e.g.
> patches that mix functional and "optical" changes, patches that are
> not describing more exactly what I did.
>
> As soon as I have some time left I will try to go once more from the
> original driver to the final driver using clear and separate, well
> bescribed patches, of course taking care of your and other people
> comments.
Sounds good. I look forward to seeing them.
g.
>
> Again, thanks
>
>
> Roman
>
> --
> Roman Fietze =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Telemotive AG B=FCro M=FChlha=
usen
> Breitwiesen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A073=
347 M=FChlhausen
> Tel.: +49(0)7335/18493-45 =A0 =A0 =A0 =A0http://www.telemotive.de
>
> Amtsgericht Ulm =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0HRB 541321
> Vorstand:
> Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC,PATCH 1/7 v2] Add a common struct clk
From: Ben Dooks @ 2010-01-12 14:27 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Francesco VIRLINZI, Jeremy Kerr, linuxppc-dev, linux-kernel,
linux-arm-kernel
In-Reply-To: <20100112090149.GB26435@n2100.arm.linux.org.uk>
On Tue, Jan 12, 2010 at 09:01:49AM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 12, 2010 at 09:48:44AM +0100, Francesco VIRLINZI wrote:
> > Hi Jeremy
> > In November I already sent a proposal on
> > a generic linux clk framework.
> > On that I would suggest:
> >
> >>
> >> +struct clk {
> >> + const struct clk_operations *ops;
> >>
> > spinlock_t lock;
> > const char *name;
> > int id;
>
> Name and ID are totally pointless, unless you insist on using the clk
> API in the wrong way (like S3C does.)
I assume by this you mean that a number of the s3c drives use clk_get with
their platform device and a name? if so, I agree this needs to get sorted
out.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ permalink raw reply
* Re: [RFC,PATCH 1/7 v2] Add a common struct clk
From: Ben Dooks @ 2010-01-12 14:24 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Francesco VIRLINZI, Jeremy Kerr, linuxppc-dev, linux-kernel,
linux-arm-kernel
In-Reply-To: <20100112090149.GB26435@n2100.arm.linux.org.uk>
On Tue, Jan 12, 2010 at 09:01:49AM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 12, 2010 at 09:48:44AM +0100, Francesco VIRLINZI wrote:
> > Hi Jeremy
> > In November I already sent a proposal on
> > a generic linux clk framework.
> > On that I would suggest:
> >
> >>
> >> +struct clk {
> >> + const struct clk_operations *ops;
> >>
> > spinlock_t lock;
> > const char *name;
> > int id;
>
> Name and ID are totally pointless, unless you insist on using the clk
> API in the wrong way (like S3C does.)
I do intend to change the clock lookup on the Samsung series, but we're
currently in the process of trying to do a whole pile of work on not
only adding new SoCs but also cleaning up the existing support and making
a whole pile of code common to all the Samsung SoC family.
I never got the time to go throughly through Francesco's clock framework
but it seemed rathe rcomplicated for our current requirements and also
had a whole pile of style problems that made it really difficult to read.
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
^ 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