27 August 2013 23:04, Stratos Karafotis wrote:
> I'm sorry. Let me try to explain this better.
Don't be :)
> With my patch, dbs_info->requested_freq will not be capped within
> policy->min and policy->max in cs_check_cpu.
> So, temporarily it may have a value greater than policy->max
> or lower
op the unnecessary duplicate check in *_check_cpu functions.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/cpufreq_conservative.c | 4
> drivers/cpufreq/cpufreq_ondemand.c | 3 ---
> 2 files changed, 7 deletions(-)
Acked-by: Viresh Kumar
--
To unsub
rnor_enabled)
> + return;
> +
> if (!all_cpus) {
> __gov_queue_work(smp_processor_id(), dbs_data, delay);
> } else {
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On 28 August 2013 02:50, Rafael J. Wysocki wrote:
> On Tuesday, August 27, 2013 10:04:52 PM Lan Tianyu wrote:
>> From my understanding.policy->min/max may be modified by some drivers
>> but the user_policy only store user space config and should not be changed
>> by other reason. :)
>
> Yes, tha
On 28 August 2013 03:31, Stephen Boyd wrote:
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> index b9b20fd..523af48 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -137,7 +137,7 @@ void gov_queue_work(str
dition
The problem probably is poor error checking which is still present at
few places, in __cpufreq_set_policy() routine..
Can you try after fixing them? Something similar has to be done..
commit 3de9bdeb28638e164d1f0eb38dd68e3f5d2ac95c
Author: Viresh Kumar
Date: Tue Aug 6 22:53:13 2013
(worker_thread+0x200/0x344)
> [] (worker_thread+0x200/0x344) from [] (kthread+0xa0/0xb0)
> [] (kthread+0xa0/0xb0) from [] (ret_from_fork+0x14/0x3c)
>
> Signed-off-by: Stephen Boyd
> ---
> drivers/cpufreq/cpufreq_governor.c | 9 -
> 1 file changed, 8 insertions(+),
On Mon, Aug 26, 2013 at 6:23 PM, Pavel Machek wrote:
> Hi!
>
>> I am reading LKML offline (mostly on ).
>> Did you send out an announcement for Linux v3.11-rc7 or am I missing
>> sth.?
>
> I don't think it hit the mailing list. (Either that, or list
> unsubscribed me, again).
No you aren't.. Even
On 29 August 2013 13:26, Sedat Dilek wrote:
> What people write on their personal whatever accounts is not of my interest.
> I never gave someone a Like/Dislike or +/- as I am not subscribed to
> such online services.
>
> The Linux v3.11-rc7 announcement belongs to LKML.
> ( Yes, I am reading anno
On 28 August 2013 22:22, Stephen Boyd wrote:
> On 08/27/13 23:58, Viresh Kumar wrote:
>> I haven't gone through the hack yet, but I am trying to understand the
>> problem first.. There had been some work in the past around this
>> kind o
On 29 August 2013 14:07, Viresh Kumar wrote:
> On 28 August 2013 22:22, Stephen Boyd wrote:
>> On 08/27/13 23:58, Viresh Kumar wrote:
>>> I haven't gone through the hack yet, but I am trying to understand the
>>> problem first.. There had been some work in
Hi,
I have been doing some CPUFreq cleanup work and
wanted to know if the below mentioned machines have separate
clock domains for their CPUs or all share the same domain?
So, that we can use some generic routines for these drivers which
would eventually do:
cpumask_setall(policy->cpus);
And I
On 29 August 2013 15:53, Sekhar Nori wrote:
> On DaVinci (DA850), there is an async domain available to keep some
> peripheral clocks insulated from cpu frequency changes. But there are a
> bunch of other clocks which do get affected by CPU frequency change
> (they need to run at a fixed ratio to
On 29 August 2013 15:57, Sekhar Nori wrote:
> I get it now. All DaVinci devices are UP only.
Thanks..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30 September 2013 23:58, Rafael J. Wysocki wrote:
> On Monday, September 16, 2013 08:40:17 PM Viresh Kumar wrote:
>> lock_policy_rwsem_{read|write}() currently has return type of int but it
>> always
>> return zero and hence its return type must be void instead. Thi
On 2 October 2013 22:08, Rafael J. Wysocki wrote:
> On Wednesday, October 02, 2013 02:13:36 PM Viresh Kumar wrote:
>> On 30 September 2013 23:58, Rafael J. Wysocki wrote:
>> > On Monday, September 16, 2013 08:40:17 PM Viresh Kumar wrote:
>> >> lock_policy_rwse
On 28 September 2013 17:38, Sachin Kamat wrote:
> The data structure of_match_ptr() protects is always compiled in.
of_match_ptr() isn't a data structure.. And also what does "protects" mean here?
> Hence of_match_ptr() is not needed.
>
> Signed-off-by: Sachi
On 1 October 2013 00:07, Daniel Lezcano wrote:
> Interesting, thanks for the pointer.
So, should I keep this patch with SRCU?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
calxeda,highbank"))
> + if ((!of_machine_is_compatible("calxeda,highbank")) &&
> + (!of_machine_is_compatible("calxeda,ecx-2000")))
> return -ENODEV;
>
> cpu_dev = get_cpu_device(0);
Acked-by: Viresh Kumar
--
To unsubscribe from this lis
On 26 September 2013 00:07, Rafael J. Wysocki wrote:
> So the problem is real, but the fix seems to be of a "quick and dirty" kind.
Hmm..
> First of all, it looks like we need a clear "begin transition" call that
> I suppose drivers should execute from their .target() methods once they have
> de
On 3 October 2013 12:36, Sachin Kamat wrote:
> On 3 October 2013 10:07, Viresh Kumar wrote:
>> On 28 September 2013 17:38, Sachin Kamat wrote:
>>> The data structure of_match_ptr() protects is always compiled in.
>>
>> of_match_ptr() isn't a data structure..
On 28 September 2013 17:38, Sachin Kamat wrote:
> The data structure of_match_ptr() protects is always compiled in.
> Hence of_match_ptr() is not needed.
>
> Signed-off-by: Sachin Kamat
> Cc: Viresh Kumar
> ---
> drivers/pinctrl/spear/pinctrl-plgpio.c |2 +-
> 1 f
On 3 October 2013 12:40, Sachin Kamat wrote:
> Do you really want a new one. If so, please let me know how you would
> like this to be re-worded. I have already used this for others and
> thought it was clear enough :)
Ahh.. misread your subject and then your reply :)..
--
To unsubscribe from thi
On 26 September 2013 13:58, Daniel Lezcano wrote:
> Yes, certainly and that will impact also the menu select governor function:
>
> ...
>
> /*
> * We want to default to C1 (hlt), not to busy polling
> * unless the timer is happening really really soon.
> */
>
On 26 September 2013 13:50, Daniel Lezcano wrote:
> Rafael is pretty busy ATM but may be he can give his feedback on this later.
For now I will resend it and maybe later you can get it cleaned up even more..
Or maybe I will do it once I have better hold on cpuidle core :)
Can I have your Ack for
Hi Rafael,
These are V2 of my CPUIdle cleanup series.. Few patches are dropped as they
required further modifications. Last one is rewritten as suggested by Daniel.
Most of them are already Acked by Daniel.
Viresh Kumar (16):
cpuidle: fix indentation of cpumask
cpuidle: Fix comments in
__cpuidle_driver_init() doesn't return anything except zero and so doesn't
really need a return type other than void.
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/driver.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/cpuidle/driver.c
Few comments in cpuidle core files have trivial mistakes. This patch fixes them.
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/coupled.c | 2 +-
drivers/cpuidle/cpuidle.c | 2 +-
drivers/cpuidle/driver.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers
__cpuidle_device_init() doesn't return anything except zero and so doesn't
really need a return type other than void.
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/cpuidle.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drive
cpumask is indented using spaces instead of tabs. Fix it.
Signed-off-by: Viresh Kumar
---
include/linux/cpuidle.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 781addc..c082425 100644
--- a/include/linux/cpuidle.h
This patch rearranges __cpuidle_register_device() a bit in order to reduce the
number of exit points of this function.
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/cpuidle.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers
Few statements in cpuidle_idle_call() are broken into multiple lines, whereas
they can actually come in a single line. Convert those to single line.
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/cpuidle.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers
Both return same error message and so better write them in a single line.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/cpuidle.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index
Instances of "struct cpuidle_driver *" are consistently named as "drv" in
cpuidle core. Its broken only at one place: show_current_driver().
Fix it for consistency.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/sysfs.c | 8
1 file c
cpuidle_driver_lock is taken correctly at most of the places but at few places
calls to cpuidle_get_driver() are done from outside of this lock.
Fix them by calling cpuidle_get_driver() after taking cpuidle_driver_lock.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle
This is trivial patch that just reorders few statements in
__cpuidle_driver_init() routine, so that we don't need both 'continue' and
'break' in the for loop. Functionally it shouldn't change anything.
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/driver.c | 10
rom
__cpuidle_register_driver() so that it is initialized only once.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/cpuidle.c | 41 -
drivers/cpuidle/driver.c | 42 ++
2 files changed, 42 inserti
cpuidle_unregister_governor() and cpuidle_replace_governor() routines aren't
used anymore and so can be removed. These were used by cpufreq governors
earlier, which can't be compiled in as modules anymore and so these are useless.
Suggested-by: Daniel Lezcano
Signed-off-by: Vi
Loop for states is currently present on callers side and so is replicated at
several places. It would be better to move that inside cpuidle_free_state_kobj()
instead.
This patch does it.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/sysfs.c | 23
If entered_state < 0, we don't need to set dev->last_residency to 'diff' as we
will be setting it to zero without using its new value.
And so move calculation of diff also inside the "if" statement.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
ompiler wasn't able to optimize it earlier)
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/cpuidle.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 518b542..ffc637a 100644
--- a/dri
__cpuidle_get_cpu_driver() is a single line function and so deserves to be
marked inline.
Acked-by: Daniel Lezcano
Signed-off-by: Viresh Kumar
---
drivers/cpuidle/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
gt; extern struct cpufreq_frequency_table sa11x0_freq_table[];
Ahh... sorry!! Below diff fixes it..
@Rafael: Please merge the attached fixup patch with $SUBJECT patch.
--x--x---
commit d2e1eb969ebdb66e3cc199fbbbe2e2a1a8e2960b
Author: Viresh Kumar
Date: Fri Oct 4 10:48:16 201
On 4 October 2013 02:37, Kevin Hilman wrote:
> I gave these a spin on OMAP3 and both full-chip retention and off-mode
> during idle are still working fine.
>
> Tested-by: Kevin Hilman
Thanks a lot !!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On 8 July 2013 21:07, Uwe Kleine-König wrote:
> This patch set hit my tree now. I wonder if it makes sense to make
> WQ_POWER_EFFICIENT_DEFAULT depend on SMP. (Oh wait, big.LITTLE isn't
> SMP, so probably there is a better symbol to depend on?)
Well, big LITTLE still runs an SMP kernel :) and so
On 8 July 2013 21:27, Uwe Kleine-König wrote:
> On Mon, Jul 08, 2013 at 09:17:01PM +0530, Viresh Kumar wrote:
>> Well, big LITTLE still runs an SMP kernel :) and so has this flag set.
> The 'S' is justified because cpu0 and cpu1 are of the same type? Are
> there b.L s
On 5 July 2013 14:16, Chanwoo Choi wrote:
> Second, previous performance/powersave governor haven't calculated CPUs load
> becuase these governor didn't change CPU frequency according to CPUs load.
> But,
> load_table debugfs file always should indicate the collected CPUs data
> regardless
> of
On 9 July 2013 12:32, Lukasz Majewski wrote:
> On Thu, 04 Jul 2013 10:50:23 +0200, Lukasz Majewski wrote:
>
> Dear Viresh, Rafael
>
> Do you have any comments/feedback for me regarding those patches?
I am busy in Linaro connect this week, but will see if I can get
some time to go over these.
--
T
On 9 July 2013 13:27, Chanwoo Choi wrote:
> So, I'd like you to review patch1,patch2, patch6. If you with that I resend
> patch1/2/6,
> I will resend new patchset incluing in patch1/2/6.
Yeah, I will do that only. Don't resend anything for now.
--
To unsubscribe from this list: send the line "un
On 5 July 2013 14:16, Chanwoo Choi wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> +/* The cpufreq_debugfs is used to create debugfs root directory for CPUFreq.
> */
> +#define MAX_DEBUGFS_NAME_LEN CPUFREQ_NAME_LEN
Why declare MAX_DEBUGFS_NAME_LEN if it is going
On 10 July 2013 09:42, Michael Wang wrote:
> I'm not sure what is supposed after notify CPUFREQ_GOV_STOP event, if it
> is in order to stop queued work and prevent follow work happen again,
> then it failed to, and we need some method to stop queue work again when
> CPUFREQ_GOV_STOP notified, like
On 10 July 2013 11:34, Michael Wang wrote:
> Thanks for the confirm :) seems like the root cause is very likely
> related with the problem Srivatsa discovered.
>
> I think the fix in his mail worth a try, but I need more investigations
> to confirm that's the right way...
Its not a fix really, bu
always fail.
>
> Fix by moving the clk_set_rate() after the table initialization.
> Tested on Lemote FuLoong mini-PC.
>
> Signed-off-by: Aaro Koskinen
> Cc: sta...@vger.kernel.org
> ---
> drivers/cpufreq/loongson2_cpufreq.c | 11 ++-
> 1 file changed, 6 insertio
On 12 July 2013 03:45, Srivatsa S. Bhat
wrote:
> The call to cpufreq_update_policy() is placed in the CPU hotplug callback
> of cpufreq_stats, which has a higher priority than the CPU hotplug callback
> of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up
> calling cpufreq_
*policy;
> +
> + policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
sizeof(*policy) ??
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ter suspend/resume" already reverted part of the
> original set of changes. So revert only the remaining ones).
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq.c |4 +++-
> drivers/cpufreq/cpufreq_stats.c |
rivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq.c | 43 ++-
> 1 file changed, 26 insertions(+), 17 deletions(-)
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
helper function. This helps in upcoming code reorganization.
>
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq.c | 62
> -
> 1 file changed, 38 insertions(+), 24 deletions(-)
Acked-by: Viresh Kumar
--
To
p
> distinguish the full init/teardown sequence from the light-weight one.
>
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq.c | 66
> -
> 1 file changed, 41 insertions(+), 25 deletions(-)
Acked-by: Vir
On 14 September 2013 03:17, David Miller wrote:
> From: Viresh Kumar
> Date: Fri, 13 Sep 2013 18:29:18 +0530
>
>> This exposes frequency table of driver to cpufreq core and is required for
>> core
>> to guess what the index for a target
On 14 September 2013 04:22, Stephen Warren wrote:
> I wonder if this series is bisectable? Perhaps I should just go and read
> the rest of the series, but I presume there's a patch somewhere else
> that adds those two cpufreq_notify_transition() to the cpufreq core.
> Either that happens before th
On 14 September 2013 05:12, Rafael J. Wysocki wrote:
> On Friday, September 13, 2013 06:29:37 PM Viresh Kumar wrote:
>> This has been running in my mind since few days... That we have fixed cpufreq
>> core and all other drivers for transition serialization but what about
>&g
On 14 September 2013 05:18, Rafael J. Wysocki wrote:
> OK, I'll think about that, but not today and probably not within the next
> few days, because I'm heading to New Orleans in several hours and really
> have other stuff to take care of now. Sorry about that.
No issues..
--
To unsubscribe from
On 14 September 2013 05:08, Rafael J. Wysocki wrote:
> On Friday, September 13, 2013 06:29:06 PM Viresh Kumar wrote:
>> This is my biggest patchset ever and it might not happen again in my entire
>> career. I hope I haven't screwed up here :)
>>
>> CPUFreq cleanu
On 15 September 2013 10:35, Rafael J. Wysocki wrote:
> Well, I guess you can assume that everyone has a chance to review the series
> by now and send it as one patch in the next iteration.
Yeah, that's what I thought..
> A patch that adds 192 lines of code isn't shockingly large by any measure.
lock_policy_rwsem_{read|write}() currently has return type of int but it always
return zero and hence its return type must be void instead. This patch makes its
return type void and fixes all users of it as well.
Reported-by: Jon Medhurst
Signed-off-by: Viresh Kumar
---
drivers/cpufreq
licy_cpu(), the
unlock_policy_rwsem_write() will release the incorrect lock.
The right solution would be to take rwsem lock/unlock for both old and new cpu.
This patch fixes this bug by taking both locks directly instead of calling
lock_policy_rwsem_write().
Reported-by: Jon Medhurst
Signed-off-by
On 16 September 2013 21:57, Jon Medhurst (Tixy) wrote:
> If I take mainline code and just change the line above to:
You meant this line by above line?
unlock_policy_rwsem_write(cpu);
>up_write(&per_cpu(cpu_policy_rwsem, (per_cpu(cpufreq_cpu_data,
> cpu))->last_cpu));
> then the big
On 17 September 2013 00:04, Rafael J. Wysocki wrote:
> Care to resend with a subject indicating that that's a patch update?
>
> Like [PATCH v2] etc. or similar?
Yeah.. I was waiting for Tixy to test it once..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On 17 September 2013 00:12, Jon Medhurst (Tixy) wrote:
> The commit log to that patch still mentions taking both locks.
Yeah, it was sent in hurry to just give you a working solution and I forgot
to see the log if it is still valid.
> The code itself fixes the lockdep errors I had, so
>
> Tested
licy_cpu().
Reported-and-Tested-by: Jon Medhurst
Signed-off-by: Viresh Kumar
---
Hi Rafael,
Only one patch is sent now as other one is unchanged.
drivers/cpufreq/cpufreq.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/c
ile we are changing policy->cpu, etc.
Suggested-by: Srivatsa S. Bhat
Signed-off-by: Viresh Kumar
---
Can be taken for 3.13.. Tested on my thinkpad with basic suspend/resume and
hotplug tests.
Was rebased on pm/linux-next with following additional patches:
cpufreq: unlock correct rwsem while up
On 17 September 2013 20:50, Stephen Warren wrote:
> On 09/11/2013 11:25 PM, Viresh Kumar wrote:
>> This broke after a recent change "cedb70a cpufreq: Split
>> __cpufreq_remove_dev()
>> into two parts" from Srivatsa..
>>
>> Consider a scenario where we h
On 17 September 2013 21:48, Viresh Kumar wrote:
> On 17 September 2013 20:50, Stephen Warren wrote:
> Yes, I have asked Rafael to get this in for rc2 and few others too..
> Waiting for his reply though..
Its applied now by Rafael..
--
To unsubscribe from this list: send the line &qu
On 18 September 2013 12:39, Srivatsa S. Bhat
wrote:
> On 09/17/2013 09:20 PM, Viresh Kumar wrote:
> The code looks good, but the patch doesn't apply properly, because of the code
> change that went in in your patch "cpufreq: Clear policy->cpus bits in
> __cpufreq_r
r take over before, it would return
> EBUSY, then udev will keep trying...
>
> cpufreq_register_driver should return EEXIST instead.
> then system could boot without appending intel_pstate=disable
> and still use intel_pstate.
>
> Signed-off-by: Yinghai Lu
Acked-by: Viresh
On 19 September 2013 18:28, Srivatsa S. Bhat
wrote:
> On 09/19/2013 06:25 PM, Linus Walleij wrote:
>> The problem is not what it returns, the system seems to survive no matter
>> whether it returns 0 or 17 or whatever.
>>
>
> Of course. What I intended to say was that I don't recall recent kernel
On 19 September 2013 23:41, Srivatsa S. Bhat
wrote:
> But there was no code to set the per-cpu values to -1 to begin with. Since
> the per-cpu variable was defined as static, it would have been initialized
> to zero. Thus, we would never actually hit the BUG_ON() condition, since
> policy_cpu didn
On 20 September 2013 07:01, Yinghai Lu wrote:
> Sorry, looks like this one is not enough.
>
> please let me know if you prefer me send addon patch
> or revised one.
Atleast you can let us know what the problem is? And then we
can decide on that.. But anyway, you can send a new patch
based over l
On 20 September 2013 10:56, Yinghai Lu wrote:
> If the hw support intel_pstate and acpi_cpufreq, intel_pstate will
> get loaded at first.
s/at //
>
> acpi_cpufreq_init will call acpi_cpufreq_early_init()
> and it allocate perf data and init those perf data in ACPI core, (that
s/it /that will /
alloc(sizeof(*new_opp),+} GFP_KERNEL);
It is almost impossible to catch these with naked eyes for such long
patches.. I took help of --word-diff though :)
If no one else sees these as problems then feel free to add my:
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubsc
On 20 September 2013 14:03, Linus Walleij wrote:
> I suspect this hunk from the patch may be the cause:
>
> + if (cpufreq_driver) {
> + /* get the CPU */
> + policy = per_cpu(cpufreq_cpu_data, cpu);
> + if (policy)
> + kobject_g
On 20 September 2013 14:11, Linus Walleij wrote:
> Any other idea why this patch is causing the issue?
I went into looking that patch in more detail
after my first reply, not as if I ran away from answering that :)
Probably yes.. I know what's causing it:
unsigned int cpufreq_get(unsigned int
On 20 September 2013 14:19, Viresh Kumar wrote:
> Hmm... Remember I told you last time that I have another way of fixing
> it up, probably we need that now..
>
> I wanted to add another variable to reflect if a cpufreq_driver is registered
> or not, and if not then return e
On 20 September 2013 20:46, Srivatsa S. Bhat
wrote:
> I think show() and store() also suffer
> from a similar fate. So do you think we need to add these checks there as
> well?
> I'm not sure, since I can't think of a situation in which show() or store()
> can be invoked before the cpufreq-driver
On 20 September 2013 18:08, Nishanth Menon wrote:
> I am open to suggestions if any one feels we can improve this better.
I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp**
though..
> I believe that change was from Patch #2[1]
Yeah.. I just replied on a single patch :)
>
lock_policy_rwsem_read() might hit BUG_ON(!policy).
Reported-and-Tested-by: Linus Walleij
Signed-off-by: Viresh Kumar
---
For 3.12.
drivers/cpufreq/cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 82ecbe3..db004a8 100644
--- a
On 20 September 2013 22:04, Linus Walleij wrote:
> In this case we have neither. So the cpufreq driver fails to
> register. But the kernel used to survive in any case, as you
> could call cpufreq_get() without a cpufreq driver registered.
Aha, so exactly what I suspected in my first mail..
--
To
On 20 September 2013 21:09, Linus Walleij wrote:
> On Fri, Sep 20, 2013 at 11:35 AM, Viresh Kumar
> wrote:
>
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1460,6 +1460,9 @@ unsigned int cpufreq_get(unsigned int cpu)
>> {
>> unsigned int ret_freq = 0;
&
Back finally and I see lots of mails over cpufreq stuff.. :)
On 3 September 2013 18:50, Srivatsa S. Bhat
wrote:
> This doesn't solve the problem completely: it prevents the store_*() task
> from continuing *only* when it concurrently executes the __cpufreq_governor()
> function along with the CPU
On 7 September 2013 01:23, Srivatsa S. Bhat
wrote:
> Commit "cpufreq: serialize calls to __cpufreq_governor()" had been a temporary
> and partial solution to the race condition between writing to a cpufreq sysfs
> file and taking a CPU offline. Now that we have a proper and complete solution
> to
le
> for me to reply to the original thread, instead have to start a new one.
>
> Commit
>
> commit dceff5ce18801dddc220d6238628619c93bc3cb6
> Author: Viresh Kumar
> Date: Sun Sep 1 22:19:37 2013 +0530
>
> cpufreq: fix serialization issues with freq change notifier
On 10 September 2013 17:19, Rafael J. Wysocki wrote:
> That said I'm actually unsure what problems *exactly* are fixed by commit
> 7c30ed5. The commit log only says that PRECHANGE or POSTCHAGE shouldn't be
> called twice in a row, but it doesn't say why. As the fallout indicates,
> that actually
On 10 September 2013 20:42, Guennadi Liakhovetski wrote:
> 4. reverted that commit, resolving a trivial conflict. Added a debug
> output in __cpufreq_driver_target() of
>
>
> if (cpufreq_disabled())
> return -ENODEV;
> + pr_info("%s() %d\n", __func__, policy->transiti
On 10 September 2013 20:14, wrote:
> From: Lan Tianyu
>
> The cpufreq_set_policy() has been removed by commit 632786c. So remove
> related comment.
> ---
> drivers/cpufreq/cpufreq.c | 4
> 1 file changed, 4 deletions(-)
I have got another patch that takes care of this while fixing other i
On 10 September 2013 21:52, Guennadi Liakhovetski wrote:
> Of course, isn't that what I've written above? reverted a commit and added
> debug - in that order.
Ok, I misread it then :(
> Sure, I can... So, with the performance governor I get
>
> [1.29] cpufreq-cpu0 cpufreq-cpu0: Looking u
That is some important piece of information that might be useful for
others and so cc'ing LKML and other lists..
On 11 September 2013 01:06, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 02:16:03 PM Lukasz Majewski wrote:
>> For my curiosity - what is the difference between bleeding-e
On 10 September 2013 22:37, Guennadi Liakhovetski wrote:
> On Tue, 10 Sep 2013, Viresh Kumar wrote:
>> Quite straight forward actually..
>
> Apparently, not quite.
I overlooked the situation where we return early from ->target() routines.. :(
Please try attached patches,
On 11 September 2013 01:16, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 08:44:18 PM Viresh Kumar wrote:
>> Now Second question, is this fine to have multiple PRECHANGE notfications
>> before any POSTCHANGE notification?
>>
>> Logically it looks obvio
On 11 September 2013 13:45, Guennadi Liakhovetski wrote:
> I'd rather wait until Rafael is convinced, then we'll see.
Okay.. I have just sent a mail to Rafael about that, see if you
are convinced with what I wrote :)
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
401 - 500 of 9140 matches
Mail list logo
