* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Pekka Enberg @ 2009-06-12 8:25 UTC (permalink / raw)
To: Nick Piggin; +Cc: Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <20090612082145.GD24044@wotan.suse.de>
On Fri, 2009-06-12 at 10:21 +0200, Nick Piggin wrote:
> On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
> > Nick Piggin wrote:
> > >>I was able to boot yesterday's next (20090611) on this machine. Not sure
> > >>
> > >
> > >Still with SLQB? With debug options turned on?
> > >
> > Ah .. spoke too soon. The kernel was not compiled with SLQB. Sorry
> > about the confusion. I can't seem to select SLQB as the slab
> > allocator.
>
> It must have been dropped out of -next. You could just try
> a known-bad kernel with my patch applied?
Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
linux-next or something?
Pekka
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Nick Piggin @ 2009-06-12 8:21 UTC (permalink / raw)
To: Sachin Sant; +Cc: Stephen Rothwell, Pekka J Enberg, linux-next, linuxppc-dev
In-Reply-To: <4A320D12.2050802@in.ibm.com>
On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >>I was able to boot yesterday's next (20090611) on this machine. Not sure
> >>
> >
> >Still with SLQB? With debug options turned on?
> >
> Ah .. spoke too soon. The kernel was not compiled with SLQB. Sorry
> about the confusion. I can't seem to select SLQB as the slab
> allocator.
It must have been dropped out of -next. You could just try
a known-bad kernel with my patch applied?
Thanks,
Nick
^ permalink raw reply
* Re: [PowerPC] 2.6.30-git3 build break : perf counters
From: Sachin Sant @ 2009-06-12 8:16 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel
In-Reply-To: <1244788494.5554.1.camel@ht.satnam>
Jaswinder Singh Rajput wrote:
> Please check this patch :
>
> [PATCH] powerpc: perf_counter fix performance counter event types
>
> Fix compilation warnings :
> CC arch/powerpc/kernel/power7-pmu.o
> arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:297: error: array index in initializer not of integer type
> arch/powerpc/kernel/power7-pmu.c:297: error: (near initialization for power7_generic_events)
> arch/powerpc/kernel/power7-pmu.c:298: error: PERF_COUNT_INSTRUCTIONS undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:298: error: array index in initializer not of integer type
> ......<SNIP>......
>
> Reported-by: Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> ---
>
Yes this fixed the build error.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Sachin Sant @ 2009-06-12 8:08 UTC (permalink / raw)
To: Nick Piggin; +Cc: Stephen Rothwell, Pekka J Enberg, linux-next, linuxppc-dev
In-Reply-To: <20090612074213.GA21070@wotan.suse.de>
Nick Piggin wrote:
>> I was able to boot yesterday's next (20090611) on this machine. Not sure
>>
>
> Still with SLQB? With debug options turned on?
>
Ah .. spoke too soon. The kernel was not compiled with SLQB. Sorry
about the confusion. I can't seem to select SLQB as the slab
allocator.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Nick Piggin @ 2009-06-12 7:42 UTC (permalink / raw)
To: Sachin Sant; +Cc: Stephen Rothwell, Pekka J Enberg, linux-next, linuxppc-dev
In-Reply-To: <4A31EB2A.9080003@in.ibm.com>
On Fri, Jun 12, 2009 at 11:14:10AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >I can't really work it out. It seems to be the kmem_cache_cache which has
> >a problem, but there have already been lots of caches created and even
> >this samw cache_node already used right beforehand with no problem.
> >
> >Unless a CPU or node comes up or something right at this point or the
> >caller is scheduled onto a different CPU... oopses seem to all
> >have CPU#1, wheras boot CPU is probably #0 (these CPUs are node 0
> >and memory is only on node 1 and 2 where there are no CPUs if I read
> >correctly).
> >
> >I still can't see the reason for the failure, but can you try this
> >patch please and show dmesg?
> I was able to boot yesterday's next (20090611) on this machine. Not sure
Still with SLQB? With debug options turned on?
> what changed(may be because of merge with linus tree), but i can no longer
> recreate this issue with next 20090611. I was consistently able to
> recreate the problem till June 10th next tree.
I would guess some kind of memory corruption that by chance did
not break the other allocators.
Please let us know if you see any more crashes. Thanks for all
your help.
^ permalink raw reply
* "next" branch update
From: Benjamin Herrenschmidt @ 2009-06-12 7:29 UTC (permalink / raw)
To: linuxppc-dev list
I pushed the following commits, along with merging Linus tree in today.
Note that it will not boot on various machines unless the allocator
init ordering problem I mentioned earlier is fixed.
Benjamin Herrenschmidt (1):
powerpc: Fix bug in move of altivec code to vector.S
Josh Boyer (3):
powerpc/4xx: Disable PCI_LEGACY
powerpc/40x: Convert AMCC Makalu board to ppc40x_simple
powerpc/40x: Convert AMCC Kilauea/Halekala boards to ppc40x_simple
Sean MacLennan (1):
i2c: Fix confusing i2c-ibm_iic message
Stefan Roese (1):
powerpc/4xx: Sequoia: Enable NAND support
^ permalink raw reply
* [Fwd: Re: slab: setup allocators earlier in the boot sequence]
From: Benjamin Herrenschmidt @ 2009-06-12 7:29 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Forwarded message - Re: slab: setup allocators earlier in the boot sequence --]
[-- Type: message/rfc822, Size: 7803 bytes --]
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>, Linux Kernel list <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>
Subject: Re: slab: setup allocators earlier in the boot sequence
Date: Fri, 12 Jun 2009 15:07:15 +1000
Message-ID: <1244783235.7172.61.camel@pasglop>
On Fri, 2009-06-12 at 14:25 +1000, Benjamin Herrenschmidt wrote:
> I'll cook up a patch that defines a global bitmask of "forbidden" GFP
> bits and see how things go.
>From ad87215e01b257ccc1af64aa9d5776ace580dea3 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 12 Jun 2009 15:03:47 +1000
Subject: [PATCH] Sanitize "gfp" flags during boot
With the recent shuffle of initialization order to move memory related
inits earlier, various subtle breakage was introduced in archs like
powerpc due to code somewhat assuming that GFP_KERNEL can be used as
soon as the allocators are up. This is not true because any __GFP_WAIT
allocation will cause interrupts to be enabled, which can be fatal if
it happens too early.
This isn't trivial to fix on every call site. For example, powerpc's
ioremap implementation needs to be called early. For that, it uses two
different mechanisms to carve out virtual space. Before memory init,
by moving down VMALLOC_END, and then, by calling get_vm_area().
Unfortunately, the later does GFK_KERNEL allocations. But we can't do
anything else because once vmalloc's been initialized, we can no longer
safely move VMALLOC_END to carve out space.
There are other examples, wehere can can be called either very early
or later on when devices are hot-plugged. It would be a major pain for
such code to have to "know" whether it's in a context where it should
use GFP_KERNEL or GFP_NOWAIT.
Finally, by having the ability to silently removed __GFP_WAIT from
allocations, we pave the way for suspend-to-RAM to use that feature
to also remove __GFP_IO from allocations done after suspending devices
has started. This is important because such allocations may hang if
devices on the swap-out path have been suspended, but not-yet suspended
drivers don't know about it, and may deadlock themselves by being hung
into a kmalloc somewhere while holding a mutex for example.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/linux/gfp.h | 8 ++++++++
init/main.c | 5 +++++
mm/page_alloc.c | 5 +++++
mm/slab.c | 9 +++++++++
mm/slub.c | 3 +++
5 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 0bbc15f..b0f7a22 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -99,6 +99,14 @@ struct vm_area_struct;
/* 4GB DMA on some platforms */
#define GFP_DMA32 __GFP_DMA32
+/* Illegal bits */
+extern gfp_t gfp_smellybits;
+
+static inline gfp_t gfp_sanitize(gfp_t gfp_flags)
+{
+ return gfp_flags & ~gfp_smellybits;
+}
+
/* Convert GFP flags to their corresponding migrate type */
static inline int allocflags_to_migratetype(gfp_t gfp_flags)
{
diff --git a/init/main.c b/init/main.c
index 5616661..bb812c1 100644
--- a/init/main.c
+++ b/init/main.c
@@ -539,6 +539,9 @@ void __init __weak thread_info_cache_init(void)
*/
static void __init mm_init(void)
{
+ /* Degrade everything into GFP_NOWAIT for now */
+ gfp_smellybits = __GFP_WAIT | __GFP_FS | __GFP_IO;
+
mem_init();
kmem_cache_init();
vmalloc_init();
@@ -634,6 +637,8 @@ asmlinkage void __init start_kernel(void)
printk(KERN_CRIT "start_kernel(): bug: interrupts were "
"enabled early\n");
early_boot_irqs_on();
+ /* GFP_KERNEL allocations are good to go now */
+ gfp_smellybits = 0;
local_irq_enable();
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 17d5f53..efde0d5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -77,6 +77,8 @@ int percpu_pagelist_fraction;
int pageblock_order __read_mostly;
#endif
+gfp_t gfp_smellybits;
+
static void __free_pages_ok(struct page *page, unsigned int order);
/*
@@ -1473,6 +1475,9 @@ __alloc_pages_internal(gfp_t gfp_mask, unsigned int order,
unsigned long did_some_progress;
unsigned long pages_reclaimed = 0;
+ /* Sanitize flags so we don't enable irqs too early during boot */
+ gfp_mask = gfp_sanitize(gfp_mask);
+
lockdep_trace_alloc(gfp_mask);
might_sleep_if(wait);
diff --git a/mm/slab.c b/mm/slab.c
index f46b65d..87b166e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2791,6 +2791,9 @@ static int cache_grow(struct kmem_cache *cachep,
gfp_t local_flags;
struct kmem_list3 *l3;
+ /* Sanitize flags so we don't enable irqs too early during boot */
+ gfp_mask = gfp_sanitize(gfp_mask);
+
/*
* Be lazy and only check for valid flags here, keeping it out of the
* critical path in kmem_cache_alloc().
@@ -3212,6 +3215,9 @@ static void *fallback_alloc(struct kmem_cache *cache, gfp_t flags)
void *obj = NULL;
int nid;
+ /* Sanitize flags so we don't enable irqs too early during boot */
+ gfp_mask = gfp_sanitize(gfp_mask);
+
if (flags & __GFP_THISNODE)
return NULL;
@@ -3434,6 +3440,9 @@ __cache_alloc(struct kmem_cache *cachep, gfp_t flags, void *caller)
unsigned long save_flags;
void *objp;
+ /* Sanitize flags so we don't enable irqs too early during boot */
+ gfp_mask = gfp_sanitize(gfp_mask);
+
lockdep_trace_alloc(flags);
if (slab_should_failslab(cachep, flags))
diff --git a/mm/slub.c b/mm/slub.c
index 3964d3c..5c646f7 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1512,6 +1512,9 @@ static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
/* We handle __GFP_ZERO in the caller */
gfpflags &= ~__GFP_ZERO;
+ /* Sanitize flags so we don't enable irqs too early during boot */
+ gfpflags = gfp_sanitize(gfpflags);
+
if (!c->page)
goto new_slab;
--
1.6.1.2.14.gf26b5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related
* [PATCH] powerpc: Fix bug in move of altivec code to vector.S
From: Benjamin Herrenschmidt @ 2009-06-12 6:51 UTC (permalink / raw)
To: linuxppc-dev list
The patch that moved to vector.S and made common between 32 and 64-bit the
altivec code had a nasty bug on 32-bit (did I really test that ?) which
causes the kernel to blr back into userspace ... oops :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
I'm going to stick that in my -next branch along with updating it to
Linus latest tonight. Things still blow in various places because
of the mem init change, see the patch I posted to lkml (I forgot to
CC it here, I'll do that now).
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 6437f90..4846946 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -733,9 +733,11 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_NEED_DTLB_SW_LRU)
AltiVecUnavailable:
EXCEPTION_PROLOG
#ifdef CONFIG_ALTIVEC
- bne load_up_altivec /* if from user, just load it up */
+ beq 1f
+ bl load_up_altivec /* if from user, just load it up */
+ b fast_exception_return
#endif /* CONFIG_ALTIVEC */
- addi r3,r1,STACK_FRAME_OVERHEAD
+1: addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception)
PerformanceMonitor:
--
1.6.1.2.14.gf26b5
^ permalink raw reply related
* Re: [PowerPC] 2.6.30-git3 build break : perf counters
From: Jaswinder Singh Rajput @ 2009-06-12 6:34 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel
In-Reply-To: <4A31ECCD.7030805@in.ibm.com>
On Fri, 2009-06-12 at 11:21 +0530, Sachin Sant wrote:
> 2.6.30-git3 build with CONFIG_PERF_COUNTERS=y failed on a powerpc box.
>
> CC arch/powerpc/kernel/power7-pmu.o
> arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:297: error: array index in initializer not of integer type
> arch/powerpc/kernel/power7-pmu.c:297: error: (near initialization for power7_generic_events)
> arch/powerpc/kernel/power7-pmu.c:298: error: PERF_COUNT_INSTRUCTIONS undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:298: error: array index in initializer not of integer type
> ......<SNIP>......
>
> Porbably because of commit 526e9a09d2e2dcb6c75c68710465678bb647e5fe
>
Please check this patch :
[PATCH] powerpc: perf_counter fix performance counter event types
Fix compilation warnings :
CC arch/powerpc/kernel/power7-pmu.o
arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared here (not in a function)
arch/powerpc/kernel/power7-pmu.c:297: error: array index in initializer not of integer type
arch/powerpc/kernel/power7-pmu.c:297: error: (near initialization for power7_generic_events)
arch/powerpc/kernel/power7-pmu.c:298: error: PERF_COUNT_INSTRUCTIONS undeclared here (not in a function)
arch/powerpc/kernel/power7-pmu.c:298: error: array index in initializer not of integer type
......<SNIP>......
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/powerpc/kernel/power7-pmu.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7-pmu.c
index b3f7d12..b72e7a1 100644
--- a/arch/powerpc/kernel/power7-pmu.c
+++ b/arch/powerpc/kernel/power7-pmu.c
@@ -294,12 +294,12 @@ static void power7_disable_pmc(unsigned int pmc, u64 mmcr[])
}
static int power7_generic_events[] = {
- [PERF_COUNT_CPU_CYCLES] = 0x1e,
- [PERF_COUNT_INSTRUCTIONS] = 2,
- [PERF_COUNT_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU */
- [PERF_COUNT_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
- [PERF_COUNT_BRANCH_INSTRUCTIONS] = 0x10068, /* BRU_FIN */
- [PERF_COUNT_BRANCH_MISSES] = 0x400f6, /* BR_MPRED */
+ [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
+ [PERF_COUNT_HW_INSTRUCTIONS] = 2,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU*/
+ [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x10068, /* BRU_FIN */
+ [PERF_COUNT_HW_BRANCH_MISSES] = 0x400f6, /* BR_MPRED */
};
#define C(x) PERF_COUNT_HW_CACHE_##x
--
1.6.3.2
^ permalink raw reply related
* Re: [PowerPC] 2.6.30-git3 build break : perf counters
From: Jaswinder Singh Rajput @ 2009-06-12 6:13 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel
In-Reply-To: <4A31ECCD.7030805@in.ibm.com>
Hello Sachin,
On Fri, 2009-06-12 at 11:21 +0530, Sachin Sant wrote:
> 2.6.30-git3 build with CONFIG_PERF_COUNTERS=y failed on a powerpc box.
>
> CC arch/powerpc/kernel/power7-pmu.o
> arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:297: error: array index in initializer not of integer type
> arch/powerpc/kernel/power7-pmu.c:297: error: (near initialization for power7_generic_events)
> arch/powerpc/kernel/power7-pmu.c:298: error: PERF_COUNT_INSTRUCTIONS undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:298: error: array index in initializer not of integer type
> ......<SNIP>......
>
Is this fix your problem :
diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7-pmu.c
index b3f7d12..fb72404 100644
--- a/arch/powerpc/kernel/power7-pmu.c
+++ b/arch/powerpc/kernel/power7-pmu.c
@@ -294,12 +294,12 @@ static void power7_disable_pmc(unsigned int pmc, u64 mmcr[])
}
static int power7_generic_events[] = {
- [PERF_COUNT_CPU_CYCLES] = 0x1e,
- [PERF_COUNT_INSTRUCTIONS] = 2,
- [PERF_COUNT_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU */
- [PERF_COUNT_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
- [PERF_COUNT_BRANCH_INSTRUCTIONS] = 0x10068, /* BRU_FIN */
- [PERF_COUNT_BRANCH_MISSES] = 0x400f6, /* BR_MPRED */
+ [PERF_COUNT_HW_CPU_CYCLES] = 0x1e,
+ [PERF_COUNT_HW_INSTRUCTIONS] = 2,
+ [PERF_COUNT_HW_CACHE_REFERENCES] = 0xc880, /* LD_REF_L1_LSU */
+ [PERF_COUNT_HW_CACHE_MISSES] = 0x400f0, /* LD_MISS_L1 */
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x10068, /* BRU_FIN */
+ [PERF_COUNT_HW_BRANCH_MISSES] = 0x400f6, /* BR_MPRED */
};
#define C(x) PERF_COUNT_HW_CACHE_##x
^ permalink raw reply related
* Re: [PATCH v4] 83xx: add support for the kmeter1 board.
From: Heiko Schocher @ 2009-06-12 5:27 UTC (permalink / raw)
To: Heiko Schocher, Kumar Gala, Scott Wood, linuxppc-dev
In-Reply-To: <20090612011332.GA9084@yookeroo.seuss>
Hello David,
David Gibson wrote:
> On Thu, Jun 11, 2009 at 08:10:41PM +0200, Heiko Schocher wrote:
>> The following series implements basic board support for
>> the kmeter1 board from keymile, based on a MPC8360.
>
> [snip]
>> + par_io@1400 {
>> + reg = <0x1400 0x100>;
>> + device_type = "par_io";
>
> This should have a compatible value instead of a device_type value.
compatible = "fsl,mpc8360-par_io"; ?
> [snip]
>
>> + num-ports = <7>;
>> +
>> + pio_ucc1: ucc_pin@00 {
>
> Since these nodes have addresses, they should also have reg
> properties. And the parent should have #address-cells and
> #size-cells.
added "#address-cells" and "#size-cells", but couldn;t find what
I should write in a "reg" entry ... I think something like that:
reg = <0x00 0x01>;
?
> [snip]
>> + qe@100000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "qe";
>
> This device_type should not be here.
deleted.
>> + compatible = "fsl,qe";
>> + ranges = <0x0 0x100000 0x100000>;
>> + reg = <0x100000 0x480>;
>> + clock-frequency = <0>; /* Filled in by U-Boot */
>> + brg-frequency = <0>; /* Filled in by U-Boot */
>> + bus-frequency = <0>; /* Filled in by U-Boot */
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PowerPC] 2.6.30-git3 build break : perf counters
From: Sachin Sant @ 2009-06-12 5:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
2.6.30-git3 build with CONFIG_PERF_COUNTERS=y failed on a powerpc box.
CC arch/powerpc/kernel/power7-pmu.o
arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared here (not in a function)
arch/powerpc/kernel/power7-pmu.c:297: error: array index in initializer not of integer type
arch/powerpc/kernel/power7-pmu.c:297: error: (near initialization for power7_generic_events)
arch/powerpc/kernel/power7-pmu.c:298: error: PERF_COUNT_INSTRUCTIONS undeclared here (not in a function)
arch/powerpc/kernel/power7-pmu.c:298: error: array index in initializer not of integer type
......<SNIP>......
Porbably because of commit 526e9a09d2e2dcb6c75c68710465678bb647e5fe
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Sachin Sant @ 2009-06-12 5:44 UTC (permalink / raw)
To: Nick Piggin; +Cc: Stephen Rothwell, Pekka J Enberg, linux-next, linuxppc-dev
In-Reply-To: <20090609141903.GE15219@wotan.suse.de>
Nick Piggin wrote:
> I can't really work it out. It seems to be the kmem_cache_cache which has
> a problem, but there have already been lots of caches created and even
> this samw cache_node already used right beforehand with no problem.
>
> Unless a CPU or node comes up or something right at this point or the
> caller is scheduled onto a different CPU... oopses seem to all
> have CPU#1, wheras boot CPU is probably #0 (these CPUs are node 0
> and memory is only on node 1 and 2 where there are no CPUs if I read
> correctly).
>
> I still can't see the reason for the failure, but can you try this
> patch please and show dmesg?
I was able to boot yesterday's next (20090611) on this machine. Not sure
what changed(may be because of merge with linus tree), but i can no longer
recreate this issue with next 20090611. I was consistently able to
recreate the problem till June 10th next tree.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH] powerpc: Make RTAS instantiation depend on CONFIG_PPC_RTAS
From: Michael Ellerman @ 2009-06-12 4:08 UTC (permalink / raw)
To: linuxppc-dev
Currently prom_init.c always instantiates RTAS, even if the kernel
is built without RTAS support - that seems wrong.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/prom_init.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 2f0e64b..6c2dc59 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1052,6 +1052,7 @@ static void __init prom_init_mem(void)
}
+#ifdef CONFIG_PPC_RTAS
/*
* Allocate room for and instantiate RTAS
*/
@@ -1109,6 +1110,9 @@ static void __init prom_instantiate_rtas(void)
prom_debug("prom_instantiate_rtas: end...\n");
}
+#else
+static inline void prom_instantiate_rtas(void) { }
+#endif /* CONFIG_PPC_RTAS */
#ifdef CONFIG_PPC64
/*
--
1.6.2.1
^ permalink raw reply related
* [PATCH 1/1] EDAC: Add DDR3 memory type for MPC85xx EDAC
From: yshi @ 2009-06-12 1:26 UTC (permalink / raw)
To: dougthompson, bluesmoke-devel@lists.sourceforge.net
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
=EF=BB=BFSince some new MPC85xx SOCs support DDR3 memory now, so
add DDR3 memory type for MPC85xx EDAC.
Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
b/drivers/edac/edac_core.h | 4 ++++
b/drivers/edac/edac_mc_sysfs.c | 4 +++-
b/drivers/edac/mpc85xx_edac.c | 6 ++++++
b/drivers/edac/mpc85xx_edac.h | 1 +
4 files changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/edac/mpc85xx_edac.h
+++ b/drivers/edac/mpc85xx_edac.h
@@ -53,6 +53,7 @@
=20
#define DSC_SDTYPE_DDR 0x02000000
#define DSC_SDTYPE_DDR2 0x03000000
+#define DSC_SDTYPE_DDR3 0x07000000
#define DSC_X32_EN 0x00000020
=20
/* Err_Int_En */
--- a/drivers/edac/edac_core.h
+++ b/drivers/edac/edac_core.h
@@ -149,6 +149,8 @@ enum mem_type {
MEM_FB_DDR2, /* fully buffered DDR2 */
MEM_RDDR2, /* Registered DDR2 RAM */
MEM_XDR, /* Rambus XDR */
+ MEM_DDR3, /* DDR3 RAM */
+ MEM_RDDR3, /* Registered DDR3 RAM */
};
=20
#define MEM_FLAG_EMPTY BIT(MEM_EMPTY)
@@ -166,6 +168,8 @@ enum mem_type {
#define MEM_FLAG_FB_DDR2 BIT(MEM_FB_DDR2)
#define MEM_FLAG_RDDR2 BIT(MEM_RDDR2)
#define MEM_FLAG_XDR BIT(MEM_XDR)
+#define MEM_FLAG_DDR3 BIT(MEM_DDR3)
+#define MEM_FLAG_RDDR3 BIT(MEM_RDDR3)
=20
/* chipset Error Detection and Correction capabilities and mode */
enum edac_type {
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -757,6 +757,9 @@ static void __devinit mpc85xx_init_csrow
case DSC_SDTYPE_DDR2:
mtype =3D MEM_RDDR2;
break;
+ case DSC_SDTYPE_DDR3:
+ mtype =3D MEM_RDDR3;
+ break;
default:
mtype =3D MEM_UNKNOWN;
break;
@@ -769,6 +772,9 @@ static void __devinit mpc85xx_init_csrow
case DSC_SDTYPE_DDR2:
mtype =3D MEM_DDR2;
break;
+ case DSC_SDTYPE_DDR3:
+ mtype =3D MEM_DDR3;
+ break;
default:
mtype =3D MEM_UNKNOWN;
break;
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -94,7 +94,9 @@ static const char *mem_types[] =3D {
[MEM_DDR2] =3D "Unbuffered-DDR2",
[MEM_FB_DDR2] =3D "FullyBuffered-DDR2",
[MEM_RDDR2] =3D "Registered-DDR2",
- [MEM_XDR] =3D "XDR"
+ [MEM_XDR] =3D "XDR",
+ [MEM_DDR3] =3D "Unbuffered-DDR3",
+ [MEM_RDDR3] =3D "Registered-DDR3"
};
=20
static const char *dev_types[] =3D {
^ permalink raw reply
* Re: [PATCH v4] 83xx: add support for the kmeter1 board.
From: David Gibson @ 2009-06-12 1:13 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <4A3148A1.3030403@denx.de>
On Thu, Jun 11, 2009 at 08:10:41PM +0200, Heiko Schocher wrote:
> The following series implements basic board support for
> the kmeter1 board from keymile, based on a MPC8360.
[snip]
> + par_io@1400 {
> + reg = <0x1400 0x100>;
> + device_type = "par_io";
This should have a compatible value instead of a device_type value.
[snip]
> + num-ports = <7>;
> +
> + pio_ucc1: ucc_pin@00 {
Since these nodes have addresses, they should also have reg
properties. And the parent should have #address-cells and
#size-cells.
[snip]
> + qe@100000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "qe";
This device_type should not be here.
> + compatible = "fsl,qe";
> + ranges = <0x0 0x100000 0x100000>;
> + reg = <0x100000 0x480>;
> + clock-frequency = <0>; /* Filled in by U-Boot */
> + brg-frequency = <0>; /* Filled in by U-Boot */
> + bus-frequency = <0>; /* Filled in by U-Boot */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 1:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, ppc-dev, linux-kernel, linux-next, paulus,
Ingo Molnar, Linus
In-Reply-To: <20090612102427.32582baa.sfr@canb.auug.org.au>
On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Jun 2009 10:14:22 +1000
> Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
>
> Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> unify and fix delayed counter wakeup") added global definitions.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Linus, please apply. BTW, This is _EXACTLY_ why this should have been in
-next for a few days before being merged :-(
Cheers,
Ben.
> ---
> arch/powerpc/include/asm/hw_irq.h | 3 ---
> arch/powerpc/kernel/irq.c | 1 +
> 2 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
> index 20a44d0..5351237 100644
> --- a/arch/powerpc/include/asm/hw_irq.h
> +++ b/arch/powerpc/include/asm/hw_irq.h
> @@ -156,8 +156,6 @@ static inline void clear_perf_counter_pending(void)
> "i" (offsetof(struct paca_struct, perf_counter_pending)));
> }
>
> -extern void perf_counter_do_pending(void);
> -
> #else
>
> static inline unsigned long test_perf_counter_pending(void)
> @@ -167,7 +165,6 @@ static inline unsigned long test_perf_counter_pending(void)
>
> static inline void set_perf_counter_pending(void) {}
> static inline void clear_perf_counter_pending(void) {}
> -static inline void perf_counter_do_pending(void) {}
> #endif /* CONFIG_PERF_COUNTERS */
>
> #endif /* __KERNEL__ */
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index feff792..844d3f8 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -53,6 +53,7 @@
> #include <linux/bootmem.h>
> #include <linux/pci.h>
> #include <linux/debugfs.h>
> +#include <linux/perf_counter.h>
>
> #include <asm/uaccess.h>
> #include <asm/system.h>
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Paul Mackerras @ 2009-06-12 0:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Peter Zijlstra, Linus, linux-kernel, linux-next, Ingo Molnar,
ppc-dev
In-Reply-To: <20090612102427.32582baa.sfr@canb.auug.org.au>
Stephen Rothwell writes:
> Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
>
> Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> unify and fix delayed counter wakeup") added global definitions.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: PWM class? (was: Re: MPC52xx simple GPIO support)
From: Anton Vorontsov @ 2009-06-12 0:37 UTC (permalink / raw)
To: Grant Likely; +Cc: ppc-dev, linux-kernel, Stefan Strobl
In-Reply-To: <fa686aa40906111500w1760290bm890f3ee132500b1d@mail.gmail.com>
On Thu, Jun 11, 2009 at 04:00:51PM -0600, Grant Likely wrote:
> On Wed, Jun 3, 2009 at 7:22 AM, Anton Vorontsov<avorontsov@ru.mvista.com> wrote:
> > On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
> > [...]
> >> The led class provides support for setting the brightness, which
> >> obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
> >> would support it in PWM mode though. I'm now wandering how this could be
> >> best implemented.
> >>
> >> 1) - Create some PWM class similar to the GPIO class
> >> - Add support for PWM mode in mpc52xx_gpt.c that uses that PWM class
> >> - And add an interface for the LED to use the PWM class
> >>
> >> 2) - Create an LED driver that accesses the mpc52xx_gpt directly.
> >>
> >> I think I would be overwhelmed trying to implement (1) but am confident
> >> to do (2). What do you think is the right approach?
> >
> > I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
> > GPIOLIB. (2) can be an acceptable approach for now, but for the
> > long-term solution (1) is the way to go.
> >
> > The non-lib PWM API is already there, see include/linux/pwm.h,
> > and arch/arm/mach-pxa/pwm.c as an implementation example.
> >
> > Note that PXA implementation is SOC-specific, which is not very
> > good.
> >
> > So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
> > ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
> > driver (of course, after adding appropriate OF code into it).
>
> Ugh. The referenced pwm api is about as trivial as it gets; it is an
> anonymous context pointer (anonymous struct pwm_device *) with a set
> of accessor functions. PWMs are also not nearly as common as GPIO
> pins, and I am not interested in gpiolib being duplicated for PWMs, at
> least not until there are more that just two examples of use to draw
> from.
I didn't say that we should duplicate gpiolib. I said that we
might borrow some ideas. ;-)
> If anything, I'd rather struct pwm_device be non-anonymous and contain
> a set of ops which call directly into the driver. That way is at
> least multiplatform friendly. I don't think the gpio API is the
> example to follow here. But even then I think it is premature to try
> and define a PWM api. Personally, I'd modify mpc52xx_gpt to export
> its own PWM interface for the time being using the existing GPIO
> infrastructure to find the appropriate pin.
Jon Smirl found that there were already some efforts put
into making generic PWM class:
http://thread.gmane.org/gmane.linux.kernel.embedded/1160
Briefly looking, the class is pretty cool. Somebody should just
continue this work.
> If you do decide to do a generic PWM api, then I think the way to go
> is to build it as an extension to gpiolib.
I don't think David Brownell will like this idea. But
who knows... maybe.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* linux-next: origin tree build failure
From: Stephen Rothwell @ 2009-06-12 0:24 UTC (permalink / raw)
To: Linus
Cc: Peter Zijlstra, linux-kernel, linux-next, paulus, Ingo Molnar,
ppc-dev
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
include/linux/perf_counter.h:677: error: redefinition of 'perf_counter_do_pending'
arch/powerpc/include/asm/hw_irq.h:170: note: previous definition of 'perf_counter_do_pending' was here
Caused by commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
unify and fix delayed counter wakeup") which added the former definitions
but forgot the remove the latter.
I applied the following patch.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Jun 2009 10:14:22 +1000
Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
unify and fix delayed counter wakeup") added global definitions.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/hw_irq.h | 3 ---
arch/powerpc/kernel/irq.c | 1 +
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index 20a44d0..5351237 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -156,8 +156,6 @@ static inline void clear_perf_counter_pending(void)
"i" (offsetof(struct paca_struct, perf_counter_pending)));
}
-extern void perf_counter_do_pending(void);
-
#else
static inline unsigned long test_perf_counter_pending(void)
@@ -167,7 +165,6 @@ static inline unsigned long test_perf_counter_pending(void)
static inline void set_perf_counter_pending(void) {}
static inline void clear_perf_counter_pending(void) {}
-static inline void perf_counter_do_pending(void) {}
#endif /* CONFIG_PERF_COUNTERS */
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index feff792..844d3f8 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -53,6 +53,7 @@
#include <linux/bootmem.h>
#include <linux/pci.h>
#include <linux/debugfs.h>
+#include <linux/perf_counter.h>
#include <asm/uaccess.h>
#include <asm/system.h>
--
1.6.3.1
^ permalink raw reply related
* [PATCH 2/2] uio: add an of_genirq driver
From: Wolfram Sang @ 2009-06-12 0:04 UTC (permalink / raw)
To: linux-kernel; +Cc: devicetree-discuss, Hans J. Koch, linuxppc-dev, Greg KH
In-Reply-To: <1244765062-14144-1-git-send-email-w.sang@pengutronix.de>
Picking up the now exported generic probe function from the
platform-variant of this driver, this patch adds an of-version. Also add
the binding documentation.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Greg KH <gregkh@suse.de>
---
In probe, I put the resources-array on the stack to simplify the code. If this
is considered too huge for the stack (140 byte for a 32-bit system at the
moment), I can also post a version using kzalloc.
Documentation/powerpc/dts-bindings/uio-generic.txt | 16 +++
drivers/uio/Kconfig | 6 +
drivers/uio/Makefile | 1 +
drivers/uio/uio_of_genirq.c | 98 ++++++++++++++++++++
4 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/uio-generic.txt
create mode 100644 drivers/uio/uio_of_genirq.c
diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt b/Documentation/powerpc/dts-bindings/uio-generic.txt
new file mode 100644
index 0000000..8ad9861
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/uio-generic.txt
@@ -0,0 +1,16 @@
+UIO for custom devices
+
+A device which will be mapped using the UIO subsystem.
+
+Properties:
+ - compatible : should contain the specific model used, followed by
+ "generic-uio".
+ - reg : address range(s) of the device (up to MAX_UIO_MAPS)
+ - interrupts : interrupt of the device
+
+Example:
+ c64fpga@0 {
+ compatible = "ptx,c64fpga001", "generic-uio";
+ reg = <0x0 0x10000>;
+ interrupts = <0 0 3>;
+ };
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 7f86534..18efe38 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -46,6 +46,12 @@ config UIO_PDRV_GENIRQ
If you don't know what to do here, say N.
+config UIO_OF_GENIRQ
+ tristate "Userspace I/O OF driver with generic IRQ handling"
+ depends on UIO_PDRV_GENIRQ && OF
+ help
+ OF wrapper for the above platform driver.
+
config UIO_SMX
tristate "SMX cryptengine UIO interface"
default n
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 5c2586d..089fd56 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_UIO) += uio.o
obj-$(CONFIG_UIO_CIF) += uio_cif.o
obj-$(CONFIG_UIO_PDRV) += uio_pdrv.o
obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
+obj-$(CONFIG_UIO_OF_GENIRQ) += uio_of_genirq.o
obj-$(CONFIG_UIO_SMX) += uio_smx.o
obj-$(CONFIG_UIO_AEC) += uio_aec.o
obj-$(CONFIG_UIO_SERCOS3) += uio_sercos3.o
diff --git a/drivers/uio/uio_of_genirq.c b/drivers/uio/uio_of_genirq.c
new file mode 100644
index 0000000..254ec5b
--- /dev/null
+++ b/drivers/uio/uio_of_genirq.c
@@ -0,0 +1,98 @@
+/*
+ * OF wrapper to make use of the uio_pdrv_genirq-driver.
+ *
+ * Copyright (C) 2009 Wolfram Sang, Pengutronix
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/uio_driver.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/uio_pdrv_genirq.h>
+
+#define OF_DRIVER_VERSION "1"
+
+static __devinit int uio_of_genirq_probe(struct of_device *op,
+ const struct of_device_id *match)
+{
+ struct uio_info *uioinfo;
+ struct resource resources[MAX_UIO_MAPS];
+ int i, ret;
+
+ uioinfo = kzalloc(sizeof(*uioinfo), GFP_KERNEL);
+ if (!uioinfo)
+ return -ENOMEM;
+
+ uioinfo->name = op->node->name;
+ uioinfo->version = OF_DRIVER_VERSION;
+ uioinfo->irq = irq_of_parse_and_map(op->node, 0);
+ if (!uioinfo->irq)
+ uioinfo->irq = UIO_IRQ_NONE;
+
+ for (i = 0; i < MAX_UIO_MAPS; ++i)
+ if (of_address_to_resource(op->node, i, &resources[i]))
+ break;
+
+ ret = __uio_pdrv_genirq_probe(&op->dev, uioinfo, &resources, i);
+ if (ret)
+ goto err_cleanup;
+
+ return 0;
+
+err_cleanup:
+ if (uioinfo->irq != UIO_IRQ_NONE)
+ irq_dispose_mapping(uioinfo->irq);
+
+ kfree(uioinfo);
+ return ret;
+}
+
+static __devexit int uio_of_genirq_remove(struct of_device *op)
+{
+ struct uio_pdrv_genirq_platdata *priv = dev_get_drvdata(&op->dev);
+
+ uio_unregister_device(priv->uioinfo);
+
+ if (priv->uioinfo->irq != UIO_IRQ_NONE)
+ irq_dispose_mapping(priv->uioinfo->irq);
+
+ kfree(priv->uioinfo);
+ kfree(priv);
+ return 0;
+}
+
+/* Match table for of_platform binding */
+static const struct of_device_id __devinitconst uio_of_genirq_match[] = {
+ { .compatible = "generic-uio", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, uio_of_genirq_match);
+
+static struct of_platform_driver uio_of_genirq_driver = {
+ .owner = THIS_MODULE,
+ .name = "uio-of-genirq",
+ .match_table = uio_of_genirq_match,
+ .probe = uio_of_genirq_probe,
+ .remove = __devexit_p(uio_of_genirq_remove),
+};
+
+static inline int __init uio_of_genirq_init(void)
+{
+ return of_register_platform_driver(&uio_of_genirq_driver);
+}
+module_init(uio_of_genirq_init);
+
+static inline void __exit uio_of_genirq_exit(void)
+{
+ of_unregister_platform_driver(&uio_of_genirq_driver);
+}
+module_exit(uio_of_genirq_exit);
+
+MODULE_AUTHOR("Wolfram Sang");
+MODULE_DESCRIPTION("Userspace I/O OF driver with generic IRQ handling");
+MODULE_LICENSE("GPL v2");
--
1.6.3.1
^ permalink raw reply related
* [PATCH 1/2] uio/pdrv_genirq: Refactor probe routine to expose a generic part
From: Wolfram Sang @ 2009-06-12 0:04 UTC (permalink / raw)
To: linux-kernel; +Cc: devicetree-discuss, Hans J. Koch, linuxppc-dev, Greg KH
In-Reply-To: <1244765062-14144-1-git-send-email-w.sang@pengutronix.de>
This patch refactors the probe routine, so that an of-version of a similiar
driver can pick it up later.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Hans J. Koch <hjk@linutronix.de>
Cc: Greg KH <gregkh@suse.de>
---
drivers/uio/uio_pdrv_genirq.c | 60 ++++++++++++++++++++------------------
include/linux/uio_pdrv_genirq.h | 13 ++++++++
2 files changed, 45 insertions(+), 28 deletions(-)
create mode 100644 include/linux/uio_pdrv_genirq.h
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index 3f06818..8f8a0f9 100644
--- a/drivers/uio/uio_pdrv_genirq.c
+++ b/drivers/uio/uio_pdrv_genirq.c
@@ -20,15 +20,10 @@
#include <linux/bitops.h>
#include <linux/interrupt.h>
#include <linux/stringify.h>
+#include <linux/uio_pdrv_genirq.h>
#define DRIVER_NAME "uio_pdrv_genirq"
-struct uio_pdrv_genirq_platdata {
- struct uio_info *uioinfo;
- spinlock_t lock;
- unsigned long flags;
-};
-
static irqreturn_t uio_pdrv_genirq_handler(int irq, struct uio_info *dev_info)
{
struct uio_pdrv_genirq_platdata *priv = dev_info->priv;
@@ -68,29 +63,18 @@ static int uio_pdrv_genirq_irqcontrol(struct uio_info *dev_info, s32 irq_on)
return 0;
}
-static int uio_pdrv_genirq_probe(struct platform_device *pdev)
+int __uio_pdrv_genirq_probe(struct device *dev, struct uio_info *uioinfo,
+ struct resource *resources, unsigned int num_resources)
{
- struct uio_info *uioinfo = pdev->dev.platform_data;
struct uio_pdrv_genirq_platdata *priv;
struct uio_mem *uiomem;
- int ret = -EINVAL;
- int i;
-
- if (!uioinfo || !uioinfo->name || !uioinfo->version) {
- dev_err(&pdev->dev, "missing platform_data\n");
- goto bad0;
- }
-
- if (uioinfo->handler || uioinfo->irqcontrol ||
- uioinfo->irq_flags & IRQF_SHARED) {
- dev_err(&pdev->dev, "interrupt configuration error\n");
- goto bad0;
- }
+ unsigned int i;
+ int ret;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
- dev_err(&pdev->dev, "unable to kmalloc\n");
+ dev_err(dev, "unable to kmalloc\n");
goto bad0;
}
@@ -100,14 +84,14 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
uiomem = &uioinfo->mem[0];
- for (i = 0; i < pdev->num_resources; ++i) {
- struct resource *r = &pdev->resource[i];
+ for (i = 0; i < num_resources; ++i) {
+ struct resource *r = resources + i;
if (r->flags != IORESOURCE_MEM)
continue;
if (uiomem >= &uioinfo->mem[MAX_UIO_MAPS]) {
- dev_warn(&pdev->dev, "device has more than "
+ dev_warn(dev, "device has more than "
__stringify(MAX_UIO_MAPS)
" I/O memory resources.\n");
break;
@@ -138,19 +122,39 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
uioinfo->irqcontrol = uio_pdrv_genirq_irqcontrol;
uioinfo->priv = priv;
- ret = uio_register_device(&pdev->dev, priv->uioinfo);
+ ret = uio_register_device(dev, priv->uioinfo);
if (ret) {
- dev_err(&pdev->dev, "unable to register uio device\n");
+ dev_err(dev, "unable to register uio device\n");
goto bad1;
}
- platform_set_drvdata(pdev, priv);
+ dev_set_drvdata(dev, priv);
return 0;
bad1:
kfree(priv);
bad0:
return ret;
}
+EXPORT_SYMBOL_GPL(__uio_pdrv_genirq_probe);
+
+static int uio_pdrv_genirq_probe(struct platform_device *pdev)
+{
+ struct uio_info *uioinfo = pdev->dev.platform_data;
+
+ if (!uioinfo || !uioinfo->name || !uioinfo->version) {
+ dev_err(&pdev->dev, "missing platform_data\n");
+ return -EINVAL;
+ }
+
+ if (uioinfo->handler || uioinfo->irqcontrol ||
+ uioinfo->irq_flags & IRQF_SHARED) {
+ dev_err(&pdev->dev, "interrupt configuration error\n");
+ return -EINVAL;
+ }
+
+ return __uio_pdrv_genirq_probe(&pdev->dev, uioinfo, pdev->resource,
+ pdev->num_resources);
+}
static int uio_pdrv_genirq_remove(struct platform_device *pdev)
{
diff --git a/include/linux/uio_pdrv_genirq.h b/include/linux/uio_pdrv_genirq.h
new file mode 100644
index 0000000..a410390
--- /dev/null
+++ b/include/linux/uio_pdrv_genirq.h
@@ -0,0 +1,13 @@
+#ifndef _LINUX_UIO_PDRV_GENIRQ_H
+#define _LINUX_UIO_PDRV_GENIRQ_H
+
+struct uio_pdrv_genirq_platdata {
+ struct uio_info *uioinfo;
+ spinlock_t lock;
+ unsigned long flags;
+};
+
+extern int __uio_pdrv_genirq_probe(struct device *dev, struct uio_info *uioinfo,
+ struct resource *resources, unsigned int num_resources);
+
+#endif
--
1.6.3.1
^ permalink raw reply related
* [PATCH 0/2] add OF wrapper for uio-pdrv-genirq
From: Wolfram Sang @ 2009-06-12 0:04 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, devicetree-discuss
This series adds an OF wrapper for the uio-pdrv-genirq driver.
Patch 1 refactors the platform driver to expose a generic probe-routine.
Patch 2 then adds the OF wrapper. Documentation for the binding is also added.
There may be an issue with stack-usage, as noted there.
Tested on MPC5200B-based custom boards with 2.6.30.
(Note: this is not meant for the current merge window.)
Thanks,
Wolfram
^ permalink raw reply
* Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: David Gibson @ 2009-06-11 23:29 UTC (permalink / raw)
To: Nate Case; +Cc: linuxppc-dev
In-Reply-To: <1244736299.29684.1641.camel@localhost.localdomain>
On Thu, Jun 11, 2009 at 11:04:59AM -0500, Nate Case wrote:
> Hi David,
>
> Thanks for the comments.
>
> On Thu, 2009-06-11 at 11:32 +1000, David Gibson wrote:
> > These last two aren't standard properties, so should probably be
> > "xes,form-factor" and "xes,boot-bank".
>
> I'll just delete them for now since they're not critical.
>
> > > + pmcslots {
> >
> > What does this structure model? Without any reg properties it's kind
> > of hard to see what you could do with it.
>
> This would be a bit more obvious to those familiar with CompactPCI and
> PMC modules. It aims to describe how many PMC slots are in the system,
> and gives information on whether or not a module is installed and if
> it's monarch of the bus or not. So it's really just a description of
> the hardware. The properties themselves are useful because you may have
> to read from GPIO lines to get this information (which may be accessible
> only via I2C, which can't be done too early in the kernel). A reg
> property could be used just for indexing the slots, but there are no
> real memory-mapped resources involved for the slot itself (that
> information would go in the PCI nodes).
Ok. I guess it would be a bit more normal to associate this sort of
passive information more closely with the bus information it relates
to. But I don't know whether that makes sense in this particular
instance.
> It'd be nice if we could get a device tree standard for this type of
> information in the future, but for now I can just delete it since we
> don't yet rely on it in the kernel.
Ok, that's probably reasonable for now. I think it would be wise to
write up a draft binding for it.
> > > +
> > > + tbi2: tbi-phy@11 {
> > > + reg = <0x11>;
> > > + device_type = "tbi-phy";
> >
> > And this one, too. Although this node should probably have a
> > compatible property instead.
>
> I don't think I can drop that device_type yet. All the other device
> trees for Freescale boards use it, and the Freescale MDIO driver appears
> to rely on it. A future patch I suppose?
Ick, ok. Fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: PWM class? (was: Re: MPC52xx simple GPIO support)
From: Grant Likely @ 2009-06-11 22:00 UTC (permalink / raw)
To: avorontsov; +Cc: ppc-dev, linux-kernel, Stefan Strobl
In-Reply-To: <20090603132217.GA18353@oksana.dev.rtsoft.ru>
On Wed, Jun 3, 2009 at 7:22 AM, Anton Vorontsov<avorontsov@ru.mvista.com> w=
rote:
> On Wed, Jun 03, 2009 at 02:42:26PM +0200, Stefan Strobl wrote:
> [...]
>> The led class provides support for setting the brightness, which
>> obviously the gpio driver doesn't support. The hardware (mpc52xx_gpt)
>> would support it in PWM mode though. I'm now wandering how this could be
>> best implemented.
>>
>> 1) - Create some PWM class similar to the GPIO class
>> =A0 =A0- Add support for PWM mode in mpc52xx_gpt.c that uses that PWM cl=
ass
>> =A0 =A0- And add an interface for the LED to use the PWM class
>>
>> 2) - Create an LED driver that accesses the mpc52xx_gpt directly.
>>
>> I think I would be overwhelmed trying to implement (1) but am confident
>> to do (2). What do you think is the right approach?
>
> I'd suggest creating a generic PWM class, i.e. PWMLIB, alike to
> GPIOLIB. (2) can be an acceptable approach for now, but for the
> long-term solution (1) is the way to go.
>
> The non-lib PWM API is already there, see include/linux/pwm.h,
> and arch/arm/mach-pxa/pwm.c as an implementation example.
>
> Note that PXA implementation is SOC-specific, which is not very
> good.
>
> So I'd suggest creating drivers/pwm/pwmlib.c, borrowing
> ideas from gpiolib. And then we can reuse drivers/leds/leds-pwm.c
> driver (of course, after adding appropriate OF code into it).
Ugh. The referenced pwm api is about as trivial as it gets; it is an
anonymous context pointer (anonymous struct pwm_device *) with a set
of accessor functions. PWMs are also not nearly as common as GPIO
pins, and I am not interested in gpiolib being duplicated for PWMs, at
least not until there are more that just two examples of use to draw
from.
If anything, I'd rather struct pwm_device be non-anonymous and contain
a set of ops which call directly into the driver. That way is at
least multiplatform friendly. I don't think the gpio API is the
example to follow here. But even then I think it is premature to try
and define a PWM api. Personally, I'd modify mpc52xx_gpt to export
its own PWM interface for the time being using the existing GPIO
infrastructure to find the appropriate pin.
If you do decide to do a generic PWM api, then I think the way to go
is to build it as an extension to gpiolib.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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