Re: [PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.

On Fri, 26 Oct 2012 15:09:05 +0800, Hongbo Zhang wrote: > From: "hongbo.zhang" > > Problem of using this list is that the cpufreq_get_max_state callback will be > called when register cooling device by thermal_cooling_device_register, but > this list isn't ready at this moment. What's more, there

Re: [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler

On 10/26/2012 06:37 PM, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> [...] >> >> So a sane series would introduce maybe two functions: >> cpu_load() and task_load() and use those where we now use >> rq->load.weight and p->se.load.weight for load balancing >> purposes. Implement these f

Re: [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler

On 10/26/2012 05:59 PM, Peter Zijlstra wrote: > On Thu, 2012-10-25 at 23:42 +0530, Preeti U Murthy wrote: > firstly, cfs_rq is the wrong place for a per-cpu load measure, secondly > why add another load field instead of fixing the one we have? Hmm..,rq->load.weight is the place. >> So why didnt

Re: [PATCH 0/4][V2] cpuidle : multiple drivers support

On Friday, October 26, 2012 09:23:45 PM Daniel Lezcano wrote: > > Rafael, > > this patchset does not apply anymore on linux-pm-next. > > Let me refresh it and resend a V3. OK, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___

Re: [PATCH 0/4][V2] cpuidle : multiple drivers support

Rafael, this patchset does not apply anymore on linux-pm-next. Let me refresh it and resend a V3. Thanks -- Daniel -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook |

[PATCH V2] gpiolib: provide provision for gpiolib to register pin range

From: Shiraz Hashim pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which a given pinctrl driver can handle. This is important to handle pinctrl gpio request calls in order to program a given pin properly for gpio operation. As gpio base is allocated dynamically during

Re: [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler

* Peter Zijlstra wrote: > [...] > > So a sane series would introduce maybe two functions: > cpu_load() and task_load() and use those where we now use > rq->load.weight and p->se.load.weight for load balancing > purposes. Implement these functions using those two > expression. So effectively

[PATCH RESEND] cpufreq: Make sure target freq is within limits

__cpufreq_driver_target() must not pass target frequency beyond the limits of current policy. Today most of cpufreq platform drivers are doing this check in their target routines. Why not move it to __cpufreq_driver_target(). Signed-off-by: Viresh Kumar --- Hi Rafael, Resend doesn't contain any

Re: [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler

On Thu, 2012-10-25 at 23:42 +0530, Preeti U Murthy wrote: > > Do explain.. > > > Let me see if I get what you are saying here right.You want to replace > for example cfs_rq->load.weight with a saner metric because it does not > consider the run time of the sched entities queued on it,merely their

Re: [RFC] cpufreq: Make sure target freq is within limits

On Thursday, October 25, 2012 12:03:34 PM Viresh Kumar wrote: > Hi Rafael, > > __cpufreq_driver_target() must not pass target frequency beyond the limits of > current policy. > > Today most of cpufreq platform drivers are doing this check in their target > routines. Why not move it to __cpufreq_d

Re: [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur

On Friday, October 26, 2012 03:06:26 PM Viresh Kumar wrote: > Avoid calling cpufreq driver's target() routine if new frequency is same as > policies current frequency. > > Signed-off-by: Viresh Kumar Looks reasonable. Any objection from anyone? Rafael > --- > drivers/cpufreq/cpufreq.c | 4 +

[PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur

Avoid calling cpufreq driver's target() routine if new frequency is same as policies current frequency. Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 261ef65..28dc134 1

Re: [PATCH 0/4][V2] cpuidle : multiple drivers support

On Thu, Oct 25, 2012 at 10:29:43PM +0200, Rafael J. Wysocki wrote: > On Thursday, October 25, 2012 04:49:33 PM Peter De Schrijver wrote: > > On Fri, Oct 19, 2012 at 12:10:45PM +0200, Daniel Lezcano wrote: > > > The discussion about having different cpus on the system with > > > different latencies

Re: [U-Boot] [PATCH v2] EXYNOS: Clock: Add common function for pll rate calculation

On 15 October 2012 20:58, Chander Kashyap wrote: > From: Minkyu Kang > > Moved the common code to calculate pll clock rate to new function > exynos_get_pll_clk(). > > Signed-off-by: Chander Kashyap > --- > Changes from v1: > - Author name changed > arch/arm/cpu/armv7/exynos/clock.c | 1

Re: [U-Boot] [PATCH v3] ARCH: EXYNOS: add support to match product id

On 15 October 2012 22:06, Chander Kashyap wrote: > From: Minkyu Kang > > Based upon single SoC there can be multiple variants. > This patch add support to match the complete product ID. > > Signed-off-by: Chander Kashyap > --- > Changes from v1: > - Author name changed > Changes from v2:

[PATCH V2 4/6] Thermal: Remove the cooling_cpufreq_list.

From: "hongbo.zhang" Problem of using this list is that the cpufreq_get_max_state callback will be called when register cooling device by thermal_cooling_device_register, but this list isn't ready at this moment. What's more, there is no need to maintain such a list, we can get cpufreq_cooling_de