Re: [PATCH] arm: Fix build error with context tracking calls

2013-09-27 Thread Frederic Weisbecker
On Wed, Sep 25, 2013 at 10:38:58AM -0700, Kevin Hilman wrote:
 Frederic Weisbecker fweis...@gmail.com writes:
 
  2013/9/14, Russell King - ARM Linux li...@arm.linux.org.uk:
  On Fri, Sep 13, 2013 at 07:03:34PM +0200, Frederic Weisbecker wrote:
  diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
  index 247091b..859c8df 100644
  --- a/kernel/context_tracking.c
  +++ b/kernel/context_tracking.c
  @@ -51,6 +51,15 @@ void context_tracking_user_enter(void)
unsigned long flags;
 
/*
  +  * Repeat the user_enter() check here because some archs may be calling
  +  * this from asm and if no CPU needs context tracking, they shouldn't
  +  * go further. We can remove that check here once these archs support
  the static key
  +  * check.
 
  The only (minor) comment on this is that the above would fail checkpatch,
  but that's not a good enough reason to respin it if you've already applied
  it IMHO.
 
 
  Ah I haven't yet pushed that patch anywhere so I can definetly fix
  that. Thanks for the review. BTW, I initially first thought this fix
  could go through your tree but if you prefer I can push it through
  Ingo to the context tracking bits.
 
  Just tell me either way.
 
 Frederic, I suggest you queue it directly for v3.12-rc.  Thanks,

Ok, I'm doing that then, thanks you!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] arm: Fix build error with context tracking calls

2013-09-22 Thread Frederic Weisbecker
2013/9/14, Russell King - ARM Linux li...@arm.linux.org.uk:
 On Fri, Sep 13, 2013 at 07:03:34PM +0200, Frederic Weisbecker wrote:
 diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
 index 247091b..859c8df 100644
 --- a/kernel/context_tracking.c
 +++ b/kernel/context_tracking.c
 @@ -51,6 +51,15 @@ void context_tracking_user_enter(void)
  unsigned long flags;

  /*
 + * Repeat the user_enter() check here because some archs may be calling
 + * this from asm and if no CPU needs context tracking, they shouldn't
 + * go further. We can remove that check here once these archs support
 the static key
 + * check.

 The only (minor) comment on this is that the above would fail checkpatch,
 but that's not a good enough reason to respin it if you've already applied
 it IMHO.


Ah I haven't yet pushed that patch anywhere so I can definetly fix
that. Thanks for the review. BTW, I initially first thought this fix
could go through your tree but if you prefer I can push it through
Ingo to the context tracking bits.

Just tell me either way.

Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] arm: Fix build error with context tracking calls

2013-09-14 Thread Frederic Weisbecker
On Fri, Sep 13, 2013 at 03:50:07PM -0700, Kevin Hilman wrote:
 Frederic Weisbecker fweis...@gmail.com writes:
 
  On Tue, Sep 10, 2013 at 08:07:45AM -0700, Kevin Hilman wrote:
  Nicolas Pitre nicolas.pi...@linaro.org writes:
  
   Adding Kevin Hilman to the CC as he might be interested as well.
  
  Thanks, I'd already noticed this but was distracted getting arm-soc
  changes ready for the merge window.  Looking into it now.
 
  Kevin, can you please try this patch? It built tested fine on ARM
  and live tested correctly on x86. There should be no problem but
  just in case.
 
 Tested-by: Kevin Hilman khil...@linaro.org
 
 Things are back to working again on ARM.  Thanks for the fix, and for
 build testing on ARM.  
 
 As you noticed to test on ARM, we still have to carry that patch to
 drop that 'depends on 64BIT' in order to build/test this... any more
 thoughts on what the remaining obstacles there are?

I was mostly fine with your last patchset that enabled that +
a few stuff to make it working on ARM. There were just a few details
to polish. But I remember I sent detailed reviews, may be you missed them
somewhow?

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] arm: Fix build error with context tracking calls

2013-09-13 Thread Frederic Weisbecker
On Tue, Sep 10, 2013 at 08:07:45AM -0700, Kevin Hilman wrote:
 Nicolas Pitre nicolas.pi...@linaro.org writes:
 
  Adding Kevin Hilman to the CC as he might be interested as well.
 
 Thanks, I'd already noticed this but was distracted getting arm-soc
 changes ready for the merge window.  Looking into it now.

Kevin, can you please try this patch? It built tested fine on ARM
and live tested correctly on x86. There should be no problem but
just in case.

Thanks!

---
From 9bb601401baea0a2b2eead3909a9f186d894d617 Mon Sep 17 00:00:00 2001
From: Frederic Weisbecker fweis...@gmail.com
Date: Tue, 10 Sep 2013 00:54:17 +0200
Subject: [PATCH] arm: Fix build error with context tracking calls

ad65782fba50 (context_tracking: Optimize main APIs off case
with static key) converted context tracking main APIs to inline
functions and left ARM asm callers behind.

This can be easily fixed by making ARM calling the post static
keys context tracking functions. We just need to replicate the
static key checks there. We'll remove these later when ARM will
support the context tracking static keys.

Reported-by: Guenter Roeck li...@roeck-us.net
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Anil Kumar anilk...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/kernel/entry-header.S |8 
 kernel/context_tracking.c  |   12 
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index de23a9b..39f89fb 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -329,10 +329,10 @@
 #ifdef CONFIG_CONTEXT_TRACKING
.if \save
stmdb   sp!, {r0-r3, ip, lr}
-   bl  user_exit
+   bl  context_tracking_user_exit
ldmia   sp!, {r0-r3, ip, lr}
.else
-   bl  user_exit
+   bl  context_tracking_user_exit
.endif
 #endif
.endm
@@ -341,10 +341,10 @@
 #ifdef CONFIG_CONTEXT_TRACKING
.if \save
stmdb   sp!, {r0-r3, ip, lr}
-   bl  user_enter
+   bl  context_tracking_user_enter
ldmia   sp!, {r0-r3, ip, lr}
.else
-   bl  user_enter
+   bl  context_tracking_user_enter
.endif
 #endif
.endm
diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index 247091b..859c8df 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -51,6 +51,15 @@ void context_tracking_user_enter(void)
unsigned long flags;
 
/*
+* Repeat the user_enter() check here because some archs may be calling
+* this from asm and if no CPU needs context tracking, they shouldn't
+* go further. We can remove that check here once these archs support 
the static key
+* check.
+*/
+   if (!static_key_false(context_tracking_enabled))
+   return;
+
+   /*
 * Some contexts may involve an exception occuring in an irq,
 * leading to that nesting:
 * rcu_irq_enter() rcu_user_exit() rcu_user_exit() rcu_irq_exit()
@@ -151,6 +160,9 @@ void context_tracking_user_exit(void)
 {
unsigned long flags;
 
+   if (!static_key_false(context_tracking_enabled))
+   return;
+
if (in_interrupt())
return;
 
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Build error in torvalds kernel 3.11 for omap2plus

2013-09-10 Thread Frederic Weisbecker
On Tue, Sep 10, 2013 at 08:07:45AM -0700, Kevin Hilman wrote:
 Nicolas Pitre nicolas.pi...@linaro.org writes:
 
  Adding Kevin Hilman to the CC as he might be interested as well.
 
 Thanks, I'd already noticed this but was distracted getting arm-soc
 changes ready for the merge window.  Looking into it now.

I have the fix pending. It passed the cross build so I'll send it soon.

Thanks.

 
 Kevin
 
  On Mon, 9 Sep 2013, Guenter Roeck wrote:
 
  On Mon, Sep 09, 2013 at 09:31:41PM +0100, Russell King - ARM Linux wrote:
   On Mon, Sep 09, 2013 at 09:03:48AM -0700, Guenter Roeck wrote:
Unfortunately, there are more problems.

arch/arm/kernel/built-in.o: In function `ret_fast_syscall':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:42:
undefined reference to `user_enter'
arch/arm/kernel/built-in.o: In function `no_work_pending':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:77:
undefined reference to `user_enter'
arch/arm/kernel/built-in.o: In function `vector_swi':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:376:
undefined reference to `user_exit'
arch/arm/kernel/built-in.o: In function `__dabt_usr':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:365: 
undefined reference to `user_exit'
arch/arm/kernel/built-in.o: In function `__irq_usr':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:375: 
undefined reference to `user_exit'
arch/arm/kernel/built-in.o: In function `__und_usr':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:388: 
undefined reference to `user_exit'
arch/arm/kernel/built-in.o: In function `__pabt_usr':
/home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:662: 
undefined reference to `user_exit'
   
   These are due to ad65782fba50 (context_tracking: Optimize main APIs off 
   case
   with static key) converting these functions to be inline.
   
   No idea what the fix for this is other than reverting the change.  Any
   ideas Frederic?
   
  I am all for reverting unless this can be fixed quickly.
  AFAICS this breaks all arm builds if CONFIG_CONTEXT_TRACKING is enabled.
  
  Guenter
  
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: rcu self-detected stall messages on OMAP3, 4 boards

2012-09-22 Thread Frederic Weisbecker
2012/9/22 Paul E. McKenney paul...@linux.vnet.ibm.com:
 On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:
 * Paul E. McKenney paul...@linux.vnet.ibm.com [120921 12:58]:
 
  Just to make sure I understand the combinations:
 
  o   All stalls have happened when running a minimal userspace.
  o   CONFIG_NO_HZ=n suppresses the stalls.
  o   CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
  no observable effect on the stalls.

 The reason why you may need minimal userspace is to cut down
 the number of timers waking up the system with NO_HZ.
 Booting with init=/bin/sh might also do the trick for that.

 Good point!  This does make for a very quiet system, but does not
 reproduce the problem under kvm, even after waiting for four minutes.
 I will leave it for more time, but it looks like I really might need to
 ask Linaro for remote access to a Panda.

I have one. I'm currently installing Ubuntu on it and I'll try to
manage to build
a kernel and reproduce the issue.

I'll give more news soon.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/4] perf: clean-up of power events API

2010-10-07 Thread Frederic Weisbecker
On Thu, Oct 07, 2010 at 05:23:43PM +0200, Pierre Tardy wrote:
 On Thu, Oct 7, 2010 at 5:08 PM, Mathieu Desnoyers
 mathieu.desnoy...@efficios.com wrote:
  [ Adding a few more CCs, since this discussion is about a tracepoint
   userspace ABI policy, which is a topic of general interest. ]
 
 To add a little more comment, this is not the first time that
 tracepoints ABI changes. You can look at pytimechart sourcecode:
 http://gitorious.org/pytimechart/pytimechart/blobs/master/timechart/ftrace.py
 
 from 2.6.31 which is the first kernel I support,
 
 sched_switch:  'task %s:%d [%d] == %s:%d [%d]',
 changed to:
 sched_switch:  'prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s
 == next_comm=%s next_pid=%d next_prio=%d',
 
 workqueue_execution: 'thread=%s
 func=%s\\+%s/%s','thread','func','func_offset','func_size'),
 changed to:
 workqueue_execution: 'thread=%s func=%s','thread','func'),
 



Seems to be only formatting changes, but no field has been removed and
no tracepoint has been renamed, etc...

So these are no stable ABI changes because the formatting can be changed
anytime. We want that flexibility and it stands on top of the per event
format files.

Tools are not supposed to read ascii formatted traces from trace/trace_pipe
files. Instead they need to read binary traces from trace_pipe_raw files
and look at the format file to know how to format this.

This is why we have these format files: to let tools adapt with changes
like format change or fields added.

And we have a library in perf and trace-cmd that let you

- request a field value in a raw trace, by its name. So the field doesn't
  need to have a stable offset in the trace.
- request ascii format info, so that if ascii format changes, the tool
  adapt.
- record binary traces, much more leightweight for the writer (kernel)
  and for the reader (user).


I did told you that it would be better you make PyTimeChart use the perf
scripting facilities, it handles all the above things + it would
avoid you to handle a lot of things.

Now it's up to you, but don't count on us to make the ascii formatting
a stable ABI.

 
 actually, over all the events pytimechart supports, only power traces
 are stable...


Now one problem is that we have really broken the workqueue tracepoints
in this release. I thought nobody was using them so we could
refactor this tracepoint subsystem, my bad.

workqueue_execution has become workqueue_execution_start and
workqueue_execution_end. workqueue_insertion is going to
suffer a similar split.

workqueue_creation and workqueue_destruction have disappear but
I can probably restore them, but for the rest, what should we do?

I really feel uncomfortable with this tracepoint/ABI problem
Mathieu suggested we start a user library that could handle these
changes when they are really necessary.

Thoughts?

(Adding Tejun in Cc).

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html