On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
> From: "hongbo.zhang"
>
> This patch set contains two patches.
>
> [PATCH 1/2]
> A new interface is introduced to deactive all the referenced cooling devices
> when thermal zone is disabled.
we can not deactive a cooling device directly.
we s
On 21 September 2012 15:21, Zhang Rui wrote:
> On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
>> From: "hongbo.zhang"
>>
>> This patch set contains two patches.
>>
>> [PATCH 1/2]
>> A new interface is introduced to deactive all the referenced cooling devices
>> when thermal zone is disabled.
On 五, 2012-09-21 at 15:50 +0800, Hongbo Zhang wrote:
> On 21 September 2012 15:21, Zhang Rui wrote:
> > On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
> >> From: "hongbo.zhang"
> >>
> >> This patch set contains two patches.
> >>
> >> [PATCH 1/2]
> >> A new interface is introduced to deactive
On 21 September 2012 16:02, Zhang Rui wrote:
> On 五, 2012-09-21 at 15:50 +0800, Hongbo Zhang wrote:
>> On 21 September 2012 15:21, Zhang Rui wrote:
>> > On 五, 2012-09-21 at 14:57 +0800, zhanghongbo wrote:
>> >> From: "hongbo.zhang"
>> >>
>> >> This patch set contains two patches.
>> >>
>> >> [PA
Like Jeff mentioned, I also saw some illegal instructions on early
linaro builds but didn't pursue it at the time. I just did a little
digging online and there was some mention of ARM errata causing issues
( https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/495536)
Based on,
https://github.
Devfreq returns governor predicted frequency as current frequency
via sysfs interface. But device may not support all frequencies
that governor predicts. So add a callback in device profile to get
current freq from driver. Also add a new sysfs node to expose
governor predicted next target frequency
Add devfreq suspend/resume apis for devfreq users. This patch
supports suspend and resume of devfreq load monitoring, required
for devices which can idle.
Signed-off-by: Rajagopal Venkat
---
drivers/devfreq/devfreq.c | 28
drivers/devfreq/governor.h
This patchset updates devfreq core to add support for devices
which can idle. When device idleness is detected perhaps
through runtime-pm, need some mechanism to suspend devfreq
load monitoring and resume when device is back online.
patch 1 introduce core design changes - per device work, decouple
Prepare devfreq core framework to support devices which
can idle. When device idleness is detected perhaps through
runtime-pm, need some mechanism to suspend devfreq load
monitoring and resume back when device is online. Present
code continues monitoring unless device is removed from
devfreq core.
From: Morten Rasmussen
Adds ftrace event for tracing task migrations using HMP
optimized scheduling.
Signed-off-by: Morten Rasmussen
---
include/trace/events/sched.h | 28
kernel/sched/fair.c | 15 +++
2 files changed, 39 insertions(+), 4 d
From: Morten Rasmussen
Adds Kconfig entries to enable HMP scheduling on ARM platforms.
Currently, it disables CPU level sched_domain load-balacing in order
to simplify things. This needs fixing in a later revision. HMP
scheduling will do the load-balancing at this level instead.
Signed-off-by: M
From: Morten Rasmussen
Adds ftrace events for key variables related to the entity
load-tracking to help debugging scheduler behaviour. Allows tracing
of load contribution and runqueue residency ratio for both entities
and runqueues as well as entity CPU usage ratio.
Signed-off-by: Morten Rasmuss
From: Morten Rasmussen
Hi Paul, Paul, Peter, Suresh, linaro-sched-sig, and LKML,
As a follow-up on my Linux Plumbers Conference talk about my experiments with
scheduling on heterogeneous systems I'm posting a proof-of-concept patch set
with my modifications. The intention behind the modification
From: Morten Rasmussen
SCHED_HMP requires the different cpu types to be represented by an
ordered list of hmp_domains. Each hmp_domain represents all cpus of
a particular type using a cpumask.
The list is platform specific and therefore must be generated by
platform code by implementing arch_get
From: Morten Rasmussen
We can't rely on Kconfig options to set the fast and slow CPU lists for
HMP scheduling if we want a single kernel binary to support multiple
devices with different CPU topology. E.g. TC2 (ARM's Test-Chip-2
big.LITTLE system), Fast Models, or even non big.LITTLE devices.
Th
From: Morten Rasmussen
Introduces a priority threshold which prevents low priority task
from migrating to faster hmp_domains (cpus). This is useful for
user-space software which assigns lower task priority to background
task.
Signed-off-by: Morten Rasmussen
---
arch/arm/Kconfig| 13 +
From: Morten Rasmussen
This patch introduces forced task migration for moving suitable
currently running tasks between hmp_domains. Task behaviour is likely
to change over time. Tasks running in a less capable hmp_domain may
change to become more demanding and should therefore be migrated up.
The
From: Morten Rasmussen
This patch introduces the basic SCHED_HMP infrastructure. Each class of
cpus is represented by a hmp_domain and tasks will only be moved between
these domains when their load profiles suggest it is beneficial.
SCHED_HMP relies heavily on the task load-tracking introduced i
From: Morten Rasmussen
We need a way to prevent tasks that are migrating up and down the
hmp_domains from migrating straight on through before the load has
adapted to the new compute capacity of the CPU on the new hmp_domain.
This patch adds a next up/down migration delay that prevents the task
f
From: Morten Rasmussen
This patch adds load_avg_ratio to each task. The load_avg_ratio is a
variant of load_avg_contrib which is not scaled by the task priority. It
is calculated like this:
runnable_avg_sum * NICE_0_LOAD / (runnable_avg_period + 1).
Signed-off-by: Morten Rasmussen
---
include
Hi all,
Some of you may have heard of a tool we use inside TI for debugging on
OMAP. It's a nice userspace tool which can inspect many aspects of
hardware state called "omapconf". The tool has just been open sourced
and can be found at:
https://github.com/omapconf/omapconf
Regards,
Mike
_
On 21 September 2012 15:07, Mike Turquette wrote:
> Hi all,
>
> Some of you may have heard of a tool we use inside TI for debugging on
> OMAP. It's a nice userspace tool which can inspect many aspects of
> hardware state called "omapconf". The tool has just been open sourced
> and can be found a
W dniu 21.09.2012 22:24, Zach Pfeffer pisze:
> On 21 September 2012 15:07, Mike Turquette wrote:
>> https://github.com/omapconf/omapconf
>
> Is there an Android.mk? Looking at
> https://github.com/omapconf/omapconf it says it works on Android, but
> I don't see an Android.mk to compile it with.
On Thu, Sep 20, 2012 at 7:33 PM, Ash Charles wrote:
> Like Jeff mentioned, I also saw some illegal instructions on early
> linaro builds but didn't pursue it at the time. I just did a little
> digging online and there was some mention of ARM errata causing issues
> ( https://bugs.launchpad.net/ub
On Thursday, September 20, 2012, Daniel Lezcano wrote:
> The function __cpuidle_register_driver name is confusing because it
> suggests, conforming to the coding style of the kernel, it registers
> the driver without taking a lock. Actually, it just fill the different
> power field states with a de
Just wanted to share this with everyone.
I've attached the "output" folder that the NI instrument creates for
each test session. In the results file you'll see a text doc called
results.txt that lists the comma delimited parameters that get
measured followed by the measurements themselves:
Curren
On 21 September 2012 16:00, Marcin Juszkiewicz
wrote:
> W dniu 21.09.2012 22:24, Zach Pfeffer pisze:
>> On 21 September 2012 15:07, Mike Turquette wrote:
>
>>> https://github.com/omapconf/omapconf
>>
>> Is there an Android.mk? Looking at
>> https://github.com/omapconf/omapconf it says it works on
27 matches
Mail list logo
