[PATCH] powerpc: Fix bug in move of altivec code to vector.S
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 b...@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 */ - addir3,r1,STACK_FRAME_OVERHEAD +1: addir3,r1,STACK_FRAME_OVERHEAD EXC_XFER_EE_LITE(0xf20, altivec_unavailable_exception) PerformanceMonitor: -- 1.6.1.2.14.gf26b5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.30-git3 build break : perf counters
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.30-git3 build break : perf counters
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 sach...@in.ibm.com
Signed-off-by: Jaswinder Singh Rajput jaswinderraj...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Fwd: Re: slab: setup allocators earlier in the boot sequence]
---BeginMessage---
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 b...@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 b...@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;
@@
next branch update
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
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 - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.30-git3 build break : perf counters
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 sach...@in.ibm.com Signed-off-by: Jaswinder Singh Rajput jaswinderraj...@gmail.com --- Yes this fixed the build error. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.30-git3 build break : perf counters
Hi Jaswinder, On Fri, 12 Jun 2009 12:04:54 +0530 Jaswinder Singh Rajput jaswin...@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 sach...@in.ibm.com Signed-off-by: Jaswinder Singh Rajput jaswinderraj...@gmail.com I have applied this to linux-next for today. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpDLmFVbILTQ.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
Hi Pekka, On Fri, 12 Jun 2009 11:25:39 +0300 Pekka Enberg penb...@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 Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpxd35sjbvZY.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
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 penb...@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! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
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 r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
--- drivers/spi/spi_mpc8xxx.c.org 2009-06-12 10:45:21.0 +0200
+++ drivers/spi/spi_mpc8xxx.c 2009-06-12 10:54:48.0 +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;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
2.6.30-git3 boot failure on PowerPC
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 0x0020 Faulting instruction address: 0xc00cb7d8 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: NIP: c00cb7d8 LR: c00cb780 CTR: 0002 REGS: c0ef3020 TRAP: 0300 Not tainted (2.6.30-git3) MSR: 80001032 ME,IR,DR CR: 2824 XER: 0001 DAR: 0020, DSISR: 4000 TASK = c0e32b40[0] 'swapper' THREAD: c0ef CPU: 0 GPR00: c0ef32a0 c0ef21b0 GPR04: 0390 0370 c1453ce8 GPR08: c14435b0 c08931f0 GPR12: 80009032 c0ff2400 029698f5 02a75be8 GPR16: 02a75be8 01b5fc90 GPR20: 80d0 c0ef3a70 GPR24: c00041fff8a8 c0fa35f0 c0f71300 c0ef3450 GPR28: c113a100 c0e6ab68 c0ef32a0 NIP [c00cb7d8] .getnstimeofday+0x8c/0x148 LR [c00cb780] .getnstimeofday+0x34/0x148 Call Trace: [c0ef3340] [c00c3ba0] .ktime_get_ts+0x5c/0xbc [c0ef33e0] [c00c3c34] .ktime_get+0x34/0x88 [c0ef3480] [c00d02fc] .tick_nohz_stop_sched_tick+0x90/0x43c [c0ef3570] [c00a3dac] .irq_exit+0xac/0xc8 [c0ef35f0] [c002ce78] .timer_interrupt+0xe0/0x110 [c0ef3680] [c0003718] decrementer_common+0x118/0x180 --- Exception: 901 at .raw_local_irq_restore+0x74/0x8c LR = .__slab_alloc+0x2e0/0x5bc [c0ef3970] [c0ef3a10] init_thread_union+0x3a10/0x4000 (unreliable) [c0ef3a00] [c01845f0] .__slab_alloc+0x2e0/0x5bc [c0ef3ae0] [c0186410] .__kmalloc+0x160/0x238 [c0ef3ba0] [c004a608] .zalloc_maybe_bootmem+0x4c/0xa8 [c0ef3c30] [c000d810] .irq_alloc_host+0x74/0x250 [c0ef3cf0] [c084906c] .xics_init_IRQ+0x344/0x3e0 [c0ef3de0] [c0848394] .pseries_xics_init_IRQ+0x18/0x34 [c0ef3e60] [c083387c] .init_IRQ+0x44/0x64 [c0ef3ee0] [c0830a78] .start_kernel+0x238/0x460 [c0ef3f90] [c00083ec] .start_here_common+0x1c/0x30 Instruction dump: 7c2004ac 7b8007e1 41820010 7c210b78 7c421378 4be8 ebbe8000 e93d0010 e95d0018 f93b f95b0008 e87d0020 e9230020 e809 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 - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyderi...@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 ti...@freescale.com wrote: Adding Kumar to the CC: list, since he might pick up the patch. Acked-by: Dan Williams dan.j.willi...@intel.com I agree with taking this through Kumar's tree. I'm going through patches for .31.. Should I still pick this up? Going 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.30-git3 boot failure on PowerPC
On Fri, 2009-06-12 at 14:32 +0530, Sachin Sant wrote: 2.6.30-git3 fails to boot on Power6 box with following messages .../... 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. Yes it's a known issue, I'm working with Pekka to find the right solution. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
Ah - thanks. The bug was caused by me being a bit too optimistic in applying the shiny-new Power7 support patches on the last day. (nice CPU btw.) In that case paulus tells me it's actually Peter screwing up moving something from the powerpc code to generic :-) .../... Such bugs happen, and they are easy enough to fix. What matters arent the 1-2 short-lived bugs that do happen when a new combination of trees is created, but the long-lived combination bugs and conflicts. I'm not saying -next would fix world hunger ... but in this case we have two sets of issues, perfctr and the init ordering change which both got merged totally bypassing -next... We should at least -try- to follow the process we've defined, don't you think ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote: On Friday 05 June 2009, Subrata Modak wrote: Correct, it fixes the issue. However, since few changes might have gone to the Kconfig, the patch does not apply cleanly. Below is the patch, just a retake of the earlier one, but on the latest code. And it got mangled a bit along the way. Plus, the original one goofed up Kconfig dependency displays ... both issues fixed in this version, against current mainline GIT. If someone can verify all four PPC/OF/OHCI configs build on on PPC64, I'm OK with it. - Dave Dave, Sorry for being late. The patch fixes the issue on the latest git for PPC64. Infact, the whole drivers/usb/host/ builds just fine: linux-2.6 # make drivers/usb/host/ CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-powerpc CALLscripts/checksyscalls.sh CC drivers/usb/host/ohci-hcd.o CC drivers/usb/host/pci-quirks.o CC drivers/usb/host/uhci-hcd.o LD drivers/usb/host/built-in.o CC [M] drivers/usb/host/isp116x-hcd.o CC [M] drivers/usb/host/u132-hcd.o You can check in the patch now. Regards-- Subrata == CUT HERE From: Arnd Bergmann a...@arndb.de Subject: fix build failure for PPC64 randconfig [usb/ohci] We could just make the USB_OHCI_HCD_PPC_OF option implicit and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE and USB_OHCI_HCD_PPC_OF_LE are set. [ dbrown...@users.sourceforge.net: fix patch manglation and dependencies ] Signed-off-by: Arnd Bergmann a...@arndb.de Resent-by: Subrata Modak subr...@linux.vnet.ibm.com Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/usb/host/Kconfig | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -180,26 +180,27 @@ config USB_OHCI_HCD_PPC_SOC Enables support for the USB controller on the MPC52xx or STB03xxx processor chip. If unsure, say Y. -config USB_OHCI_HCD_PPC_OF - bool OHCI support for PPC USB controller on OF platform bus - depends on USB_OHCI_HCD PPC_OF - default y - ---help--- - Enables support for the USB controller PowerPC present on the - OpenFirmware platform bus. - config USB_OHCI_HCD_PPC_OF_BE - bool Support big endian HC - depends on USB_OHCI_HCD_PPC_OF - default y + bool OHCI support for OF platform bus (big endian) + depends on USB_OHCI_HCD PPC_OF select USB_OHCI_BIG_ENDIAN_DESC select USB_OHCI_BIG_ENDIAN_MMIO + ---help--- + Enables support for big-endian USB controllers present on the + OpenFirmware platform bus. config USB_OHCI_HCD_PPC_OF_LE - bool Support little endian HC - depends on USB_OHCI_HCD_PPC_OF - default n + bool OHCI support for OF platform bus (little endian) + depends on USB_OHCI_HCD PPC_OF select USB_OHCI_LITTLE_ENDIAN + ---help--- + Enables support for little-endian USB controllers present on the + OpenFirmware platform bus. + +config USB_OHCI_HCD_PPC_OF + bool + depends on USB_OHCI_HCD PPC_OF + default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE config USB_OHCI_HCD_PCI bool OHCI support for PCI-bus USB controllers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote: We should at least -try- to follow the process we've defined, don't you think ? So you're saying -next should include whole new subsystems even though its not clear they will be merged? That'll invariably create the opposite case where a tree doesn't get pulled and breaks bits due to its absence. -next does a great job of sorting the existing subsystem trees, but I don't think its Stephens job to decide if things will get merged. Therefore when things are in limbo (there was no definite ACK from Linus on perf counters) both inclusion and exclusion from -next can lead to trouble. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
* Peter Zijlstra a.p.zijls...@chello.nl wrote: On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote: We should at least -try- to follow the process we've defined, don't you think ? So you're saying -next should include whole new subsystems even though its not clear they will be merged? That'll invariably create the opposite case where a tree doesn't get pulled and breaks bits due to its absence. -next does a great job of sorting the existing subsystem trees, but I don't think its Stephens job to decide if things will get merged. Therefore when things are in limbo (there was no definite ACK from Linus on perf counters) both inclusion and exclusion from -next can lead to trouble. Precisely. linux-next is for the uncontroversial stuff from existing subsystems. Sometimes for features pushed by or approved by existing subsystem maintainers. But it is not for controversial stuff - Linus is the upstream maintainer, not Stephen. We had a real mess with perfmon3 which was included into linux-next in a rouge way without Cc:-ing the affected maintainers and against the maintainers. There was a repeat incident recently as well, where a tree was included into linux-next without the approval (and without the Cc:) of affected maintainers. linux-next needs to be more careful about adding trees. All in one, we did the same with perfcounters that we expected of perfmonv3. No double standard. Nor is there any real issue here. The bug was my fault, it was trivial to fix, it affects a small subset of testers and it is already upstream, applied on the same day perfcounters were pulled. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 11:43 +0200, Peter Zijlstra wrote: On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote: We should at least -try- to follow the process we've defined, don't you think ? So you're saying -next should include whole new subsystems even though its not clear they will be merged? Maybe yes. And if there's some debate as to whether it should be merged or not, maybe Linus should make the decision, let -next carry it for a few days to iron out those problems, and -then- merge it. That'll invariably create the opposite case where a tree doesn't get pulled and breaks bits due to its absence. -next does a great job of sorting the existing subsystem trees, but I don't think its Stephens job to decide if things will get merged. No, it's not, but then, maybe Linus could play the game and -tell- us whether he intend to merge or not at least a few days in advance :-) Therefore when things are in limbo (there was no definite ACK from Linus on perf counters) both inclusion and exclusion from -next can lead to trouble. Well, Linus did ACK by merging :-) So he should have been able to give that ack a few days in advance too.. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote: From: Stephen Rothwell s...@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 s...@canb.auug.org.au Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org Ah - thanks. The bug was caused by me being a bit too optimistic in applying the shiny-new Power7 support patches on the last day. (nice CPU btw.) Linus, please apply. BTW, This is _EXACTLY_ why this should have been in -next for a few days before being merged :-( Not really: for example current upstream is build-broken on x86 due to an integration artifact via the kmemleak tree - despite it having been in linux-next for months. Paulus was building and booting powerpc on a daily basis and i ran cross-builds as well. Such bugs happen, and they are easy enough to fix. What matters arent the 1-2 short-lived bugs that do happen when a new combination of trees is created, but the long-lived combination bugs and conflicts. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add compiler memory barrier to mtmsr macro
On 32-bit non-Book E, local_irq_restore() turns into just mtmsr(),
which doesn't currently have a compiler memory barrier. This means
that accesses to memory inside a local_irq_save/restore section,
or a spin_lock_irqsave/spin_unlock_irqrestore section on UP, can
be reordered by the compiler to occur outside that section.
To fix this, this adds a compiler memory barrier to mtmsr for both
32-bit and 64-bit. Having a compiler memory barrier in mtmsr makes
sense because it will almost always be changing something about the
context in which memory accesses are done, so in general we don't want
memory accesses getting moved from one side of an mtmsr to the other.
With the barrier in mtmsr(), some of the explicit barriers in
hw_irq.h are now redundant, so this removes them.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/hw_irq.h |5 ++---
arch/powerpc/include/asm/reg.h|4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 20a44d0..7eada1a 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -80,7 +80,7 @@ static inline void local_irq_disable(void)
__asm__ __volatile__(wrteei 0: : :memory);
#else
unsigned long msr;
- __asm__ __volatile__(: : :memory);
+
msr = mfmsr();
SET_MSR_EE(msr ~MSR_EE);
#endif
@@ -92,7 +92,7 @@ static inline void local_irq_enable(void)
__asm__ __volatile__(wrteei 1: : :memory);
#else
unsigned long msr;
- __asm__ __volatile__(: : :memory);
+
msr = mfmsr();
SET_MSR_EE(msr | MSR_EE);
#endif
@@ -108,7 +108,6 @@ static inline void local_irq_save_ptr(unsigned long *flags)
#else
SET_MSR_EE(msr ~MSR_EE);
#endif
- __asm__ __volatile__(: : :memory);
}
#define local_save_flags(flags)((flags) = mfmsr())
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index fb359b0..a3c28e4 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -745,11 +745,11 @@
asm volatile(mfmsr %0 : =r (rval)); rval;})
#ifdef CONFIG_PPC64
#define __mtmsrd(v, l) asm volatile(mtmsrd %0, __stringify(l) \
-: : r (v))
+: : r (v) : memory)
#define mtmsrd(v) __mtmsrd((v), 0)
#define mtmsr(v) mtmsrd(v)
#else
-#define mtmsr(v) asm volatile(mtmsr %0 : : r (v))
+#define mtmsr(v) asm volatile(mtmsr %0 : : r (v) : memory)
#endif
#define mfspr(rn) ({unsigned long rval; \
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
32-bit powerpc processors have no 64-bit atomic instructions, but we will
need atomic64_t in order to support the perf_counter subsystem on 32-bit
processors.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks to provide atomicity. For each atomic operation, the address
of the atomic64_t variable is hashed to an index into an array of 16
spinlocks. That spinlock is taken (with interrupts disabled) around the
operation, which can then be coded non-atomically within the lock.
On UP, all the spinlock manipulation goes away and we simply disable
interrupts around each operation. In fact gcc eliminates the whole
atomic64_lock variable as well.
Signed-off-by: Paul Mackerras pau...@samba.org
---
Compile-tested only at this stage, which is why it's [RFC].
arch/powerpc/include/asm/atomic.h | 29 ++
arch/powerpc/lib/Makefile |2 +-
arch/powerpc/lib/atomic64_32.c| 173 +
3 files changed, 203 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/lib/atomic64_32.c
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index b401950..45356d6 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -470,6 +470,35 @@ static __inline__ int atomic64_add_unless(atomic64_t *v,
long a, long u)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#else /* not __powerpc64__ */
+
+typedef struct {
+ long long counter;
+} atomic64_t;
+
+#define ATOMIC64_INIT(i) { (i) }
+
+extern long long atomic64_read(const atomic64_t *v);
+extern void atomic64_set(atomic64_t *v, long long i);
+extern void atomic64_add(long long a, atomic64_t *v);
+extern long long atomic64_add_return(long long a, atomic64_t *v);
+extern void atomic64_sub(long long a, atomic64_t *v);
+extern long long atomic64_sub_return(long long a, atomic64_t *v);
+extern long long atomic64_dec_if_positive(atomic64_t *v);
+extern long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n);
+extern long long atomic64_xchg(atomic64_t *v, long long new);
+extern int atomic64_add_unless(atomic64_t *v, long long a, long long u);
+
+#define atomic64_add_negative(a, v)(atomic64_add_return((a), (v)) 0)
+#define atomic64_inc(v)(atomic64_add(1LL, (v))
+#define atomic64_inc_return(v) (atomic64_add_return(1LL, (v))
+#define atomic64_inc_and_test(v) (atomic64_inc_return(v) == 0)
+#define atomic64_sub_and_test(a, v)(atomic64_sub_return((a), (v)) == 0)
+#define atomic64_dec(v)(atomic64_sub(1LL, (v))
+#define atomic64_dec_return(v) (atomic64_sub_return(1LL, (v))
+#define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
+#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+
#endif /* __powerpc64__ */
#include asm-generic/atomic.h
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 29b742b..1537f13 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -11,7 +11,7 @@ CFLAGS_REMOVE_feature-fixups.o = -pg
obj-y := string.o alloc.o \
checksum_$(CONFIG_WORD_SIZE).o
-obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o
+obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o atomic64_32.o
obj-$(CONFIG_HAS_IOMEM)+= devres.o
obj-$(CONFIG_PPC64)+= copypage_64.o copyuser_64.o \
diff --git a/arch/powerpc/lib/atomic64_32.c b/arch/powerpc/lib/atomic64_32.c
new file mode 100644
index 000..4c24b8a
--- /dev/null
+++ b/arch/powerpc/lib/atomic64_32.c
@@ -0,0 +1,173 @@
+/*
+ * Implementation of 64-bit atomics on 32-bit PowerPC processors.
+ *
+ * Copyright © 2009 Paul Mackerras, IBM Corp. pau...@au1.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include linux/types.h
+#include linux/cache.h
+#include linux/spinlock.h
+#include linux/init.h
+#include asm/atomic.h
+
+/*
+ * We use a hashed array of spinlocks to provide exclusive access
+ * to each atomic64_t variable. Since this is expected to used on
+ * systems with at most 4 processors, we use a relatively small
+ * array of 16 spinlocks.
+ */
+#define NR_LOCKS 16
+
+/*
+ * Ensure each lock is in a separate cacheline on SMP.
+ */
+static union {
+ spinlock_t lock;
+ char pad[L1_CACHE_BYTES];
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+
+static inline spinlock_t *lock_addr(const atomic64_t *v)
+{
+ unsigned long addr = (unsigned long) v;
+
+ addr = L1_CACHE_SHIFT;
+ addr ^= (addr 8) ^ (addr 16);
+ return atomic64_lock[addr (NR_LOCKS - 1)].lock;
+}
+
+long long atomic64_read(const atomic64_t *v)
+{
+ unsigned long flags;
+ spinlock_t *lock =
Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Ah - thanks. The bug was caused by me being a bit too optimistic in applying the shiny-new Power7 support patches on the last day. (nice CPU btw.) In that case paulus tells me it's actually Peter screwing up moving something from the powerpc code to generic :-) Yes, but i committed it and it's my task to make sure that the thing works as a whole so it's my fault still :) .../... Such bugs happen, and they are easy enough to fix. What matters arent the 1-2 short-lived bugs that do happen when a new combination of trees is created, but the long-lived combination bugs and conflicts. I'm not saying -next would fix world hunger ... but in this case we have two sets of issues, perfctr and the init ordering change which both got merged totally bypassing -next... We should at least -try- to follow the process we've defined, don't you think ? You are trying to define a process that does not exist in that form and which never existed in that form. It was never true that new code _MUST_ go via linux-next - and i hope it will never be true. linux-next has integration testing so that interactions between maintainer trees are mapped and that architectures that otherwise few people use get build-tested too (well beyond their practical relevance, i have to add) - but there's little critical review done in linux-next. Nor should it be the forum for that, it simply contains way too much stuff and has a weird history format with daily rebases that makes review hard and expensive in that form. linux-next should not be second-guessing maintainers and should not act as an approval forum for controversial features, increasing the (already quite substantial) pressure on maintainers to apply more crap. And that is true even if it's a new feature that i happen to support - as in this case - it sure would have been handy to have more perfcounters test coverage, every little bit of extra testing helps. If linux-next wants to do that then it should be renamed to something else and not called linux-next. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: linux-next has integration testing so that interactions between maintainer trees are mapped and that architectures that otherwise few people use get build-tested too (well beyond their practical relevance, i have to add) - but there's little critical review done in linux-next. Nor should it be the forum for that, it simply contains way too much stuff and has a weird history format with daily rebases that makes review hard and expensive in that form. I think you are mixing several issues. One is integration testing, one is the problem of remote architecture of subsystems testing... linux-next should not be second-guessing maintainers and should not act as an approval forum for controversial features, increasing the (already quite substantial) pressure on maintainers to apply more crap. I agree here. That's not the point. The idea is that for things that -are- approved by their respective maintainers, to get some integration testing and ironing of those mechanical bugs so that by the time they hit mainstream, they don't break bisection among others. Yes, next is -not- the place to debate controversial features. That's not, I believe, why it was initiated (I may be wrong, Stephen will correct me if I am), but the way I see things is that stuff that is meant to be merged gets a chance to get some of that integration testing against all the other stuff that is also meant to be merged to limit the amount of clash and problems once we hit Linus tree. And that is true even if it's a new feature that i happen to support - as in this case - it sure would have been handy to have more perfcounters test coverage, every little bit of extra testing helps. That doesn't invalidate my point. We are not talking about whether perfcounters is worth merging or not, testing more or not, but strictly, imho, about getting a chance (a couple of days at least) to do that integration testing and catch the simple issues like the one that triggered my initial rant -before- they hit mainline. To some extent, here, the issue is on Linus side and it's up to him (Hey Linus ! still listening ?) to maybe be more proactive at giving an ack or nack so that we can get a chance to do that final pass of ironing out the mechanical bugs before we hit the main tree. Cheers, Ben. If linux-next wants to do that then it should be renamed to something else and not called linux-next. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On Thu, Jun 11, 2009 at 9:32 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. I understand that. What I'm saying is the RIO block level ATMU is a Freescale specific detail and not part of any standard RIO bus programming model. We have mapping APIs that we can connect to for this via the DMA API layer. Ok, I see your point now. Do you mean dma_map_*() for DMA API layer? But in my understanding the current dma_map_*() APIs are preparing local memory for device to access which is similar to the inbound case. Is it suitable to also use them for mapping device's space for CPU access? Can you give an example of using this API for Address Translation and Mapping purpose? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote: To some extent, here, the issue is on Linus side and it's up to him (Hey Linus ! still listening ?) to maybe be more proactive at giving an ack or nack so that we can get a chance to do that final pass of ironing out the mechanical bugs before we hit the main tree. Let me add a little bit more background to my reasoning here and why I think having this integration testing step is so valuable... It all boils down to bisection and having a bisectable tree. Yes, I hate bisecting and I'm sure you are the same. It's a major PITA and in most cases, I'm better off tracking down the actual bug and then finding how it came into being. However, what the ability to have a reasonably bisectable tree buys us is all those users, testers, good wills, etc... people who do not have the knowledge, skill, familiarity with the code etc... to track the bug down, to be able to still find out what precise patch brought that pesky regression that doesn't happen on anybody else machine, and thus brings us some useful material to work with when we cannot reproduce the exact same setup on our own machines. Yes, I and I'm sure you can deal with a bisection breakage caused by a minor screweup like the one we are talking about. But our testers often can't and will just give up. It has -nothing- to do with whether the patches are controversial or not, it is purely about trying to make sure that things going into linus tree had at least a few days of churning by the various involved parties to try to get closer to the graal of a fully bisectable tree. At least that's how I see it. Now, we may disagree and I'm happy to discuss that more around a beer at next KS, and to some extent, what is done is done, and if we screwed up with -next vs. perfmon, then so be it and let's learn from our mistakes, but I believe it makes a lot of sense to have that staging area that helps us making sure that within a merge window with gazillion things being merged pretty much at once, we keep this ability for our users and testers to track down which individual patch broke something. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: linux-next should not be second-guessing maintainers and should not act as an approval forum for controversial features, increasing the (already quite substantial) pressure on maintainers to apply more crap. I agree here. That's not the point. The idea is that for things that -are- approved by their respective maintainers, to get some integration testing and ironing of those mechanical bugs so that by the time they hit mainstream, they don't break bisection among others. This is certainly doable for agreeable features - which is the bulk - and it is being done. But this is a catch-22 for _controversial_ new features - which perfcounters clearly was, in case you turned off your lkml subscription ;-) And if you hit that build breakage during bisection you can do: git cherry-pick e14112d Also, you seem to brush off the notion that far more bugs slip through linux-next than get caught by it. So if you think linux-next matters in terms of _regression_ testing, the numbers dont seem to support that notion. This particular incident does support that notion though, granted - but it's taken out of context IMHO: In terms of test coverage, at least for our trees, less than 1% of the bugs we handle get reported in a linux-next context - and most of the bugs that get reported (against say the scheduler tree) are related to rare architectures. In fact, i checked, there were _zero_ x86 bugs reported against linux-next and solved against it between v2.6.30-rc1 and v2.6.30: git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/ Doing it over the full cycle shows one commit altogether - a Xen build failure. In fact, i just checked the whole stabilization cycle for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were only 5 linux-next originated patches, most of them build failures. I did this by looking at all occurances of 'next', in all commit logs: git log --grep=next -i v2.6.30-rc1..v2.6.30 and then manually checking the context of all 'next' matches and counting the linux-next related commits. So lets be generous and say that because some people dont put the bug report originator into the changelog it was four times as many, 20 - but that's still dwarved by the sheer amount of post-rc1 changes: thousands of changes and hundreds of regressions. linux-next is mostly useful (to me at least) not for the cross-builds it does, but in terms of mapping out upcoming conflicts - which also drives early detection of problematic patches and problematic conflicts. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote: To some extent, here, the issue is on Linus side and it's up to him (Hey Linus ! still listening ?) to maybe be more proactive at giving an ack or nack so that we can get a chance to do that final pass of ironing out the mechanical bugs before we hit the main tree. Let me add a little bit more background to my reasoning here and why I think having this integration testing step is so valuable... It all boils down to bisection and having a bisectable tree. I think you are way too concentrated on this particular incident, and you are generalizing it into something that is not so in practice. Even in this particular case, there's just 3 other commit points in the Git tree between commit 8a1ca8c (the breakage on PowerPC) and e14112d (the fix). We'll have up to 10,000 commits. I bisect on an almost daily basis, and i'm not seeing unreasonable problems. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: next branch update
On Fri, Jun 12, 2009 at 2:29 AM, Benjamin Herrenschmidtb...@kernel.crashing.org wrote: I pushed the following commits, along with merging Linus tree in today. Is there a reason you keep ignoring my patch? [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout() There is PowerPC code in the ALSA tree that depends on my patch, so that code will break if you don't push my patch upstream. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote: This is certainly doable for agreeable features - which is the bulk - and it is being done. But this is a catch-22 for _controversial_ new features - which perfcounters clearly was, in case you turned off your lkml subscription ;-) I didn't :-) My point here is that Linus can make a decision with an email -before- merging so that -next gets a chance, at least for a couple of days, to do the integration testing once the controversy has been sorted by his highness. And if you hit that build breakage during bisection you can do: git cherry-pick e14112d Right, I can, you can, but can random tester who wants to track down what his problem is ? I'm not sure... Also, you seem to brush off the notion that far more bugs slip through linux-next than get caught by it. Less than without linux-next. We aren't perfect and no process will solve everything. But this could have been easily avoided. So if you think linux-next matters in terms of _regression_ testing, the numbers dont seem to support that notion. This particular incident does support that notion though, granted - but it's taken out of context IMHO: In terms of test coverage, at least for our trees, less than 1% of the bugs we handle get reported in a linux-next context - and most of the bugs that get reported (against say the scheduler tree) are related to rare architectures. But most obvious bugs will have been caught way before that, which leaves the hard to catch ones or the configuration-specific ones. Those will pass linux-next, I agree. But that isn't my point and that isn't what linux-next will catch. What is will catch is that kind of really simple mechanical problems, such as build breakage for other archs. If perfcounters had been 1 or 2 days in -next before being merged, we would have avoided that problem and made everybody's bisecting life easier. In fact, i checked, there were _zero_ x86 bugs reported against linux-next and solved against it between v2.6.30-rc1 and v2.6.30: No but Stephen caught a bunch of mechanical compile fails due to integration problems. git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/ Doing it over the full cycle shows one commit altogether - a Xen build failure. In fact, i just checked the whole stabilization cycle for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were only 5 linux-next originated patches, most of them build failures. I did this by looking at all occurances of 'next', in all commit logs: git log --grep=next -i v2.6.30-rc1..v2.6.30 and then manually checking the context of all 'next' matches and counting the linux-next related commits. So lets be generous and say that because some people dont put the bug report originator into the changelog it was four times as many, 20 - but that's still dwarved by the sheer amount of post-rc1 changes: thousands of changes and hundreds of regressions. linux-next is mostly useful (to me at least) not for the cross-builds it does, but in terms of mapping out upcoming conflicts - which also drives early detection of problematic patches and problematic conflicts. Yes, it does. The problem is that it helps -you- that way, but won't help -us- vs. that kind of mechanical problems unless -you- also play the game and get your stuff in there for a little while before merging it :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On Jun 12, 2009, at 8:27 AM, Li Yang wrote: On Thu, Jun 11, 2009 at 9:32 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. I understand that. What I'm saying is the RIO block level ATMU is a Freescale specific detail and not part of any standard RIO bus programming model. We have mapping APIs that we can connect to for this via the DMA API layer. Ok, I see your point now. Do you mean dma_map_*() for DMA API layer? But in my understanding the current dma_map_*() APIs are preparing local memory for device to access which is similar to the inbound case. Is it suitable to also use them for mapping device's space for CPU access? Can you give an example of using this API for Address Translation and Mapping purpose? Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses the dma_map_ layer as the way to do address translation. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: next branch update
On Fri, 2009-06-12 at 08:54 -0500, Timur Tabi wrote: On Fri, Jun 12, 2009 at 2:29 AM, Benjamin Herrenschmidtb...@kernel.crashing.org wrote: I pushed the following commits, along with merging Linus tree in today. Is there a reason you keep ignoring my patch? Other than I hate you ? just kidding :-) [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout() There is PowerPC code in the ALSA tree that depends on my patch, so that code will break if you don't push my patch upstream. I know, and you may have noticed I haven't sent a pull request to Linus yet... I was planning on scrubbing patchwork once more today and got sidetracked with fixing the breakage that went into mainline already while I was not looking :-) I haven't closed powerpc-next, I know I'm late, but don't worry, your patch is on my todo list. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
On Jun 12, 2009, at 7:02 AM, Paul Mackerras wrote: 32-bit powerpc processors have no 64-bit atomic instructions, but we will need atomic64_t in order to support the perf_counter subsystem on 32- bit processors. This adds an implementation of 64-bit atomic operations using hashed spinlocks to provide atomicity. For each atomic operation, the address of the atomic64_t variable is hashed to an index into an array of 16 spinlocks. That spinlock is taken (with interrupts disabled) around the operation, which can then be coded non-atomically within the lock. On UP, all the spinlock manipulation goes away and we simply disable interrupts around each operation. In fact gcc eliminates the whole atomic64_lock variable as well. Signed-off-by: Paul Mackerras pau...@samba.org --- Compile-tested only at this stage, which is why it's [RFC]. any reason not to make this lib/asm generic? Seems like it isn't ppc specific. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote: To some extent, here, the issue is on Linus side and it's up to him (Hey Linus ! still listening ?) to maybe be more proactive at giving an ack or nack so that we can get a chance to do that final pass of ironing out the mechanical bugs before we hit the main tree. Let me add a little bit more background to my reasoning here and why I think having this integration testing step is so valuable... It all boils down to bisection and having a bisectable tree. I think you are way too concentrated on this particular incident, and you are generalizing it into something that is not so in practice. Maybe. But maybe it's representative... so far in this merge window, 100% of the powerpc build and runtime breakage upstream comes from stuff that didn't get into -next before. Some of the runtime breakage in powerpc-next comes from my own bugs, indeed, and fortunately I caught it before I asked Linus to pull. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote: This is certainly doable for agreeable features - which is the bulk - and it is being done. But this is a catch-22 for _controversial_ new features - which perfcounters clearly was, in case you turned off your lkml subscription ;-) I didn't :-) My point here is that Linus can make a decision with an email -before- merging so that -next gets a chance, at least for a couple of days, to do the integration testing once the controversy has been sorted by his highness. Uhm, the bug you are making a big deal of would have been found and fixed by Paulus a few hours after any such mail - and probably by me too as i do daily cross builds to Power. So yes, we had a bug, but any extra linux-next hoops would not have prevented it: i could still have messed up by getting lured by that nice piece of Power7 hardware enablement patch on the last day ;-) So the bug was my fault for being too fast-and-loose with that particular patch, creating a ~5-commits-hop build breakage bisection window on Power. Now that i'm sufficiently chastised, can we now move on please? :) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote: * Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote: To some extent, here, the issue is on Linus side and it's up to him (Hey Linus ! still listening ?) to maybe be more proactive at giving an ack or nack so that we can get a chance to do that final pass of ironing out the mechanical bugs before we hit the main tree. Let me add a little bit more background to my reasoning here and why I think having this integration testing step is so valuable... It all boils down to bisection and having a bisectable tree. I think you are way too concentrated on this particular incident, and you are generalizing it into something that is not so in practice. Maybe. But maybe it's representative... so far in this merge window, 100% of the powerpc build and runtime breakage upstream comes from stuff that didn't get into -next before. But that's axiomatic, isnt it? linux-next build-tests PowerPC as the first in the row of tests - so no change that was in linux-next can ever cause a build failure on PowerPC, right? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
Uhm, the bug you are making a big deal of would have been found and fixed by Paulus a few hours after any such mail - and probably by me too as i do daily cross builds to Power. So yes, we had a bug, but any extra linux-next hoops would not have prevented it: i could still have messed up by getting lured by that nice piece of Power7 hardware enablement patch on the last day ;-) So the bug was my fault for being too fast-and-loose with that particular patch, creating a ~5-commits-hop build breakage bisection window on Power. Now that i'm sufficiently chastised, can we now move on please? :) Sure we can :-) My point is, get a break before you merge upstream :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
On Fri, 2009-06-12 at 16:11 +0200, Ingo Molnar wrote: Maybe. But maybe it's representative... so far in this merge window, 100% of the powerpc build and runtime breakage upstream comes from stuff that didn't get into -next before. But that's axiomatic, isnt it? linux-next build-tests PowerPC as the first in the row of tests - so no change that was in linux-next can ever cause a build failure on PowerPC, right? I'd have to check with Stephen but I think linux-next tests a whole bunch of archs each round. Anyway, the idea is, just don't get things upstream before the at least had a chance to go through that little bit of integration testing .. Is it -that- hard ? Oh and before you ask me, yes, I do the same mistakes, and I have been caught too merging things at the last minute that ended up broken and that could have been caught by -next... I'm just trying to advocate the idea that we all try to improve in that area :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
On Jun 12, 2009, at 4:23 AM, Li Yang wrote: On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyderi...@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 ti...@freescale.com wrote: Adding Kumar to the CC: list, since he might pick up the patch. Acked-by: Dan Williams dan.j.willi...@intel.com I agree with taking this through Kumar's tree. I'm going through patches for .31.. Should I still pick this up? Going 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. I agree w/this and just wanting to see what Dan's preference is. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fsldma: use PCI Read Multiple command
Kumar Gala wrote: On Jun 12, 2009, at 4:23 AM, Li Yang wrote: On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyderi...@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 ti...@freescale.com wrote: Adding Kumar to the CC: list, since he might pick up the patch. Acked-by: Dan Williams dan.j.willi...@intel.com I agree with taking this through Kumar's tree. I'm going through patches for .31.. Should I still pick this up? Going 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. I agree w/this and just wanting to see what Dan's preference is. I'll take fsldma patches through the dmaengine tree with Leo's ack/sign-off. That last request was a one-off because I had nothing else to push and the discussion was very architecture specific. Thanks, Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
On Fri, Jun 12, 2009 at 09:04:52AM -0500, Kumar Gala wrote: On UP, all the spinlock manipulation goes away and we simply disable interrupts around each operation. In fact gcc eliminates the whole atomic64_lock variable as well. Signed-off-by: Paul Mackerras pau...@samba.org --- Compile-tested only at this stage, which is why it's [RFC]. any reason not to make this lib/asm generic? Seems like it isn't ppc specific. Indeed... PA-RISC uses these for all atomics, since we have no useful atomic insns to implement them... I'd be happy to submit a cleanup after you merge this, if you don't have time to ahead of time. regards, Kyle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fbdev/xilinxfb: Fix improper casting and tighen up probe path
From: Grant Likely grant.lik...@secretlab.ca
The xilinxfb driver is improperly casting a physical address to a
u32, and the probe routine isn't as straight forward as it could be.
(discovered by gcc spitting out warnings on most recent change to
xilinxfb driver).
This patch fixes the cast and simplifies the probe path.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
John, can you please test and verify this fix is correct?
Thanks,
g.
drivers/video/xilinxfb.c | 59 ++
1 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 7a868bd..b68b331 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -124,7 +124,6 @@ struct xilinxfb_drvdata {
registers */
dcr_host_t dcr_host;
- unsigned intdcr_start;
unsigned intdcr_len;
void*fb_virt; /* virt. address of the frame buffer */
@@ -325,8 +324,8 @@ static int xilinxfb_assign(struct device *dev,
drvdata-regs);
}
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, fb: phys=%p, virt=%p, size=%x\n,
- (void *)drvdata-fb_phys, drvdata-fb_virt, fbsize);
+ dev_dbg(dev, fb: phys=%llx, virt=%p, size=%x\n,
+ (unsigned long long)drvdata-fb_phys, drvdata-fb_virt, fbsize);
return 0; /* success */
@@ -404,9 +403,7 @@ xilinxfb_of_probe(struct of_device *op, const struct
of_device_id *match)
u32 tft_access;
struct xilinxfb_platform_data pdata;
struct resource res;
- int size, rc;
- int start = 0, len = 0;
- dcr_host_t dcr_host;
+ int size, rc, start;
struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
@@ -414,35 +411,39 @@ xilinxfb_of_probe(struct of_device *op, const struct
of_device_id *match)
dev_dbg(op-dev, xilinxfb_of_probe(%p, %p)\n, op, match);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(op-dev, Couldn't allocate device private record\n);
+ return -ENOMEM;
+ }
+
/*
* To check whether the core is connected directly to DCR or PLB
* interface and initialize the tft_access accordingly.
*/
p = (u32 *)of_get_property(op-node, xlnx,dcr-splb-slave-if, NULL);
-
- if (p)
- tft_access = *p;
- else
- tft_access = 0; /* For backward compatibility */
+ tft_access = p ? *p : 0;
/*
* Fill the resource structure if its direct PLB interface
* otherwise fill the dcr_host structure.
*/
if (tft_access) {
+ drvdata-flags |= PLB_ACCESS_FLAG;
rc = of_address_to_resource(op-node, 0, res);
if (rc) {
dev_err(op-dev, invalid address\n);
- return -ENODEV;
+ goto err;
}
-
} else {
+ res.start = 0;
start = dcr_resource_start(op-node, 0);
- len = dcr_resource_len(op-node, 0);
- dcr_host = dcr_map(op-node, start, len);
- if (!DCR_MAP_OK(dcr_host)) {
- dev_err(op-dev, invalid address\n);
- return -ENODEV;
+ drvdata-dcr_len = dcr_resource_len(op-node, 0);
+ drvdata-dcr_host = dcr_map(op-node, start, drvdata-len);
+ if (!DCR_MAP_OK(drvdata-dcr_host)) {
+ dev_err(op-dev, invalid DCR address\n);
+ goto err;
}
}
@@ -467,26 +468,12 @@ xilinxfb_of_probe(struct of_device *op, const struct
of_device_id *match)
if (of_find_property(op-node, rotate-display, NULL))
pdata.rotate_screen = 1;
- /* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata) {
- dev_err(op-dev, Couldn't allocate device private record\n);
- return -ENOMEM;
- }
dev_set_drvdata(op-dev, drvdata);
+ return xilinxfb_assign(op-dev, drvdata, res.start, pdata);
- if (tft_access)
- drvdata-flags |= PLB_ACCESS_FLAG;
-
- /* Arguments are passed based on the interface */
- if (drvdata-flags PLB_ACCESS_FLAG) {
- return xilinxfb_assign(op-dev, drvdata, res.start, pdata);
- } else {
- drvdata-dcr_start = start;
- drvdata-dcr_len = len;
- drvdata-dcr_host = dcr_host;
- return xilinxfb_assign(op-dev, drvdata, 0, pdata);
- }
+ err:
+ kfree(drvdata);
+ return -ENODEV;
}
static int
Re: [PATCH] fsldma: use PCI Read Multiple command
On Jun 12, 2009, at 12:38 PM, Dan Williams wrote: Kumar Gala wrote: On Jun 12, 2009, at 4:23 AM, Li Yang wrote: On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyderi...@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 ti...@freescale.com wrote: Adding Kumar to the CC: list, since he might pick up the patch. Acked-by: Dan Williams dan.j.willi...@intel.com I agree with taking this through Kumar's tree. I'm going through patches for .31.. Should I still pick this up? Going 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. I agree w/this and just wanting to see what Dan's preference is. I'll take fsldma patches through the dmaengine tree with Leo's ack/ sign-off. That last request was a one-off because I had nothing else to push and the discussion was very architecture specific. Sounds good to me. I expect you to pick up this patch for .31 - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
build failure in PPC mpc5200_psc_ac97
The new driver for AC97 on the mpc5200 has landed in front of Timur's patch implementing spin_event_timeout(). Timur's patch is in powerpc-next which hasn't been merged yet. mpc5200_psc_ac97 will build ok after this merge happens. -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net/fs_enet: Allow use_rmii to be set in OF
Allow use_rmii in fs_platform_info to be set in the OF device tree using phy-mode=rmii. Signed-off-by: Ken MacLeod k...@bitsko.slc.ut.us --- drivers/net/fs_enet/fs_enet-main.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c index a9cbc31..57879be 100644 --- a/drivers/net/fs_enet/fs_enet-main.c +++ b/drivers/net/fs_enet/fs_enet-main.c @@ -1043,6 +1043,7 @@ static int __devinit fs_enet_probe(struct of_device *ofdev, struct fs_platform_info *fpi; const u32 *data; const u8 *mac_addr; + const char *str; int privsize, len, ret = -ENODEV; fpi = kzalloc(sizeof(*fpi), GFP_KERNEL); @@ -1057,6 +1058,10 @@ static int __devinit fs_enet_probe(struct of_device *ofdev, fpi-cp_command = *data; } + str = of_get_property(ofdev-node, phy-mode, len); + if (str != NULL !strcasecmp(str, rmii)) + fpi-use_rmii = 1; + fpi-rx_ring = 32; fpi-tx_ring = 32; fpi-rx_copybreak = 240; -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2.6.31] ehca: Tolerate dynamic memory operations and huge pages
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in ehca_mem_notifier() in ehca_main.c:
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached to the lpar */
spin_lock_irqsave(shca_list_lock, flags);
if (list_empty(shca_list)) {
spin_unlock_irqrestore(shca_list_lock, flags);
return NOTIFY_OK;
} else {
spin_unlock_irqrestore(shca_list_lock, flags);
if (printk_timed_ratelimit(ehca_dmem_warn_time,
30 * 1000))
ehca_gen_err(DMEM operations are not allowed
in conjunction with eHCA);
return NOTIFY_BAD;
}
But your patch description says:
This patch implements toleration of dynamic memory operations
But it seems you're still going to hit the same NOTIFY_BAD case above
after your patch. So something doesn't compute for me. Could you
explain more?
Second, a nit:
+#define EHCA_REG_MR 0
+#define EHCA_REG_BUSMAP_MR (~0)
and you pass these as the reg_busmap parm in:
int ehca_reg_mr(struct ehca_shca *shca,
struct ehca_mr *e_mr,
u64 *iova_start,
@@ -991,7 +1031,8 @@
struct ehca_pd *e_pd,
struct ehca_mr_pginfo *pginfo,
u32 *lkey, /*OUT*/
-u32 *rkey) /*OUT*/
+u32 *rkey, /*OUT*/
+int reg_busmap)
and test it as:
+if (reg_busmap)
+ret = ehca_reg_bmap_mr_rpages(shca, e_mr, pginfo);
+else
+ret = ehca_reg_mr_rpages(shca, e_mr, pginfo);
So the ~0 for true looks a bit odd. One option would be to make
reg_busmap a bool, since that's how you're using it, but then you lose
the nice self-documenting macro where you call things.
So I think it would be cleaner to do something like
enum ehca_reg_type {
EHCA_REG_MR,
EHCA_REG_BUSMAP_MR
};
and make the int reg_busmap parameter into enum ehca_reg_type reg_type
and have the code become
+ if (reg_type == EHCA_REG_BUSMAP_MR)
+ ret = ehca_reg_bmap_mr_rpages(shca, e_mr, pginfo);
+ else if (reg_type == EHCA_REG_MR)
+ ret = ehca_reg_mr_rpages(shca, e_mr, pginfo);
+ else
+ ret = -EINVAL
or something like that.
+struct ib_dma_mapping_ops ehca_dma_mapping_ops = {
+.mapping_error = ehca_dma_mapping_error,
+.map_single = ehca_dma_map_single,
+.unmap_single = ehca_dma_unmap_single,
+.map_page = ehca_dma_map_page,
+.unmap_page = ehca_dma_unmap_page,
+.map_sg = ehca_dma_map_sg,
+.unmap_sg = ehca_dma_unmap_sg,
+.dma_address = ehca_dma_address,
+.dma_len = ehca_dma_len,
+.sync_single_for_cpu = ehca_dma_sync_single_for_cpu,
+.sync_single_for_device = ehca_dma_sync_single_for_device,
+.alloc_coherent = ehca_dma_alloc_coherent,
+.free_coherent = ehca_dma_free_coherent,
+};
I always think structures like this are easier to read if you align the
'=' signs. But no big deal.
+ret = ehca_create_busmap();
+if (ret) {
+ehca_gen_err(Cannot create busmap.);
+goto module_init2;
+}
+
ret = ibmebus_register_driver(ehca_driver);
if (ret) {
ehca_gen_err(Cannot register eHCA device driver);
ret = -EINVAL;
-goto module_init2;
+goto module_init3;
}
ret = register_memory_notifier(ehca_mem_nb);
if (ret) {
ehca_gen_err(Failed registering memory add/remove notifier);
-goto module_init3;
+goto module_init4;
Having to renumber unrelated things is when something changes is why I
don't like this style of error path labels. But I think it's well and
truly too late to fix that in ehca.
- R.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
Hi Ingo, On Fri, 12 Jun 2009 15:44:28 +0200 Ingo Molnar mi...@elte.hu wrote: In terms of test coverage, at least for our trees, less than 1% of the bugs we handle get reported in a linux-next context - and most of the bugs that get reported (against say the scheduler tree) are related to rare architectures. I expect that most bugs get reported and fixed before code gets to linux-next (in fact one of the prerequisites for being in linux-next is that code has been tested as well as possible). In fact, i checked, there were _zero_ x86 bugs reported against linux-next and solved against it between v2.6.30-rc1 and v2.6.30: git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/ Doing it over the full cycle shows one commit altogether - a Xen build failure. In fact, i just checked the whole stabilization cycle for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were only 5 linux-next originated patches, most of them build failures. Nice set of figures. For some other context, between April 6 and June 9 (2.6.30-rc1 to 2.6.30) I sent 50 emails with subjects like linux-next: xxx tree build failure. What results from those emails? I sometimes don't even hear back. Almost all of the failures get fixed. A lot of these probably also get discovered independently. I don't really care as long as they do get fixed. One of those failures was a sparc build failure due to a change in the tip-core tree (see commit d2de688891909b148efe83a6fc9520a9cd6015f0). Another report produced commit 27b19565fe4ca5b0e9d2ae98ce4b81ca728bf445. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgphNIFlQi6Zk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: origin tree build failure
Hi Ingo, On Fri, 12 Jun 2009 16:11:18 +0200 Ingo Molnar mi...@elte.hu wrote: But that's axiomatic, isnt it? linux-next build-tests PowerPC as the first in the row of tests - so no change that was in linux-next can ever cause a build failure on PowerPC, right? Not really. I build a powerpc ppc64_defconfig and an x86_64 allmodconfig between merging most trees. At the end of the day, I do the following builds before releasing linux-next: powerpc allnoconfig powerpc64 allnoconfig powerpc ppc44x_defconfig powerpc allyesconfig i386 defconfig sparc64 defconfig sparc defconfig Which clearly doesn't cover all possible configs, but is a start and catches a lot (the powerpc allyesconfig is only 64 bit). Then after release, linux-next gets built for a lot of architectures and configs (see http://kisskb.ellerman.id.au/kisskb/branch/9/). A couple of people also do randconfig builds which find all sorts of things. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpDV6GhrC545.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
