On Wed, Jun 22, 2011 at 3:50 PM, Amit Kucheria wrote:
> On 11 Jun 22, Vishwanath Sripathy wrote:
>> Hi Nicolas,
>>
>> Can you pls pull below patch from 2.6.39 mainline kernel into 11.5
>> Linaro kernel? This would fix some of the DVFS related issues seen on
&g
Hi Nicolas,
Can you pls pull below patch from 2.6.39 mainline kernel into 11.5
Linaro kernel? This would fix some of the DVFS related issues seen on
OMAP3.
Patch:
commit 5fd2a84ab3c8b87176e25db1d98c5cc34043a669
Author: Avinash H.M
OMAP3: set the core dpll clk rate in its set_rate function
Vi
tre
> wrote:
>> On Fri, 1 Apr 2011, Vishwanath Sripathy wrote:
>>
>>> Hi Nicolas,
>>>
>>> Pls find rebased OMAP DVFS patches attached. Apologies for the delay
>>> as I had to rework some of the patches because of kernel migration.
>>
>&
On Tue, Mar 29, 2011 at 3:43 AM, Nicolas Pitre wrote:
> On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
>
>> Hi Nicolas,
>>
>> Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and
>> these are rebased against latest .38 linaro kernel.
>> oma
On Wed, Mar 2, 2011 at 4:35 AM, Nicolas Pitre wrote:
> On Mon, 28 Feb 2011, Nicolas Pitre wrote:
>
>> On Mon, 28 Feb 2011, Vishwanath Sripathy wrote:
>>
>> > Hi Nicolas,
>> >
>> > Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and
>
On Mon, Feb 28, 2011 at 9:36 PM, Jean Pihet wrote:
> 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
>
Hi Nicolas,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and
these are rebased against latest .38 linaro kernel.
omap cpufreq driver changes are already posted to lo
(https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer
changes will be upstreamed once Basic DVFS frame
Hi Nicole,
Could you pls take attached patch set for 2.6.38 Linaro kernel? These
are already posted to lo and so far there are no comments.
LO Link: https://patchwork.kernel.org/patch/566461/
Attached patches are rebased to latest Linaro .38 kernel.
Regards
Vishwa
omap3_cpuidle.tar
Description
On Thu, Feb 17, 2011 at 12:41 AM, Nicolas Pitre
wrote:
> On Tue, 15 Feb 2011, Vishwanath Sripathy wrote:
>
>> Hi Nicolas,
>>
>> Pls find attached the patch set for supporting DVFS feature on OMAP.
>> These patches have been generated against latest Linaro 2.6.37 tree
Yong,
On Tue, Feb 8, 2011 at 9:21 PM, Yong Shen wrote:
> Hi Arnaud,
> I also took a while to think about this before posting patches. I prefer to
> put it in board related code since the various PMIC used on each boards may
> have influence on cpuidle latency or other charactors, although it coul
Vincent,
On Mon, Feb 7, 2011 at 3:55 PM, Vincent Guittot
wrote:
> Hi vishwa,
>
> I have passed cpufreq-bench on my platform. The results below have
> been reached with a sampling rate of 20ms and a sampling_down factor
> set to 10.
>
> I have a question about the sampling_down feature : The ondem
Yong,
Idea of defining various C states is to get maximum power savings both
active and inactive usecases.
C states you defined below are definitely good as a starting point.
May be you can define more C states by adding more granularity
depending on what are controlled as part of CPUIdle.
Eg: In
I suppose attached patch from Paul should fix this issue.
regards
Vishwa
On Fri, Jan 21, 2011 at 2:41 PM, john stultz wrote:
> On Fri, 2011-01-21 at 00:36 -0800, john stultz wrote:
>> Hey Nicolas,
>> Over the last few days I've been playing with recent kernels on a
>> BeagleBoard xM. So fa
Hello Everyone,
The minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-12-22
Attendees: Vishwa, Torez, Vincent, Yong
Regards,
Vishwa
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
ht
Hello Everyone,
The minutes of the weekly call can be found at:
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2010-12-15
Attendees: Vishwa, Steve, Torez, Vincent, Yong, Amit Daniel
Highlight: CPU Hotplug
Regards,
Vishwa
___
linaro-dev
Mike,
> -Original Message-
> From: Turquette, Mike [mailto:mturque...@ti.com]
> Sent: Wednesday, December 01, 2010 1:20 AM
> To: Vishwanath BS
> Cc: linux-o...@vger.kernel.org; linaro-dev@lists.linaro.org
> Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency
>
> On Thu, Nov 2
Dave,
On Tue, Nov 30, 2010 at 2:15 AM, Michael Hope wrote:
> On Tue, Nov 30, 2010 at 12:37 AM, Dave Martin wrote:
>> On Sun, Nov 28, 2010 at 10:28 PM, Michael Hope
>> wrote:
>>> I sat down and measured the power consumption of the NEON unit on an
>>> OMAP3. Method and results are here:
>>> h
binary manually.
>
> Copying these results to the list as requested but is that really necessary
> for everyone? Could you summarise the results for us all when you've got
> enough please?
>
> Mark
>
>
> From: Vishwanath Sripathy
Nicolas,
Can you pls merge this patch into Linaro tree?
Vishwa
On Sat, Nov 27, 2010 at 4:08 AM, Christian Robottom Reis
wrote:
> On Mon, Nov 22, 2010 at 11:09:03AM -0500, David C Niemi wrote:
>> The general problem here is that the ondemand governor is aimed more at
>> power savings than perform
onsiveness to quick
> load transients involving some I/O. It's also worth considering
> lowering up_threshold to 50 or even down to 15-20.
>
> David C Niemi
>
> Vishwanath Sripathy wrote:
>> Amit,
>>
>> On Tue, Nov 23, 2010 at 8:22 PM, Amit Kucheria
&g
puidle. I will try to measure it for some usecase and
compare the power impact.
Vishwa
>
> /Amit
>
> On Tue, Nov 23, 2010 at 5:59 PM, Vishwanath Sripathy
> wrote:
>> Thanks David for the inputs.
>> I tried your patch. In addition to that I reduced transition_latency.
es
> the performance governor quite well while the original ondemand
> performance was poor. On the other hand, it is not much help if you are
> trying to minimize power consumption on light to medium loads. If you
> set sampling_down_factor to "1" it preserves default behavior.
Hi,
I was trying to investigate performance issues that we were seeing
with some usecases like Video playback on OMAP Platforms with ondemand
governor.
As part of this, I found a tool called cpufreq-bench
(http://lwn.net/Articles/339862) which can be used determine the
performance impact of ondema
Hi All,
tarball with cpufreqbench and readme is available at
http://people.linaro.org/~amitk/cpufreq.tgz
Vishwanath
On Tue, Nov 16, 2010 at 3:37 PM, Sripathy, Vishwanath
wrote:
> All,
>
>
>
> I am trying to investigate ondemand governor’s limitation in Linux kernel.
> As part of that, I have fou
ACTION: Vishwa to send link for patches (patchworks) for ARM
context save and restore (for OMAP) to the team (mainly for Yong
and Vincent).
Patches posted to LO (mainly OMAP CPUIdle assembly code clean
up):
https://patchwork.kernel.org/patch/204172/
https://patchwork.kernel.org/patch/204182/
Detai
Yong,
>On Mon, Oct 18, 2010 at 1:51 PM, wrote:
>From: Yong Shen
>the operating points are tested on babbage 3.0
Commit log needs more description like
What are the supported operating points,
Is there any link between mpu OPP and other devices?
What are the platforms this patch is tested agains
>
>On Fri, Oct 8, 2010 at 12:55 AM, Nicolas Pitre
wrote:
>On Thu, 7 Oct 2010, Vishwanath Sripathy wrote:
>
>> Hi All,
>>
>> Purpose of this email is to debate on the pros and cons of having a
common
>> ARM context save/restore code.
>> Currently each S
Hi All,
Purpose of this email is to debate on the pros and cons of having a common
ARM context save/restore code.
Currently each SOC has its own way of saving/restoring ARM registers and
there has been a proposal to have a common code for the same instead of
duplicating the same in different place
Amit,
> On Fri, Sep 24, 2010 at 12:13 PM, Amit Kucheria
> wrote:
> Vishwa,
>
>
> > On 10 Sep 23, Vishwanath Sripathy wrote:
> > From: Vishwanath BS
> >
> > This patch series has some clean up in OMAP3 sleep code.
> >
> > Vishwanath BS (2):
>
From: Vishwanath BS
This patch has done some clean up of omap3 sleep code.
Basically all possible hardcodings are removed.
Reorganized code into more logical buckets for better readability.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/sleep34xx.S | 375
From: Vishwanath BS
There is no need to keep omap3 sleep code in SRAM. This code can be run very
well on DDR. This would help us to instrument CPUIdle latencies.
Tested on ZOOM3.
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+),
From: Vishwanath BS
This patch series has some clean up in OMAP3 sleep code.
Vishwanath BS (2):
OMAP3 PM: move omap3 sleep to ddr
OMAP3 PM: sleep code clean up
arch/arm/mach-omap2/pm34xx.c |9 +-
arch/arm/mach-omap2/sleep34xx.S | 375 ++-
More update.
I had missed to apply latest patch from Amit A before this test.
After applying the latest patch, things are working fine.
Apologies for the confusion.
Regards
Vishwa
On Tue, Aug 31, 2010 at 11:20 AM, Vishwanath Sripathy <
vishwanath.sripa...@linaro.org> wrote:
> I had mi
to cross compile it for OMAP.
Regards
Vishwa
On Mon, Aug 30, 2010 at 11:30 AM, Vishwanath Sripathy <
vishwanath.sripa...@linaro.org> wrote:
> Some updates on Action items:
> * ACTION: Vishwa to verify powertop on 2.6.35
> I verified powertop using latest Kevin's pm branc
Some updates on Action items:
* ACTION: Vishwa to verify powertop on 2.6.35
I verified powertop using latest Kevin's pm branch (2.6.35) and it is
working as expected.
Regards
Vishwa
On Wed, Aug 25, 2010 at 3:11 PM, Amit Kucheria wrote:
> The minutes of the weekly call can be found at:
>
> https
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 states. For OMAP, 32k clock is chosen as
reference clock this as
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 states. For OMAP, 32k clock is chosen as
reference clock thi
From: vishwanath.sripa...@linaro.org
This patch has instrumentation code for measuring CPUIdle C states for OMAP.
THis is still under development and not completely tested yet.
Idea here is to capture the timestamp at various phases of CPU Idle and
then compute the sw latency for various c states
I tried to install xdeb on my ubuntu PC (V 10.04), but faced some issues.
Attached is the error log. Any inputs?
Thanks
Vishwa
On Fri, Jul 30, 2010 at 5:48 PM, Loïc Minier wrote:
> On Fri, Jul 30, 2010, Amit Kucheria wrote:
> > > Will it make sense to have a "readme.ARM" or some other file in
>
Hi Folks,
I have put some ideas on CPU Idle instrumentation in below link.
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/CPUIdle
Kindly let me know your inputs.
Regards
Vishwa
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://l
40 matches
Mail list logo
