Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory

[Minchan Kim]

On Tue, Sep 11, 2012 at 01:18:24PM +0800, Jerry wrote:
 Hi Kim,
 
 Thank you for your kindness. Let me clarify this:
 
 On ARM architecture, there are 32 bits physical addresses space. However,
 the addresses space is divided into 8 banks normally. Each bank
 disabled/enabled by a chip selector signal. In my platform, bank0 connects
 a DDR chip, and bank1 also connects another DDR chip. And each DDR chip
 whose capability is 512MB is integrated into the main board. So, it could
 not be removed by hand. We can disable/enable each bank by peripheral
 device controller registers.
 
 When system enter suspend state, if all the pages allocated could be
 migrated to one bank, there are no valid data in the another bank. In this
 time, I could disable the free bank. It isn't necessary to provided power
 to this chip in the suspend state. When system resume, I just need to
 enable it again.
 

Yes. I already know it and other trials for that a few years ago[1].
A few years ago, I investigated the benefit between power consumption
benefit during suspend VS start-up latency of resume and
power consumption cost of migration(page migration and IO write for
migration) and concluded normally the gain is not big. :)
The situation could be changed these days as workload are changing
but I'm skeptical about that approach, still.

Anyway, it's my private thought so you don't need to care about that.
If you are ready to submit the patchset, please send out.

1. http://lwn.net/Articles/478049/

Thanks.

- 
Kind regards,
Minchan Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23

[Huang Changming-R66093]

Best Regards
Jerry Huang


 -Original Message-
 From: Chris Ball [mailto:c...@laptop.org]
 Sent: Wednesday, September 12, 2012 4:59 AM
 To: Kumar Gala
 Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list; linux-
 m...@vger.kernel.org; Anton Vorontsov
 Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
 
 Hi,
 
 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?
 
  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).
 
 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.
 

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.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Add an xmon command to dump one or all pacas

[Michael Ellerman]

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.

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 @ cff20a80:
 possible = yes
 present  = yes
 online   = yes
 lock_token   = 0x8000  (0x8)
 paca_index   = 0x3 (0xa)
 kernel_toc   = 0xc144f990  (0x10)
 kernelbase   = 0xc000  (0x18)
 kernel_msr   = 0xb0001032  (0x20)
 stab_real= 0x0 (0x28)
 stab_addr= 0x0 (0x30)
 emergency_sp = 0xc0003ffe4000  (0x38)
 data_offset  = 0xa4(0x40)
 hw_cpu_id= 0x9 (0x50)
 cpu_start= 0x1 (0x52)
 kexec_state  = 0x0 (0x53)
 __current= 0xc0007e568680  (0x218)
 kstack   = 0xc0007e5a3e30  (0x220)
 stab_rr  = 0x1a(0x228)
 saved_r1 = 0xc0007e7cb450  (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 mich...@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\
   dldump the kernel log buffer\n\
+  dp #  dump paca for cpu # (or all)\n\
   dr   dump stream of raw bytes\n\
   eprint exception information\n\
   fflush 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);
-- 
1.7.9.5

___

Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame

[tiejun.chen]

On 09/11/2012 01:51 PM, Benjamin Herrenschmidt wrote:

On Tue, 2012-09-11 at 10:20 +0800, Tiejun Chen wrote:

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.


Ok, so not quite there yet :-)

See below:


Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
  arch/powerpc/kernel/entry_32.S |   45 ++--
  arch/powerpc/kernel/entry_64.S |   32 
  2 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index ead5016..6cfe12f 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -831,19 +831,54 @@ 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, _TIF_EMULATE_STACK_STORE */
+   CURRENT_THREAD_INFO(r9, r1)
+   lwz r0,TI_FLAGS(r9)
+   andis.  r0,r0,_TIF_EMULATE_STACK_STORE@h
+   beq+1f


So you used r0 to load the TI_FLAGS and immediately clobbered it in
andis. forcing you to re-load them later down. Instead, put them in r8

lwz r8,TI_FLAGS(r9)
andis.  r0,r8,_TIF_*
beq+*


+   addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */


Then you put your entry in r8 


I'll update this for 32b and 64b sections.




+   lwz r3,GPR1(r1)
+   subir3,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 */
+   mr  r1,r3   /* Reroute the trampoline frame to r1 */
+   bl  memcpy  /* Copy from the original to the 
trampoline */


Which you just clobbered... oops :-)

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.

Tiejun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[v4][PATCH 1/4] powerpc/kprobe: introduce a new thread flag

[Tiejun Chen]

We need to add a new thread flag, TIF_EMULATE_STACK_STORE,
for emulating stack store operation while exiting exception.

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
 arch/powerpc/include/asm/thread_info.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/include/asm/thread_info.h 
b/arch/powerpc/include/asm/thread_info.h
index e942203..8ceea14 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -104,6 +104,8 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_NOTIFY_RESUME  13  /* callback before returning to user */
 #define TIF_UPROBE 14  /* breakpointed or single-stepping */
 #define TIF_SYSCALL_TRACEPOINT 15  /* syscall tracepoint instrumentation */
+#define TIF_EMULATE_STACK_STORE16  /* Is an instruction emulation
+   for stack store? */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
@@ -121,6 +123,7 @@ static inline struct thread_info *current_thread_info(void)
 #define _TIF_NOTIFY_RESUME (1TIF_NOTIFY_RESUME)
 #define _TIF_UPROBE(1TIF_UPROBE)
 #define _TIF_SYSCALL_TRACEPOINT(1TIF_SYSCALL_TRACEPOINT)
+#define _TIF_EMULATE_STACK_STORE   (1TIF_EMULATE_STACK_STORE)
 #define _TIF_SYSCALL_T_OR_A(_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
 _TIF_SECCOMP | _TIF_SYSCALL_TRACEPOINT)
 
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[v4][PATCH 2/4] powerpc/ppc32: make copy_and_flush() as global

[Tiejun Chen]

Somewhere we need this simple copy_and_flush().

Signed-off-by: Tiejun Chen tiejun.c...@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)
+   addir5,r5,-4
+   addir6,r6,-4
+4: li  r0,L1_CACHE_BYTES/4
+   mtctr   r0
+3: addir6,r6,4 /* copy a cache line */
+   lwzxr0,r6,r4
+   stwxr0,r6,r3
+   bdnz3b
+   dcbst   r6,r3   /* write it to memory */
+   sync
+   icbir6,r3   /* flush the icache line */
+   cmplw   0,r6,r5
+   blt 4b
+   sync/* additional sync needed on g4 */
+   isync
+   addir5,r5,4
+   addir6,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)
-   addir5,r5,-4
-   addir6,r6,-4
-4: li  r0,L1_CACHE_BYTES/4
-   mtctr   r0
-3: addir6,r6,4 /* copy a cache line */
-   lwzxr0,r6,r4
-   stwxr0,r6,r3
-   bdnz3b
-   dcbst   r6,r3   /* write it to memory */
-   sync
-   icbir6,r3   /* flush the icache line */
-   cmplw   0,r6,r5
-   blt 4b
-   sync/* additional sync needed on g4 */
-   isync
-   addir5,r5,4
-   addir6,r6,4
-   blr
-
 #ifdef CONFIG_SMP
.globl __secondary_start_mpc86xx
 __secondary_start_mpc86xx:
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[v4][PATCH 3/4] powerpc/kprobe: complete kprobe and migrate exception frame

[Tiejun Chen]

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.c...@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
+
+   addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
+
+   lwz r3,GPR1(r1)
+   subir3,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
+   addir5,r9,TI_FLAGS
+0: lwarx   r8,0,r5
+   andcr8,r8,r11
+#ifdef CONFIG_IBM405_ERR77
+   dcbt0,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
+
+   addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
+
+   lwz r3,GPR1(r1)
+   subir3,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
+   addir5,r9,TI_FLAGS
+   ldarx   r4,0,r5
+   andcr4,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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[v4][PATCH 4/4] powerpc/kprobe: don't emulate store when kprobe stwu r1

[Tiejun Chen]

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.c...@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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame

[Benjamin Herrenschmidt]

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.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Add an xmon command to dump one or all pacas

[Benjamin Herrenschmidt]

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 @ cff20a80:
  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   = 0xc144f990(0x10)
  kernelbase   = 0xc000(0x18)
  kernel_msr   = 0xb0001032(0x20)
  stab_real= 0x0   (0x28)
  stab_addr= 0x0   (0x30)
  emergency_sp = 0xc0003ffe4000(0x38)
  data_offset  = 0xa4  (0x40)
  hw_cpu_id= 0x9   (0x50)
  cpu_start= 0x1   (0x52)
  kexec_state  = 0x0   (0x53)
  __current= 0xc0007e568680(0x218)
  kstack   = 0xc0007e5a3e30(0x220)
  stab_rr  = 0x1a  (0x228)
  saved_r1 = 0xc0007e7cb450(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 mich...@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\
dldump 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);
 + 

Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame

[tiejun.chen]

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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v7 1/8] Talitos: Support for async_tx XOR offload

[Liu Qiang-B32616]

  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=linux-arm-kernelm=129407269402930w=2
  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?
 
 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).
 
 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 :
 
 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...)
 
 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:
 
 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...)
 
 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 should
be ok for hardware when in step 5 (but I will avoid map same address on 
different
device).

second, I have a workaround to make dma_map/unmap by order when using 2 
different
device to offload, I will submit next descriptor until current descriptor 
complete,
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) == DMA_ERROR)
+   panic(%s: DMA_ERROR waiting for tx\n, __func__);
}
EXPORT_SYMBOL_GPL(async_tx_submit);

Also use your example, 
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 channel 
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 know 
whether
it does work on other architecture.

Thanks.

 
 --
 Dan


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 0/8] Avoid cache trashing on clearing huge/gigantic page

[Kirill A. Shutemov]

Hi,

Any feedback?

-- 
 Kirill A. Shutemov


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v3][PATCH 2/3] ppc/kprobe: complete kprobe and migrate exception frame

[Benjamin Herrenschmidt]

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.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Add an xmon command to dump one or all pacas

[Stephen Rothwell]

Hi Michael,

On Wed, 12 Sep 2012 17:52:40 +1000 Michael Ellerman mich...@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 Rothwells...@canb.auug.org.au


pgpzwe5KPTrCY.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/p5040: fix dtb build warning of p5040ds.dtb

[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 b38...@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@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 = 0x1f00 0x0100;
};
-   adt7461@4c {
-   compatible = adi,adt7461;
-   reg = 0x4c;
-   };
};
 
board-control@3,0 {
-- 
1.6.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer

[Li Yang-R58472]

 -Original Message-
 From: Felipe Balbi [mailto:ba...@ti.com]
 Sent: Thursday, September 06, 2012 10:28 PM
 To: Enrico Scholz
 Cc: ba...@ti.com; Chen Peter-B29397; linux-...@vger.kernel.org; linuxppc-
 d...@lists.ozlabs.org; Li Yang-R58472; gre...@linuxfoundation.org
 Subject: Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime
 STATUS for IN xfer
 
 Hi,
 
 On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote:
  Felipe Balbi ba...@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 = udc-status_req;
| ...
| list_add_tail(req-queue, ep-queue); if
| (ep0_prime_status(udc, EP_DIR_OUT))
|   
|   struct fsl_req *req = 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.
 
 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 
problem is a serious one to be fixed right away.  So

Acked-by: Li Yang le...@freescale.com

We need to revisit the error handling issue later and find a proper way to 
address it.

Regards,
Leo

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23

[Kumar Gala]

On Sep 12, 2012, at 1:18 AM, Huang Changming-R66093 wrote:

 
 
 Best Regards
 Jerry Huang
 
 
 -Original Message-
 From: Chris Ball [mailto:c...@laptop.org]
 Sent: Wednesday, September 12, 2012 4:59 AM
 To: Kumar Gala
 Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list; linux-
 m...@vger.kernel.org; Anton Vorontsov
 Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
 
 Hi,
 
 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?
 
 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).
 
 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.
 
 
 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro

[Mihai Caraman]

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.cara...@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


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/5] ASoC: fsl: mpc5200 combine psc_dma platform data

[Mark Brown]

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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 5/5] ASoC: fsl: mpc5200 remove pcm030 and efika audio fabric

[Eric Millbrandt]

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 appears 
to exist out-of-tree, http://www.powerdeveloper.org/platforms/efika/devicetree.

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 to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/5] ASoC: fsl: mpc5200 multi-codec fixups

[Eric Millbrandt]

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 boardsdepends on 6xx +
 select
  FSL_SOC select PPC_CLOCKselect 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 have 
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 to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver

[Dan Horák]

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-develm=124345080216952w=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 ac...@cruxppc.org
Signed-off-by: Giuseppe Coviello c...@cruxppc.org
Tested-by: Dan Horák d...@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. pau...@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 = 4, .cardname = IBM GXT4000P },
[GXT6000P] = { .refclk_ps = 4, .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 pau...@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 
\xresxyres[-bpp][@refresh]\);
-- 
1.7.7.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: specify initrd location using 64-bit

[Geert Uytterhoeven]

On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy cy...@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 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver

[Dan Horák]

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-develm=124345080216952w=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 ac...@cruxppc.org
Signed-off-by: Giuseppe Coviello c...@cruxppc.org
Tested-by: Dan Horák d...@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. pau...@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 = 4, .cardname = IBM GXT4000P },
[GXT6000P] = { .refclk_ps = 4, .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 pau...@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 
\xresxyres[-bpp][@refresh]\);
-- 
1.7.7.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver

[Dan Horák]

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-develm=124345080216952w=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 ac...@cruxppc.org
Signed-off-by: Giuseppe Coviello c...@cruxppc.org
Tested-by: Dan Horák d...@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. pau...@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 = 4, .cardname = IBM GXT4000P },
[GXT6000P] = { .refclk_ps = 4, .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 pau...@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 
\xresxyres[-bpp][@refresh]\);
-- 
1.7.7.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] of: specify initrd location using 64-bit

[Cyril Chemparathy]

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;

RE: [alsa-devel] [PATCH 2/5] ASoC: fsl: mpc5200 combine psc_dma platform data

[Eric Millbrandt]

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_soc_ops for an ASoC machine driver would only work for very few boards.  
I'll 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 to 
whom it is addressed and may contain information that is privileged. If the 
reader of this message is not the intended recipient, you are hereby notified 
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory

[Vasilis Liaskovitis]

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 0x4000-0x5fff]
 [  325.018060]  [mem 0x4000-0x5fff] page 2M
 [  325.019168] [ea000100-ea00011f] potential offnode 
 page_structs
 [  325.024172] [ea000120-ea00013f] potential offnode 
 page_structs
 [  325.028596]  [ea000140-ea00017f] PMD - 
 [88003500-8800353f] on node 1
 [  325.031775] [ea000160-ea00017f] 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] pseries: double NR_CPUS in defconfig

[Nishanth Aravamudan]

Anticipating growth in coming years, we should ensure we are getting a
good lead on testing.

Signed-off-by: Nishanth Aravamudan n...@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

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup

[Ashley Lai]

This patch removed the tasklet and moved the wait queue into the
private structure.  It also cleaned up the response CRQ path.

Signed-off-by: Ashley Lai ad...@us.ibm.com
---
James,

This patch is based on your next branch.
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git

Thanks,
Ashley Lai
---
 drivers/char/tpm/tpm_ibmvtpm.c | 81 +++---
 drivers/char/tpm/tpm_ibmvtpm.h |  5 ++-
 2 files changed, 30 insertions(+), 56 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index efc4ab3..88a95ea 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -38,8 +38,6 @@ static struct vio_device_id tpm_ibmvtpm_device_table[] 
__devinitdata = {
 };
 MODULE_DEVICE_TABLE(vio, tpm_ibmvtpm_device_table);
 
-DECLARE_WAIT_QUEUE_HEAD(wq);
-
 /**
  * ibmvtpm_send_crq - Send a CRQ request
  * @vdev:  vio device struct
@@ -83,6 +81,7 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
 {
struct ibmvtpm_dev *ibmvtpm;
u16 len;
+   int sig;
 
ibmvtpm = (struct ibmvtpm_dev *)chip-vendor.data;
 
@@ -91,22 +90,23 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
return 0;
}
 
-   wait_event_interruptible(wq, ibmvtpm-crq_res.len != 0);
+   sig = wait_event_interruptible(ibmvtpm-wq, ibmvtpm-res_len != 0);
+   if (sig)
+   return -EINTR;
+
+   len = ibmvtpm-res_len;
 
-   if (count  ibmvtpm-crq_res.len) {
+   if (count  len) {
dev_err(ibmvtpm-dev,
Invalid size in recv: count=%ld, crq_size=%d\n,
-   count, ibmvtpm-crq_res.len);
+   count, len);
return -EIO;
}
 
spin_lock(ibmvtpm-rtce_lock);
-   memcpy((void *)buf, (void *)ibmvtpm-rtce_buf, ibmvtpm-crq_res.len);
-   memset(ibmvtpm-rtce_buf, 0, ibmvtpm-crq_res.len);
-   ibmvtpm-crq_res.valid = 0;
-   ibmvtpm-crq_res.msg = 0;
-   len = ibmvtpm-crq_res.len;
-   ibmvtpm-crq_res.len = 0;
+   memcpy((void *)buf, (void *)ibmvtpm-rtce_buf, len);
+   memset(ibmvtpm-rtce_buf, 0, len);
+   ibmvtpm-res_len = 0;
spin_unlock(ibmvtpm-rtce_lock);
return len;
 }
@@ -273,7 +273,6 @@ static int __devexit tpm_ibmvtpm_remove(struct vio_dev 
*vdev)
int rc = 0;
 
free_irq(vdev-irq, ibmvtpm);
-   tasklet_kill(ibmvtpm-tasklet);
 
do {
if (rc)
@@ -372,7 +371,6 @@ static int ibmvtpm_reset_crq(struct ibmvtpm_dev *ibmvtpm)
 static int tpm_ibmvtpm_resume(struct device *dev)
 {
struct ibmvtpm_dev *ibmvtpm = ibmvtpm_get_data(dev);
-   unsigned long flags;
int rc = 0;
 
do {
@@ -387,10 +385,11 @@ static int tpm_ibmvtpm_resume(struct device *dev)
return rc;
}
 
-   spin_lock_irqsave(ibmvtpm-lock, flags);
-   vio_disable_interrupts(ibmvtpm-vdev);
-   tasklet_schedule(ibmvtpm-tasklet);
-   spin_unlock_irqrestore(ibmvtpm-lock, flags);
+   rc = vio_enable_interrupts(ibmvtpm-vdev);
+   if (rc) {
+   dev_err(dev, Error vio_enable_interrupts rc=%d\n, rc);
+   return rc;
+   }
 
rc = ibmvtpm_crq_send_init(ibmvtpm);
if (rc)
@@ -467,7 +466,7 @@ static struct ibmvtpm_crq *ibmvtpm_crq_get_next(struct 
ibmvtpm_dev *ibmvtpm)
if (crq-valid  VTPM_MSG_RES) {
if (++crq_q-index == crq_q-num_entry)
crq_q-index = 0;
-   rmb();
+   smp_rmb();
} else
crq = NULL;
return crq;
@@ -535,11 +534,9 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
ibmvtpm-vtpm_version = crq-data;
return;
case VTPM_TPM_COMMAND_RES:
-   ibmvtpm-crq_res.valid = crq-valid;
-   ibmvtpm-crq_res.msg = crq-msg;
-   ibmvtpm-crq_res.len = crq-len;
-   ibmvtpm-crq_res.data = crq-data;
-   wake_up_interruptible(wq);
+   /* len of the data in rtce buffer */
+   ibmvtpm-res_len = crq-len;
+   wake_up_interruptible(ibmvtpm-wq);
return;
default:
return;
@@ -559,38 +556,19 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
 static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
 {
struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
-   unsigned long flags;
-
-   spin_lock_irqsave(ibmvtpm-lock, flags);
-   vio_disable_interrupts(ibmvtpm-vdev);
-   tasklet_schedule(ibmvtpm-tasklet);
-   spin_unlock_irqrestore(ibmvtpm-lock, flags);
-
-   return IRQ_HANDLED;
-}
-
-/**
- * ibmvtpm_tasklet - Interrupt handler tasklet
- * @data:  ibm 

Re: [PATCH] of: specify initrd location using 64-bit

[Cyril Chemparathy]

On 9/12/2012 12:16 PM, Geert Uytterhoeven wrote:

On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy cy...@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?



The rest of the memory specific bits of the device-tree code use u64 for 
addresses, and I kept it the same for consistency.



Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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



--
Thanks
- Cyril
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro

[Alexander Graf]

On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:

 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.

Not sure I understand what you're trying to achieve here. Please elaborate ;)

Alex

 Use a rare label number
 to avoid conflicts with the calling contexts.
 
 Signed-off-by: Mihai Caraman mihai.cara...@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
mtocrf0x80, r11/* check MSR[GS] without clobbering reg */
 -bf3, kvmppc_resume_\intno\()_\srr1
 +bf3, 1975f
bkvmppc_handler_\intno\()_\srr1
 -kvmppc_resume_\intno\()_\srr1:
 +1975:
 END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
 #endif
 .endm
 -- 
 1.7.4.1
 
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm-ppc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/p5040: fix dtb build warning of p5040ds.dtb

[Kumar Gala]

On Sep 12, 2012, at 5:36 AM, Shaohui Xie wrote:

 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 b38...@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@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(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V10] powerpc/fsl-pci: Unify pci/pcie initialization code

[Kumar Gala]

On Aug 28, 2012, at 2:44 AM, Jia Hongtao wrote:

 We unified the Freescale pci/pcie initialization by changing the fsl_pci
 to a platform driver. In previous PCI code architecture the initialization
 routine is called at board_setup_arch stage. Now the initialization is done
 in probe function which is architectural better. Also It's convenient for
 adding PM support for PCI controller in later patch.
 
 Now we registered pci controllers as platform devices. So we combine two
 initialization code as one platform driver.
 
 Signed-off-by: Jia Hongtao b38...@freescale.com
 Signed-off-by: Li Yang le...@freescale.com
 Signed-off-by: Chunhe Lan chunhe@freescale.com
 ---
 Changes for V10:
 * Just update comments for mpc85xx_cds_pci_assign_primary
 
 arch/powerpc/platforms/85xx/common.c   |   10 +++
 arch/powerpc/platforms/85xx/corenet_ds.c   |   34 ++
 arch/powerpc/platforms/85xx/ge_imp3a.c |   62 ++---
 arch/powerpc/platforms/85xx/mpc8536_ds.c   |   36 +-
 arch/powerpc/platforms/85xx/mpc85xx_ads.c  |   11 +--
 arch/powerpc/platforms/85xx/mpc85xx_cds.c  |   44 +
 arch/powerpc/platforms/85xx/mpc85xx_ds.c   |   14 ++--
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |   40 ++-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c  |   30 +++-
 arch/powerpc/platforms/85xx/p1010rdb.c |   14 +---
 arch/powerpc/platforms/85xx/p1022_ds.c |   36 +-
 arch/powerpc/platforms/85xx/p1022_rdk.c|   36 +-
 arch/powerpc/platforms/85xx/p1023_rds.c|9 +--
 arch/powerpc/platforms/85xx/p2041_rdb.c|2 +-
 arch/powerpc/platforms/85xx/p3041_ds.c |2 +-
 arch/powerpc/platforms/85xx/p4080_ds.c |2 +-
 arch/powerpc/platforms/85xx/p5020_ds.c |2 +-
 arch/powerpc/platforms/85xx/p5040_ds.c |2 +-
 arch/powerpc/platforms/85xx/qemu_e500.c|4 +-
 arch/powerpc/platforms/85xx/sbc8548.c  |   21 +-
 arch/powerpc/platforms/85xx/socrates.c |   11 +---
 arch/powerpc/platforms/85xx/stx_gp3.c  |   13 +---
 arch/powerpc/platforms/85xx/tqm85xx.c  |   21 +-
 arch/powerpc/platforms/85xx/xes_mpc85xx.c  |   56 ++-
 arch/powerpc/platforms/86xx/gef_ppc9a.c|   12 +--
 arch/powerpc/platforms/86xx/gef_sbc310.c   |   13 +---
 arch/powerpc/platforms/86xx/gef_sbc610.c   |   12 +--
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c |   21 ++
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |   42 ++--
 arch/powerpc/platforms/86xx/sbc8641d.c |   14 +---
 arch/powerpc/sysdev/fsl_pci.c  |  102 +---
 arch/powerpc/sysdev/fsl_pci.h  |   15 +++-
 drivers/edac/mpc85xx_edac.c|   43 +++-
 33 files changed, 249 insertions(+), 537 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] powerpc/pci: Add IP revision register define for Freescale PCIe controller

[Kumar Gala]

On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:

 Signed-off-by: Roy Zang tie-fei.z...@freescale.com
 ---
 arch/powerpc/sysdev/fsl_pci.h |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] powerpc/pci: Use PCIe IP block revision register instead of compatible

[Kumar Gala]

On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:

 Freescale PCIe IP block revision bigger than rev2.2 will also need
 redefine the sequence of inbound windows. So change to use IP block
 revision instead of compatible for the judgment.
 
 Signed-off-by: Roy Zang tie-fei.z...@freescale.com
 ---
 
 arch/powerpc/sysdev/fsl_pci.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: specify initrd location using 64-bit

[Rob Herring]

On 09/12/2012 11:05 AM, Cyril Chemparathy 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.

S-o-B?

 ---
  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/size need to change too. Not sure about similar things
on other arches.

Does u-boot need similar fixes?

  {
   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
 

Re: [PATCH] of: specify initrd location using 64-bit

[Sebastian Andrzej Siewior]

On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:

-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?



The rest of the memory specific bits of the device-tree code use u64 for
addresses, and I kept it the same for consistency.


Geert is right here. If it is a physical address, it should be
phys_addr_t.

Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: specify initrd location using 64-bit

[Rob Herring]

On 09/12/2012 03:31 PM, Nicolas Pitre wrote:
 On Wed, 12 Sep 2012, Rob Herring wrote:
 
 On 09/12/2012 11:05 AM, Cyril Chemparathy 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.

 S-o-B?

 ---
  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/size need to change too. Not sure about similar things
 on other arches.
 
 size ?

phys_initrd_size. Arguably, we'll never have a 4GB initrd with a PAE
system or perhaps run into other issues first (like space to decompress
it), but technically the DTS could specify one.

Rob

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro

[Scott Wood]

On 09/12/2012 01:56 PM, Alexander Graf wrote:
 
 
 On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:
 
 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.
 
 Not sure I understand what you're trying to achieve here. Please elaborate ;)

On 64-bit book3e we compile multiple versions of the TLB miss handlers,
and choose from them at runtime.  Without this patch, we get duplicate
label errors if more than one variant of the same exception uses DO_KVM.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro

[Alexander Graf]

On 12.09.2012, at 23:38, Scott Wood scottw...@freescale.com wrote:

 On 09/12/2012 01:56 PM, Alexander Graf wrote:
 
 
 On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:
 
 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.
 
 Not sure I understand what you're trying to achieve here. Please elaborate ;)
 
 On 64-bit book3e we compile multiple versions of the TLB miss handlers,
 and choose from them at runtime.  

Why?

 Without this patch, we get duplicate
 label errors if more than one variant of the same exception uses DO_KVM.

Makes sense. The proposed solution also looks good. Just quickly walk me 
through the reasoning for the runtime check again please.


Alex

 
 -Scott
 
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm-ppc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro

[Scott Wood]

On 09/12/2012 04:45 PM, Alexander Graf wrote:
 
 
 On 12.09.2012, at 23:38, Scott Wood scottw...@freescale.com wrote:
 
 On 09/12/2012 01:56 PM, Alexander Graf wrote:


 On 12.09.2012, at 15:18, Mihai Caraman mihai.cara...@freescale.com wrote:

 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.

 Not sure I understand what you're trying to achieve here. Please elaborate 
 ;)

 On 64-bit book3e we compile multiple versions of the TLB miss handlers,
 and choose from them at runtime.  
 
 Why?

Because one size does not fit all, and we try to not force a separate
kernel build based on what sort of TLB miss handler a piece of hardware
wants.  Some of the differences are too large to be sanely handled by
feature fixups.

 Without this patch, we get duplicate
 label errors if more than one variant of the same exception uses DO_KVM.
 
 Makes sense. The proposed solution also looks good. Just quickly walk me 
 through the reasoning for the runtime check again please.

To start with, you have a TLB miss handler for when partial hardware
tablewalk is used (only the final page table level is looked up in
hardware, so we still need a TLB miss handler to load indirect entries),
and one where that feature is not available.  Then you have the bolted
variant used by e5500, which is faster than the generic version because
it doesn't have to deal with recursive faults.  So far the bolted
version is the only one with DO_KVM.

I posted a patch to add another variant, for e6500-style hardware
tablewalk, which shares the bolted prolog/epilog (besides prolog/epilog
performance, e6500 is incompatible with the IBM tablewalk code for
various reasons).  That caused us to have two DO_KVMs for the same
exception type.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: specify initrd location using 64-bit

[Rob Herring]

On 09/12/2012 02:58 PM, Sebastian Andrzej Siewior wrote:
 On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
 -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?


 The rest of the memory specific bits of the device-tree code use u64 for
 addresses, and I kept it the same for consistency.
 
 Geert is right here. If it is a physical address, it should be
 phys_addr_t.

While generally true, for the DT specific code I think it should be a
fixed u64. The size of the address is defined by the FDT, not the
kernel. It is very likely we could have a FDT that specifies addresses
in 64-bit values, but then we boot a kernel is compiled for !LPAE.
phys_addr_t is currently sized based on LPAE setting.

Also, this is how the memory and reserved nodes are handled currently,
so we should be consistent.

Rob

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: specify initrd location using 64-bit

[Nicolas Pitre]

On Wed, 12 Sep 2012, Rob Herring wrote:

 On 09/12/2012 11:05 AM, Cyril Chemparathy 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.
 
 S-o-B?
 
  ---
   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/size need to change too. Not sure about similar things
 on other arches.

size ?


Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver

[Nik Mak]

Right, as far as i'm concerced that patch always worked without issues.

--nico




On Wed, 12 Sep 2012 18:06:44 +0200
Dan Horák d...@danny.cz wrote:

 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-develm=124345080216952w=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 ac...@cruxppc.org
 Signed-off-by: Giuseppe Coviello c...@cruxppc.org
 Tested-by: Dan Horák d...@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. pau...@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 = 4, .cardname = IBM GXT4000P },
   [GXT6000P] = { .refclk_ps = 4, .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 pau...@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 
 \xresxyres[-bpp][@refresh]\);
 -- 
 1.7.7.6
 


-- 
Sent from Genesi EfikaMX Smartbook - Freescale i.MX51 based
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: fix typo in PTRS_PER_PUD

[Scott Wood]

PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE.  We
got away with it because PUD and PMD had the same index size, but this is
no longer true with Aneesh's patchset to support a 46-bit user effective
address space.

Signed-off-by: Scott Wood scottw...@freescale.com
---
 arch/powerpc/include/asm/pgtable-ppc64-4k.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/pgtable-ppc64-4k.h 
b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
index b3eccf2..12798c9 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64-4k.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
@@ -19,7 +19,7 @@
 
 #define PTRS_PER_PTE   (1  PTE_INDEX_SIZE)
 #define PTRS_PER_PMD   (1  PMD_INDEX_SIZE)
-#define PTRS_PER_PUD   (1  PMD_INDEX_SIZE)
+#define PTRS_PER_PUD   (1  PUD_INDEX_SIZE)
 #define PTRS_PER_PGD   (1  PGD_INDEX_SIZE)
 
 /* PMD_SHIFT determines what a second-level page table entry can map */
-- 
1.7.9.5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: fix typo in PTRS_PER_PUD

[Benjamin Herrenschmidt]

On Wed, 2012-09-12 at 18:00 -0500, Scott Wood wrote:
 PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE.  We
 got away with it because PUD and PMD had the same index size, but this is
 no longer true with Aneesh's patchset to support a 46-bit user effective
 address space.

Ah, my typo :-) Cool, I'll make sure to apply that before Aneesh
patches.

Thanks,
Ben.

 Signed-off-by: Scott Wood scottw...@freescale.com
 ---
  arch/powerpc/include/asm/pgtable-ppc64-4k.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/powerpc/include/asm/pgtable-ppc64-4k.h 
 b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
 index b3eccf2..12798c9 100644
 --- a/arch/powerpc/include/asm/pgtable-ppc64-4k.h
 +++ b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
 @@ -19,7 +19,7 @@
  
  #define PTRS_PER_PTE (1  PTE_INDEX_SIZE)
  #define PTRS_PER_PMD (1  PMD_INDEX_SIZE)
 -#define PTRS_PER_PUD (1  PMD_INDEX_SIZE)
 +#define PTRS_PER_PUD (1  PUD_INDEX_SIZE)
  #define PTRS_PER_PGD (1  PGD_INDEX_SIZE)
  
  /* PMD_SHIFT determines what a second-level page table entry can map */


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] of: specify initrd location using 64-bit

[Cyril Chemparathy]

On 9/12/2012 4:23 PM, Rob Herring wrote:

On 09/12/2012 11:05 AM, Cyril Chemparathy 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.


S-o-B?



Sorry about that, will include in v2.

[...]

--- 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/size need to change too. Not sure about similar things
on other arches.



I've fixed phys_initrd_start (not size) in another patch, please see [1].


Does u-boot need similar fixes?



We aren't there yet :-)  We are currently running this platform without 
u-boot.



[1] http://permalink.gmane.org/gmane.linux.kernel/1356713

--
Thanks
- Cyril
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver

[Benjamin Herrenschmidt]

On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
 I'm reviving an old patch from 2009 that adds support for GXT4000P and 
 GXT6500P
 adapter to the gxt4500 driver.

Who is the original author ?

Cheers,
Ben.

 See threads at http://marc.info/?l=linux-fbdev-develm=124345080216952w=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 ac...@cruxppc.org
 Signed-off-by: Giuseppe Coviello c...@cruxppc.org
 Tested-by: Dan Horák d...@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. pau...@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 = 4, .cardname = IBM GXT4000P },
   [GXT6000P] = { .refclk_ps = 4, .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 pau...@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 
 \xresxyres[-bpp][@refresh]\);


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23

[Huang Changming-R66093]

 
  -Original Message-
  From: Chris Ball [mailto:c...@laptop.org]
  Sent: Wednesday, September 12, 2012 4:59 AM
  To: Kumar Gala
  Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
  linux- m...@vger.kernel.org; Anton Vorontsov
  Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the
  CMD23
 
  Hi,
 
  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?
 
  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).
 
  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.
 
 
  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.
 
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) support 
it.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 5/5] ASoC: fsl: mpc5200 remove pcm030 and efika audio fabric

[Mark Brown]

On Wed, Sep 12, 2012 at 10:05:33AM -0400, Eric Millbrandt wrote:

Please fix your mailer to word wrap within paragraphs.

 On 2012-09-11 Mark Brown wrote:

  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
 appears to exist out-of-tree,

Hrm, well - that's not terribly clever.  It'll mean a regression on
existing systems and since they're clearly taking advantage of the
ability to distribute the device tree separately...  we'd really want
some sort of backwards compatibility to avoid breaking upgrades.  Not
sure what the normal way of doing that is.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver

[Geert Uytterhoeven]

On Thu, Sep 13, 2012 at 2:01 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
 I'm reviving an old patch from 2009 that adds support for GXT4000P and 
 GXT6500P
 adapter to the gxt4500 driver.

 Who is the original author ?

Signed-off-by: Nico Macrionitis ac...@cruxppc.org
Signed-off-by: Giuseppe Coviello c...@cruxppc.org

It even has your ack (albeit not in canonical form ;-), cfr.

 See threads at http://marc.info/?l=linux-fbdev-develm=124345080216952w=2
 and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
 for more details.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev