Instead of devfreq device driver explicitly calling devfreq suspend
and resume apis perhaps from runtime-pm suspend and resume callbacks,
let devfreq core handle it automatically.
Attach devfreq core to runtime-pm framework so that, devfreq device
driver pm_runtime_suspend() will automatically sus
On 01/07/2013 09:18 PM, Vincent Guittot wrote:
> On 2 January 2013 05:22, Preeti U Murthy wrote:
>> Hi everyone,
>> I have been looking at how different workloads react when the per entity
>> load tracking metric is integrated into the load balancer and what are
>> the possible reasons for it.
>>
Mark the stats start time stamp when actual load monitoring is
started for accuracy.
Signed-off-by: Rajagopal Venkat
---
drivers/devfreq/devfreq.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 5782c9b..284
Set devfreq device min and max frequency limits when device
is added to devfreq, provided frequency table is supplied.
This helps governors to suggest target frequency with in
limits.
Signed-off-by: Rajagopal Venkat
---
drivers/devfreq/devfreq.c | 24
1 file changed, 2
devfreq stats is not taking device suspend and resume into
account. Fix it.
Signed-off-by: Rajagopal Venkat
---
drivers/devfreq/devfreq.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 2843a22..4c
Hi Steven,
On 8 January 2013 03:59, Steven Rostedt wrote:
> On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
>
>> > By default, I would suggest for cache locality,
>> > that we try to keep it on the same CPU. But if there's a better CPU to
>> > run on, it runs there.
>>
>> That would break
On Monday, January 07, 2013 11:56:36 PM Daniel Lezcano wrote:
> On 01/07/2013 10:58 PM, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Thanks for the patch!
> >
> > I'd like Daniel to have a look at it still.
>
> I agree with this patch. I was about to send exactly the same.
>
> Thanks Krzysztof for
On 01/07/2013 10:58 PM, Rafael J. Wysocki wrote:
> Hi,
>
> Thanks for the patch!
>
> I'd like Daniel to have a look at it still.
I agree with this patch. I was about to send exactly the same.
Thanks Krzysztof for fixing this.
> On Monday, January 07, 2013 08:12:01 PM Krzysztof Mazur wrote:
>>
This patchset updates OS Save and Restore mechanism for v7 and v7.1 debug for
self-hosted debug powerdown support to Linux 3.8-rc2.
v7 debug for self-hosted debug tested on Pandaboard (A9) which unfortunately
does not support OS Save and Restore.
v7.1 debug for self-hosted debug tested on TC2 big
v7 debug introduced OS Save and Restore mechanism. On a v7 debug SinglePower
system, i.e a system without a separate core and debug power domain, which does
not support external debug over powerdown, it is implementation defined whether
OS Save and Restore is implemented.
v7.1 debug requires OS Sav
This patch introduces debug powerdown support for self-hosted debug for v7
and v7.1 debug architecture for a SinglePower system, i.e. a system without a
separate core and debug power domain. On a SinglePower system the OS Lock is
lost over a powerdown.
If CONFIG_CPU_PM is set the new function pm_i
On Mon, 7 Jan 2013, Marc Zyngier wrote:
> On 07/01/13 17:21, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Stefano Stabellini wrote:
> >> On Fri, 14 Sep 2012, Pawel Moll wrote:
> >>> On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> C
On 01/07/2013 07:24 AM, Jon Medhurst (Tixy) wrote:
I get this compilation error:
arch/arm/mm/cache-l2x0.c: In function 'l2x0_init':
arch/arm/mm/cache-l2x0.c:376:3: error: 'cache_id' undeclared (first use in this
function)
arch/arm/mm/cache-l2x0.c:376:3: note: each undeclared identifier is repor
[Removed Suresh and Venki from discussion, they switched their companies
probably]
On 7 January 2013 20:34, Tejun Heo wrote:
> The latter part "not using idle cpu just for processing work" does
> apply to homogeneous systems too but as I wrote earlier work items
> don't spontaneously happen on an
On 01/07/2013 07:24 AM, Jon Medhurst (Tixy) wrote:
On Fri, 2013-01-04 at 14:06 -0800, John Stultz wrote:
Instead of doing the full re-base, I just merged the 3.8-rc2+ tree into
the linaro-android-3.7-anton-rebase branch, and the collisions were
seemingly manageable.
I've only compile tested on
On 7 January 2013 18:58, Steven Rostedt wrote:
> On Mon, 2013-01-07 at 15:28 +0530, Viresh Kumar wrote:
>> I have another idea that we can try:
>>
>> queue_work_on_any_cpu().
>
> I think this is a good idea.
:) :)
>> - the mask of cpus to schedule this work on
>> OR
>> - Sched Level (SD_LEVEL)
On 07/01/13 17:21, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Stefano Stabellini wrote:
>> On Fri, 14 Sep 2012, Pawel Moll wrote:
>>> On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
CC: Russell King
CC: Pawel Moll
CC: Marc
On Fri, 14 Sep 2012, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Pawel Moll wrote:
> > On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini
> > > CC: Russell King
> > > CC: Pawel Moll
> > > CC: Marc Zyngier
> > > ---
> > > arch/arm/mach-vexp
On 2 January 2013 05:22, Preeti U Murthy wrote:
> Hi everyone,
> I have been looking at how different workloads react when the per entity
> load tracking metric is integrated into the load balancer and what are
> the possible reasons for it.
>
> I had posted the integration patch earlier:
> https:
On Mon, Jan 7, 2013 at 8:34 PM, Tejun Heo wrote:
> Hello, Viresh.
>
> On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
>> Firstly the root cause of this patchset.
>>
>> Myself and some others in Linaro are working on ARM future cores:
>> big.LITTLE systems.
>> Here we have few very po
On Fri, 2013-01-04 at 14:06 -0800, John Stultz wrote:
> Ok, I've got a first-pass branch here:
> git://git.linaro.org/people/jstultz/android.git
> linaro-android-3.8-jstultz-test
Thanks for that.
> Instead of doing the full re-base, I just merged the 3.8-rc2+ tree into
> the linaro-android
Hello, Viresh.
On Mon, Jan 07, 2013 at 03:28:33PM +0530, Viresh Kumar wrote:
> Firstly the root cause of this patchset.
>
> Myself and some others in Linaro are working on ARM future cores:
> big.LITTLE systems.
> Here we have few very powerful, high power consuming cores (big,
> currently A15's)
On Mon, 2013-01-07 at 13:47 +, Dave Martin wrote:
> (Minor point: you can merge the "b start" with the first entry of
> the vectors, because this slot is never used for any other purpose in
> any vector table. The code works anyway, though.)
I considered that when I wrote the patch but though
On Mon, 2013-01-07 at 13:59 +, Peter Maydell wrote:
> On 7 January 2013 13:47, Dave Martin wrote:
> > On Thu, Dec 20, 2012 at 12:23:48PM +, Jon Medhurst (Tixy) wrote:
> >> Does anyone have any further outstanding concerns or comments about my
> >> proposed patch?
> >
> > Since this doesn't
On 7 January 2013 13:47, Dave Martin wrote:
> On Thu, Dec 20, 2012 at 12:23:48PM +, Jon Medhurst (Tixy) wrote:
>> Does anyone have any further outstanding concerns or comments about my
>> proposed patch?
>
> Since this doesn't seem to be merged yet, I'll just comment that this
> all looks sens
On Thu, Dec 20, 2012 at 12:23:48PM +, Jon Medhurst (Tixy) wrote:
> On Fri, 2012-12-14 at 15:54 +, Jon Medhurst (Tixy) wrote:
> > On Fri, 2012-12-14 at 10:10 -0500, Christoffer Dall wrote:
> > > On Fri, Dec 14, 2012 at 3:49 AM, Jon Medhurst (Tixy)
> > > wrote:
> > > > On Thu, 2012-12-13 at
Hi Tejun,
On 4 January 2013 20:39, Tejun Heo wrote:
> I don't know either. Changing behavior subtly like this is hard. I
> usually try to spot some problem cases and try to identify patterns
> there. Once you identify a few of them, understanding and detecting
> other problem cases get a lot e
27 matches
Mail list logo