Rob,
On Wed, Feb 1, 2012 at 4:00 AM, Robert Lee wrote:
> Now that the core cpuidle driver keeps time and handles irq enabling,
> remove this functionality. Also, remove irq disabling as all paths to
> cpuidle_idle_call already call local_irq_disable. Also, restructure
> idle functions as needed
Robert,
On Mon, Feb 27, 2012 at 5:47 AM, Robert Lee wrote:
> Add functionality that is commonly duplicated by various platforms.
>
> Signed-off-by: Robert Lee
> ---
> drivers/cpuidle/cpuidle.c | 37 ++
> include/linux/cpuidle.h | 55
> +
On Mon, Feb 27, 2012 at 5:47 AM, Robert Lee wrote:
> Use core cpuidle timekeeping and irqen wrapper and remove that
> handling from this code.
>
> Signed-off-by: Robert Lee
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 43 +++-
> 1 files changed, 18 insertions(+),
Hi Peter,
On Mon, Feb 27, 2012 at 9:35 PM, Peter Maydell wrote:
> Hi; I'm hoping somebody will be willing to run a test kernel
> for me on some omap boards and send me the dmesg output.
> (I'm trying to sort out QEMU's modelling of the OMAP ID
> registers and the TRMs are rather unhelpful; in par
Hi Rob,
On Wed, Feb 29, 2012 at 4:11 AM, Robert Lee wrote:
> Make necessary changes to implement time keeping and irq enabling
> in the core cpuidle code. This will allow the removal of these
> functionalities from various platform cpuidle implementations whose
> timekeeping and irq enabling fol
en_core_tk_irqen) in cpuidle_idle_call
> (thanks
> Daniel Lezcano)
> * Moved CPUIDLE_ARM_WFI_STATE macro to arch/arm/include/asm/cpuidle.h (thanks
> Jean Pihet)
> * Cleaned up some comments and a stray change (thanks Jean)
Except the comments I sent to the list, this version looks g
Rob,
On Wed, Feb 29, 2012 at 4:11 AM, Robert Lee wrote:
> Enable core cpuidle timekeeping and irq enabling and remove that
> handling from this code.
>
> Signed-off-by: Robert Lee
> ---
> arch/arm/mach-davinci/cpuidle.c | 78 +++---
> 1 files changed, 31 insert
k at this series because some of his earlier
> clean up has introduced those custom functions which
> are getting removed in this series.
I am OK with the patch set, I only have minor remarks to the individual patches.
Reviewed-by: Jean Pihet
>
> Regards
> santosh
>
>
Than
On Wed, Mar 21, 2012 at 11:03 AM, Santosh Shilimkar
wrote:
> On Wednesday 21 March 2012 03:16 PM, Daniel Lezcano wrote:
>> On 03/21/2012 10:41 AM, Shilimkar, Santosh wrote:
>>> On Wed, Mar 21, 2012 at 2:57 PM, Daniel Lezcano
>>> wrote:
The 'valid' field is never used in the code, let's remo
On Wed, Mar 21, 2012 at 10:27 AM, Daniel Lezcano
wrote:
> The cpuidle API allows to declare statically the states in the driver
> structure. Let's use it.
> We do no longer need the fill_cstate function called at runtime and
> by the way adding more instructions at boot time.
>
> Signed-off-by: Da
On Wed, Mar 21, 2012 at 11:07 AM, Santosh Shilimkar
wrote:
> Daniel,
>
> On Wednesday 21 March 2012 02:57 PM, Daniel Lezcano wrote:
>> This patchset is a proposition to improve a bit the code.
>> The changes are code cleanup and does not change the behavior of the
>> driver itself.
>>
>> A couple
Hi Daniel,
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
wrote:
> As we will be able to remove C-states from userspace with the sysfs
> API, this function is no longer needed. We remove it and that simplifies
> the code for more consolidation.
>
> Signed-off-by: Daniel Lezcano
> ---
> arch/a
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
wrote:
> This variable is only used in the pm-debug.c file.
>
> Signed-off-by: Daniel Lezcano
> ---
> arch/arm/mach-omap2/pm-debug.c | 2 +-
> arch/arm/mach-omap2/pm.h | 30 --
> 2 files changed, 13 insertion
On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
wrote:
> Use the new cpuidle API and define in the driver the states.
>
> Signed-off-by: Daniel Lezcano
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 85 +---
> 1 files changed, 59 insertions(+), 26 deletions(-)
>
>
On Fri, Mar 23, 2012 at 1:41 PM, Daniel Lezcano
wrote:
> On 03/23/2012 01:35 PM, Jean Pihet wrote:
>>
>> On Fri, Mar 23, 2012 at 10:26 AM, Daniel Lezcano
>> wrote:
>>>
>>> Use the new cpuidle API and define in the driver the states
Daniel,
On Wed, Apr 4, 2012 at 11:42 AM, Daniel Lezcano
wrote:
> We are storing the 'omap3_idle_data' in the private data field
> if the cpuidle device. As we are using this variable only in this file,
Typo: _of_ the cpuidle device.
> that does not really make sense. Let's use the global variabl
with this patch set, except the very minor remarks on 2 patches.
FWIW:
Reviewed-by: Jean Pihet
Thanks,
Jean
>
> Daniel Lezcano (17):
> ARM: OMAP4: cpuidle - Remove unused valid field
> ARM: OMAP4: cpuidle - Declare the states with the driver declaration
> ARM: OMAP4: cpuidle - R
et's use the global variable directly
> instead dereferencing pointers in an idle critical loop.
>
> Also, that simplfies the code.
>
> Signed-off-by: Daniel Lezcano
> Reviewed-by: Jean Pihet
> Reviewed-by: Santosh Shilimkar
Regards,
Jean
_
Hi Vincent,
On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
wrote:
> Add infrastructure to be able to modify the cpu_power of each core
>
> Signed-off-by: Vincent Guittot
> ---
> arch/arm/include/asm/topology.h | 2 ++
> arch/arm/kernel/topology.c | 36 +++
Vincent,
On Tue, Jun 12, 2012 at 2:02 PM, Vincent Guittot
wrote:
> Use cpu compatibility field and clock-frequency field of DT to
> estimate the capacity of each core of the system
>
> Signed-off-by: Vincent Guittot
> ---
> arch/arm/kernel/topology.c | 122
> ++
Hi Daniel,
On Fri, Jun 8, 2012 at 11:34 PM, Daniel Lezcano
wrote:
> On 06/08/2012 07:33 PM, Deepthi Dharwar wrote:
>> Hi Daniel,
>
> Hi Deepthi,
>
>> On 06/08/2012 09:32 PM, Daniel Lezcano wrote:
>>
>>> We have the state index passed as parameter to the 'enter' function.
>>> Most of the drivers a
Hi Amit, Peter,
On Wed, Jun 13, 2012 at 2:47 PM, Peter Zijlstra wrote:
> On Wed, 2012-06-13 at 18:14 +0530, Amit Kucheria wrote:
>> Various discussions around power-aware scheduling have amplified the
>> need for the scheduler to have some knowledge of DVFS. This would then
>> require the schedul
Hi Daniel,
On Mon, Jun 18, 2012 at 2:55 PM, Daniel Lezcano
wrote:
> On 06/18/2012 02:53 PM, Peter De Schrijver wrote:
>> On Mon, Jun 18, 2012 at 02:35:42PM +0200, Daniel Lezcano wrote:
>>> On 06/18/2012 01:54 PM, Deepthi Dharwar wrote:
On 06/18/2012 02:10 PM, Daniel Lezcano wrote:
>
Hello,
On 15 May 2014 07:36, sneha priya wrote:
> Hello,
>
> There is an issue related to perf which I am facing since 15 days. Hoping
> that the great minds here will help me to solve this.
>
> I have a requirement to make perf tool work on a device having ARM
> architecture. But, on recording
review by the ARM experts and hopefully should be
merged soon.
Regards,
Jean
On 16 May 2014 09:34, Jean Pihet wrote:
> Hello,
>
>
> On 15 May 2014 07:36, sneha priya wrote:
>> Hello,
>>
>> There is an issue related to perf which I am facing since 15 days. Hoping
>
Hi
On 19 May 2014 16:08, Prankul Garg wrote:
> Jean Pihet writes:
>
>>
>> Hello,
>>
>> Indeed there is a problem in the ARM code for tracepoints.
>> After a good discussion with the perf maintainers a solution has be
>> found, cf. http://www.s
Hi,
On 21 May 2014 16:04, Prankul Garg wrote:
> Jean Pihet writes:
>
>
>
>> Also your build is quite old, a lot of changes went into perf since 3.4.
>
> Hi Jean,
>
> finally, it works for me too. The problem i was facing due to the older
> kernel.
That is gr
Hi!
I wanted to ask for help on the Foundation model which becomes really
slow after a while, to the point where it is not usable anymore.
Quite often I have to kill the model (Ctrl-C) and restart it, with
corrupted files on the root FS.
I am using the latest Foundation model, kernel image, instr
Hi Jon,
That is a nice follow up to the OMAP idle code clean up, cf.
http://lists.linaro.org/pipermail/linaro-dev/2010-October/001084.html.
It would be nice to see how the code is organized and the impact of
integrating it into the kernel.
Regards,
Jean
On Tue, Oct 12, 2010 at 12:39 PM, Jon Call
Hi Dave,
On Tue, Dec 7, 2010 at 11:16 AM, Dave Martin wrote:
> On Tue, Dec 7, 2010 at 6:31 AM, Santosh Shilimkar
> wrote:
>> Dave,
>>> -Original Message-
>>> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
>>> boun...@lists.linaro.org] On Behalf Of Dave Martin
>>> Sent: Mon
directive for each ENTRY().
>
> * .align before data words.
>
> * Handle non-interworking return from v7_flush_dcache_all.
>
> Signed-off-by: Dave Martin
Reviewed OK
Reviewed-by: Jean Pihet
Tested OK on OMAP3 with and without CONFIG_THUMB2_KERNEL set. PM
RETention and OFF
sembly in Thumb-2 (otherwise, the result is
> random data in the middle of the code).
>
> The Makefile already ensures that this file is built with a high
> enough gcc -march= flag (armv7-a).
>
> Signed-off-by: Dave Martin
> Tested-by: Santosh Shilimkar
Reviewed OK
Reviewed
On Thu, Feb 17, 2011 at 1:42 PM, Dave Martin wrote:
> * Build unconditionally as ARM for correct interoperation with
> OMAP firmware.
>
> * Remove deprecated PC-relative stores
>
> * Add the required ENDPROC() directive for each ENTRY().
>
> * .align before data words
>
> Signed-off-by: Dave
Hi Pierre,
On Mon, Feb 28, 2011 at 4:09 PM, Pierre Tardy wrote:
> On Mon, Feb 28, 2011 at 2:43 PM, Vincent Guittot
> wrote:
>> On 27 February 2011 17:31, Pierre Tardy wrote:
>>> On Fri, Feb 18, 2011 at 11:03 AM, Vincent Guittot
>>> wrote:
Hi,
I have started to use the new cpuidl
On Mon, Feb 28, 2011 at 4:49 PM, Pierre Tardy wrote:
> On Mon, Feb 28, 2011 at 4:30 PM, Jean Pihet wrote:
>> Hi Pierre,
>>
>> On Mon, Feb 28, 2011 at 4:09 PM, Pierre Tardy wrote:
>>> On Mon, Feb 28, 2011 at 2:43 PM, Vincent Guittot
>>> wrote:
>>>
Benoit,
On Fri, Aug 27, 2010 at 12:25 PM, Cousson, Benoit wrote:
>> This patch has instrumentation code for measuring latencies for
>> various CPUIdle C states for OMAP. Idea here is to capture the
>> timestamp at various phases of CPU Idle and then compute the sw
>> latency for various c states.
Hi,
On Sat, Aug 28, 2010 at 12:08 AM, wrote:
> From: Vishwanath BS
>
> This patch has instrumentation code for measuring latencies for
> various CPUIdle C states for OMAP. Idea here is to capture the
> timestamp at various phases of CPU Idle and then compute the sw
> latency for various c state
Hi Amit, Santosh,
On Thu, Sep 2, 2010 at 10:11 AM, Shilimkar, Santosh
wrote:
...
>> > The point is to keep the minimum possible in the kernel: just the
>> > tracepoints we're interested in. The rest (calculations, averages,
>> > analysis, etc.) does not need to be in the kernel and can be done
Hi Vishwa,
On Mon, Sep 6, 2010 at 1:15 PM, Sripathy, Vishwanath
wrote:
> I did some profiling of assembly code on OMAP3630 board (ZOOM3). In worst
> case it takes around 3.28ms and best case around 2.93ms for mpu off mode.
Can you give a bit more details? Which measurement has been taken (ASM
on
39 matches
Mail list logo
