---
> Arnd Bergmann (2):
> cpufreq: SPEAr needs cpufreq table
> cpufreq: big.LITTLE needs cpufreq table
>
> Ezequiel Garcia (1):
> cpufreq: kirkwood: Select CPU_FREQ_TABLE option
>
> drivers/cpufreq/Kconfig.arm | 3 +++
> 1 file ch
On Friday, June 07, 2013 04:35:24 PM Viresh Kumar wrote:
> On 7 June 2013 16:41, Rafael J. Wysocki wrote:
> > On Friday, June 07, 2013 04:26:36 PM Viresh Kumar wrote:
>
> >> cpufreq: bit.LITTLE needs cpufreq table
> >
> > That should be big.LITTLE I suppose
> 1 file changed, 3 insertions(+)
>
> --
> Viresh
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Friday, February 22, 2013 07:47:44 AM Viresh Kumar wrote:
> On 22 February 2013 05:15, Rafael J. Wysocki wrote:
> > Why did you change all of the lines of this macro instead of changing just
> > the
> > one line you needed to change?
>
> I didn't like the i
On Friday, February 22, 2013 07:44:23 AM Viresh Kumar wrote:
> On 22 February 2013 05:23, Rafael J. Wysocki wrote:
> > On Monday, February 11, 2013 01:20:02 PM Viresh Kumar wrote:
>
> >> +config CPU_FREQ_HAVE_MULTIPLE_POLICIES
> >> + bool
> >> +
>
On Friday, February 22, 2013 07:38:12 AM Viresh Kumar wrote:
> On 22 February 2013 05:05, Rafael J. Wysocki wrote:
> > On Monday, February 11, 2013 01:20:00 PM Viresh Kumar wrote:
>
> >> This patch is inclined towards providing this infrastructure. Because we
> >>
else
> +#endif
> return cpufreq_global_kobject;
-> I wonder why don't you arrange things so that policy->kobj is always
returned, but it points to cpufreq_global_kobject in case there's only one
(i.e. make policy->kobj a pointer)?
> }
Thanks,
Rafa
t attribute *attr, char *buf);
> - ssize_t (*store)(struct kobject *a, struct attribute *b,
> - const char *c, size_t count);
> -};
> -
> -#define define_one_global_ro(_name) \
> -static struct global_attr _name =\
> -__ATTR(_name, 0444, show_##_name,
gt; old, u_int div, u_int mu
> * CPUFREQ GOVERNORS*
> */
>
> -#define CPUFREQ_GOV_START 1
> -#define CPUFREQ_GOV_STOP 2
> -#define CPUFR
On Saturday, February 09, 2013 07:40:26 AM Viresh Kumar wrote:
> On 9 February 2013 05:38, Dirk Brandewie wrote:
> > On 02/08/2013 03:56 PM, Rafael J. Wysocki wrote:
> >>
> >> On Friday, February 08, 2013 09:02:37 PM Rafael J. Wysocki wrote:
> >>>
> &g
On Friday, February 08, 2013 04:08:49 PM Dirk Brandewie wrote:
> On 02/08/2013 03:56 PM, Rafael J. Wysocki wrote:
> > On Friday, February 08, 2013 09:02:37 PM Rafael J. Wysocki wrote:
> >> On Friday, February 08, 2013 08:06:52 PM Viresh Kumar wrote:
> >>> On 8
On Friday, February 08, 2013 09:02:37 PM Rafael J. Wysocki wrote:
> On Friday, February 08, 2013 08:06:52 PM Viresh Kumar wrote:
> > On 8 February 2013 18:02, Rafael J. Wysocki wrote:
> > > So as I said, please rework the fixes on top of linux-pm.git/pm-cpufreq.
> >
&
On Friday, February 08, 2013 08:06:52 PM Viresh Kumar wrote:
> On 8 February 2013 18:02, Rafael J. Wysocki wrote:
> > So as I said, please rework the fixes on top of linux-pm.git/pm-cpufreq.
>
> I already did. Please check for-rafael branch
Cool. This is the one I'm sup
On Friday, February 08, 2013 08:20:55 AM Viresh Kumar wrote:
> On 8 February 2013 05:03, Rafael J. Wysocki wrote:
> > I should have done that before, sorry about it.
> >
> > Can you please rework this series on top of linux-pm.git/pm-cpufreq and
> > try to avoid intro
On Friday, February 08, 2013 12:33:14 AM Rafael J. Wysocki wrote:
> On Thursday, February 07, 2013 03:57:42 PM Viresh Kumar wrote:
> > Hi Rafael,
> >
> > This is another unplanned patchset for all the platforms that i broke. :)
> >
> > Okay, there are two import
ase rework this series on top of linux-pm.git/pm-cpufreq and
try to avoid introducing new issues this time?
If this works, we'll rebase all of the other new material on top of it,
if possible.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Thursday, February 07, 2013 06:52:20 PM Viresh Kumar wrote:
> On 7 February 2013 18:35, Rafael J. Wysocki wrote:
> > I think they all make sense, so applied to linux-next.
> >
> > I would prefer not to make any more changes to cpufreq before v3.9 from now
> > o
ld prefer not to make any more changes to cpufreq before v3.9 from now on,
except for fixes and maybe the Drik's patchset that I kind of scheduled for
merging into bleeding-edge later today.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
> @Rafael: ??
You may do that, if you want, but that's slightly confusing.
Also the policy is that material which is not going to be included into v3.9
shouldn't be in linux-next before v3.9-rc1.
Moreover, for build testing it is sufficient to put it into a branch somewhere
at g
On Tuesday, February 05, 2013 02:58:35 PM Nathan Zimmer wrote:
> Ok, I'll rebase and retest from linux-next then.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
li
On Tuesday, February 05, 2013 03:28:30 PM Viresh Kumar wrote:
> On Tue, Feb 5, 2013 at 3:33 PM, Rafael J. Wysocki wrote:
> > I actually don't agree with that, becuase the Nathan's apprach shows the
> > reasoning that leads to the RCU introduction quite clearly. So if you
On Tuesday, February 05, 2013 01:58:20 PM Viresh Kumar wrote:
> On Tue, Feb 5, 2013 at 6:37 AM, Rafael J. Wysocki wrote:
> > On Monday, February 04, 2013 04:45:11 PM Nathan Zimmer wrote:
> >> I am noticing the cpufreq_driver_lock is quite hot.
> >> On an idle 512 syste
it 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.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-d
ch attached with this change.
OK, thanks!
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ge branch of my tree and see if there's anything missing
or something that shouldn't be there (cpufreq-wise).
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
l have to go after 3.9-rc1 or be
postponed until the 3.10 merge window.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ou plan to do
> > > further cleanup work on this code.
> > >
> > > /me tries to also keep that ->cpu field in mind.
> >
> > You can make it part of your patchsets v8.
>
> I'm not sending a v8 as Rafael already asked for incremental, but I'll
&
y this
> one so I agree on dropping mine.
>
> Rafael, this is screwing up a bit on bisection for cpu hotplug problems
> so I'm sending a v7 with the cleanup on first patch and this one
> dropped if you are ok with rebasing your pm-cpufreq-next. Let me know
> if you prefer me to just send a revert + cleanup patch instead.
I've dropped the $subject one already and please post an incremental fix on
top of the first one in your series.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tuesday, January 29, 2013 08:00:23 PM Viresh Kumar wrote:
> On 29 January 2013 17:21, Rafael J. Wysocki wrote:
> > On Tuesday, January 29, 2013 10:09:59 AM Viresh Kumar wrote:
> >> With the addition of following patch, related_cpus is required to be set by
> >&g
()
> routines, as the same work is done by core too.
>
> If platform driver needs to set the related_cpus mask with some additional
> cpus,
> other than cpus present in policy->cpus, they are free to do it as we aren't
> overriding anything.
>
> Signed-o
3:23:04 2013 +
>
> cpufreq: Simplify cpufreq_add_dev()
>
I've dropped this one in the meantime.
Can you please fold the $subject patch into "cpufreq: Simplify
cpufreq_add_dev()"
and post the result instead? That surely will be less confusing?
Rafael
--
I speak only for my
-
> drivers/cpufreq/cpufreq_stats.c | 27 +++-
> drivers/cpufreq/freq_table.c| 9 ++
> include/linux/cpufreq.h | 14 +-
> 4 files changed, 178 insertions(+), 188 deletions(-)
>
>
--
I speak o
online. We aren't
> + * managing offline cpus here.
> + */
> + cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
> +
> policy->user_policy.min = policy->min;
> policy->user_policy.max = policy->max;
>
>
--
I speak on
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
On Friday, January 04, 2013 10:44:36 AM Viresh Kumar wrote:
> On 3 January 2013 17:32, Rafael J. Wysocki wrote:
> > True, but have those bugs been introduced recently (ie. in v3.8-rc1 or
> > later)?
>
> Don't know... I feel they were always there, its just that n
On Thursday, January 03, 2013 09:02:22 AM Viresh Kumar wrote:
> On 3 January 2013 06:43, Rafael J. Wysocki wrote:
> >> BTW, i consider them as fixes and so would make sense to get them in next
> >> rc.
> >> What do you think?
> >
> > Yes, if somebody
On Wednesday, January 02, 2013 11:59:57 AM Viresh Kumar wrote:
> On 16 December 2012 19:07, Viresh Kumar wrote:
> > On 16 December 2012 18:34, Rafael J. Wysocki wrote:
>
> >> Well, this series makes sense to me, but I'd like to hear what the other
> >> peo
e, which are online. We aren't
> + * managing offline cpus here.
> + */
> + cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
> +
> policy->user_policy.min = policy->min;
> policy->user_policy.max = policy->max;
>
&g
data->last_state_idx = i;
> > data->exit_us = s->exit_latency;
> > break;
> > }
> > }
>
> Actually I was planning to do that in a separate patch.
Can you submit that second patch too, please, so that people don't h
---
> > drivers/cpuidle/cpuidle.c| 17 -
> > drivers/cpuidle/driver.c | 25 -
> > drivers/cpuidle/governors/menu.c |8 ++--
> > include/linux/cpuidle.h |2 +-
> > 4 files changed, 7 insertions(+
r;
> - s64 usec_delta;
> int cpu = smp_processor_id();
>
> cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
> @@ -297,8 +295,6 @@ static int intel_idle(struct cpuidle_device *dev,
> if (!(lapic_timer_reliable_states & (1 << (cstate
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
>
> - kt_before = ktime_get_real();
> -
> stop_critical_timings();
> if (!need_resched()) {
>
> @@ -310,17 +306,9 @@ static int intel_idle(struct cpuidle_device *dev,
>
> start_critical_timings();
>
> - kt_after = ktime_get_real();
> - usec_delta = ktime_to_us(ktime_sub(kt_after, kt_before));
> -
> - local_irq_enable();
> -
> if (!(lapic_timer_reliable_states & (1 << (cstate
> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
>
> - /* Update cpuidle counters */
> - dev->last_residency = (int)usec_delta;
> -
> return index;
> }
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ktime_t kt_before, kt_after;
> - s64 usec_delta;
> int cpu = smp_processor_id();
>
> cstate = (((eax) >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
> @@ -297,8 +295,6 @@ static int intel_idle(struct cpuidle_device *dev,
> if (!(lapic_timer_reli
+--
> drivers/cpuidle/sysfs.c | 174 --
> include/linux/cpuidle.h |8 ++-
> 6 files changed, 388 insertions(+), 52 deletions(-)
All patches in the series applied to the linux-next branch of the linux-pm.git
tree a
le_state_usage *state_usage;
> - struct completion kobj_unregister;
> - struct kobject kobj;
> -};
> -
> struct cpuidle_device {
> unsigned intregistered:1;
> unsigned intenabled:1;
--
I speak only for myself.
Rafael J. Wysocki, Intel Open So
On Friday, October 26, 2012 01:17:12 PM Rafael J. Wysocki wrote:
> 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: Vir
cy->min)
> + target_freq = policy->min;
> +
> + pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> + policy->cpu, target_freq, relation, old_target_freq);
>
> if (target_freq == policy->cur)
>
t; index ed87399..860a686 100644
> --- a/drivers/cpuidle/sysfs.c
> +++ b/drivers/cpuidle/sysfs.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "cpuidle.h"
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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
q);
> if (cpu_online(policy->cpu) && cpufreq_driver->target)
> retval = cpufreq_driver->target(policy, target_freq, relation);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
_online(policy->cpu) && cpufreq_driver->target)
> retval = cpufreq_driver->target(policy, target_freq, relation);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thursday, October 25, 2012 08:59:11 AM Viresh Kumar wrote:
> On 25 October 2012 02:42, Rafael J. Wysocki wrote:
> > On Wednesday 24 of October 2012 21:43:46 Rafael J. Wysocki wrote:
> >> On Wednesday 24 of October 2012 11:37:13 Viresh Kumar wrote:
> >> > On 22 Oc
On Thursday, October 25, 2012 09:00:22 AM Viresh Kumar wrote:
> On 25 October 2012 02:44, Rafael J. Wysocki wrote:
> > On Wednesday 24 of October 2012 13:15:58 Viresh Kumar wrote:
> >> There were few sparse warnings due to mismatch of type on function
> >> arguments.
&
return retval;
> - }
> - acpi_processor_registered++;
> + acpi_processor_setup_cpuidle_cx(pr, dev);
> +
> + /* Register per-cpu cpuidle_device. Cpuidle driver
> + * must already be registered before registering device
> + */
> + retval = cpuidle_register_device(dev);
> + if (retval) {
> + if (acpi_processor_registered == 0)
> + cpuidle_unregister_driver(&acpi_idle_driver);
> + return retval;
> }
> +
> + acpi_processor_registered++;
> +
> return 0;
> }
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
cx(pr);
> + acpi_processor_setup_cpuidle_cx(pr, dev);
>
> /* Register per-cpu cpuidle_device. Cpuidle driver
>* must already be registered before registering device
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
t; -
> #include
> #include
> -#include
>
> #define PREFIX "ACPI: "
> ACPI_MODULE_NAME("processor_idle");
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
AD 1 /* 1us */
> -#define PM_TIMER_TICKS_TO_US(p) (((p) *
> 1000)/(PM_TIMER_FREQUENCY/1000))
>
> static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
> module_param(max_cstate, uint, );
>
--
I speak only for myself.
Rafael J.
ested on ARM Dual Cortex-A9 U8500 (aka Snowball)
> >
> > V1 tested on Tegra3 and Vexpress TC2
> >
>
> V2 tested on Tegra3.
Do I assume correctly that Tested-by applies?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Saturday 20 of October 2012 10:12:07 Viresh Kumar wrote:
> On Oct 20, 2012 3:37 AM, "Rafael J. Wysocki" wrote:
> >
> > On Saturday 20 of October 2012 01:42:05 Viresh Kumar wrote:
> > > There is no need to do cpufreq_get_cpu() and cpufreq_put_cpu() for
> dr
drivers/cpufreq/cpufreq_userspace.c
> +++ b/drivers/cpufreq/cpufreq_userspace.c
> @@ -11,6 +11,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include
> #include
> #include
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cp
FREQ_STAT_DETAILS
> unsigned int *trans_table;
> @@ -223,7 +223,7 @@ static int cpufreq_stats_create_table(struct
> cpufreq_policy *policy,
> count++;
> }
>
> - alloc_size = count * sizeof(int) + count * sizeof(cputime64_t);
> + allo
On Wednesday 24 of October 2012 21:43:46 Rafael J. Wysocki wrote:
> On Wednesday 24 of October 2012 11:37:13 Viresh Kumar wrote:
> > On 22 October 2012 14:16, Viresh Kumar wrote:
> > > On 20 October 2012 01:42, Viresh Kumar wrote:
> > >> Initially ondemand governor
> For everybody else, this patch is already pushed by Rafael in his linux-next
> branch.
Well, not yet, although I'm going to do that.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
f71 viresh kumar 2012-10-23 50return idle_time;
> > 83a73f71 viresh kumar 2012-10-23 51 }
> > 83a73f71 viresh kumar 2012-10-23 52 EXPORT_SYMBOL_GPL(get_cpu_idle_time);
> >
> > ---
> > 0-DAY kernel build testing backend Open Source Technology Center
&
icy = cpufreq_cpu_get(policy->cpu);
> if (!policy)
> return -EINVAL;
>
> - if (cpu_online(cpu) && cpufreq_driver->getavg)
> - ret = cpufreq_driver->getavg(policy, cpu);
> + ret = cpufreq_driver->getavg(policy, cpu);
t; -
> struct cpuidle_device {
> unsigned intregistered:1;
> unsigned intenabled:1;
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
cpuidle_device *device)
> +{
> + return cpuidle_add_state_sysfs(device);
> +}
> +
> +/**
> + * cpuidle_remove_device_sysfs : removes device specific sysfs attributes
> + * @device : the target device
> + */
> +void cpuidle_remove_device_sysfs(struct cpuidle_device *device)
> +{
>
te;
> @@ -413,6 +413,8 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
> struct device *cpu_dev = get_cpu_device((unsigned long)dev->cpu);
> int error;
>
> + init_completion(&dev->kobj_unregister);
> +
> error = kobject_init_and_add(&dev->kobj, &ktype_cpuidle, &am
puidle");
> if (!error)
> @@ -426,11 +424,7 @@ int cpuidle_add_sysfs(struct device *cpu_dev)
> * cpuidle_remove_sysfs - deletes a sysfs instance on the target device
> * @dev: the target device
> */
> -void cpuidle_remove_sysfs(struct device *cpu_dev)
> +void cpuidle_remove_sysfs(struct cpuidle_device *dev)
> {
> - int cpu = cpu_dev->id;
> - struct cpuidle_device *dev;
> -
> - dev = per_cpu(cpuidle_devices, cpu);
> kobject_put(&dev->kobj);
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tuesday 16 of October 2012 06:40:19 MyungJoo Ham wrote:
> > On Monday 08 of October 2012 10:48:24 MyungJoo Ham wrote:
> > > > On 8 October 2012 03:31, Rafael J. Wysocki wrote:
> > > > > On Thursday 04 of October 2012 14:58:33 Rajagopal Venkat wrote:
> >
On Tuesday 16 of October 2012 09:09:15 Viresh Kumar wrote:
> On 15 October 2012 23:21, Rafael J. Wysocki wrote:
> > On Wednesday 10 of October 2012 10:12:11 Viresh Kumar wrote:
> >> Arrays for governer and driver name are of size CPUFREQ_NAME_LEN or 16.
> >> i.e.
On Monday 08 of October 2012 10:48:24 MyungJoo Ham wrote:
> > On 8 October 2012 03:31, Rafael J. Wysocki wrote:
> > > On Thursday 04 of October 2012 14:58:33 Rajagopal Venkat wrote:
> > >> Add devfreq suspend/resume apis for devfreq users. This patch
> > >>
+= sprintf(&buf[i], "\n");
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index b60f6ba..fc4b785 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -22,6 +22,8 @@
> #include
>
> #define CPUFREQ_NAME_LEN 16
>
; static ssize_t show_bios_limit(struct cpufreq_policy *policy, char *buf)
> {
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wednesday 03 of October 2012 21:38:09 Vincent Guittot wrote:
> On Wednesday, 3 October 2012, Paul E. McKenney
> wrote:
> > On Tue, Oct 02, 2012 at 04:02:05AM +0200, Rafael J. Wysocki wrote:
> >> On Monday 01 of October 2012 15:42:39 Vincent Guittot wrote:
> >> &
On Thursday 11 of October 2012 12:04:37 Daniel Lezcano wrote:
> On 10/07/2012 11:26 PM, Rafael J. Wysocki wrote:
> > On Tuesday 25 of September 2012 00:43:54 Daniel Lezcano wrote:
> >> With the tegra3 and the big.LITTLE [1] new architectures, several cpus
> >> wit
ivers/devfreq/governor.h| 11 +
> >> drivers/devfreq/governor_performance.c| 16 +-
> >> drivers/devfreq/governor_powersave.c | 16 +-
> >> drivers/devfreq/governor_simpleondemand.c | 24 ++
> >> drivers/devfreq/governor_userspace.c
> }
>
> +static int devfreq_suspend_device(struct devfreq *devfreq)
> +{
> + return 0;
> +}
> +
> +static int devfreq_resume_device(struct devfreq *devfreq)
> +{
> + return 0;
> +}
> +
> static struct opp *devfreq_recommended_opp(struct device *dev,
> unsigned long *freq, u32 flags)
> {
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
j)
> goto error_state;
> @@ -374,7 +399,8 @@ int cpuidle_add_state_sysfs(struct cpuidle_device *device)
> kobj->state_usage = &device->states_usage[i];
> init_completion(&kobj->kobj_unregister);
>
> - ret = kobject_init_and_add(&kobj->kobj, &ktype_state_cpuidle,
> &device->kobj,
> + ret = kobject_init_and_add(&kobj->kobj,
> +&ktype_state_cpuidle, &device->kobj,
> "state%d", i);
> if (ret) {
> kfree(kobj);
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index a4ff9f8..0e0b0ad 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -164,6 +164,13 @@ extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
> struct cpuidle_driver *drv, int index));
> extern int cpuidle_play_dead(void);
>
> +extern int cpuidle_for_each_driver(
> + int (*cb)(int, struct cpuidle_driver *, void *), void *data);
> +
> +extern struct cpuidle_driver *cpuidle_get_cpu_driver(int cpu);
> +extern int cpuidle_register_cpu_driver(struct cpuidle_driver *drv, int cpu);
> +extern void cpuidle_unregister_cpu_driver(struct cpuidle_driver *drv, int
> cpu);
> +
> #else
> static inline void disable_cpuidle(void) { }
> static inline int cpuidle_idle_call(void) { return -ENODEV; }
> @@ -190,7 +197,6 @@ static inline int cpuidle_wrap_enter(struct
> cpuidle_device *dev,
> struct cpuidle_driver *drv, int index))
> { return -ENODEV; }
> static inline int cpuidle_play_dead(void) {return -ENODEV; }
> -
> #endif
>
> #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
> Sounds like a reasonable idea.
>
> > and the content of the file:
> >
> > /sys/devices/system/cpu/cpuidle/current_driver will show the driver
> > associated with current cpu ?
> >
>
> I think that's ok.
Yes, that sounds good.
Thanks,
Rafae
t > 0))
> cpuidle_curr_driver = NULL;
> -
> +out:
> spin_unlock(&cpuidle_driver_lock);
> }
> EXPORT_SYMBOL_GPL(cpuidle_unregister_driver);
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tuesday 02 of October 2012 14:27:17 Daniel Lezcano wrote:
> On 10/02/2012 04:08 AM, Rafael J. Wysocki wrote:
> > On Sunday 30 of September 2012 18:34:31 Daniel Lezcano wrote:
> >> On 09/30/2012 12:07 AM, Rafael J. Wysocki wrote:
> >>> On Saturday, September
On Sunday 30 of September 2012 18:34:31 Daniel Lezcano wrote:
> On 09/30/2012 12:07 AM, Rafael J. Wysocki wrote:
> > On Saturday, September 29, 2012, Daniel Lezcano wrote:
> >> On 09/29/2012 11:41 AM, Francesco Lavra wrote:
> >>> Hi,
> >> Hi Francesco,
&
On Monday 01 of October 2012 15:42:39 Vincent Guittot wrote:
> Hi Rafael,
>
> Ping.
I'm considering this for v3.8, but I'd like Paul (CCed) to tell me what he
thinks about it.
Thanks,
Rafael
> On 25 September 2012 15:42, Vincent Guittot
> wrote:
> > synchronize_rcu blocks the caller of opp_e
On Monday 01 of October 2012 15:42:39 Vincent Guittot wrote:
> Hi Rafael,
>
> Ping.
I'm considering this for v3.8, but I'd like Paul (CCed) to tell me what he
thinks about it.
Thanks,
Rafael
> On 25 September 2012 15:42, Vincent Guittot
> wrote:
> > synchronize_rcu blocks the caller of opp_e
On Saturday, September 29, 2012, Daniel Lezcano wrote:
> On 09/29/2012 11:41 AM, Francesco Lavra wrote:
> > Hi,
>
> Hi Francesco,
>
> thanks for reviewing the patch.
>
> >> static ssize_t show_current_driver(struct device *dev,
> >> struct device_attribute *attr,
>
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
On Wednesday, September 19, 2012, Daniel Lezcano wrote:
> This mindless patch is just about removing some trailing
> carriage returns.
>
> Signed-off-by: Daniel Lezcano
Applied.
Thanks,
Rafael
> ---
> drivers/cpuidle/driver.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
On Wednesday, September 19, 2012, Daniel Lezcano wrote:
> Clarify the purpose of the function by changing its name and
> move the condition out of this function.
Why exactly are you removing the condition?
Rafael
> Signed-off-by: Daniel Lezcano
> ---
> drivers/cpuidle/driver.c | 15
On Wednesday, September 19, 2012, Daniel Lezcano wrote:
> These two functions are never used.
This is not the case. pm_genpd_attach_cpuidle() and
pm_genpd_detach_cpuidle() use them.
Please be more careful.
Thanks,
Rafael
> Signed-off-by: Daniel Lezcano
> ---
> drivers/cpuidle/driver.c | 2
On Tuesday, September 18, 2012, Lorenzo Pieralisi wrote:
> On Mon, Sep 17, 2012 at 10:35:00PM +0100, Daniel Lezcano wrote:
> > On 09/17/2012 10:50 PM, Rafael J. Wysocki wrote:
> > > On Monday, September 17, 2012, Daniel Lezcano wrote:
> > >> On 09/08/2012 12:
On Monday, September 17, 2012, Daniel Lezcano wrote:
> On 09/17/2012 10:50 PM, Rafael J. Wysocki wrote:
> > On Monday, September 17, 2012, Daniel Lezcano wrote:
> >> On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote:
> >>> On Friday, September 07, 2012, Daniel Lezc
On Monday, September 17, 2012, Daniel Lezcano wrote:
> On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote:
> > On Friday, September 07, 2012, Daniel Lezcano wrote:
> >> Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab,
> >> cpuidle: Single/Global registration
On Monday, September 17, 2012, MyungJoo Ham wrote:
> > From: Rajagopal Venkat
> >
> > 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
> > cu
On Sunday, September 16, 2012, Daniel Lezcano wrote:
> On 09/07/2012 11:50 PM, Rafael J. Wysocki wrote:
> > On Friday, September 07, 2012, Daniel Lezcano wrote:
> >> The cpuidle core takes care of filling this field from drv->state_count.
> >
> > I'm not qu
On Friday, September 14, 2012, Daniel Lezcano wrote:
> The 'device' parameter is not used neither in acpi_processor_power_init
> and acpi_processor_power_exit. This patch removes it.
>
> Signed-off-by: Daniel Lezcano
Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
Th
On Friday, September 14, 2012, Daniel Lezcano wrote:
> The 'errata' variable is a global variable which is set to zero,
> no need to do that with a memset in the init function.
>
> Signed-off-by: Daniel Lezcano
Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
Thanks,
On Friday, September 14, 2012, Daniel Lezcano wrote:
> Currently we have the cpuidle_device field in the acpi_processor_power
> structure.
> This adds a dependency between processor.h and cpuidle.h
>
> Although it is not a real problem, removing this dependency has the benefit of
> separating a b
On Tuesday, September 11, 2012, Daniel Lezcano wrote:
> On 09/08/2012 12:06 AM, Rafael J. Wysocki wrote:
> > On Friday, September 07, 2012, Rafael J. Wysocki wrote:
> >> On Friday, September 07, 2012, Rafael J. Wysocki wrote:
> >>> On Friday, September
On Tuesday, September 11, 2012, Daniel Lezcano wrote:
> On 09/07/2012 11:19 PM, Rafael J. Wysocki wrote:
> > On Friday, September 07, 2012, Daniel Lezcano wrote:
> >> This variable is only used in the in processor_driver.c.
> >> This patch reduces the scope of the va
On Monday, September 10, 2012, Rajagopal Venkat wrote:
> On 10 September 2012 03:16, Rafael J. Wysocki wrote:
> > On Monday, September 03, 2012, Rajagopal Venkat wrote:
> >> Prepare devfreq core framework to support devices which
> >> can idle. When device idleness
1 - 100 of 128 matches
Mail list logo
