* [v4][PATCH 2/4] powerpc/ppc32: make copy_and_flush() as global
From: Tiejun Chen @ 2012-09-12 8:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1347439325-5563-1-git-send-email-tiejun.chen@windriver.com>
Somewhere we need this simple copy_and_flush().
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/entry_32.S | 27 +++++++++++++++++++++++++++
arch/powerpc/kernel/head_32.S | 26 --------------------------
2 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ead5016..1536d2c 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -32,6 +32,7 @@
#include <asm/unistd.h>
#include <asm/ftrace.h>
#include <asm/ptrace.h>
+#include <asm/cache.h>
#undef SHOW_SYSCALLS
#undef SHOW_SYSCALLS_TASK
@@ -1265,6 +1266,32 @@ ee_restarts:
.previous
/*
+ * Copy routine used to copy the kernel to start at physical address 0
+ * and flush and invalidate the caches as needed.
+ * r3 = dest addr, r4 = source addr, r5 = copy limit, r6 = start offset
+ * on exit, r3, r4, r5 are unchanged, r6 is updated to be >= r5.
+ */
+_GLOBAL(copy_and_flush)
+ addi r5,r5,-4
+ addi r6,r6,-4
+4: li r0,L1_CACHE_BYTES/4
+ mtctr r0
+3: addi r6,r6,4 /* copy a cache line */
+ lwzx r0,r6,r4
+ stwx r0,r6,r3
+ bdnz 3b
+ dcbst r6,r3 /* write it to memory */
+ sync
+ icbi r6,r3 /* flush the icache line */
+ cmplw 0,r6,r5
+ blt 4b
+ sync /* additional sync needed on g4 */
+ isync
+ addi r5,r5,4
+ addi r6,r6,4
+ blr
+
+/*
* PROM code for specific machines follows. Put it
* here so it's easy to add arch-specific sections later.
* -- Cort
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index dc0488b..14ea361 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -777,32 +777,6 @@ relocate_kernel:
bl copy_and_flush /* copy the rest */
b turn_on_mmu
-/*
- * Copy routine used to copy the kernel to start at physical address 0
- * and flush and invalidate the caches as needed.
- * r3 = dest addr, r4 = source addr, r5 = copy limit, r6 = start offset
- * on exit, r3, r4, r5 are unchanged, r6 is updated to be >= r5.
- */
-_ENTRY(copy_and_flush)
- addi r5,r5,-4
- addi r6,r6,-4
-4: li r0,L1_CACHE_BYTES/4
- mtctr r0
-3: addi r6,r6,4 /* copy a cache line */
- lwzx r0,r6,r4
- stwx r0,r6,r3
- bdnz 3b
- dcbst r6,r3 /* write it to memory */
- sync
- icbi r6,r3 /* flush the icache line */
- cmplw 0,r6,r5
- blt 4b
- sync /* additional sync needed on g4 */
- isync
- addi r5,r5,4
- addi r6,r6,4
- blr
-
#ifdef CONFIG_SMP
.globl __secondary_start_mpc86xx
__secondary_start_mpc86xx:
--
1.7.9.5
^ permalink raw reply related
* [v4][PATCH 3/4] powerpc/kprobe: complete kprobe and migrate exception frame
From: Tiejun Chen @ 2012-09-12 8:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1347439325-5563-1-git-send-email-tiejun.chen@windriver.com>
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline exception frame below the kprobed
function stack and copy the current exception frame to the trampoline.
Then we can do this real store operation to implement 'stwu', and reroute
the trampoline frame to r1 to complete this exception migration.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
v4:
* improve register usage
* use copy_and_flush() to replace memcpy since that only clobber r0, r6
and LR explicitly.
* retest
arch/powerpc/kernel/entry_32.S | 44 ++++++++++++++++++++++++++++++++++------
arch/powerpc/kernel/entry_64.S | 32 +++++++++++++++++++++++++++++
2 files changed, 70 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 1536d2c..b18e494 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -832,19 +832,53 @@ restore_user:
bnel- load_dbcr0
#endif
-#ifdef CONFIG_PREEMPT
b restore
/* N.B. the only way to get here is from the beq following ret_from_except. */
resume_kernel:
- /* check current_thread_info->preempt_count */
+ /* check current_thread_info, _TIF_EMULATE_STACK_STORE */
CURRENT_THREAD_INFO(r9, r1)
+ lwz r8,TI_FLAGS(r9)
+ andis. r8,r8,_TIF_EMULATE_STACK_STORE@h
+ beq+ 1f
+
+ addi r8,r1,INT_FRAME_SIZE /* Get the kprobed function entry */
+
+ lwz r3,GPR1(r1)
+ subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception frame */
+ mr r4,r1 /* src: current exception frame */
+ li r5,INT_FRAME_SIZE /* size: INT_FRAME_SIZE */
+ li r6,0 /* start offset: 0 */
+ mr r1,r3 /* Reroute the trampoline frame to r1 */
+ /* Copy from the original to the trampoline.
+ * Its safe since copy_and_flush *only* clobbers r0, r6 and lr.
+ */
+ bl copy_and_flush
+
+ /* Do real store operation to complete stwu */
+ lwz r5,GPR1(r1)
+ stw r8,0(r5)
+
+ /* Clear _TIF_EMULATE_STACK_STORE flag */
+ lis r11,_TIF_EMULATE_STACK_STORE@h
+ addi r5,r9,TI_FLAGS
+0: lwarx r8,0,r5
+ andc r8,r8,r11
+#ifdef CONFIG_IBM405_ERR77
+ dcbt 0,r5
+#endif
+ stwcx. r8,0,r5
+ bne- 0b
+1:
+
+#ifdef CONFIG_PREEMPT
+ /* check current_thread_info->preempt_count */
lwz r0,TI_PREEMPT(r9)
cmpwi 0,r0,0 /* if non-zero, just restore regs and return */
bne restore
- lwz r0,TI_FLAGS(r9)
- andi. r0,r0,_TIF_NEED_RESCHED
+ andi. r8,r8,_TIF_NEED_RESCHED
beq+ restore
+ lwz r3,_MSR(r1)
andi. r0,r3,MSR_EE /* interrupts off? */
beq restore /* don't schedule if so */
#ifdef CONFIG_TRACE_IRQFLAGS
@@ -865,8 +899,6 @@ resume_kernel:
*/
bl trace_hardirqs_on
#endif
-#else
-resume_kernel:
#endif /* CONFIG_PREEMPT */
/* interrupts are hard-disabled at this point */
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index b40e0b4..d060f4d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -593,6 +593,38 @@ _GLOBAL(ret_from_except_lite)
b .ret_from_except
resume_kernel:
+ /* check current_thread_info, _TIF_EMULATE_STACK_STORE */
+ CURRENT_THREAD_INFO(r9, r1)
+ ld r8,TI_FLAGS(r9)
+ andis. r8,r8,_TIF_EMULATE_STACK_STORE@h
+ beq+ 1f
+
+ addi r8,r1,INT_FRAME_SIZE /* Get the kprobed function entry */
+
+ lwz r3,GPR1(r1)
+ subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception frame */
+ mr r4,r1 /* src: current exception frame */
+ li r5,INT_FRAME_SIZE /* size: INT_FRAME_SIZE */
+ li r6,0 /* start offset: 0 */
+ mr r1,r3 /* Reroute the trampoline frame to r1 */
+ /* Copy from the original to the trampoline.
+ * Its safe since copy_and_flush *only* clobbers r0, r6 and lr
+ */
+ bl .copy_and_flush
+
+ /* Do real store operation to complete stwu */
+ lwz r5,GPR1(r1)
+ std r8,0(r5)
+
+ /* Clear _TIF_EMULATE_STACK_STORE flag */
+ lis r11,_TIF_EMULATE_STACK_STORE@h
+ addi r5,r9,TI_FLAGS
+ ldarx r4,0,r5
+ andc r4,r4,r11
+ stdcx. r4,0,r5
+ bne- 0b
+1:
+
#ifdef CONFIG_PREEMPT
/* Check if we need to preempt */
andi. r0,r4,_TIF_NEED_RESCHED
--
1.7.9.5
^ permalink raw reply related
* [v4][PATCH 4/4] powerpc/kprobe: don't emulate store when kprobe stwu r1
From: Tiejun Chen @ 2012-09-12 8:42 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1347439325-5563-1-git-send-email-tiejun.chen@windriver.com>
We don't do the real store operation for kprobing 'stwu Rx,(y)R1'
since this may corrupt the exception frame, now we will do this
operation safely in exception return code after migrate current
exception frame below the kprobed function stack.
So we only update gpr[1] here and trigger a thread flag to mask
this.
Note we should make sure if we trigger kernel stack over flow.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/lib/sstep.c | 36 ++++++++++++++++++++++++++++++++++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 9a52349..e15c521 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -566,7 +566,7 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned int instr)
unsigned long int ea;
unsigned int cr, mb, me, sh;
int err;
- unsigned long old_ra;
+ unsigned long old_ra, val3;
long ival;
opcode = instr >> 26;
@@ -1486,11 +1486,43 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned int instr)
goto ldst_done;
case 36: /* stw */
- case 37: /* stwu */
val = regs->gpr[rd];
err = write_mem(val, dform_ea(instr, regs), 4, regs);
goto ldst_done;
+ case 37: /* stwu */
+ val = regs->gpr[rd];
+ val3 = dform_ea(instr, regs);
+ /*
+ * For PPC32 we always use stwu to change stack point with r1. So
+ * this emulated store may corrupt the exception frame, now we
+ * have to provide the exception frame trampoline, which is pushed
+ * below the kprobed function stack. So we only update gpr[1] but
+ * don't emulate the real store operation. We will do real store
+ * operation safely in exception return code by checking this flag.
+ */
+ if ((ra == 1) && !(regs->msr & MSR_PR) \
+ && (val3 >= (regs->gpr[1] - STACK_INT_FRAME_SIZE))) {
+ /*
+ * Check if we will touch kernel sack overflow
+ */
+ if (val3 - STACK_INT_FRAME_SIZE <= current->thread.ksp_limit) {
+ printk(KERN_CRIT "Can't kprobe this since Kernel stack overflow.\n");
+ err = -EINVAL;
+ break;
+ }
+
+ /*
+ * Check if we already set since that means we'll
+ * lose the previous value.
+ */
+ WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE));
+ set_thread_flag(TIF_EMULATE_STACK_STORE);
+ err = 0;
+ } else
+ err = write_mem(val, val3, 4, regs);
+ goto ldst_done;
+
case 38: /* stb */
case 39: /* stbu */
val = regs->gpr[rd];
--
1.7.9.5
^ permalink raw reply related
* Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame
From: Benjamin Herrenschmidt @ 2012-09-12 8:43 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <505049FE.8060204@windriver.com>
On Wed, 2012-09-12 at 16:38 +0800, tiejun.chen wrote:
> > So you need to store that old r1 somewhere fist then retrieve it
> > after the memcpy call. That or open-code the memcpy to avoid all
> > the clobbering problems.
>
> Maybe we can use copy_and_flush() since looks copy_and_flush() only
> clobber r0,
> r6 and LR explicitly.
>
> I'll resync these comments for v4.
I'd say just open code it. You already have src and dst in registers,
the length can easily be put in ctr... easier that way, not clobbering
to worry about nor stack frame to create etc...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Add an xmon command to dump one or all pacas
From: Benjamin Herrenschmidt @ 2012-09-12 8:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1347436360-29095-1-git-send-email-michael@ellerman.id.au>
On Wed, 2012-09-12 at 17:52 +1000, Michael Ellerman wrote:
> This was originally motivated by a desire to see the mapping between
> logical and hardware cpu numbers.
>
> But it seemed that it made more sense to just add a command to dump
> (most of) the paca.
>
> With no arguments "dp" will dump the paca for all possible cpus. If
> there are no possible cpus, like early in boot, it will tell you that.
I'd rather "dp" dump the paca for the current active CPU in xmon.
Shouldn't be hard to make a "dpa" that dumps them all too.
(You can do inchar to check the next char and if not 'a' you can put it
back in termch).
Cheers,
Ben.
> It also takes an argument, eg. "dp 3" which is the logical cpu number
> in hex. This form does not check if the cpu is possible, but displays
> the paca regardless, as well as the cpu's state in the possible, present
> and online masks.
>
> Sample output, number in brackets is the offset into the struct:
>
> 2:mon> dp 3
> paca for cpu 0x3 @ c00000000ff20a80:
> possible = yes
> present = yes
> online = yes
A bit of bike shed painting but ... the above isn't strictly PACA
fields... Handy to have but should it be part of the same command ?
Cheers,
Ben.
> lock_token = 0x8000 (0x8)
> paca_index = 0x3 (0xa)
> kernel_toc = 0xc00000000144f990 (0x10)
> kernelbase = 0xc000000000000000 (0x18)
> kernel_msr = 0xb000000000001032 (0x20)
> stab_real = 0x0 (0x28)
> stab_addr = 0x0 (0x30)
> emergency_sp = 0xc00000003ffe4000 (0x38)
> data_offset = 0xa40000 (0x40)
> hw_cpu_id = 0x9 (0x50)
> cpu_start = 0x1 (0x52)
> kexec_state = 0x0 (0x53)
> __current = 0xc00000007e568680 (0x218)
> kstack = 0xc00000007e5a3e30 (0x220)
> stab_rr = 0x1a (0x228)
> saved_r1 = 0xc00000007e7cb450 (0x230)
> trap_save = 0x0 (0x240)
> soft_enabled = 0x0 (0x242)
> irq_happened = 0x0 (0x243)
> io_sync = 0x0 (0x244)
> irq_work_pending = 0x0 (0x245)
> nap_state_lost = 0x0 (0x246)
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/xmon/xmon.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index eab3492..f090c46 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -202,6 +202,7 @@ Commands:\n\
> df dump float values\n\
> dd dump double values\n\
> dl dump the kernel log buffer\n\
> + dp # dump paca for cpu # (or all)\n\
> dr dump stream of raw bytes\n\
> e print exception information\n\
> f flush cache\n\
> @@ -2008,6 +2009,82 @@ static void xmon_rawdump (unsigned long adrs, long ndump)
> printf("\n");
> }
>
> +static void dump_one_paca(int cpu)
> +{
> + struct paca_struct *p;
> +
> + if (setjmp(bus_error_jmp) != 0) {
> + printf("*** Error dumping paca for cpu 0x%x!\n", cpu);
> + return;
> + }
> +
> + catch_memory_errors = 1;
> + sync();
> +
> + p = &paca[cpu];
> +
> + printf("paca for cpu 0x%x @ %p:\n", cpu, p);
> +
> + printf(" %-*s = %s\n", 16, "possible", cpu_possible(cpu) ? "yes" : "no");
> + printf(" %-*s = %s\n", 16, "present", cpu_present(cpu) ? "yes" : "no");
> + printf(" %-*s = %s\n", 16, "online", cpu_online(cpu) ? "yes" : "no");
> +
> +#define DUMP(name, format) \
> + printf(" %-*s = %#-*"format"\t(0x%lx)\n", 16, #name, 18, p->name, \
> + (u64)((void *)&(p->name) - (void *)p));
> +
> + DUMP(lock_token, "x");
> + DUMP(paca_index, "x");
> + DUMP(kernel_toc, "lx");
> + DUMP(kernelbase, "lx");
> + DUMP(kernel_msr, "lx");
> +#ifdef CONFIG_PPC_STD_MMU_64
> + DUMP(stab_real, "lx");
> + DUMP(stab_addr, "lx");
> +#endif
> + DUMP(emergency_sp, "p");
> + DUMP(data_offset, "lx");
> + DUMP(hw_cpu_id, "x");
> + DUMP(cpu_start, "x");
> + DUMP(kexec_state, "x");
> + DUMP(__current, "p");
> + DUMP(kstack, "lx");
> + DUMP(stab_rr, "lx");
> + DUMP(saved_r1, "lx");
> + DUMP(trap_save, "x");
> + DUMP(soft_enabled, "x");
> + DUMP(irq_happened, "x");
> + DUMP(io_sync, "x");
> + DUMP(irq_work_pending, "x");
> + DUMP(nap_state_lost, "x");
> +
> +#undef DUMP
> +
> + catch_memory_errors = 0;
> + sync();
> +}
> +
> +static void dump_pacas(void)
> +{
> + unsigned long num = ULONG_MAX;
> + int cpu;
> +
> + scanhex(&num);
> + if (num != ULONG_MAX) {
> + /* NB we allow showing a non-possible paca here */
> + dump_one_paca(num);
> + return;
> + }
> +
> + if (num_possible_cpus() == 0) {
> + printf("No possible cpus, use 'dp #' to dump individual cpus\n");
> + return;
> + }
> +
> + for_each_possible_cpu(cpu)
> + dump_one_paca(cpu);
> +}
> +
> #define isxdigit(c) (('0' <= (c) && (c) <= '9') \
> || ('a' <= (c) && (c) <= 'f') \
> || ('A' <= (c) && (c) <= 'F'))
> @@ -2017,6 +2094,12 @@ dump(void)
> int c;
>
> c = inchar();
> +
> + if (c == 'p') {
> + dump_pacas();
> + return;
> + }
> +
> if ((isxdigit(c) && c != 'f' && c != 'd') || c == '\n')
> termch = c;
> scanhex((void *)&adrs);
^ permalink raw reply
* Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame
From: tiejun.chen @ 2012-09-12 8:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1347439382.2603.97.camel@pasglop>
On 09/12/2012 04:43 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2012-09-12 at 16:38 +0800, tiejun.chen wrote:
>>> So you need to store that old r1 somewhere fist then retrieve it
>>> after the memcpy call. That or open-code the memcpy to avoid all
>>> the clobbering problems.
>>
>> Maybe we can use copy_and_flush() since looks copy_and_flush() only
>> clobber r0,
>> r6 and LR explicitly.
>>
>> I'll resync these comments for v4.
>
> I'd say just open code it. You already have src and dst in registers,
> the length can easily be put in ctr... easier that way, not clobbering
ctr should be easier :)
> to worry about nor stack frame to create etc...
If you don't like this v4, let me know and then I can go back memcpy for next
version.
Tiejun
^ permalink raw reply
* RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload
From: Liu Qiang-B32616 @ 2012-09-12 9:45 UTC (permalink / raw)
To: Dan Williams
Cc: Li Yang-R58472, arnd@arndb.de, vinod.koul@intel.com,
gregkh@linuxfoundation.org, Dave Jiang,
linux-kernel@vger.kernel.org, Phillips Kim-R1AAHA,
linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
davem@davemloft.net, herbert@gondor.apana.org.au
In-Reply-To: <CAA9_cmfT1R2+r9_8g0giMJz+wvrNce6T6GPDpvUTtcA-UyAZNQ@mail.gmail.com>
> >> Will this engine be coordinating with another to handle memory copies?
> >> The dma mapping code for async_tx/raid is broken when dma mapping
> >> requests overlap or cross dma device boundaries [1].
> >>
> >> [1]: http://marc.info/?l=3Dlinux-arm-kernel&m=3D129407269402930&w=3D2
> > Yes, it needs fsl-dma to handle memcpy copies.
> > I read your link, the unmap address is stored in talitos hwdesc, the
> address will be unmapped when async_tx ack this descriptor, I know fsl-
> dma won't wait this ack flag in current kernel, so I fix it in fsl-dma
> patch 5/8. Do you mean that?
>=20
> Unfortunately no. I'm open to other suggestions. but as far as I can
> see it requires deeper changes to rip out the dma mapping that happens
> in async_tx and the automatic unmapping done by drivers. It should
> all be pushed to the client (md).
>=20
> Currently async_tx hides hardware details from md such that it doesn't
> even care if the operation is offloaded to hardware at all, but that
> takes things too far. In the worst case an copy->xor chain handled by
> multiple channels results in :
>=20
> 1/ dma_map(copy_chan...)
> 2/ dma_map(xor_chan...)
> 3/ <exec copy>
> 4/ dma_unmap(copy_chan...)
> 5/ <exec xor> <---initiated by the copy_chan
> 6/ dma_unmap(xor_chan...)
>=20
> Step 2 violates the dma api since the buffers belong to the xor_chan
> until unmap. Step 5 also causes the random completion context of the
> copy channel to bleed into submission context of the xor channel which
> is problematic. So the order needs to be:
>=20
> 1/ dma_map(copy_chan...)
> 2/ <exec copy>
> 3/ dma_unmap(copy_chan...)
> 4/ dma_map(xor_chan...)
> 5/ <exec xor> <--initiated by md in a static context
> 6/ dma_unmap(xor_chan...)
>=20
> Also, if xor_chan and copy_chan lie with the same dma mapping domain
> (iommu or parent device) then we can map the stripe once and skip the
> extra maintenance for the duration of the chain of operations. This
> dumps a lot of hardware details on md, but I think it is the only way
> to get consistent semantics when arbitrary offload devices are
> involved.
Thanks for your answer and links, I did some investigate these days,
first, powerpc processor should be hardware assured cache coherency, it sho=
uld
be ok for hardware when in step 5 (but I will avoid map same address on dif=
ferent
device).
second, I have a workaround to make dma_map/unmap by order when using 2 dif=
ferent
device to offload, I will submit next descriptor until current descriptor c=
omplete,
if (submit->flags & ASYNC_TX_ACK)
async_tx_ack(tx);
if (depend_tx)
async_tx_ack(depend_tx);
+ /* do more check to support 2 devices offload? */
+ if (dma_wait_for_async_tx(tx) =3D=3D DMA_ERROR)
+ panic("%s: DMA_ERROR waiting for tx\n", __func__);
}
EXPORT_SYMBOL_GPL(async_tx_submit);
Also use your example,=20
1/ dma_map(copy_chan...)
2/ tx->submit(tx); async_tx_ack(tx);
3/ dma_unmap(copy_chan...)
4/ dma_map(xor_chan...)
5/ <exec xor> <-- initialized by tx->submit(tx);
6/ dma_unmap(xor_chan...)
Under this way, actually dma_run_dependency() is useless, so this can make =
sure copy
and xor with same page processed by order, and only one descriptor per chan=
nel is
served. dma_unmap in driver is controlled by client (tx->flags)
How's you thinking or any suggestions? I test it on our powerpc, I don't kn=
ow whether
it does work on other architecture.
Thanks.
>=20
> --
> Dan
^ permalink raw reply
* Re: [PATCH v4 0/8] Avoid cache trashing on clearing huge/gigantic page
From: Kirill A. Shutemov @ 2012-09-12 10:09 UTC (permalink / raw)
To: linux-mm
Cc: Andrea Arcangeli, linux-mips, Andi Kleen, Alex Shi,
Robert Richter, linuxppc-dev, x86, Hugh Dickins, linux-kernel,
Jan Beulich, Andy Lutomirski, Johannes Weiner, linux-sh,
Ingo Molnar, Mel Gorman, H. Peter Anvin, sparclinux,
Thomas Gleixner, Tim Chen, Andrew Morton, KAMEZAWA Hiroyuki
In-Reply-To: <1345470757-12005-1-git-send-email-kirill.shutemov@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 50 bytes --]
Hi,
Any feedback?
--
Kirill A. Shutemov
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame
From: Benjamin Herrenschmidt @ 2012-09-12 10:38 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <50504DEE.6060903@windriver.com>
On Wed, 2012-09-12 at 16:55 +0800, tiejun.chen wrote:
> > to worry about nor stack frame to create etc...
>
> If you don't like this v4, let me know and then I can go back memcpy
> for next
> version.
Just open code the whole copy. It should be easy really. As I said, you
have the src and dst already in registers and you know they are aligned,
so just put the size of the frame in a register (divided by 4), do an
mtctr and do a little load_update/store_update loop to do the copy, all
in the asm.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Add an xmon command to dump one or all pacas
From: Stephen Rothwell @ 2012-09-12 11:07 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1347436360-29095-1-git-send-email-michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
Hi Michael,
On Wed, 12 Sep 2012 17:52:40 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> +#define DUMP(name, format) \
> + printf(" %-*s = %#-*"format"\t(0x%lx)\n", 16, #name, 18, p->name, \
> + (u64)((void *)&(p->name) - (void *)p));
I must say that I hate macros that reference (assumed) globals and
shouldn't you use offsetof(struct paca_struct, name) (from
linux/stddef.h)?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] powerpc/p5040: fix dtb build warning of p5040ds.dtb
From: Shaohui Xie @ 2012-09-12 10:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Shaohui Xie
Device node adt7461 was wrongly added in p5040ds.dts, it should be added
into i2c instead of localbus, when build p5040ds.dtb, a warning will dump:
Warning (reg_format): "reg" property in
/localbus@ffe124000/nand@2,0/adt7461@4c has invalid length (4 bytes)
(#address-cells == 1, #size-cells == 1)
This was introduced by:
commit ea6b1ba692bcb5f6e39f409a78cf8b04fdf23baa
Author: Jia Hongtao <B38951@freescale.com>
Date: Tue Aug 28 10:00:55 2012 +0800
powerpc: add adt7461 thermal monitor support to applicable boards
Add thermal monitor support to following boards:
P1022DS, MPC8536DS, P2041RDB, P3041DS, P4080DS, P5020DS, P5040DS
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
based on next branch of http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
arch/powerpc/boot/dts/p5040ds.dts | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/p5040ds.dts b/arch/powerpc/boot/dts/p5040ds.dts
index 8165c93..860b5cc 100644
--- a/arch/powerpc/boot/dts/p5040ds.dts
+++ b/arch/powerpc/boot/dts/p5040ds.dts
@@ -95,6 +95,10 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
};
};
@@ -146,10 +150,6 @@
label = "NAND Writable User area";
reg = <0x1f000000 0x01000000>;
};
- adt7461@4c {
- compatible = "adi,adt7461";
- reg = <0x4c>;
- };
};
board-control@3,0 {
--
1.6.4
^ permalink raw reply related
* RE: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer
From: Li Yang-R58472 @ 2012-09-12 11:17 UTC (permalink / raw)
To: balbi@ti.com, Enrico Scholz
Cc: Chen Peter-B29397, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, gregkh@linuxfoundation.org
In-Reply-To: <20120906142739.GV29202@arwen.pp.htv.fi>
> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@ti.com]
> Sent: Thursday, September 06, 2012 10:28 PM
> To: Enrico Scholz
> Cc: balbi@ti.com; Chen Peter-B29397; linux-usb@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Li Yang-R58472; gregkh@linuxfoundation.org
> Subject: Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime
> STATUS for IN xfer
>=20
> Hi,
>=20
> On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote:
> > Felipe Balbi <balbi@ti.com> writes:
> >
> > >> > Because the fsl_udc_core driver shares one 'status_req' object
> > >> > for the complete ep0 control transfer, it is not possible to
> > >> > prime the final STATUS phase immediately after the IN
> > >> > transaction. E.g. ch9getstatus()
> > >> > executed:
> > >> >
> > >> > | req =3D udc->status_req;
> > >> > | ...
> > >> > | list_add_tail(&req->queue, &ep->queue); if
> > >> > | (ep0_prime_status(udc, EP_DIR_OUT))
> > >> > | ....
> > >> > | struct fsl_req *req =3D udc->status_req;
> > >> > | list_add_tail(&req->queue, &ep->queue);
> > >> >
> > >> > which corrupts the ep->queue list by inserting 'status_req'
> > >> > twice. This causes a kernel oops e.g. when 'lsusb -v' is executed
> on the host.
> > >> >
> > >> > Patch delays the final 'ep0_prime_status(udc, EP_DIR_OUT))' by
> > >> > moving it into the ep0 completion handler.
> > >> >
> > >> Enrico, thanks for pointing this problem.
> > >>
> > >> As "prime STATUS phase immediately after the IN transaction" is
> > >> followed USB 2.0 spec, to fix this problem, it is better to add
> data_req for ep0.
> > >> In fact, it is already at FSL i.mx internal code, just still not
> mainlined.
> > >
> > > so, do I get an Acked-by to this patch ? Does it need to go on
> > > v3.6-rc or can it wait until v3.7 merge window ?
> >
> > Without this (or the mentioned data_req patch), I can crash a g_multi
> > gadget by executing 'lsusb -v' as root on the host. Should not be
> > exploitable (only a BUG_ON() is triggered) but issue should be fixed
> > asap.
>=20
> cool, so I'll apply to my fixes branch as soon as I get Acked-by or
> Tested-by from someone.
This seems to revert the error handling for USB2.0 spec 8.5.3.3. But the p=
roblem is a serious one to be fixed right away. So
Acked-by: Li Yang <leoli@freescale.com>
We need to revisit the error handling issue later and find a proper way to =
address it.
Regards,
Leo
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
From: Kumar Gala @ 2012-09-12 12:13 UTC (permalink / raw)
To: Huang Changming-R66093
Cc: linux-mmc@vger.kernel.org, Chris Ball,
linuxppc-dev@lists.ozlabs.org list, Anton Vorontsov
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C17701A@039-SN1MPN1-002.039d.mgd.msft.net>
On Sep 12, 2012, at 1:18 AM, Huang Changming-R66093 wrote:
>=20
>=20
> Best Regards
> Jerry Huang
>=20
>=20
>> -----Original Message-----
>> From: Chris Ball [mailto:cjb@laptop.org]
>> Sent: Wednesday, September 12, 2012 4:59 AM
>> To: Kumar Gala
>> Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list; =
linux-
>> mmc@vger.kernel.org; Anton Vorontsov
>> Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the =
CMD23
>>=20
>> Hi,
>>=20
>> On Tue, Sep 11 2012, Kumar Gala wrote:
>>> thanks for the info. Do you know what's required on controller side
>>> to handle cards that support CMD23?
>>>=20
>>> I'm trying to figure out if older controller's on FSL SoCs are =
missing
>>> some feature to allow CMD23 to work (vs Auto-CMD23).
>>=20
>> It seems plausible that it's just not implemented on these =
controllers.
>> It's a little strange, since the command's been specified for so long =
and
>> we haven't seen any other controllers with problems. The patch would =
be
>> correct if this is true.
>>=20
>=20
> I didn't find any description about it, but after testing on FSL =
silicones, I got this result:
> Some silicones support this command, and some silicones don't support =
it, which will cause I/O error.
Can you list out which SoCs support it and which don't. Having this =
list will be useful in understanding which controller versions supported =
it.
- k=
^ permalink raw reply
* [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver
From: Dan Horák @ 2012-09-12 12:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nico Macrionitis, Giuseppe Coviello
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds support for GXT4000P and GXT6500P cards found on some
IBM pSeries machines.
GXT4000P/6000P and GXT4500P/6500P couples are identical from
software's point of view and are based on the same Raster Engine
(RC1000), except for a different reference clock for the PLL.
GXT6x00P models are equipped with an additional Geometry Engine
(GT1000) but this driver doesn't use it.
Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
Tested-by: Dan Horák <dan@danny.cz>
---
drivers/video/Kconfig | 8 +++++---
drivers/video/gxt4500.c | 15 +++++++++++++--
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..c89eb1e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2167,14 +2167,16 @@ config FB_PNX4008_DUM_RGB
Say Y here to enable support for PNX4008 RGB Framebuffer
config FB_IBM_GXT4500
- tristate "Framebuffer support for IBM GXT4500P adaptor"
+ tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
depends on FB && PPC
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
- Say Y here to enable support for the IBM GXT4500P display
- adaptor, found on some IBM System P (pSeries) machines.
+ Say Y here to enable support for the IBM GXT4000P/6000P and
+ GXT4500P/6500P display adaptor based on Raster Engine RC1000,
+ found on some IBM System P (pSeries) machines. This driver
+ doesn't use Geometry Engine GT1000.
config FB_PS3
tristate "PS3 GPU framebuffer driver"
diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
index 0fad23f..755c3e7 100644
--- a/drivers/video/gxt4500.c
+++ b/drivers/video/gxt4500.c
@@ -1,5 +1,6 @@
/*
- * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
+ * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
+ * display adaptors
*
* Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
*/
@@ -14,6 +15,8 @@
#include <linux/string.h>
#define PCI_DEVICE_ID_IBM_GXT4500P 0x21c
+#define PCI_DEVICE_ID_IBM_GXT6500P 0x21b
+#define PCI_DEVICE_ID_IBM_GXT4000P 0x16e
#define PCI_DEVICE_ID_IBM_GXT6000P 0x170
/* GXT4500P registers */
@@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devinitdata = {
/* List of supported cards */
enum gxt_cards {
GXT4500P,
+ GXT6500P,
+ GXT4000P,
GXT6000P
};
@@ -182,6 +187,8 @@ static const struct cardinfo {
const char *cardname;
} cardinfo[] = {
[GXT4500P] = { .refclk_ps = 9259, .cardname = "IBM GXT4500P" },
+ [GXT6500P] = { .refclk_ps = 9259, .cardname = "IBM GXT6500P" },
+ [GXT4000P] = { .refclk_ps = 40000, .cardname = "IBM GXT4000P" },
[GXT6000P] = { .refclk_ps = 40000, .cardname = "IBM GXT6000P" },
};
@@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev *pdev)
static const struct pci_device_id gxt4500_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
.driver_data = GXT4500P },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
+ .driver_data = GXT6500P },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
+ .driver_data = GXT4000P },
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
.driver_data = GXT6000P },
{ 0 }
@@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
module_exit(gxt4500_exit);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
-MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
+MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
MODULE_LICENSE("GPL");
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");
--
1.7.7.6
^ permalink raw reply related
* [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro
From: Mihai Caraman @ 2012-09-12 13:18 UTC (permalink / raw)
To: kvm-ppc; +Cc: Mihai Caraman, linuxppc-dev, kvm
The current form of DO_KVM macro restricts its use to one call per input
parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
definition.
Duplicate calls of DO_KVM are required by distinct implementations of
exeption handlers which are delegated at runtime. Use a rare label number
to avoid conflicts with the calling contexts.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/include/asm/kvm_booke_hv_asm.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_booke_hv_asm.h b/arch/powerpc/include/asm/kvm_booke_hv_asm.h
index 30a600f..a37a12a 100644
--- a/arch/powerpc/include/asm/kvm_booke_hv_asm.h
+++ b/arch/powerpc/include/asm/kvm_booke_hv_asm.h
@@ -38,9 +38,9 @@
#ifdef CONFIG_KVM_BOOKE_HV
BEGIN_FTR_SECTION
mtocrf 0x80, r11 /* check MSR[GS] without clobbering reg */
- bf 3, kvmppc_resume_\intno\()_\srr1
+ bf 3, 1975f
b kvmppc_handler_\intno\()_\srr1
-kvmppc_resume_\intno\()_\srr1:
+1975:
END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
#endif
.endm
--
1.7.4.1
^ permalink raw reply related
* [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver
From: Dan Horák @ 2012-09-12 12:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nico Macrionitis, Giuseppe Coviello
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds support for GXT4000P and GXT6500P cards found on some
IBM pSeries machines.
GXT4000P/6000P and GXT4500P/6500P couples are identical from
software's point of view and are based on the same Raster Engine
(RC1000), except for a different reference clock for the PLL.
GXT6x00P models are equipped with an additional Geometry Engine
(GT1000) but this driver doesn't use it.
Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
Tested-by: Dan Horák <dan@danny.cz>
---
drivers/video/Kconfig | 8 +++++---
drivers/video/gxt4500.c | 15 +++++++++++++--
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..c89eb1e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2167,14 +2167,16 @@ config FB_PNX4008_DUM_RGB
Say Y here to enable support for PNX4008 RGB Framebuffer
config FB_IBM_GXT4500
- tristate "Framebuffer support for IBM GXT4500P adaptor"
+ tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
depends on FB && PPC
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
- Say Y here to enable support for the IBM GXT4500P display
- adaptor, found on some IBM System P (pSeries) machines.
+ Say Y here to enable support for the IBM GXT4000P/6000P and
+ GXT4500P/6500P display adaptor based on Raster Engine RC1000,
+ found on some IBM System P (pSeries) machines. This driver
+ doesn't use Geometry Engine GT1000.
config FB_PS3
tristate "PS3 GPU framebuffer driver"
diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
index 0fad23f..755c3e7 100644
--- a/drivers/video/gxt4500.c
+++ b/drivers/video/gxt4500.c
@@ -1,5 +1,6 @@
/*
- * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
+ * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
+ * display adaptors
*
* Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
*/
@@ -14,6 +15,8 @@
#include <linux/string.h>
#define PCI_DEVICE_ID_IBM_GXT4500P 0x21c
+#define PCI_DEVICE_ID_IBM_GXT6500P 0x21b
+#define PCI_DEVICE_ID_IBM_GXT4000P 0x16e
#define PCI_DEVICE_ID_IBM_GXT6000P 0x170
/* GXT4500P registers */
@@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devinitdata = {
/* List of supported cards */
enum gxt_cards {
GXT4500P,
+ GXT6500P,
+ GXT4000P,
GXT6000P
};
@@ -182,6 +187,8 @@ static const struct cardinfo {
const char *cardname;
} cardinfo[] = {
[GXT4500P] = { .refclk_ps = 9259, .cardname = "IBM GXT4500P" },
+ [GXT6500P] = { .refclk_ps = 9259, .cardname = "IBM GXT6500P" },
+ [GXT4000P] = { .refclk_ps = 40000, .cardname = "IBM GXT4000P" },
[GXT6000P] = { .refclk_ps = 40000, .cardname = "IBM GXT6000P" },
};
@@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev *pdev)
static const struct pci_device_id gxt4500_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
.driver_data = GXT4500P },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
+ .driver_data = GXT6500P },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
+ .driver_data = GXT4000P },
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
.driver_data = GXT6000P },
{ 0 }
@@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
module_exit(gxt4500_exit);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
-MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
+MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
MODULE_LICENSE("GPL");
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH 2/5] ASoC: fsl: mpc5200 combine psc_dma platform data
From: Mark Brown @ 2012-09-12 13:54 UTC (permalink / raw)
To: Eric Millbrandt
Cc: alsa-devel, Anatolij Gustschin, linuxppc-dev, Liam Girdwood
In-Reply-To: <1347416089-23393-3-git-send-email-emillbrandt@dekaresearch.com>
On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
> The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared platform data
> with mpc5200_dma.
This looks good but depends on patch 1 so I can't apply it - if you can
rebase things so this is patch 1 I'll apply it.
^ permalink raw reply
* RE: [PATCH 5/5] ASoC: fsl: mpc5200 remove pcm030 and efika audio fabric
From: Eric Millbrandt @ 2012-09-12 14:05 UTC (permalink / raw)
To: 'Mark Brown'
Cc: alsa-devel@alsa-project.org, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <20120912032026.GI9162@opensource.wolfsonmicro.com>
Hi Mark,
On 2012-09-11 Mark Brown wrote:
> On Tue, Sep 11, 2012 at 10:14:49PM -0400, Eric Millbrandt wrote:
>> MPC5200 ASoC setup can now be done in the device tree.
>
> I only noticed DT bindings being added for pcm030, not for efika?
>
When I looked I didn't see the Efika (PPC 5200B) DT in-tree. It only appea=
rs to exist out-of-tree, http://www.powerdeveloper.org/platforms/efika/devi=
cetree.
Eric
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* RE: [PATCH 1/5] ASoC: fsl: mpc5200 multi-codec fixups
From: Eric Millbrandt @ 2012-09-12 14:29 UTC (permalink / raw)
To: 'Mark Brown'
Cc: alsa-devel@alsa-project.org, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <20120912030457.GF9162@opensource.wolfsonmicro.com>
Hi Mark,
On 2012-09-11 Mark Brown wrote:
>> --- a/arch/powerpc/platforms/52xx/Kconfig
>> +++ b/arch/powerpc/platforms/52xx/Kconfig
>> @@ -1,6 +1,7 @@
>> config PPC_MPC52xx bool "52xx-based boards" depends on 6xx + =
select
>> FSL_SOC select PPC_CLOCK select PPC_PCI_CHOICE
>
> This doesnt seem to have much to do with the commit message...
>
I'll spit this into another patch. SND_POWERPC_SOC, which wraps all of the=
Powerpc socs, depends on FSL_SOC. Would it be better to have SND_POWERPC_=
SOC depend on FSL_SOC or PPC_MPC52xx?
>> -/* ALSA only supports a single AC97 device so static is recommend here
>> */ +/* ALSA only supports a single AC97 bus device so static is
>> recommend +here */
>> static struct psc_dma *psc_dma;
>
> Or this.
>
I'll also be split this out. The change was to clarify that now you can ha=
ve multiple ac97 codec, but soc-core can still only have on ac97 bus.
Eric
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* [PATCH] of: specify initrd location using 64-bit
From: Cyril Chemparathy @ 2012-09-12 16:05 UTC (permalink / raw)
To: devicetree-discuss, linux-arm-kernel, linux-c6x-dev, linux-kernel,
linux-mips, linux, linuxppc-dev, microblaze-uclinux
Cc: x86, david.daney, bigeasy, paul.gortmaker, paulus, hpa,
m.szyprowski, jonas, linux, nico, a-jacquiot, mingo, suzuki,
mahesh, linus.walleij, Cyril Chemparathy, arnd, msalter,
rob.herring, tglx, blogic, dhowells, monstr, ralf, tj
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of the current unsigned long.
---
arch/arm/mm/init.c | 2 +-
arch/c6x/kernel/devicetree.c | 3 +--
arch/microblaze/kernel/prom.c | 3 +--
arch/mips/kernel/prom.c | 3 +--
arch/openrisc/kernel/prom.c | 3 +--
arch/powerpc/kernel/prom.c | 3 +--
arch/x86/kernel/devicetree.c | 3 +--
drivers/of/fdt.c | 10 ++++++----
include/linux/of_fdt.h | 3 +--
9 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index ad722f1..579792c 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
__tagtable(ATAG_INITRD2, parse_tag_initrd2);
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
index bdb56f0..287d0e6 100644
--- a/arch/c6x/kernel/devicetree.c
+++ b/arch/c6x/kernel/devicetree.c
@@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 4a764cc..cecd42c 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 028f6f8..e37e0dc 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -41,8 +41,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
index 5869e3f..150215a 100644
--- a/arch/openrisc/kernel/prom.c
+++ b/arch/openrisc/kernel/prom.c
@@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 37725e8..ac15f63 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -549,8 +549,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index b158152..2fbad6b 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 91a375f..2ff8b7a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -554,7 +554,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
*/
void __init early_init_dt_check_for_initrd(unsigned long node)
{
- unsigned long start, end, len;
+ u64 start, end;
+ unsigned long len;
__be32 *prop;
pr_debug("Looking for initrd properties... ");
@@ -562,15 +563,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
if (!prop)
return;
- start = of_read_ulong(prop, len/4);
+ start = of_read_number(prop, len/4);
prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
if (!prop)
return;
- end = of_read_ulong(prop, len/4);
+ end = of_read_number(prop, len/4);
early_init_dt_setup_initrd_arch(start, end);
- pr_debug("initrd_start=0x%lx initrd_end=0x%lx\n", start, end);
+ pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n",
+ (unsigned long long)start, (unsigned long long)end);
}
#else
inline void early_init_dt_check_for_initrd(unsigned long node)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..4a17939 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
* physical addresses.
*/
#ifdef CONFIG_BLK_DEV_INITRD
-extern void early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end);
+extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
#endif
/* Early flat tree scan hooks */
--
1.7.9.5
^ permalink raw reply related
* [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver
From: Dan Horák @ 2012-09-12 16:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nico Macrionitis, Giuseppe Coviello
I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
adapter to the gxt4500 driver.
See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
for more details.
This patch adds support for GXT4000P and GXT6500P cards found on some
IBM pSeries machines.
GXT4000P/6000P and GXT4500P/6500P couples are identical from
software's point of view and are based on the same Raster Engine
(RC1000), except for a different reference clock for the PLL.
GXT6x00P models are equipped with an additional Geometry Engine
(GT1000) but this driver doesn't use it.
Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
Tested-by: Dan Horák <dan@danny.cz>
---
drivers/video/Kconfig | 8 +++++---
drivers/video/gxt4500.c | 15 +++++++++++++--
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..c89eb1e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2167,14 +2167,16 @@ config FB_PNX4008_DUM_RGB
Say Y here to enable support for PNX4008 RGB Framebuffer
config FB_IBM_GXT4500
- tristate "Framebuffer support for IBM GXT4500P adaptor"
+ tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
depends on FB && PPC
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
---help---
- Say Y here to enable support for the IBM GXT4500P display
- adaptor, found on some IBM System P (pSeries) machines.
+ Say Y here to enable support for the IBM GXT4000P/6000P and
+ GXT4500P/6500P display adaptor based on Raster Engine RC1000,
+ found on some IBM System P (pSeries) machines. This driver
+ doesn't use Geometry Engine GT1000.
config FB_PS3
tristate "PS3 GPU framebuffer driver"
diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
index 0fad23f..755c3e7 100644
--- a/drivers/video/gxt4500.c
+++ b/drivers/video/gxt4500.c
@@ -1,5 +1,6 @@
/*
- * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
+ * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
+ * display adaptors
*
* Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
*/
@@ -14,6 +15,8 @@
#include <linux/string.h>
#define PCI_DEVICE_ID_IBM_GXT4500P 0x21c
+#define PCI_DEVICE_ID_IBM_GXT6500P 0x21b
+#define PCI_DEVICE_ID_IBM_GXT4000P 0x16e
#define PCI_DEVICE_ID_IBM_GXT6000P 0x170
/* GXT4500P registers */
@@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devinitdata = {
/* List of supported cards */
enum gxt_cards {
GXT4500P,
+ GXT6500P,
+ GXT4000P,
GXT6000P
};
@@ -182,6 +187,8 @@ static const struct cardinfo {
const char *cardname;
} cardinfo[] = {
[GXT4500P] = { .refclk_ps = 9259, .cardname = "IBM GXT4500P" },
+ [GXT6500P] = { .refclk_ps = 9259, .cardname = "IBM GXT6500P" },
+ [GXT4000P] = { .refclk_ps = 40000, .cardname = "IBM GXT4000P" },
[GXT6000P] = { .refclk_ps = 40000, .cardname = "IBM GXT6000P" },
};
@@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev *pdev)
static const struct pci_device_id gxt4500_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
.driver_data = GXT4500P },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
+ .driver_data = GXT6500P },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
+ .driver_data = GXT4000P },
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
.driver_data = GXT6000P },
{ 0 }
@@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
module_exit(gxt4500_exit);
MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
-MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
+MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
MODULE_LICENSE("GPL");
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] of: specify initrd location using 64-bit
From: Geert Uytterhoeven @ 2012-09-12 16:16 UTC (permalink / raw)
To: Cyril Chemparathy
Cc: linux-mips, x86, a-jacquiot, mahesh, linus.walleij,
paul.gortmaker, paulus, hpa, m.szyprowski, jonas, linux,
linux-c6x-dev, nico, david.daney, mingo, suzuki, linux-arm-kernel,
linux, arnd, microblaze-uclinux, devicetree-discuss, msalter,
rob.herring, tglx, bigeasy, blogic, dhowells, monstr,
linux-kernel, ralf, tj, linuxppc-dev
In-Reply-To: <1347465937-7056-1-git-send-email-cyril@ti.com>
On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy <cyril@ti.com> wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
Why not phys_addr_t?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [alsa-devel] [PATCH 2/5] ASoC: fsl: mpc5200 combine psc_dma platform data
From: Eric Millbrandt @ 2012-09-12 17:15 UTC (permalink / raw)
To: 'Mark Brown'
Cc: alsa-devel@alsa-project.org, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <20120912135412.GF19055@opensource.wolfsonmicro.com>
Hi Mark,
On 2012-09-12 Mark Brown wrote:
> On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
>> The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared
>> platform data with mpc5200_dma.
>
> This looks good but depends on patch 1 so I can't apply it - if you can
> rebase things so this is patch 1 I'll apply it.
After mulling your comments I see now that not being able to define a snd_s=
oc_ops for an ASoC machine driver would only work for very few boards. I'l=
l think on it some more and respin the series to be pcm030 specific.
Eric
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory
From: Vasilis Liaskovitis @ 2012-09-12 17:18 UTC (permalink / raw)
To: Wen Congyang
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, Yasuaki Ishimatsu, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, Andrew Morton,
linuxppc-dev, cl, liuj97
In-Reply-To: <50501B9C.7000200@cn.fujitsu.com>
Hi,
On Wed, Sep 12, 2012 at 01:20:28PM +0800, Wen Congyang wrote:
> >
> > On Mon, Sep 10, 2012 at 10:01:44AM +0800, Wen Congyang wrote:
> >> At 09/10/2012 09:46 AM, Yasuaki Ishimatsu Wrote:
> >>> How do you test the patch? As Andrew says, for hot-removing memory,
> >>> we need a particular hardware. I think so too. So many people may want
> >>> to know how to test the patch.
> >>> If we apply following patch to kvm guest, can we hot-remove memory on
> >>> kvm guest?
> >>>
> >>> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg01389.html
> >>
> >> Yes, if we apply this patchset, we can test hot-remove memory on kvm guest.
> >> But that patchset doesn't implement _PS3, so there is some restriction.
> >
> > the following repos contain the patchset above, plus 2 more patches that add
> > PS3 support to the dimm devices in qemu/seabios:
> >
> > https://github.com/vliaskov/seabios/commits/memhp-v2
> > https://github.com/vliaskov/qemu-kvm/commits/memhp-v2
> >
> > I have not posted the PS3 patches yet in the qemu list, but will post them
> > soon for v3 of the memory hotplug series. If you have issues testing, let me
> > know.
>
> Hmm, seabios doesn't support ACPI table SLIT. We can specify node it for dimm
> device, so I think we should support SLIT in seabios. Otherwise we may meet
> the following kernel messages:
> [ 325.016769] init_memory_mapping: [mem 0x40000000-0x5fffffff]
> [ 325.018060] [mem 0x40000000-0x5fffffff] page 2M
> [ 325.019168] [ffffea0001000000-ffffea00011fffff] potential offnode page_structs
> [ 325.024172] [ffffea0001200000-ffffea00013fffff] potential offnode page_structs
> [ 325.028596] [ffffea0001400000-ffffea00017fffff] PMD -> [ffff880035000000-ffff8800353fffff] on node 1
> [ 325.031775] [ffffea0001600000-ffffea00017fffff] potential offnode page_structs
>
> Do you have plan to do it?
thanks for testing.
commit 5294828 from https://github.com/vliaskov/seabios/commits/memhp-v2
implements a SLIT table for the given numa nodes.
However I am not sure the SLIT is the problem. The kernel builds a default
numa_distance table in arch/x86/mm/numa.c: numa_alloc_distance(). If the BIOS
doesn't present a SLIT, this should take effect (numactl --hardware should
report this table)
Do you have more details on how to reproduce the warning? e.g. how many dimms
are present in the system? Does this happen on the first dimm hot-plugged?
Are all SRAT entries parsed correctly at boot-time or do you see any other
warnings at boot-time?
I 'll investigate a bit more and report back.
thanks,
- Vasilis
^ permalink raw reply
* [PATCH] pseries: double NR_CPUS in defconfig
From: Nishanth Aravamudan @ 2012-09-12 17:47 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
Anticipating growth in coming years, we should ensure we are getting a
good lead on testing.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 1f65b3c..a0e0e53 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -2,7 +2,7 @@ CONFIG_PPC64=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
CONFIG_SMP=y
-CONFIG_NR_CPUS=1024
+CONFIG_NR_CPUS=2048
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
^ permalink raw reply related
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