This patch fixes the following compiler warning of uninitialized
variable:
drivers/base/regmap/regmap-debugfs.c: In function ‘regmap_read_debugfs’:
drivers/base/regmap/regmap-debugfs.c:180:9: warning: ‘ret’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Stratos
updated.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.h | 2 +-
drivers/cpufreq/cpufreq_ondemand.c | 16 ++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index
Fix some typos in comments.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_ondemand.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 09b27ae..f3eb26c 100644
--- a
Fix a couple of typos in comments.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufreq/cpufreq_conservative.c
index e8bb915..4fd0006 100644
This patch removes the unused variable 'c' in mwait_play_dead and fixes
the following warning:
arch/x86/kernel/smpboot.c: In function ‘mwait_play_dead’:
arch/x86/kernel/smpboot.c:1370:22: warning:
unused variable ‘c’ [-Wunused-variable]
Signed-off-by: Stratos Karafotis
---
arch/
On 04/02/2013 04:50 PM, Rafael J. Wysocki wrote:
> Do you have any numbers indicating that this actually makes things better?
>
> Rafael
No, I don't.
The expected behaviour after this patch is to "force" max frequency few
sampling periods earlier.
The idea was to increase system responsiveness e
On 04/03/2013 02:14 PM, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 12:13:56 PM Viresh Kumar wrote:
>> On 3 April 2013 12:01, stratosk wrote:
>>> I'm sorry, I don't understand.
>>> The goal of this patch is not energy saving.
>>
>> He probably misunderstood it...
>>
>>> The goal is to
: Stratos Karafotis
---
drivers/base/regmap/regcache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index d81f605..a469748 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -590,7
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
> Hi Stratos,
>
> Yes, your results show some improvements. BUT if performance is the only thing
> we were looking for, then we will never use ondemand governor but performance
> governor.
>
> I suspect this little increase in performance mu
This patch restructures code for better readability and easier
maintenance.
Also introduces lowmemorykiller.h header file.
Signed-off-by: Stratos Karafotis
---
drivers/staging/android/lowmemorykiller.c | 162 ++
drivers/staging/android/lowmemorykiller.h | 42
On 02/01/2013 12:25 AM, Greg Kroah-Hartman wrote:
Given that no one is working on it, why does it need to be maintained
easier? :)
Thanks for your immediate response.
I was thinking to work on this driver. Is it going to be obsolete or
something?
Why create a .h file? Who needs it? Only
Fix the following build warnings
sound/pci/hda/patch_sigmatel.c: In function ‘stac92hd71bxx_fixup_hp’:
sound/pci/hda/patch_sigmatel.c:2434:24: warning: unused variable ‘spec’
[-Wunused-variable]
Signed-off-by: Stratos Karafotis
---
sound/pci/hda/patch_sigmatel.c | 14 +-
1 file
:1752:6: note: ‘vlan’ was declared here
Signed-off-by: Stratos Karafotis
---
drivers/infiniband/hw/mlx4/qp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 19e0637..37829b6 100644
--- a/drivers/infiniband
. We use a parameter in
function get_cpu_idle_time to distinguish when the iowait time will be
added to idle time or not, without the need of keeping the prev_io_wait.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 2 +-
drivers/cpufreq/cpufreq_governor.c | 46
s_busy, we re-calculate iowait time
and we subtract it from idle time.
With this patch iowait time is calculated only when necessary avoiding
the double call to get_cpu_iowait_time_us. We use a parameter in
function get_cpu_idle_time to distinguish when the iowait time will be
added to idle time
Fix the following compiler warning (also a checkpatch error):
net/ipv6/xfrm6_mode_tunnel.c: In function ‘xfrm6_mode_tunnel_input’:
net/ipv6/xfrm6_mode_tunnel.c:72:2: warning: suggest parentheses around
assignment used as truth value [-Wparentheses]
Signed-off-by: Stratos Karafotis
---
net/ipv6
: controls the final up_threshold
- grad_up_threshold: over this gradient of load we will decrease
up_threshold by early_differential.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 1 +
drivers/cpufreq/cpufreq_governor.h | 4
drivers/cpufreq
lculate the gradient of load_freq. If it is
too steep we assume that the load most probably will go over
up_threshold in next iteration(s) and we increase frequency immediately.
New tuners are introduced:
- early_demand: to enable this functionality (disabled by default).
- grad_up_threshold: over this
steep we assume that the load most probably will go over
up_threshold in next iteration(s) and we increase frequency immediately.
New tuners are introduced:
- early_demand: to enable this functionality (disabled by default).
- grad_up_threshold: over this gradient of load we will increase
frequ
off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 4
drivers/cpufreq/cpufreq_ondemand.c | 3 ---
2 files changed, 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufreq/cpufreq_conservative.c
index 7f67a75..f62d822 100644
--- a/drivers/c
- 'Governer' should be 'Governor'
- 'S' is used for Siemens (electrical conductance) in SI units.
Use small 's' for seconds.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 2 +-
drivers/cpufreq/cpufreq_governor.h | 12 ++---
On 08/27/2013 08:57 AM, Viresh Kumar wrote:
> On 27 August 2013 00:07, Stratos Karafotis wrote:
>> drivers/cpufreq/cpufreq_conservative.c | 4
>
> Get rid of few more checks..
>
> /* if we are already at full speed then break out early */
> if (dbs_info->re
On 08/27/2013 07:07 PM, Viresh Kumar wrote:
On 27 August 2013 21:16, Stratos Karafotis wrote:
I think we should keep these checks because:
1) They shorten the execution code (there is no unnecessary call of
__cpufreq_driver_target)
I don't really count this one.. This is how code is pr
On 04/10/2013 06:22 AM, Viresh Kumar wrote:
On 9 April 2013 22:26, Stratos Karafotis wrote:
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the only
thing
Hi Rafael,
On 06/11/2013 02:24 AM, Rafael J. Wysocki wrote:
> On Tuesday, June 11, 2013 12:57:26 AM Stratos Karafotis wrote:
>> On 06/09/2013 11:58 PM, Rafael J. Wysocki wrote:
>>> Well, this means that your changes may hurt performance if the load comes
>>> and
>&
On 06/14/2013 12:40 AM, Borislav Petkov wrote:
> On Fri, Jun 14, 2013 at 12:22:18AM +0300, Stratos Karafotis wrote:
>> Please let me share some more test results using aim9 benchmark suite:
>> https://docs.google.com/spreadsheet/ccc?key=0AnMfNYUV1k0ddDdGdlJyUHpqT2xGY1lBOEt2UEVn
Hi,
On 06/14/2013 03:55 PM, Rafael J. Wysocki wrote:
> On Friday, June 14, 2013 02:44:01 PM Borislav Petkov wrote:
>> On Fri, Jun 14, 2013 at 02:46:38PM +0200, Rafael J. Wysocki wrote:
>>> OK, so here's a deal. After 3.10-rc1 goes out, I'll put this into
>>> linux-next
>>
>> Yeah, you mean 3.11-rc
On 06/04/2013 08:19 AM, Viresh Kumar wrote:
On 4 June 2013 01:18, Stratos Karafotis wrote:
Calculation of frequency target in ondemand governor changed and it is
s/frequency target/target frequency
I will change it also in 3/3 that I use the same.
independent from measured average
On 06/03/2013 11:38 PM, David C Niemi wrote:
>
> Interesting analysis; I just got back from vacation and have not had a chance
> to comment until now.
>
> I like Stratos' general idea of making the decision to upshift or downshift
> independent of current frequency, as it makes thinks simpler a
I think you are right. I will reorder 2/3 and 3/3 with the change you suggested.
Thanks,
Stratos
Viresh Kumar wrote:
>On 4 June 2013 20:36, Stratos Karafotis wrote:
>> On 06/04/2013 08:19 AM, Viresh Kumar wrote:
>>> Should this be done in 3/3 ?
>>>
>>
>>
Calculation of target frequency in ondemand governor changed and it is
independent from measured average frequency.
Remove unused__cpufreq_driver_getavg function and getavg member from
cpufreq_driver struct.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq.c | 12
Changes since v2:
- Reorder patches 2/3 and 3/3
- Fix typos in patch changelog
Changes since v1:
- Use policy->cpuinfo.max_freq in the calculation formula
of target frequency instead of policy->max
- Split the patch into 3 parts
Stratos Kar
Calculation of target frequency in ondemand governor changed and it is
independent from measured average frequency.
Remove unused APERF/MPERF support.
Signed-off-by: Stratos Karafotis
---
arch/x86/include/asm/processor.h | 29 ---
drivers/cpufreq/Makefile | 2
ies were used less by ~9%
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 10 +-
drivers/cpufreq/cpufreq_governor.h | 1 -
drivers/cpufreq/cpufreq_ondemand.c | 39 +++---
3 files changed, 8 insertions(+), 42 deletions(-)
diff --gi
Hi Borislav,
On 06/05/2013 07:17 PM, Borislav Petkov wrote:
On Wed, Jun 05, 2013 at 07:01:25PM +0300, Stratos Karafotis wrote:
Ondemand calculates load in terms of frequency and increases it only
if the load_freq is greater than up_threshold multiplied by current
or average frequency. This
Fix the following compiler warning:
fs/ext4/inode.c: In function ‘ext4_da_writepages’:
fs/ext4/inode.c:2212:6: warning: ‘err’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
fs/ext4/inode.c:2155:6: note: ‘err’ was declared here
Signed-off-by: Stratos Karafotis
---
fs/ext4
Hi Rafael,
I will try to provide the requested info (although, I'm not sure how to measure
total energy :) )
Thanks,
Stratos
"Rafael J. Wysocki" wrote:
>On Wednesday, June 05, 2013 08:13:26 PM Stratos Karafotis wrote:
>> Hi Borislav,
>>
>> On 06/05/
Thanks Viresh. I think I couldn't explain this in better way.
Also thanks for acknowledgment!
Stratos
Viresh Kumar wrote:
>On 6 June 2013 15:31, Borislav Petkov wrote:
>
>> Hold on, you say above "easily saturate minimum frequency and lead the
>> CPU to max". I read this as we jump straight to
gt; of platforms/vendors if possible, please.
>
> Thanks.
>
On 06/06/2013 04:15 PM, Borislav Petkov wrote:> Please do not top-post.
>
> On Thu, Jun 06, 2013 at 03:54:20PM +0300, Stratos Karafotis wrote:
>> I will try to provide the requested info (although, I'm not sure
On 06/06/2013 08:11 PM, Borislav Petkov wrote:
On Thu, Jun 06, 2013 at 07:46:17PM +0300, Stratos Karafotis wrote:
Apologies for top-posting. I was able to send email only from my phone.
Thanks for you hint about turbostat.
As you most probably understood, I'm individual amateur k
On 05/28/2013 11:54 PM, Rafael J. Wysocki wrote:
> On Tuesday, May 28, 2013 08:03:19 PM Stratos Karafotis wrote:
>> I mean any value of freq table. Please let me know if you want me to rephrase
>> it in description.
>
> Yes, it would be nice to be more precise.
OK sure, I wi
On 05/30/2013 01:29 AM, Rafael J. Wysocki wrote:
On Wednesday, May 29, 2013 06:15:56 PM Stratos Karafotis wrote:
On 05/28/2013 11:54 PM, Rafael J. Wysocki wrote:
On Tuesday, May 28, 2013 08:03:19 PM Stratos Karafotis wrote:
I mean any value of freq table. Please let me know if you want me to
used less by ~9%
Signed-off-by: Stratos Karafotis
---
arch/x86/include/asm/processor.h | 29 --
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 5
drivers/cpufreq/cpufreq.c | 21
drivers/cpufreq
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>> ---
>> arch/x86/include/asm/processor.h | 29 --
>> drivers/cpufreq/Makefile | 2 +-
>> drivers/cpufreq/acpi-cpufreq.c | 5
>> drivers/cpufreq/cpufreq.c | 21
>> drivers/cpufreq
On 06/01/2013 03:27 PM, Rafael J. Wysocki wrote:
> On Friday, May 31, 2013 07:33:06 PM Stratos Karafotis wrote:
>> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>>>> ---
>>>>arch/x86/include/asm/processor.h | 29 --
>>>&g
On 06/01/2013 05:56 PM, Viresh Kumar wrote:
> On 31 May 2013 22:03, Stratos Karafotis wrote:
>> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>>> I believe you should have removed other users of getavg() in a separate
>>> patch and also cc'd relevant people so t
On 06/03/2013 02:24 PM, Viresh Kumar wrote:
> On 3 June 2013 16:27, Rafael J. Wysocki wrote:
>> The question is if we want policy->max to re-scale them effectively (i.e. to
>> change weights so that the maximum load maps to the highest frequency
>> available
>> at the moment) or if we want policy
ies were used less by ~9%
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 10 +-
drivers/cpufreq/cpufreq_governor.h | 1 -
drivers/cpufreq/cpufreq_ondemand.c | 39 +++---
3 files changed, 8 insertions(+), 42 deletions(-)
diff --gi
Changes since v1:
Use policy->cpuinfo.max_freq in the calculation formula
of target frequency instead of policy->max
Split the patch into 3 parts
Stratos Karafotis (3):
cpufreq: ondemand: Change the calculation of target frequency
cpufreq: Remove
Calculation of frequency target in ondemand governor changed and it is
independent from measured average frequency.
Remove unused__cpufreq_driver_getavg function and getavg member from
cpufreq_driver struct. Also, remove the callback getavg in
acpi_cpufreq_driver.
Signed-off-by: Stratos
Calculation of frequency target in ondemand governor changed and it is
independent from measured average frequency.
Remove unused APERF/MPERF support.
Signed-off-by: Stratos Karafotis
---
arch/x86/include/asm/processor.h | 29 ---
drivers/cpufreq/mperf.c | 51
On 06/05/2013 11:35 PM, Rafael J. Wysocki wrote:
> On Wednesday, June 05, 2013 08:13:26 PM Stratos Karafotis wrote:
>> Hi Borislav,
>>
>> On 06/05/2013 07:17 PM, Borislav Petkov wrote:
>>> On Wed, Jun 05, 2013 at 07:01:25PM +0300, Stratos Karafotis wrote:
>>>
On 06/07/2013 11:57 PM, Rafael J. Wysocki wrote:
> On Friday, June 07, 2013 10:14:34 PM Stratos Karafotis wrote:
>> On 06/05/2013 11:35 PM, Rafael J. Wysocki wrote:
>>> On Wednesday, June 05, 2013 08:13:26 PM Stratos Karafotis wrote:
>>>> Hi Borislav,
>>>
consumption.
I will also send the results running the test as you said.
Thanks again,
Stratos
"Rafael J. Wysocki" wrote:
>On Saturday, June 08, 2013 12:56:00 PM Stratos Karafotis wrote:
>> On 06/07/2013 11:57 PM, Rafael J. Wysocki wrote:
>> > On Friday, June
On 06/08/2013 05:05 PM, Rafael J. Wysocki wrote:
> On Saturday, June 08, 2013 03:34:29 PM Stratos Karafotis wrote:
>> I also did the test with the way you mentioned. But I thought to run
>> turbostat for 100 sec as I did with powertop.
>
> Ah, OK.
>
>> Actually
On 06/09/2013 07:26 PM, Borislav Petkov wrote:
> On Sun, Jun 09, 2013 at 12:18:09AM +0200, Rafael J. Wysocki wrote:
>> The average power drawn by the package is slightly higher with the
>> patchset applied (27.66 W vs 27.25 W), but since the time needed to
>> complete the workload with the patchset
On 06/09/2013 11:58 PM, Rafael J. Wysocki wrote:
> Well, this means that your changes may hurt performance if the load comes and
> goes in spikes, which is not so good. The fact that they cause less energy to
> be used at the same time kind of balance that, though. [After all, we're
> talking abo
On 03/22/2013 01:54 AM, Rafael J. Wysocki wrote:
>
> Applied to linux-pm.git/bleeding-edge and will be moved to linux-next if there
> are no build problems in the bleeding-edge branch.
>
> Thanks,
> Rafael
Hi Rafael,
I just noticed a regression with this patch with the calculation of wall time
With commit 8755a8ae31ba213db196324011a0da2a85807f25 the wall in
get_cpu_idle_time is not calculated, when we use ondemand with
io_is_busy = 1, preventing the CPU to increase to max frequency.
Properly, calculate wall time when we use io_is_busy.
Signed-off-by: Stratos Karafotis
---
drivers
-8<---
Use an inline function to evaluate freq_target to avoid duplicate code.
Also, define a macro for the default frequency step.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 28
1
On 08/18/2013 08:04 PM, Oleg Nesterov wrote:
> Sorry for double post. forgot to cc cpufreq maintainers.
>
> On 08/16, Frederic Weisbecker wrote:
>>
>> To fix this, lets only update the sleeptime stats locally when the CPU
>> exits from idle.
>
> I am in no position to ack the changes in this area
On 08/22/2013 10:59 AM, Takashi Iwai wrote:
> At Thu, 22 Aug 2013 00:42:41 +0300,
> Stratos Karafotis wrote:
>>
>> Hi,
>>
>> I get the following oops during boot when build with
>> CONFIG_SND_DYNAMIC_MINORS
>> not set (3.11-rc6).
>>
On 08/23/2013 12:23 AM, Takashi Iwai wrote:
> At Thu, 22 Aug 2013 19:03:44 +0300,
> Stratos Karafotis wrote:
>>
>> On 08/22/2013 10:59 AM, Takashi Iwai wrote:
>>> At Thu, 22 Aug 2013 00:42:41 +0300,
>>> Stratos Karafotis wrote:
>>>>
>>>
sampling_down_factor tunable is unused since commit
8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago).
This patch restores the original functionality.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a
Hi Viresh,
On 03/05/2013 02:23 AM, Viresh Kumar wrote:> Interesting. Because it was
removed earlier and no body complained :)
>
> I got following from Documentation:
>
> sampling_down_factor: this parameter controls the rate at which the
> kernel makes a decision on when to decrease the frequen
On 03/05/2013 09:34 AM, Viresh Kumar wrote:
On 5 March 2013 13:22, Stratos Karafotis wrote:
I misread it here when i looked at this mail for the first time. :)
I strongly believe that we need a full stop (.) before "Every sampling_rate",
otherwise it looks like we check for down_fa
Hi David,
On 03/05/2013 04:21 PM, David C Niemi wrote:
I should clarify -- I wrote the sampling_down_factor in the *ondemand*
governor. I chose the name of the parameter based on the vaguely similar
parameter in the conservative governor, but the documentation that was
referenced (about it o
sampling_down_factor tunable is unused since commit
8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago).
This patch restores the original functionality and documents the
tunable.
Signed-off-by: Stratos Karafotis
---
Documentation/cpu-freq/governors.txt | 6 ++
drivers/cpufreq
When we evaluate the CPU load for frequency decrease we have to compare
the load against down_threshold. There is no need to subtract 10 points
from down_threshold.
Instead, we have to use the default down_threshold or user's selection
unmodified.
Signed-off-by: Stratos Karafotis
---
dr
Use an inline function to evaluate freq_target to avoid duplicate code.
Also, define a macro for the default frequency step and fix the
calculation of freq_target when the max freq is less that 100.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 27
I'm sorry for this confusion.
Below v2 of this patch.
Thanks,
Stratos
8<
Use an inline function to evaluate freq_target to avoid duplicate code.
Also, define a macro for the default frequency step.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufre
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the only thing
we were looking for, then we will never use ondemand governor but performance
governor.
I suspect
declared
here
Signed-off-by: Stratos Karafotis
---
drivers/md/dm-raid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 1d3fe1a..8041de8 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -380,7 +380,7 @@ static int
On 04/09/2013 07:56 PM, Stratos Karafotis wrote:
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the
only thing
we were looking for, then we will never use
attached with and without this patch. cpufreq_stats (time_in_state) are
also included. Tested on Intel i7-3770 CPU @ 3.40GH and on
Quad core 1500 MHz Krait.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 10 +-
drivers/cpufreq/cpufreq_governor.h | 1 -
drivers
ore 1500MHz Krait.
Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an
increase 1.5% to performance. cpufreq_stats (time_in_state) shows
that middle frequencies are used more, with this patch. Highest
and lowest frequencies were used less by ~9%
Signed-off-by: Stratos Karafotis
On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> On 21 February 2013 23:09, Stratos Karafotis wrote:
>
>> Signed-off-by: Stratos Karafotis
>
> Acked-by: Viresh Kumar
>
Hi Rafael,
In case you are interested in this patch I rebased it to the latest
linux-pm/bleeding-e
On 03/06/2013 09:35 PM, David C Niemi wrote:
> The "10" sounds like an attempt to add some hysteresis to the up/down
> decisionmaking. If you take it out, you should make sure you don't get into
> situations where you're continually switching rapidly between two
> frequencies. (In the ondemand
> On 6 March 2013 22:15, Stratos Karafotis wrote:
>> Use an inline function to evaluate freq_target to avoid duplicate code.
>>
>> Also, define a macro for the default frequency step.
>>
>> Signed-off-by: Stratos Karafotis
>> ---
>>
On Mon, Sep 19, 2016 at 7:16 PM, Andreas Herrmann wrote:
> On Fri, Sep 16, 2016 at 09:58:42PM +0300, Stratos Karafotis wrote:
>> Hi,
>>
>> [ I 'm resending this message, because I think some recipients didn't receive
>> it. ]
>>
>> On 16/09/2016 1
Remove 3 sets of unnecessary braces
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1eafd8c..ca3c01f 100644
--- a/drivers/cpufreq/cpufreq.c
Fix 2 checkpatch errors about using assignment in if condition,
1 checkpatch error about a required space after comma
and 3 warnings about line over 80 characters.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq.c | 23 ---
1 file changed, 12 insertions(+), 11
On 20/03/2014 12:45 πμ, Rafael J. Wysocki wrote:
> On Wednesday, March 19, 2014 11:33:00 PM Stratos Karafotis wrote:
>> Remove 3 sets of unnecessary braces
>>
>> Signed-off-by: Stratos Karafotis
>> ---
>> drivers/cpufreq/cpufreq.c | 11 ---
>> 1 fil
On Fri, Nov 8, 2013 at 6:55 AM, Viresh Kumar wrote:
> On 8 November 2013 00:36, Stratos Karafotis wrote:
>> I think the existing code already checks if the requested_freq is greater
>> than policy->max in __cpufreq_driver_target.
>
> Yes it does. But the problem is:
On Fri, Nov 8, 2013 at 8:16 PM, Viresh Kumar wrote:
> On 8 November 2013 23:13, Stratos Karafotis wrote:
>> Please let me rephrase my previous post. In some circumstances (depending
>> on freq_step and freq_table values) CPU frequency will never reach to
>> policy->max.
&
After commit dfa5bb622555d9da0df21b50f46ebdeef390041b
"cpufreq: ondemand: Change the calculation of target frequency",
this return statement is no longer needed.
Reported-by: Henrik Nilsson
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_ondemand.c | 1 -
1 file
On 11/01/2013 02:18 AM, Rafael J. Wysocki wrote:
On Friday, November 01, 2013 12:09:16 AM Viresh Kumar wrote:
On 31 October 2013 23:57, Stratos Karafotis wrote:
After commit dfa5bb622555d9da0df21b50f46ebdeef390041b
"cpufreq: ondemand: Change the calculation of target frequency",
t
On 21/07/2014 12:51 πμ, Pavel Machek wrote:
> Hi!
>
>> Tested on Intel i7-3770 CPU @ 3.40GHz and on ARM quad core 1500MHz Krait
>> (Android smartphone).
>> Benchmarks on Intel i7 shows a performance improvement on low and medium
>> work loads with lower power consumption. Specifics
Fix 4 spelling errors in help sections.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/Kconfig.arm | 4 ++--
drivers/cpufreq/Kconfig.x86 | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 5805035
: please, no spaces at the start of a line
Also, define the pr_fmt macro instead of PFX for the module name.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/powernow-k8.c | 180 ++
drivers/cpufreq/powernow-k8.h | 11 ++-
2 files changed, 84 insertions
On 23/04/2014 07:46 πμ, Viresh Kumar wrote:
> On 23 April 2014 02:43, Stratos Karafotis wrote:
>> @@ -342,7 +333,7 @@ static int core_voltage_pre_transition(struct
>> powernow_k8_data *data,
>> return 1;
>>
>> if (savefid != data->
On 23/04/2014 01:37 μμ, Rafael J. Wysocki wrote:
> On Wednesday, April 23, 2014 12:13:54 AM Stratos Karafotis wrote:
>> Fix the following checkpatch warnings:
>
> In addition to comments from Viresh, I have a general one.
>
> Some of the checkpatch.pl warnings are no
Hi Prabhakar,
On 25/04/2014 03:31 μμ, Prabhakar Lad wrote:
> Hi Stratos,
>
> Thanks for the patch.
>
> On Tue, Apr 22, 2014 at 4:30 AM, Stratos Karafotis
> wrote:
>> The cpufreq core now supports the cpufreq_for_each_entry and
>> cpufreq_for_each_valid_entry mac
- cpufreq_for_each_valid_entry: iterate over each entry that contains
a valid frequency.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
Documentation/cpu-freq/cpu-drivers.txt | 19 +++
drivers/cpufreq/cpufreq.c | 11 +++
include/linux
t double ! operator in cpu_cooling
- Change the pos loop cursor variable to freq_pos in longhaul
- Declare pos variable on a separate line
Stratos Karafotis (8):
cpufreq: Introduce macros for cpufreq_frequency_table iteration
cpufreq: Use cpufreq_for_each_* macros for frequency
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/acpi-cpufreq.c | 9
The cpufreq core now supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
arch/mips/loongson/lemote-2f/clock.c | 16 +---
1 file changed, 5 insertions
The cpufreq core now supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
arch/arm/mach-davinci/da850.c | 9 +
1 file changed, 5 insertions(+), 4 deletions
The cpufreq core now supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/sh/clk/core.c | 20 +---
1 file changed, 5 insertions(+), 15
The cpufreq core now supports the cpufreq_for_each_valid_entry macro
helper for iteration over the cpufreq_frequency_table, so use it.
Also remove the redundant !! operator.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/thermal/cpu_cooling.c | 33
1 - 100 of 223 matches
Mail list logo
