Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems

2011-02-02 Thread David Gibson 
On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
> On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> > On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > > Since other OS's may be running on the other cores don't use tlbivax
> > 
> > [snip]
> > > +#ifdef CONFIG_44x
> > > +void __init early_init_mmu_44x(void)
> > > +{
> > > + unsigned long root = of_get_flat_dt_root();
> > > + if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> > > + amp = 1;
> > > +}
> > > +#endif /* CONFIG_44x */
> > 
> > A test against a hardcoded compatible string seems a nasty way to do
> > this.  Maybe we should define a new boolean property for the root
> > node.
> 
> I'm not crazy about this string, but I needed something in the device
> tree to key off of.  Freescale has something similar (i.e.
> MPC8572DS-CAMP), so I chose to follow their example.  I'd be happy to
> replace it with a boolean property.  Any objection to just using
> "amp"?

Bit too short, I think.  I'd suggest either spelling out
'asymmetric-multiprocessor' or 'cooperative-partition' (a more
accurate term, IMO).

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 6/6] ftrace syscalls: Early terminate search for sys_ni_syscall

2011-02-02 Thread Ian Munsie 
From: Ian Munsie 

Many system calls are unimplemented and mapped to sys_ni_syscall, but at
boot ftrace would still search through every syscall metadata entry for
a match which wouldn't be there.

This patch adds causes the search to terminate early if the system call
is not mapped.

Signed-off-by: Ian Munsie 
---
 kernel/trace/trace_syscalls.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 7b76a65..f498154 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -84,6 +84,9 @@ static struct syscall_metadata *find_syscall_meta(unsigned 
long syscall)
stop = (struct syscall_metadata *)__stop_syscalls_metadata;
kallsyms_lookup(syscall, NULL, NULL, NULL, str);
 
+   if (arch_syscall_match_sym_name(str, "sys_ni_syscall"))
+   return NULL;
+
for ( ; start < stop; start++) {
if (start->name && arch_syscall_match_sym_name(str, 
start->name))
return start;
-- 
1.7.2.3

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

[PATCH 5/6] ftrace, powerpc: Implement raw syscall tracepoints on PowerPC

2011-02-02 Thread Ian Munsie 
From: Ian Munsie 

This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.

To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi. instruction's UI field. The instructions
in question are in /arch/powerpc/kernel/entry_{32,64}.S to and the
_TIF_SYSCALL_T_OR_A with the thread flags to see if system call tracing
is enabled.

In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.

Signed-off-by: Ian Munsie 
---
 arch/powerpc/Kconfig   |1 +
 arch/powerpc/include/asm/ftrace.h  |   14 ++
 arch/powerpc/include/asm/syscall.h |5 +
 arch/powerpc/include/asm/thread_info.h |7 +--
 arch/powerpc/kernel/Makefile   |1 +
 arch/powerpc/kernel/ftrace.c   |8 
 arch/powerpc/kernel/ptrace.c   |   10 ++
 7 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 7d69e9b..a0e8e02 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -134,6 +134,7 @@ config PPC
select HAVE_GENERIC_HARDIRQS
select HAVE_SPARSE_IRQ
select IRQ_PER_CPU
+   select HAVE_SYSCALL_TRACEPOINTS
 
 config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/ftrace.h 
b/arch/powerpc/include/asm/ftrace.h
index dde1296..169d039 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -60,4 +60,18 @@ struct dyn_arch_ftrace {
 
 #endif
 
+#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64) && 
!defined(__ASSEMBLY__)
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym, const char 
*name)
+{
+   /*
+* Compare the symbol name with the system call name. Skip the .sys or 
.SyS
+* prefix from the symbol name and the sys prefix from the system call 
name and
+* just match the rest. This is only needed on ppc64 since symbol names 
on
+* 32bit do not start with a period so the generic function will work.
+*/
+   return !strcmp(sym + 4, name + 3);
+}
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_PPC64 && !__ASSEMBLY__ */
+
 #endif /* _ASM_POWERPC_FTRACE */
diff --git a/arch/powerpc/include/asm/syscall.h 
b/arch/powerpc/include/asm/syscall.h
index 23913e9..b54b2ad 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -15,6 +15,11 @@
 
 #include 
 
+/* ftrace syscalls requires exporting the sys_call_table */
+#ifdef CONFIG_FTRACE_SYSCALLS
+extern const unsigned long *sys_call_table;
+#endif /* CONFIG_FTRACE_SYSCALLS */
+
 static inline long syscall_get_nr(struct task_struct *task,
  struct pt_regs *regs)
 {
diff --git a/arch/powerpc/include/asm/thread_info.h 
b/arch/powerpc/include/asm/thread_info.h
index 65eb859..4403f09 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_NOERROR12  /* Force successful syscall return */
 #define TIF_NOTIFY_RESUME  13  /* callback before returning to user */
 #define TIF_FREEZE 14  /* Freezing for suspend */
-#define TIF_RUNLATCH   15  /* Is the runlatch enabled? */
+#define TIF_SYSCALL_TRACEPOINT 15  /* syscall tracepoint instrumentation */
+#define TIF_RUNLATCH   16  /* Is the runlatch enabled? */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE (1<
 #include 
 #include 
+#include 
 
 
 #ifdef CONFIG_DYNAMIC_FTRACE
@@ -600,3 +601,10 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr)
}
 }
 #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64)
+unsigned long __init arch_syscall_addr(int nr)
+{
+   return sys_call_table[nr*2];
+}
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9065369..b6ff0cb 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_PPC32
 #include 
 #endif
@@ -40,6 +41,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 /*
  * The parameter save area on the stack is used to store arguments being passed
  * to callee function and is located at fixed offset from stack pointer.
@@ -1691,6 +1695,9 @@ long do_syscall_trace_enter(struct pt_regs *regs)
 */
ret = -1L;
 
+   if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+   trace_sys_e

[PATCH 4/6] ftrace syscalls: Allow arch specific syscall symbol matching

2011-02-02 Thread Ian Munsie 
From: Ian Munsie 

Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.

This patch moves the match logic out into a separate function which an
arch can override by defining ARCH_HAS_SYSCALL_MATCH_SYM_NAME in
asm/ftrace.h and implementing arch_syscall_match_sym_name.

Signed-off-by: Ian Munsie 
---
 Documentation/trace/ftrace-design.txt |4 
 kernel/trace/trace_syscalls.c |   21 ++---
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/Documentation/trace/ftrace-design.txt 
b/Documentation/trace/ftrace-design.txt
index 6fca17b..79fcafc 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -250,6 +250,10 @@ You need very few things to get the syscalls tracing in an 
arch.
 - If the system call table on this arch is more complicated than a simple array
   of addresses of the system calls, implement an arch_syscall_addr to return
   the address of a given system call.
+- If the symbol names of the system calls do not match the function names on
+  this arch, define ARCH_HAS_SYSCALL_MATCH_SYM_NAME in asm/ftrace.h and
+  implement arch_syscall_match_sym_name with the appropriate logic to return
+  true if the function name corresponds with the symbol name.
 - Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
 
 
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 33360b9..7b76a65 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -60,6 +60,19 @@ extern unsigned long __stop_syscalls_metadata[];
 
 static struct syscall_metadata **syscalls_metadata;
 
+#ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+static inline bool arch_syscall_match_sym_name(const char *sym, const char 
*name)
+{
+   /*
+* Only compare after the "sys" prefix. Archs that use
+* syscall wrappers may have syscalls symbols aliases prefixed
+* with "SyS" instead of "sys", leading to an unwanted
+* mismatch.
+*/
+   return !strcmp(sym + 3, name + 3);
+}
+#endif
+
 static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
 {
struct syscall_metadata *start;
@@ -72,13 +85,7 @@ static struct syscall_metadata *find_syscall_meta(unsigned 
long syscall)
kallsyms_lookup(syscall, NULL, NULL, NULL, str);
 
for ( ; start < stop; start++) {
-   /*
-* Only compare after the "sys" prefix. Archs that use
-* syscall wrappers may have syscalls symbols aliases prefixed
-* with "SyS" instead of "sys", leading to an unwanted
-* mismatch.
-*/
-   if (start->name && !strcmp(start->name + 3, str + 3))
+   if (start->name && arch_syscall_match_sym_name(str, 
start->name))
return start;
}
return NULL;
-- 
1.7.2.3

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

[PATCH 3/6] ftrace syscalls: Make arch_syscall_addr weak

2011-02-02 Thread Ian Munsie 
From: Ian Munsie 

Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.

This patch makes the generic arch_syscall_addr weak to allow
architectures with non-trivial system call tables to override it.

Signed-off-by: Ian Munsie 
---
 Documentation/trace/ftrace-design.txt |3 +++
 kernel/trace/trace_syscalls.c |2 +-
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/Documentation/trace/ftrace-design.txt 
b/Documentation/trace/ftrace-design.txt
index dc52bd4..6fca17b 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -247,6 +247,9 @@ You need very few things to get the syscalls tracing in an 
arch.
 - Support the TIF_SYSCALL_TRACEPOINT thread flags.
 - Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace
   in the ptrace syscalls tracing path.
+- If the system call table on this arch is more complicated than a simple array
+  of addresses of the system calls, implement an arch_syscall_addr to return
+  the address of a given system call.
 - Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
 
 
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 1a6e8dd..33360b9 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -445,7 +445,7 @@ int init_syscall_trace(struct ftrace_event_call *call)
return id;
 }
 
-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init __weak arch_syscall_addr(int nr)
 {
return (unsigned long)sys_call_table[nr];
 }
-- 
1.7.2.3

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

[PATCH 2/6] ftrace syscalls: Convert redundant syscall_nr checks into WARN_ON

2011-02-02 Thread Ian Munsie 
From: Ian Munsie 

With the ftrace events now checking if the syscall_nr is valid upon
initialisation it should no longer be possible to register or unregister
a syscall event without a valid syscall_nr since they should not be
created. This adds a WARN_ON_ONCE in the register and unregister
functions to locate potential regressions in the future.

Signed-off-by: Ian Munsie 
---
 kernel/trace/trace_syscalls.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index a66bc13..1a6e8dd 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -358,7 +358,7 @@ int reg_event_syscall_enter(struct ftrace_event_call *call)
int num;
 
num = ((struct syscall_metadata *)call->data)->syscall_nr;
-   if (num < 0 || num >= NR_syscalls)
+   if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return -ENOSYS;
mutex_lock(&syscall_trace_lock);
if (!sys_refcount_enter)
@@ -376,7 +376,7 @@ void unreg_event_syscall_enter(struct ftrace_event_call 
*call)
int num;
 
num = ((struct syscall_metadata *)call->data)->syscall_nr;
-   if (num < 0 || num >= NR_syscalls)
+   if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return;
mutex_lock(&syscall_trace_lock);
sys_refcount_enter--;
@@ -392,7 +392,7 @@ int reg_event_syscall_exit(struct ftrace_event_call *call)
int num;
 
num = ((struct syscall_metadata *)call->data)->syscall_nr;
-   if (num < 0 || num >= NR_syscalls)
+   if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return -ENOSYS;
mutex_lock(&syscall_trace_lock);
if (!sys_refcount_exit)
@@ -410,7 +410,7 @@ void unreg_event_syscall_exit(struct ftrace_event_call 
*call)
int num;
 
num = ((struct syscall_metadata *)call->data)->syscall_nr;
-   if (num < 0 || num >= NR_syscalls)
+   if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls))
return;
mutex_lock(&syscall_trace_lock);
sys_refcount_exit--;
-- 
1.7.2.3

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

[PATCH 1/6] ftrace syscalls: don't add events for unmapped syscalls

2011-02-02 Thread Ian Munsie 
From: Ian Munsie 

FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.

This could happen, for example, on architectures who's symbol names are
unusual and will not match the system call name. It could also happen
with system calls which were mapped to sys_ni_syscall.

This patch changes the default system call number in the metadata to -1.
If the system call name from the metadata is not successfully mapped to
a system call number during boot, than the event initialisation routine
will now return an error, preventing the event from being created.

Signed-off-by: Ian Munsie 
---
 include/linux/syscalls.h  |2 ++
 kernel/trace/trace_syscalls.c |8 
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 18cd068..2e5a68d 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -160,6 +160,7 @@ extern struct trace_event_functions 
exit_syscall_print_funcs;
  __attribute__((section("__syscalls_metadata")))   \
  __syscall_meta_##sname = {\
.name   = "sys"#sname,  \
+   .syscall_nr = -1,   /* Filled in at boot */ \
.nb_args= nb,   \
.types  = types_##sname,\
.args   = args_##sname, \
@@ -176,6 +177,7 @@ extern struct trace_event_functions 
exit_syscall_print_funcs;
  __attribute__((section("__syscalls_metadata")))   \
  __syscall_meta__##sname = {   \
.name   = "sys_"#sname, \
+   .syscall_nr = -1,   /* Filled in at boot */ \
.nb_args= 0,\
.enter_event= &event_enter__##sname,\
.exit_event = &event_exit__##sname, \
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index b706529..a66bc13 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -423,6 +423,14 @@ void unreg_event_syscall_exit(struct ftrace_event_call 
*call)
 int init_syscall_trace(struct ftrace_event_call *call)
 {
int id;
+   int num;
+
+   num = ((struct syscall_metadata *)call->data)->syscall_nr;
+   if (num < 0 || num >= NR_syscalls) {
+   pr_debug("syscall %s metadata not mapped, disabling ftrace 
event\n",
+   ((struct syscall_metadata *)call->data)->name);
+   return -ENOSYS;
+   }
 
if (set_syscall_print_fmt(call) < 0)
return -ENOMEM;
-- 
1.7.2.3

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

PowerPC, ftrace: Add PPC raw syscall tracepoints & ftrace fixes (mimimal subset only) v4

2011-02-02 Thread Ian Munsie 
Hi All,

This is a partial version of my 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC implementation'. This is updated from
yesterday with arch_syscall_addr changed to a static inline function from
Steven's suggestion.

This subset implements the raw syscall tracepoints on PowerPC which has been
requested recently.  It also fixes ftrace syscalls to ensure that events will
only be created for syscalls that successfully map their metadata to a syscall
number, so that non-working phantom events are not created. Patches #2 and #6
in this series are not strictly necessary for this, they just optimise ftrace
syscalls a bit.

What's missing from this series that was in the full 40 patch v2 series is the
conversion of all the syscalls implemented under /arch/powerpc, Jason Baron's
compat syscall support and the conversion of the remaining native and compat
syscalls to this infrastructure.

Cheers,
-Ian


Changelog:
Subset v4:
- Changed arch_syscall_addr to a static inline function from Steven's
  suggestion. Archs implementing their own function must now define
  ARCH_HAS_SYSCALL_MATCH_SYM_NAME in their asm/ftrace.h

Subset v3:
- Rather than removing the redundant syscall_nr checks completely, I have
  turned them into WARN_ON_ONCE to catch possible future regressions, from
  Steven Rostedt's suggestion.
- From Mike Frysinger's suggestion, arch_syscall_addr is now a macro rather
  than a weak function to minimise the overhead at boot. Archs with special
  requirements (such as ppc64) can define their own macro in asm/ftrace.h.
  Steven Rostedt suggested this be made a static inline function, but I don't
  see how this would be possible (at least without #defines and #ifndefs) given
  that it has to be weak to allow archs to override it (Unless I misunderstood
  something?  Steven?).

Subset v2:
- Minimal unchanged subset from 'ftrace syscalls, PowerPC: Various fixes,
  Compat Syscall support and PowerPC implementation' v2 patch series.


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

[PATCH v2 3/3] powerpc: make MPIC honor the 'no-reset' device tree property

2011-02-02 Thread Meador Inge 
This property, defined in the Open PIC binding, tells the kernel not to use the
reset bit in the global configuration register.  Additionally, its presence
mandates that only sources which are actually used (i.e. appear in the device
tree) should have their VECPRI bits initialized.

Signed-off-by: Meador Inge 
CC: Hollis Blanchard 
CC: Benjamin Herrenschmidt 
---
 arch/powerpc/include/asm/mpic.h |4 ++-
 arch/powerpc/sysdev/mpic.c  |   54 ++
 2 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index 9b94f18..688e3e0 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -322,6 +322,8 @@ struct mpic
 #ifdef CONFIG_PM
struct mpic_irq_save*save_data;
 #endif
+
+   int cpu;
 };
 
 /*
@@ -333,7 +335,7 @@ struct mpic
  */
 
 /* This is the primary controller, only that one has IPIs and
- * has afinity control. A non-primary MPIC always uses CPU0
+ * has affinity control. A non-primary MPIC always uses CPU0
  * registers only
  */
 #define MPIC_PRIMARY   0x0001
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index a98f41d..5f17022 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -308,6 +308,15 @@ static inline void mpic_map(struct mpic *mpic, struct 
device_node *node,
 #define mpic_map(m,n,p,b,o,s)  _mpic_map_mmio(m,p,b,o,s)
 #endif /* !CONFIG_PPC_DCR */
 
+static inline void mpic_init_vector(struct mpic *mpic, int source)
+{
+   /* start with vector = source number, and masked */
+   u32 vecpri = MPIC_VECPRI_MASK | source | (8 << 
MPIC_VECPRI_PRIORITY_SHIFT);
+   
+   /* init hw */
+   mpic_irq_write(source, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
+   mpic_irq_write(source, MPIC_INFO(IRQ_DESTINATION), 1 << mpic->cpu);
+}
 
 
 /* Check if we have one of those nice broken MPICs with a flipped endian on
@@ -622,6 +631,14 @@ static unsigned int mpic_is_ipi(struct mpic *mpic, 
unsigned int irq)
return (src >= mpic->ipi_vecs[0] && src <= mpic->ipi_vecs[3]);
 }
 
+/* Determine if the linux irq is a timer interrupt */
+static unsigned int mpic_is_timer_interrupt(struct mpic *mpic, unsigned int 
irq)
+{
+   unsigned int src = mpic_irq_to_hw(irq);
+
+   return (src >= mpic->timer_vecs[0] && src <= mpic->timer_vecs[3]);
+}
+
 
 /* Convert a cpu mask from logical to physical cpu numbers. */
 static inline u32 mpic_physmask(u32 cpumask)
@@ -963,6 +980,15 @@ static int mpic_host_map(struct irq_host *h, unsigned int 
virq,
if (hw >= mpic->irq_count)
return -EINVAL;
 
+   /* If the MPIC was reset, then all vectors have already been
+* initialized.  Otherwise, the appropriate vector needs to be
+* initialized here to ensure that only used sources are setup with
+* a vector.
+*/
+   if (!(mpic->flags & MPIC_WANTS_RESET))
+   if (!(mpic_is_ipi(mpic, hw) || mpic_is_timer_interrupt(mpic, 
hw)))
+   mpic_init_vector(mpic, hw);
+
mpic_msi_reserve_hwirq(mpic, hw);
 
/* Default chip */
@@ -1129,7 +1155,16 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic_map(mpic, node, paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 
0x1000);
 
/* Reset */
-   if (flags & MPIC_WANTS_RESET) {
+
+   /* When using a device-node, reset requests are only honored if the MPIC
+* is allowed to reset.
+*/
+   if (node && of_get_property(node, "no-reset", NULL)) {
+   mpic->flags &= ~MPIC_WANTS_RESET;
+   }
+
+   if (mpic->flags & MPIC_WANTS_RESET) {
+   printk(KERN_DEBUG "mpic: Resetting\n");
mpic_write(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0),
   mpic_read(mpic->gregs, MPIC_INFO(GREG_GLOBAL_CONF_0))
   | MPIC_GREG_GCONF_RESET);
@@ -1246,7 +1281,6 @@ void __init mpic_set_default_senses(struct mpic *mpic, u8 
*senses, int count)
 void __init mpic_init(struct mpic *mpic)
 {
int i;
-   int cpu;
 
BUG_ON(mpic->num_sources == 0);
 
@@ -1290,18 +1324,14 @@ void __init mpic_init(struct mpic *mpic)
mpic_pasemi_msi_init(mpic);
 
if (mpic->flags & MPIC_PRIMARY)
-   cpu = hard_smp_processor_id();
+   mpic->cpu = hard_smp_processor_id();
else
-   cpu = 0;
+   mpic->cpu = 0;
 
-   for (i = 0; i < mpic->num_sources; i++) {
-   /* start with vector = source number, and masked */
-   u32 vecpri = MPIC_VECPRI_MASK | i |
-   (8 << MPIC_VECPRI_PRIORITY_SHIFT);
-   
-   /* init hw */
-   mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
-   mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
+   if (mpic->flags & MPIC_WANTS_RESET) {
+

[PATCH v2 2/3] powerpc: document the Open PIC device tree binding

2011-02-02 Thread Meador Inge 
This binding documents several properties that have been in use for quite
some time, and adds one new property 'no-reset', which controls whether the
Open PIC should be reset during runtime initialization.

The general formatting and interrupt specifier definition is based off of
Stuart Yoder's FSL MPIC binding.

Signed-off-by: Meador Inge 
CC: Hollis Blanchard 
CC: Stuart Yoder 
---
 Documentation/powerpc/dts-bindings/open-pic.txt |  115 +++
 1 files changed, 115 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt

diff --git a/Documentation/powerpc/dts-bindings/open-pic.txt 
b/Documentation/powerpc/dts-bindings/open-pic.txt
new file mode 100644
index 000..447ef65
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/open-pic.txt
@@ -0,0 +1,115 @@
+* Open PIC Binding
+
+This binding specifies what properties must be available in the device tree
+representation of an Open PIC compliant interrupt controller.  This binding is
+based on the binding defined for Open PIC in [1] and is a superset of that
+binding.
+
+PROPERTIES
+
+  NOTE: Many of these descriptions were paraphrased here from [1] to aid
+readability.
+
+  - compatible
+  Usage: required
+  Value type: 
+  Definition: Specifies the compatibility list for the PIC.  The
+  property value shall include "open-pic".
+
+  - reg
+  Usage: required
+  Value type: 
+  Definition: Specifies the base physical address(s) and size(s) of this
+  PIC's addressable register space.
+
+  - interrupt-controller
+  Usage: required
+  Value type: 
+  Definition: The presence of this property identifies the node
+  as an Open PIC.  No property value should be defined.
+
+  - #interrupt-cells
+  Usage: required
+  Value type: 
+  Definition: Specifies the number of cells needed to encode an
+  interrupt source.  Shall be 2.
+
+  - #address-cells
+  Usage: required
+  Value type: 
+  Definition: Specifies the number of cells needed to encode an
+  address.  The value of this property shall always be 0.
+  As such, 'interrupt-map' nodes do not have to specify a
+  parent unit address.
+
+  - no-reset
+  Usage: optional
+  Value type: 
+  Definition: The presence of this property indicates that the PIC
+  should not be reset during runtime initialization.  The presence of
+  this property also mandates that any initialization related to
+  interrupt sources shall be limited to sources explicitly referenced
+  in the device tree.
+
+INTERRUPT SPECIFIER DEFINITION
+
+  Interrupt specifiers consists of 2 cells encoded as
+  follows:
+
+   <1st-cell>   interrupt-number
+
+Identifies the interrupt source.
+
+   <2nd-cell>   level-sense information, encoded as follows:
+0 = low-to-high edge triggered
+1 = active low level-sensitive
+2 = active high level-sensitive
+3 = high-to-low edge triggered
+
+EXAMPLE 1
+
+/*
+ * An Open PIC interrupt controller
+ */
+   mpic: pic@4 {
+// This is an interrupt controller node.
+   interrupt-controller;
+
+// No address cells so that 'interrupt-map' nodes which reference
+// this Open PIC node do not need a parent address specifier.
+   #address-cells = <0>;
+
+// Two cells to encode interrupt sources.
+   #interrupt-cells = <2>;
+
+// Offset address of 0x4 and size of 0x4.
+   reg = <0x4 0x4>;
+
+// Compatible with Open PIC.
+   compatible = "open-pic";
+
+// The PIC should not be reset.
+   no-reset;
+   };
+
+EXAMPLE 2
+
+/*
+ * An interrupt generating device that is wired to an Open PIC.
+ */
+serial0: serial@4500 {
+// Interrupt source '42' that is active high level-sensitive.
+// Note that there are only two cells as specified in the interrupt
+// parent's '#interrupt-cells' property.
+interrupts = <42 2>;
+
+// The interrupt controller that this device is wired to.
+interrupt-parent = <&mpic>;
+};
+
+REFERENCES
+
+[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform
+Requirements (ePAPR), Version 1.0, July 2008.
+(http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf)
+
-- 
1.6.3.3

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

[PATCH v2 0/3] powerpc: Open PIC binding and 'no-reset' implementation

2011-02-02 Thread Meador Inge 
This patch set provides a binding for Open PIC and implements support for
a new property, specified by that binding, called 'no-reset'.  With 'no-reset'
in place the 'protected-sources' property is no longer needed and was removed.

Signed-off-by: Meador Inge 
CC: Hollis Blanchard 

Meador Inge (3):
  powerpc: Removing support for 'protected-sources'
  powerpc: document the Open PIC device tree binding
  powerpc: make MPIC honor the 'no-reset' device tree property

 Documentation/powerpc/dts-bindings/open-pic.txt |  115 +++
 arch/powerpc/include/asm/mpic.h |7 +-
 arch/powerpc/sysdev/mpic.c  |   92 --
 3 files changed, 160 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/open-pic.txt

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

[PATCH v2 1/3] powerpc: Removing support for 'protected-sources'

2011-02-02 Thread Meador Inge 
In a recent discussion [1, 2] concerning device trees for AMP systems, the
question of whether we really need 'protected-sources' arose.  The general
consensus was that if you don't want a source to be used, then it should *not*
be mentioned in an 'interrupts' property.  If a source really needs to be
mentioned, then it should be put in a property other than 'interrupts' with
a specific binding for that use case.

[1] 
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004038.html
[2] 
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/003991.html

Signed-off-by: Meador Inge 
CC: Hollis Blanchard 
CC: Benjamin Herrenschmidt 
---
 arch/powerpc/include/asm/mpic.h |3 ---
 arch/powerpc/sysdev/mpic.c  |   38 --
 2 files changed, 0 insertions(+), 41 deletions(-)

diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index e000cce..9b94f18 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -301,9 +301,6 @@ struct mpic
struct mpic_reg_bankcpuregs[MPIC_MAX_CPUS];
struct mpic_reg_bankisus[MPIC_MAX_ISU];
 
-   /* Protected sources */
-   unsigned long   *protected;
-
 #ifdef CONFIG_MPIC_WEIRD
/* Pointer to HW info array */
u32 *hw_set;
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 7c13426..a98f41d 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -947,8 +947,6 @@ static int mpic_host_map(struct irq_host *h, unsigned int 
virq,
 
if (hw == mpic->spurious_vec)
return -EINVAL;
-   if (mpic->protected && test_bit(hw, mpic->protected))
-   return -EINVAL;
 
 #ifdef CONFIG_SMP
else if (hw >= mpic->ipi_vecs[0]) {
@@ -1095,26 +1093,6 @@ struct mpic * __init mpic_alloc(struct device_node *node,
if (node && of_get_property(node, "big-endian", NULL) != NULL)
mpic->flags |= MPIC_BIG_ENDIAN;
 
-   /* Look for protected sources */
-   if (node) {
-   int psize;
-   unsigned int bits, mapsize;
-   const u32 *psrc =
-   of_get_property(node, "protected-sources", &psize);
-   if (psrc) {
-   psize /= 4;
-   bits = intvec_top + 1;
-   mapsize = BITS_TO_LONGS(bits) * sizeof(unsigned long);
-   mpic->protected = kzalloc(mapsize, GFP_KERNEL);
-   BUG_ON(mpic->protected == NULL);
-   for (i = 0; i < psize; i++) {
-   if (psrc[i] > intvec_top)
-   continue;
-   __set_bit(psrc[i], mpic->protected);
-   }
-   }
-   }
-
 #ifdef CONFIG_MPIC_WEIRD
mpic->hw_set = mpic_infos[MPIC_GET_REGSET(flags)];
 #endif
@@ -1321,9 +1299,6 @@ void __init mpic_init(struct mpic *mpic)
u32 vecpri = MPIC_VECPRI_MASK | i |
(8 << MPIC_VECPRI_PRIORITY_SHIFT);

-   /* check if protected */
-   if (mpic->protected && test_bit(i, mpic->protected))
-   continue;
/* init hw */
mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
@@ -1492,13 +1467,6 @@ static unsigned int _mpic_get_one_irq(struct mpic *mpic, 
int reg)
mpic_eoi(mpic);
return NO_IRQ;
}
-   if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
-   if (printk_ratelimit())
-   printk(KERN_WARNING "%s: Got protected source %d !\n",
-  mpic->name, (int)src);
-   mpic_eoi(mpic);
-   return NO_IRQ;
-   }
 
return irq_linear_revmap(mpic->irqhost, src);
 }
@@ -1532,12 +1500,6 @@ unsigned int mpic_get_coreint_irq(void)
mpic_eoi(mpic);
return NO_IRQ;
}
-   if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
-   if (printk_ratelimit())
-   printk(KERN_WARNING "%s: Got protected source %d !\n",
-  mpic->name, (int)src);
-   return NO_IRQ;
-   }
 
return irq_linear_revmap(mpic->irqhost, src);
 #else
-- 
1.6.3.3

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

Re: [PATCH 4/6] ftrace syscalls: Allow arch specific syscall symbol matching

2011-02-02 Thread Ian Munsie 
Excerpts from Steven Rostedt's message of Thu Feb 03 01:04:44 +1100 2011:
> I'll answer your question here.

> > +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name + 3)
> 
> Instead, you could have:
> 
> #ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> 
> static inline arch_syscall_match_sym_name(const char *sym, const char *name)
> {
> return strcmp(sym + 3, name + 3) != 0;
> }
> 
> 
> If an arch needs to make its own, then it can simply override it by
> creating its own version and defining:
> 
> #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> 
> Just like they do when an arch has its own strcmp.

Ok, I've changed it over. Just doing a quick regression test on ppc64 &
x86 then I'll repost.

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

Re: [PATCH V2 1/6] powerpc: Move udbg_early_init() after early_init_devtree()

2011-02-02 Thread Dave Kleikamp 
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
> On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> > so that it can use information from the device tree.
> 
> Hrm.  On the other hand this means that the early_init_devtree() code
> can't benefit from hardcoded early debugging.  Since you don't
> actually appear to use devtree information in udbg_early_init() in the
> latest series, I'd suggest dropping this patch.

Patch 2 depends on early_init_devtree() being run.  Until then, I don't
know of a way to get at the bootargs.
-- 
Dave Kleikamp
IBM Linux Technology Center

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

Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems

2011-02-02 Thread Dave Kleikamp 
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > Since other OS's may be running on the other cores don't use tlbivax
> 
> [snip]
> > +#ifdef CONFIG_44x
> > +void __init early_init_mmu_44x(void)
> > +{
> > +   unsigned long root = of_get_flat_dt_root();
> > +   if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> > +   amp = 1;
> > +}
> > +#endif /* CONFIG_44x */
> 
> A test against a hardcoded compatible string seems a nasty way to do
> this.  Maybe we should define a new boolean property for the root
> node.

I'm not crazy about this string, but I needed something in the device
tree to key off of.  Freescale has something similar (i.e.
MPC8572DS-CAMP), so I chose to follow their example.  I'd be happy to
replace it with a boolean property.  Any objection to just using "amp"?

Thanks,
Shaggy
-- 
Dave Kleikamp
IBM Linux Technology Center

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

Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems

2011-02-02 Thread David Gibson 
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> Since other OS's may be running on the other cores don't use tlbivax

[snip]
> +#ifdef CONFIG_44x
> +void __init early_init_mmu_44x(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + if (of_flat_dt_is_compatible(root, "ibm,47x-AMP"))
> + amp = 1;
> +}
> +#endif /* CONFIG_44x */

A test against a hardcoded compatible string seems a nasty way to do
this.  Maybe we should define a new boolean property for the root
node.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 1/6] powerpc: Move udbg_early_init() after early_init_devtree()

2011-02-02 Thread David Gibson 
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> so that it can use information from the device tree.

Hrm.  On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging.  Since you don't
actually appear to use devtree information in udbg_early_init() in the
latest series, I'd suggest dropping this patch.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: BootX

2011-02-02 Thread Benjamin Herrenschmidt 
On Wed, 2011-02-02 at 16:09 -0600, kevin diggs wrote:
> Hi,
> 
> And one more thing:  Why does an SMP kernel (mesh compiled in an SMP
> enabled kernel) work?

Could be an alignment or timing problem, depending on random things the
alignment of some DMA data structures or timing of access might end up
being subtely different.
 
> What all does SMP do? If it matters, I'm voluntary preempt.
> 
> Is the DMA hardware in this thing used in any other system (I guess I
> mean both other computers and other sub-systems in this computer -
> does the 53c94 use it? The audio uses it, right?)?

The DBDMA engine is used in various Apple chips but with more or less HW
bugs in it :-)

To get some more info about the MESH, I suggest you google for a
document called "MacTech.pdf" (Macintosh Technology in the
Common Hardware Reference Platform).

This describes the "MacIO" chip that was designed by Apple for CHRP
machines, which is a successor of the Bandit chip which I think contains
the MESH on your machine. The basic IO cells like MESH are the same (tho
it's possible that the one you have contains more bugs).

Cheers,
Ben.

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

Re: BootX

2011-02-02 Thread kevin diggs 
Hi,

And one more thing:  Why does an SMP kernel (mesh compiled in an SMP
enabled kernel) work?

What all does SMP do? If it matters, I'm voluntary preempt.

Is the DMA hardware in this thing used in any other system (I guess I
mean both other computers and other sub-systems in this computer -
does the 53c94 use it? The audio uses it, right?)?

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

Question on supporting multiple HW versions with a single driver (warning: long post)

2011-02-02 Thread Bruce_Leonard 
So this is sort of a follow on question to one I posted a month ago about 
trying to get a PCI driver to work with OF (which I think I more or less 
understood the answer to).  I'm encountering a different sort of problem 
that I'd like to solve with OF but I'm not sure I can.  Let me lay out a 
little background first.

We build embedded systems, so we never really have hot plug events and our 
addresses (at least for HW interfaces) are pretty much static for any 
given product.  In other words for product "A" the NAND controller will 
always be at address "X", though on product "B" that same NAND controller 
may be at address "Y".  Also, the devices in the product are static, i.e., 
we'll always talk to an LXT971 as the PHY.

Currently I'm working on building a driver for an ethernet MAC we're 
putting in an FPGA.  The MAC is based on the MPC8347 TSEC and the driver 
is based on the gianfar driver.  (My previous question was how to spoof 
the OF gianfar driver into thinking it was a PCI driver because our MAC is 
going to be hanging off a PCI bus.  Ultimately I decided to just 
steal...err...borrow... the guts of the gianfar driver and make it a PCI 
driver that only deals with our MAC.)

Right in the middle of writing this driver, my HW guys came to me and said 
they wanted to use this same MAC in other products.  Great I said.  Local 
bus they said.  Which opens up a whole can of worms and leads to my 
question.  We've got a MAC in a FPGA with a nice generic interface on the 
front of it that can talk to a whole range of different busses, PCI, PCIe, 
local bus (of any variety of any processor), etc.  But the internals of 
the MAC (i.e., the register sets, the buffers, the whole buffer descriptor 
mechanism) all looks the same.  Seems to me that this is exactly the sort 
of situation OF and device trees was developed for.

What I'd like to do, and I'm sure it's possible but I have no idea how, is 
to still have this as an OF driver and have the device tree tell the 
kernel about the HW interface to use.  So on one product (currently all 
products use an MCP83xx variant) I would have a child node under a PCI 
node to describe it's interrupts, addressing (which could also come from a 
PCI probe I expect), compatibility, any attached PHYs etc, and on a second 
product do the same thing under a localbus node.

First question that comes to mind is ordering.  If I put a child node in 
the PCI node of the device tree, what happens when the device tree is 
processed?  Is it immediately going to try and find and install a driver 
for that child node?  Since the device tree is processed very early, the 
PCI bus isn't going to be set up and available yet.  Will trying to 
install a PCI driver via OF even be possible at this point?  Then I'd 
still need a PCI function to claim the device when the PCI bus gets 
probed.  If the driver is already installed via OF, what does the PCI 
function do?

Or am I all backwards.  Does having the child node to the PCI node 
actually do anything when the early OF code runs?  If not would the PCI 
probe function be the first indication to the system that the driver needs 
to be loaded?  In which case I just walk the device tree looking 
for...what?  How would I match up the PCI ID with something in the device 
tree?

Then there's the local bus side of the question?  That should truly be an 
OF driver and use struct of_platform_driver along with that whole 
mechanism.  How do I make that compatible with the version of the MAC that 
runs on PCI?

Or am I making a whole lot of work for myself and I should just make them 
separate drivers?  I'm trying to keep the code base as small and coherent 
as possible.  I don't want to have to maintain multiple copies of a driver 
that are essentially identical.

Thanks.

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

Re: BootX

2011-02-02 Thread kevin diggs 
Ben,

I know you are VERY busy. I appreciate your taking the time to reply.

Since I'm am still using this thing I'll take a stab at trying to
track it down. I just posted the FYI to see if I could trigger some
thoughts (like your post).

With a 4.3.5 compiled mesh, it fails a lot of early stuff like getting
cache info? I don't remember the full list because it fails to find
the root fs and does the reboot in 180 seconds thing (I still have in
a back corner of my brain the serial console xmon boot stuff and will
probably eventually try that).

I am hopeful that since it (at least so far) always fails that it
might not be THAT bad to track down. That coupled with some knowledge
of what the compilers are doing differently can hopefully help track
it down.

Thanks!

kevin

On Wed, Feb 2, 2011 at 3:40 PM, Benjamin Herrenschmidt
 wrote:
>
> That's interesting... That driver is really nasty, we probably have a
> bug in it that's exposed by optimizations done by more recent compilers
> but it's not going to be trivial to figure out I'm afraid. I at least
> have very dim memories of mesh and how it operates...
>
> One thing to be careful of with Mesh is that the DMA engine, while
> supposedly cache coherent, has shown in the past to have issues when
> DMA'ing to unaligned memory locations. This shouldn't be a problem with
> normal block transfers but we may have to be careful with things like
> inquiry, mode pages, sense requests etc...
>
> Ben.
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: BootX

2011-02-02 Thread Benjamin Herrenschmidt 
On Wed, 2011-02-02 at 13:36 -0600, kevin diggs wrote:
> Hi,
> 
> FYI:
> 
> I have narrowed this down to drivers/scsi/mesh.c (the root disk
> controller for the PowerMac 8600). I have compiled everything else for
> 2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the
> beast boots. I am using it to post this follow up.

That's interesting... That driver is really nasty, we probably have a
bug in it that's exposed by optimizations done by more recent compilers
but it's not going to be trivial to figure out I'm afraid. I at least
have very dim memories of mesh and how it operates...

One thing to be careful of with Mesh is that the DMA engine, while
supposedly cache coherent, has shown in the past to have issues when
DMA'ing to unaligned memory locations. This shouldn't be a problem with
normal block transfers but we may have to be careful with things like
inquiry, mode pages, sense requests etc...

Ben.

> kevin
> 
> > On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs  
> > wrote:
> >> Hi,
> >>
> >> If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
> >> WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
> >> G4 that runs is a dual cpu beast and thus also runs SMP.
> >>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


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

Re: BootX

2011-02-02 Thread kevin diggs 
Hi,

FYI:

I have narrowed this down to drivers/scsi/mesh.c (the root disk
controller for the PowerMac 8600). I have compiled everything else for
2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the
beast boots. I am using it to post this follow up.

kevin

> On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs  wrote:
>> Hi,
>>
>> If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that
>> WILL boot on the PowerMac8600 (single 750GX). The previously mentioned
>> G4 that runs is a dual cpu beast and thus also runs SMP.
>>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

4xx next branch

2011-02-02 Thread Josh Boyer 
Hi All,

I've added the following patches to my next branch:

Dave Kleikamp (2):
  powerpc/476: define specific cpu table entry DD2 core
  powerpc/476: Workaround for PLB6 hang

Rupjyoti Sarmah (1):
  powerpc/44x: PHY fixup for USB on canyonlands board

Tirumala Marri (1):
  powerpc/44x: Add USB DWC DTS entry to Canyonlands board


There are a few more I'd like to review still, including the AMP support
for 476 before I ask Ben to pull.  The above patches will sit in my
branch for a few days.  If there are any others I have missed, please
let me know.

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

RE: [PATCH 4/6] ftrace syscalls: Allow arch specific syscallsymbol matching

2011-02-02 Thread Steven Rostedt 
On Wed, 2011-02-02 at 14:15 +, David Laight wrote:
> > +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name
> + 3)
> 
> Whenever you use a #define macro arg, you should enclose it in ().
> About the only time you don't need to is when it is being
> passed as an argument to another function
> (ie when it's use is also ',' separated).
> 
> So the above ought to be:
> #define arch_syscall_match_sym_name(sym, name) (!strcmp((sym) + 3,
> (name) + 3))

I would have mentioned this if I wanted it to stay a macro ;)

> 
> Whether an inline function is better or worse is much more subtle!
> For instance I've used:
>asm volatile ( "# line " STR(__LINE__) :: )
> to stop gcc merging the tails of conditionals.
> Useful when the conditional is at the end of a loop (etc),
> it might increase code size slightly, but removes a branch.
> 
> If I put one of those in an 'inline' function separate copies
> of the function end up sharing code.
> With a #define __LINE__ differs so they don't.
> 
> (I had some code to get below 190 clocks, these changes
> were significant!)

For what you were doing, this may have helped. But the code in question
is the "default" version of the function. I much more prefer it to be a
static inline. The issues you experience could change from gcc to gcc.
But static inlined functions are much cleaner and easier to read than
macros.

Using a macro for this purpose is just too messy.

Again, look at include/trace/ftrace.h. If I'm saying using a macro is
ugly, then don't use it! Listen to me, because I'm Mr. Ugly Macro Man.

-- Steve


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

RE: [PATCH 4/6] ftrace syscalls: Allow arch specific syscallsymbol matching

2011-02-02 Thread David Laight 
 
> +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name
+ 3)

Whenever you use a #define macro arg, you should enclose it in ().
About the only time you don't need to is when it is being
passed as an argument to another function
(ie when it's use is also ',' separated).

So the above ought to be:
#define arch_syscall_match_sym_name(sym, name) (!strcmp((sym) + 3,
(name) + 3))

Whether an inline function is better or worse is much more subtle!
For instance I've used:
   asm volatile ( "# line " STR(__LINE__) :: )
to stop gcc merging the tails of conditionals.
Useful when the conditional is at the end of a loop (etc),
it might increase code size slightly, but removes a branch.

If I put one of those in an 'inline' function separate copies
of the function end up sharing code.
With a #define __LINE__ differs so they don't.

(I had some code to get below 190 clocks, these changes
were significant!)

David


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

Re: [PATCH 4/6] ftrace syscalls: Allow arch specific syscall symbol matching

2011-02-02 Thread Steven Rostedt 
On Wed, 2011-02-02 at 18:11 +1100, Ian Munsie wrote:

I'll answer your question here.

> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index dcd6a7c..0d0e109 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -527,6 +527,15 @@ extern enum ftrace_dump_mode ftrace_dump_on_oops;
>  #ifdef CONFIG_FTRACE_SYSCALLS
>  
>  unsigned long arch_syscall_addr(int nr);
> +#ifndef arch_syscall_match_sym_name
> +/*
> + * Only compare after the "sys" prefix. Archs that use
> + * syscall wrappers may have syscalls symbols aliases prefixed
> + * with "SyS" instead of "sys", leading to an unwanted
> + * mismatch.
> + */
> +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name + 3)

Instead, you could have:

#ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME

static inline arch_syscall_match_sym_name(const char *sym, const char *name)
{
return strcmp(sym + 3, name + 3) != 0;
}


If an arch needs to make its own, then it can simply override it by
creating its own version and defining:

#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME

Just like they do when an arch has its own strcmp.

This just keeps things cleaner. I like to avoid macros as they can have
nasty side effects (never would have guess that if you look at what I've
done in trace/ftrace.h ;-)

For example, if we use your call as:

arch_syscall_match_sym_name(str = sym[5], name);

That str would end up being something unexpected. I'm not condoning such
side-effect code, but it is something to think about when using macros.

-- Steve


> +#endif
>  
>  #endif /* CONFIG_FTRACE_SYSCALLS */
>  
> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> index 33360b9..76bffba 100644
> --- a/kernel/trace/trace_syscalls.c
> +++ b/kernel/trace/trace_syscalls.c
> @@ -72,13 +72,7 @@ static struct syscall_metadata *find_syscall_meta(unsigned 
> long syscall)
>   kallsyms_lookup(syscall, NULL, NULL, NULL, str);
>  
>   for ( ; start < stop; start++) {
> - /*
> -  * Only compare after the "sys" prefix. Archs that use
> -  * syscall wrappers may have syscalls symbols aliases prefixed
> -  * with "SyS" instead of "sys", leading to an unwanted
> -  * mismatch.
> -  */
> - if (start->name && !strcmp(start->name + 3, str + 3))
> + if (start->name && arch_syscall_match_sym_name(str, 
> start->name))
>   return start;
>   }
>   return NULL;


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

Re: [PATCH V2 4/6] powerpc/44x: don't use tlbivax on AMP systems

2011-02-02 Thread Dave Kleikamp 
On Wed, 2011-02-02 at 01:48 -0600, Kumar Gala wrote:
> On Feb 1, 2011, at 12:48 PM, Dave Kleikamp wrote:
> 
> > Since other OS's may be running on the other cores don't use tlbivax
> 
> Are you guys building SMP kernel for use with AMP?  Just wondering why you'd 
> be using tlbivax at all.

Yes, for instance, a 4-core chip could run two 2-way instances.

Shaggy
-- 
Dave Kleikamp
IBM Linux Technology Center

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

Re: [PATCH V2 6/6] powerpc/476: Create a dts files for two 476 AMP instances under ISS

2011-02-02 Thread David Gibson 
On Tue, Feb 01, 2011 at 12:48:46PM -0600, Dave Kleikamp wrote:
> These are completely independent OS instances, each running on 2
> cores.

[snip]
> +/memreserve/ 0x01f0 0x0010;

A comment describing what this reserved section is for would be good.

> +/ {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + model = "ibm,iss-4xx";
> + compatible = "ibm,iss-4xx", "ibm,47x-AMP";
> + dcr-parent = <&{/cpus/cpu@0}>;
> +
> + aliases {
> + serial0 = &UART0;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + model = "PowerPC,4xx"; // real CPU changed in sim

If the comment is true, then it's probably simpler to just omit the
model property.  I'm pretty sure nothing will look at it.

> + reg = <0>;
> + clock-frequency = <1>; // 100Mhz :-)
> + timebase-frequency = <1>;> +
> i-cache-line-size = <32>;
> + d-cache-line-size = <32>;
> + i-cache-size = <32768>;
> + d-cache-size = <32768>;
> + dcr-controller;
> + dcr-access-method = "native";
> + status = "ok";

Should be "okay" rather than "ok".

[snip]
> + UART0: serial@4200 {
> + device_type = "serial";
> + compatible = "ns16550a";
> + reg = <0x4200 0x0008>;
> + virtual-reg = <0xe200>;
> + clock-frequency = <11059200>;
> + current-speed = <115200>;
> + interrupt-parent = <&MPIC>;
> + interrupts = <0x0 0x2>;
> + };
> + };
> + };
> +
> + nvrtc {
> + compatible = "ds1743-nvram", "ds1743", "rtc-ds1743";
> + reg = <0 0xEF703000 0x2000>;
> + };
> +
> + chosen {
> + linux,stdout-path = "/plb/opb/serial@4200";

You can use a string reference here:
linux,stdout-path = &UART0;

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev