On Mon, Feb 4, 2013 at 10:20 PM, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 09:07:11PM +0530, Viresh Kumar wrote:
>> └── ondemand
>> ├── sampling_rate
>> ├── up_threshold
>> └── ignore_nice
>
> So this is adding the current governor as a per-cpu thing.
Its per policy, but yes it
On 01/29/2013 06:26 PM, Jon Medhurst (Tixy) wrote:
What I suspect is that the configuration in SITE1/HBI0249A/board.txt
isn't right, particularly the value for SCC 0x700. We are currently
putting the files and instructions together for the 13.01 release, but
if you use the attached board.txt fi
Hi Vincent,
> Hi Lukasz,
>
> I still need to get figures for the cover letter of the V3 of packing
> small tasks patches. Nevertheless, the patches series is available
> here:
> http://git.linaro.org/gitweb?p=people/vingu/kernel.git;a=shortlog;h=refs/heads/sched-pack-small-tasks-v3
>
Thanks for
On Tue, Jan 15, 2013 at 8:21 PM, Rajagopal Venkat
wrote:
> On 14 January 2013 20:06, MyungJoo Ham wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>> wrote:
>>> Set devfreq device min and max frequency limits when device
>>> is added to devfreq, provided frequency table is supplied.
>>
On Tue, Jan 15, 2013 at 8:46 PM, Rajagopal Venkat
wrote:
> On 14 January 2013 20:18, MyungJoo Ham wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>> wrote:
>>> devfreq stats is not taking device suspend and resume into
>>> account. Fix it.
>>>
>>> Signed-off-by: Rajagopal Venkat
>>
>
Len Brown sent a patch to remove this field in the intel_idle driver.
The other user of this field is the davinci cpuidle driver and a
patch has been sent to remove the usage of it.
This patch removes the last user of this field.
Signed-off-by: Daniel Lezcano
---
drivers/acpi/processor_idle.c |
These different headers are not needed.
Signed-off-by: Daniel Lezcano
---
drivers/acpi/processor_idle.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 5cb5f24..82626e9 100644
--- a/drivers/ac
The cpuidle_device is retrieved in the function by using directly
the global variable. But the caller of this function already have
this device and it can be passed as a parameter. That is one small
step to encapsulate the code more.
Signed-off-by: Daniel Lezcano
---
drivers/acpi/processor_idle.
The different definitions are not used anywhere in the code.
Signed-off-by: Daniel Lezcano
---
drivers/acpi/processor_idle.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index e606e36..5cb5f24 100644
--- a/drivers/acpi/p
Greetings,
The current 13.02 schedule has been published on wiki:
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule
llct rebuild is planned later today.
The 13.02 release would be v3.8-rc8 based (tentative).
Please make sure that requests to add new topics (with the git b
On 4 February 2013 20:35, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 07:51:33PM +0530, Viresh Kumar wrote:
>> We correlate things with cpus rather than policies and so the current
>> directory structure of cpu/cpu*/cpufreq/*** is the best suited ones.
>
> Ok, show me the details of that layo
On 4 February 2013 19:39, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
>> All files which are directly present in cpu/cpu*/cpufreq/ folder. I am
>> not talking about governor tunables but policy tunables. Things like
>> scaling_[min]max_freq are policy tun
On 4 February 2013 19:06, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
>> That's not completely true. There lies cpufreq directory in cpu/cpu*/
>> too, where we have per policy stuff in cpu/cpu*/, like policy tunables
>> and stats. And the same is true for
On 4 February 2013 18:34, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote:
>> What i believe is, the place where this directory was present earlier
>> (cpu/cpufreq/) wasn't the right place. Everything else was in
>> cpu/cpu*/cpufreq,
>> then why this in cpu/
On 4 February 2013 18:02, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 05:54:18PM +0530, Viresh Kumar wrote:
>> One important point i would like to highlight is: governors directory
>> would be present in cpu/cpu*/cpufreq/ now instead of cpu/cpufreq/.
>
> Uh, hold on, isn't this breaking a bun
On 4 February 2013 17:47, Rafael J. Wysocki wrote:
> Well, [1-2/4] are things I can take for v3.9 no problem. The other two I'd
> wait for the next cycle to be honest. We already have 30+ cpufreq patches
> scheduled for v3.9 and some of them quite subtle for that matter.
To be honest, i wanted
On 31 January 2013 07:56, Viresh Kumar wrote:
> With the recent changes in cpufreq core, we just need to set mask of all
> possible cpus into policy->cpus. Rest would be done by core.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/exynos-cpufreq.c | 14 +-
> 1 file changed,
On Monday, February 04, 2013 05:08:50 PM Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor. i.e. We
On 02/01/2013 07:49 PM, Len Brown wrote:
> On 02/01/2013 08:48 AM, Daniel Lezcano wrote:
>> This patchset does some cleanup. It could have been folded in a single
>> patch but the review would have been less clean than splitting it into
>> small and trivial patches.
>>
>> The main purpose of this p
Replace the flag by a simple global boolean in the cpuidle.c.
That will allow to cleanup the rest of the code right after,
because the ops won't make sense.
Signed-off-by: Daniel Lezcano
Acked-by: Sekhar Nori
---
arch/arm/mach-davinci/cpuidle.c | 23 ++-
1 file changed, 10
The device->state_count is initialized in the cpuidle_register_device
function.
Signed-off-by: Daniel Lezcano
Acked-by: Sekhar Nori
---
arch/arm/mach-davinci/cpuidle.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index
This patchset does some cleanup. It could have been folded in a single
patch but the review would have been less clean than splitting it into
small and trivial patches.
The main purpose of this patch is to remove the usage of the driver_data
field from the state_usage structure. Len Brown is doing
With one function handling the idle state and a single variable,
the usage of the davinci_ops is overkill.
This patch removes these ops and simplify the code.
Furthermore, the 'driver_data' field is no longer used, we have
1 of the 3 remaining user of this field removed.
Signed-off-by: Daniel Le
The patch is mindless, it just moves the idle function below in the file
in order to prevent forward declaration in the next patch.
Signed-off-by: Daniel Lezcano
Acked-by: Sekhar Nori
---
arch/arm/mach-davinci/cpuidle.c | 72 +++
1 file changed, 36 insertio
Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packag
Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packag
policy->cpu or cpus in policy->cpus can't be offline anymore. And so we don't
need to check if they are online or not.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 17 +++--
drivers/cpufreq/cpufreq_governor.c | 2 +-
drivers/cpufreq/cpufreq_userspace.c | 2
Macro "CPUFREQ_STATDEVICE_ATTR" is defined local to cpufreq_stats.c file and is
almost a copy of the generic version present in cpufreq.h file. Lets use the
generic version instead.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_stats.c | 18 ++
1 file changed, 6 inserti
Currently, there can't be multiple instances of single governor_type. If we have
a multi-package system, where we have multiple instances of struct policy (per
package), we can't have multiple instances of same governor. i.e. We can't have
multiple instances of ondemand governor for multiple packag
Hi Dear Poynor/All cpufreq owner,
I studied the cpufreq interactive governor recently, and there is per
cpu timer for each cpu, that means the workload will be queried and
calculated based on each cpu's workload when timer expires.
I am considering about the case of bad application then workload
On 2/1/2013 7:18 PM, Daniel Lezcano wrote:
> +static bool ddr2_pdown = false;
checkpatch.pl warned against zero initialization of static variable
here. Other than that the series looks good. I checked that both state0
and state1 are entered on da850 evm. Making power measurements requires
more ela
On 1 February 2013 19:03, Frederic Weisbecker wrote:
> 2013/1/29 Vincent Guittot :
>> On my smp platform which is made of 5 cores in 2 clusters,I have the
>> nr_busy_cpu field of sched_group_power struct that is not null when the
>> platform is fully idle. The root cause seems to be:
>> During the
MyungJoo, Ping.
On 15 January 2013 17:16, Rajagopal Venkat wrote:
> On 14 January 2013 20:18, MyungJoo Ham wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>> wrote:
>>> devfreq stats is not taking device suspend and resume into
>>> account. Fix it.
>>>
>>> Signed-off-by: Rajagopal Ve
MyungJoo, Ping.
On 15 January 2013 16:51, Rajagopal Venkat wrote:
> On 14 January 2013 20:06, MyungJoo Ham wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>> wrote:
>>> Set devfreq device min and max frequency limits when device
>>> is added to devfreq, provided frequency table is su
34 matches
Mail list logo
