* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Li Yang @ 2009-06-12 9:23 UTC (permalink / raw)
To: Ira Snyder
Cc: David Hawkins, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <20090611151750.GB9323@ovro.caltech.edu>
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu> wrote:
> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>
>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>
>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>> wrote:
>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>
>>>
>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>
>>> I agree with taking this through Kumar's tree.
>>
>> I'm going through patches for .31.. Should I still pick this up? =C2=A0G=
oing
>> forward should I pick up fsldma patches?
>>
>
> I'm fine with that, but you should probably talk to Li Yang (added to
> CC). He's gotten in contact with me a few times recently.
I am fine with both ways for this patch as it is only related to
Freescale register details. But in general I think patches should go
through functional subsystem, as they usually would need insight of
the subsystem architecture. I prefer the way that the patch acked or
signed-off by Freescale guys and push upstream through Dan's tree as
most other subsystems did. Unless Dan prefers to ack the subsystem
architectural part of each patch and have them pushed other way.
- Leo
^ permalink raw reply
* 2.6.30-git3 boot failure on PowerPC
From: Sachin Sant @ 2009-06-12 9:02 UTC (permalink / raw)
To: linuxppc-dev
2.6.30-git3 fails to boot on Power6 box with following messages
[boot]0020 XICS Init
Unable to handle kernel paging request for data at address 0x00000020
Faulting instruction address: 0xc0000000000cb7d8
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c0000000000cb7d8 LR: c0000000000cb780 CTR: 0000000000000002
REGS: c000000000ef3020 TRAP: 0300 Not tainted (2.6.30-git3)
MSR: 8000000000001032 <ME,IR,DR> CR: 28000024 XER: 00000001
DAR: 0000000000000020, DSISR: 0000000040000000
TASK = c000000000e32b40[0] 'swapper' THREAD: c000000000ef0000 CPU: 0
GPR00: 0000000000000000 c000000000ef32a0 c000000000ef21b0 0000000000000000
GPR04: 0000000000000000 0000000000000390 0000000000000370 c000000001453ce8
GPR08: c0000000014435b0 0000000000000000 0000000000000000 c0000000008931f0
GPR12: 8000000000009032 c000000000ff2400 00000000029698f5 0000000002a75be8
GPR16: 0000000000000000 0000000002a75be8 0000000001b5fc90 0000000000000000
GPR20: 0000000000000000 00000000000080d0 ffffffffffffffff c000000000ef3a70
GPR24: c000000041fff8a8 c000000000fa35f0 c000000000f71300 c000000000ef3450
GPR28: 0000000000000000 c00000000113a100 c000000000e6ab68 c000000000ef32a0
NIP [c0000000000cb7d8] .getnstimeofday+0x8c/0x148
LR [c0000000000cb780] .getnstimeofday+0x34/0x148
Call Trace:
[c000000000ef3340] [c0000000000c3ba0] .ktime_get_ts+0x5c/0xbc
[c000000000ef33e0] [c0000000000c3c34] .ktime_get+0x34/0x88
[c000000000ef3480] [c0000000000d02fc] .tick_nohz_stop_sched_tick+0x90/0x43c
[c000000000ef3570] [c0000000000a3dac] .irq_exit+0xac/0xc8
[c000000000ef35f0] [c00000000002ce78] .timer_interrupt+0xe0/0x110
[c000000000ef3680] [c000000000003718] decrementer_common+0x118/0x180
--- Exception: 901 at .raw_local_irq_restore+0x74/0x8c
LR = .__slab_alloc+0x2e0/0x5bc
[c000000000ef3970] [c000000000ef3a10] init_thread_union+0x3a10/0x4000 (unreliable)
[c000000000ef3a00] [c0000000001845f0] .__slab_alloc+0x2e0/0x5bc
[c000000000ef3ae0] [c000000000186410] .__kmalloc+0x160/0x238
[c000000000ef3ba0] [c00000000004a608] .zalloc_maybe_bootmem+0x4c/0xa8
[c000000000ef3c30] [c00000000000d810] .irq_alloc_host+0x74/0x250
[c000000000ef3cf0] [c00000000084906c] .xics_init_IRQ+0x344/0x3e0
[c000000000ef3de0] [c000000000848394] .pseries_xics_init_IRQ+0x18/0x34
[c000000000ef3e60] [c00000000083387c] .init_IRQ+0x44/0x64
[c000000000ef3ee0] [c000000000830a78] .start_kernel+0x238/0x460
[c000000000ef3f90] [c0000000000083ec] .start_here_common+0x1c/0x30
Instruction dump:
7c2004ac 7b8007e1 41820010 7c210b78 7c421378 4bffffe8 ebbe8000 e93d0010
e95d0018 f93b0000 f95b0008 e87d0020 <e9230020> e8090000 f8410028 7c0903a6
---[ end trace 31fd0ba7d8756001 ]---
git2 boots fine with the same config.
I came across the following mail from Ben so this could be a know issue.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073102.html
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
From: Rini van Zetten @ 2009-06-12 8:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: spi-devel-general, Andrew Morton, linuxppc-dev list
In-Reply-To: <7071E2AF-65ED-41C2-AFE7-06E9336619CB@kernel.crashing.org>
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>; /* cs2 */
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
---
Changes :
patch against 2.6.30-rc8-mm1
--- drivers/spi/spi_mpc8xxx.c.org 2009-06-12 10:45:21.000000000 +0200
+++ drivers/spi/spi_mpc8xxx.c 2009-06-12 10:54:48.000000000 +0200
@@ -666,9 +666,10 @@ static void mpc8xxx_spi_cs_control(struc
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
u16 cs = spi->chip_select;
int gpio = pinfo->gpios[cs];
- bool alow = pinfo->alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo->alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -707,27 +708,29 @@ static int of_mpc8xxx_spi_get_chipselect
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, &flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
+ goto err_loop;
+ }
+
+ pinfo->gpios[i] = gpio;
+ pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo->gpios[i],
+ pinfo->alow_flags[i]);
+ if (ret) {
+ dev_err(dev, "can't set output direction for gpio "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo->gpios[i] = -EEXIST;
+ } else {
dev_err(dev, "invalid gpio #%d: %d\n", i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
- goto err_loop;
- }
-
- pinfo->gpios[i] = gpio;
- pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
--
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Pekka Enberg @ 2009-06-12 8:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Nick Piggin, linuxppc-dev, linux-next
In-Reply-To: <20090612183559.33018f0c.sfr@canb.auug.org.au>
On Fri, 2009-06-12 at 18:35 +1000, Stephen Rothwell wrote:
> Hi Pekka,
>
> On Fri, 12 Jun 2009 11:25:39 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> >
> > Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
> > linux-next or something?
>
> Yesterday (next-20090611) the slab tree for linux-next had only one
> commit in it ("SLUB: Out-of-memory diagnostics"). Today (next-20090612)
> it has quite a lot in it again - including SLQB.
Ah, ok. I did mess it up for few hours and I guess you picked up then.
Thanks, Stephen!
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Stephen Rothwell @ 2009-06-12 8:35 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Nick Piggin, linuxppc-dev, linux-next
In-Reply-To: <1244795139.30512.23.camel@penberg-laptop>
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
Hi Pekka,
On Fri, 12 Jun 2009 11:25:39 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
> linux-next or something?
Yesterday (next-20090611) the slab tree for linux-next had only one
commit in it ("SLUB: Out-of-memory diagnostics"). Today (next-20090612)
it has quite a lot in it again - including SLQB.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PowerPC] 2.6.30-git3 build break : perf counters
From: Stephen Rothwell @ 2009-06-12 8:25 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>
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Hi Jaswinder,
On Fri, 12 Jun 2009 12:04:54 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> 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>
I have applied this to linux-next for today. Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* 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
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