On 29/04/2014 11:28 μμ, Stratos Karafotis wrote:
> Many drivers keep frequencies in frequency table in ascending
> or descending order. When governor tries to change to policy->min
> or policy->max respectively then the cpufreq_frequency_table_target
> could return
Hi Dirk,
On 08/05/2014 11:52 μμ, Dirk Brandewie wrote:
> On 05/05/2014 04:57 PM, Stratos Karafotis wrote:
>> Currently the driver calculates the next pstate proportional to
>> core_busy factor, scaled by the ratio max_pstate / current_pstate.
>>
>> Using the scaled lo
On 10/06/2014 12:22 πμ, Joe Perches wrote:
> On Tue, 2014-06-10 at 00:01 +0300, Stratos Karafotis wrote:
>> Remove unnecessary braces.
>
> []
>
>> @@ -204,20 +203,16 @@ static inline void intel_pstate_busy_pid_reset(struct
>> cpudata *cpu)
>
>> static
On 10/06/2014 08:29 πμ, Viresh Kumar wrote:
> On 10 June 2014 02:30, Stratos Karafotis wrote:
>> Also put them in alphabetical order.
>>
>> Signed-off-by: Stratos Karafotis
>> ---
>> drivers/cpufreq/intel_pstate.c | 17 ++---
>> 1 file
On 10/06/2014 08:27 πμ, Viresh Kumar wrote:
> On 10 June 2014 02:30, Stratos Karafotis wrote:
>> Simplify the code by removing the inline functions
>> pstate_increase and pstate_decrease and use directly the
>> intel_pstate_set_pstate.
>>
>> Signed-off-by: Stra
On 10/06/2014 06:47 μμ, Dirk Brandewie wrote:
> On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
>> Add stats file in debugfs under driver's parent directory
>> (pstate_snb) which counts the time in nsecs per requested
>> P state and the number of times the specific s
On 10/06/2014 07:05 μμ, Dirk Brandewie wrote:
> On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
>> Store busy_scaled value to avoid to duplicate call of
>> intel_pstate_get_scaled_busy on every sampling interval.
>>
>
> The second call *only* happens if the tracepo
On 10/06/2014 08:05 μμ, Dirk Brandewie wrote:
> On 06/10/2014 09:21 AM, Stratos Karafotis wrote:
>> On 10/06/2014 06:47 μμ, Dirk Brandewie wrote:
>>> On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
>>>> Add stats file in debugfs under driver's parent directory
On 10/06/2014 08:07 μμ, Dirk Brandewie wrote:
> On 06/10/2014 07:51 AM, Stratos Karafotis wrote:
>> On 10/06/2014 08:27 πμ, Viresh Kumar wrote:
>>> On 10 June 2014 02:30, Stratos Karafotis wrote:
>>>> Simplify the code by removing the inline functions
>>&g
On 10/06/2014 11:17 μμ, Rafael J. Wysocki wrote:
> On Tuesday, June 10, 2014 10:26:44 AM Dirk Brandewie wrote:
>> On 06/10/2014 08:31 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, June 10, 2014 08:12:48 AM Dirk Brandewie wrote:
>>>> On 06/09/2014 02:01 PM, Stratos
On 10/06/2014 11:43 μμ, Rafael J. Wysocki wrote:
> On Tuesday, June 10, 2014 11:14:53 PM Stratos Karafotis wrote:
>> On 10/06/2014 11:17 μμ, Rafael J. Wysocki wrote:
>>> On Tuesday, June 10, 2014 10:26:44 AM Dirk Brandewie wrote:
>>>> On 06/10/2014 08:
On 11/06/2014 12:38 πμ, Rafael J. Wysocki wrote:
> On Wednesday, June 11, 2014 12:02:09 AM Stratos Karafotis wrote:
>> On 10/06/2014 11:43 μμ, Rafael J. Wysocki wrote:
>>> On Tuesday, June 10, 2014 11:14:53 PM Stratos Karafotis wrote:
>>>> On 10/06/2014 11:
is (before rounding):
core_pct = 12111
fp_toint(core_pct) = 47
After rounding:
core_pct = 12112
fp_toint(core_pct) = 47
After rounding with int_toftp(1):
core_pct = 12367
fp_toint(core_pct) = 48
Signed-off-by: Stratos Karafotis
---
Hi Rafael,
I'm sorry for submitting again in merge window, but
On 11/06/2014 04:41 μμ, Doug Smythies wrote:
>
> On 2014.06.11 05:34 Stratos Karafotis wrote:
>
>> Local variable core_pct holds fixed point values.
>> When we round it we add "1" to core_pct. This has almost
>> no effect.
>>
>> So, add int_toft
On 11/06/2014 06:02 μμ, Doug Smythies wrote:
>
> On 2104.06.11 07:08 Stratos Karafotis wrote:
>> On 11/06/2014 04:41 μμ, Doug Smythies wrote:
>>
>> No.
>>
>> The intent was only ever to round properly the pseudo floating point result
>> of the divide.
On 12/06/2014 12:15 πμ, Doug Smythies wrote:
>
>
> -Original Message-
> From: Stratos Karafotis [mailto:strat...@semaphore.gr]
> Sent: June-11-2014 13:20
> To: Doug Smythies
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> r...@rjwysocki.net;
calculation
if tracing is on).
Thanks!
Stratos Karafotis (7):
cpufreq: intel_pstate: Remove duplicate CPU ID check
cpufreq: intel_pstate: Avoid duplicate call of
intel_pstate_get_scaled_busy
cpufreq: intel_pstate: Add debugfs file stats
cpufreq: intel_pstate: Simplify code
Also put them in alphabetical order.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 26a0262..d4f0518 100644
Store busy_scaled value to avoid to duplicate call of
intel_pstate_get_scaled_busy on every sampling interval.
Also, rename the function to intel_pstate_calc_scaled_busy.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 12 ++--
1 file changed, 6 insertions(+), 6
Since we never remove sysfs entry, we can make the intel_pstate_kobject
local.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index fa44f0f
Remove unnecessary blank lines.
Remove unnecessary parentheses.
Remove unnecessary braces.
Put the code in one line where possible.
Add blank lines after variable declarations.
Alignment to open parenthesis.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 96
Simplify the code by removing the inline functions
pstate_increase and pstate_decrease and use directly the
intel_pstate_set_pstate.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git
We check the CPU ID during driver init. There is no need
to do it again per logical CPU initialization.
So, remove the duplicate check.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b
39 85446 3803
...
The file can be used for debugging but also for monitoring
various system workloads.
Also, make the debugfs_parent local as we never remove
the driver's debugfs files.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 80
On 10/06/2014 12:07 πμ, David Rientjes wrote:
> On Tue, 10 Jun 2014, Stratos Karafotis wrote:
>
>> Since we never remove sysfs entry, we can make the intel_pstate_kobject
>> local.
>>
>
> For even more savings, this function and
> intel_pstate_debug_expose_para
On Tue, Mar 25, 2014 at 11:32 AM, Viresh Kumar wrote:
> One of the comments in tick_handle_periodic() had 'when' instead of 'which'
> (My
> guess :)). Fix it.
>
> Signed-off-by: Viresh Kumar
> ---
> kernel/time/tick-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
y when a frequency in cpufreq_frequency_table
equals to target one.
Testing this during kernel compilation using ondemand governor
with a frequency table in ascending order, the
cpufreq_frequency_table_target returned early on the first
iteration at about 30% of times called.
Signed-off-by: Stratos Kar
Hi all!
On 12/05/2014 11:30 μμ, Stratos Karafotis wrote:
> On 09/05/2014 05:56 μμ, Stratos Karafotis wrote:
>> Hi Dirk,
>>
>> On 08/05/2014 11:52 μμ, Dirk Brandewie wrote:
>>> On 05/05/2014 04:57 PM, Stratos Karafotis wrote:
>>>> Currently the driv
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
---
Changes v2 -> v3
- Added 'ARM' prefix in the subject as Sekhar Nori sugges
- 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
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
---
drivers/mfd/db8500-prcmu.c | 19 ---
1 file changed, 8 insertions(+), 11
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_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 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
---
Please note that I was no able to compile test this patch due to
lack of cross compiler
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
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
Hi Pavel!
On 11/07/2014 07:57 μμ, 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:
>>
On 11/07/2014 09:34 μμ, Pavel Machek wrote:
> On Fri 2014-07-11 20:29:57, Stratos Karafotis wrote:
>> Hi Pavel!
>>
>> On 11/07/2014 07:57 μμ, Pavel Machek wrote:
>>> Hi!
>>>
>>>> Tested on Intel i7-3770 CPU @ 3.40GHz and on ARM quad core 1500M
Introduce CPUFREQ_RELATION_C for frequency selection.
It selects the frequency with the minimum euclidean distance to target.
In case of equal distance between 2 frequencies, it will select the
greater frequency.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/freq_table.c | 12
the closest frequency to target.
Patch 2 is the actual change to ondemand governor.
You may find graphs with the 'deadband' effect and benchmark results:
https://docs.google.com/spreadsheets/d/16kDBh5lyc6YvBnoS1hUa1t2O38z0xrWvaEj5XtJ8auw/edit#gid=2072493052
Thanks
Stratos Karafotis (2
FFMPEG:
Time: -6.29%, energy: -4.02%
Also, running mp3 decoding (very low load) shows no differences with and
without this patch.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_ondemand.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/c
On 13/06/2014 04:48 μμ, Dirk Brandewie wrote:
> On 06/12/2014 01:03 PM, Rafael J. Wysocki wrote:
>> On Thursday, June 12, 2014 05:35:59 PM Stratos Karafotis wrote:
>>> On 12/06/2014 12:15 πμ, Doug Smythies wrote:
>>>>
>>>>
>>>> -Original M
On 13/06/2014 09:49 πμ, Doug Smythies wrote:
> On 2014.06.12 13:03 Rafael J. Wysocki wrote:
>> On Thursday, June 12, 2014 05:35:59 PM Stratos Karafotis wrote:
>>> On 12/06/2014 12:15 πμ, Doug Smythies wrote:
>>>>
>>>>
>>>> On 2014.06.11 13:20
On 14/06/2014 06:45 μμ, Doug Smythies wrote:
> I am sorry to be late chiming in on this one.
>
> On 2014.06.10 09:27 Stratos Karafotis wrote:
>> On 10/06/2014 07:05 μμ, Dirk Brandewie wrote:
>> On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
>>> Store busy_scaled va
Hi Doug,
On 12/07/2014 06:45 μμ, Doug Smythies wrote:
>
> On 2014.07.30 10:00 Stratos Karafotis wrote:
>
>> This patchset changes slightly the calculation of target frequency to
>> eliminate the deadband effect (explained in patch 2 changelog) that it
>> seems
of a line
Also, define the pr_fmt macro instead of PFX for the module name.
Signed-off-by: Stratos Karafotis
---
Changes v1 -> v2
- Use pr_err_once instead of printk_once
- Change missing_pss_msg to macro (because pr_err_once
doesn't compile otherwise)
- Put
Hi,
On 12/05/2014 05:14 πμ, Stratos Karafotis wrote:
> From: Dirk Brandewie
>
> Commit fcb6a15c intel_pstate: Take core C0 time into account for core busy
> introduced a regression referenced below. The issue with "lockup"
> after suspend that this commit wa
On 09/05/2014 05:56 μμ, Stratos Karafotis wrote:
> Hi Dirk,
>
> On 08/05/2014 11:52 μμ, Dirk Brandewie wrote:
>> On 05/05/2014 04:57 PM, Stratos Karafotis wrote:
>>> Currently the driver calculates the next pstate proportional to
>>> core_busy facto
Hi,
On 12/05/2014 10:34 μμ, Yuyang Du wrote:
> On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote:
>> On 09/05/2014 05:56 μμ, Stratos Karafotis wrote:
>>
>> Next performance state = min_perf + (max_perf - min_perf) * load / 100
>>
> Hi,
>
>
On 12/05/2014 11:01 μμ, Yuyang Du wrote:
> On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote:
>> Hi,
>>
>> On 12/05/2014 10:34 μμ, Yuyang Du wrote:
>>> On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote:
>>>> On 09
On 13/05/2014 12:59 πμ, Yuyang Du wrote:
Maybe, in some cases yes. But not always.
For example, please consider a CPU running a tight "for" loop in 100MHz
for a couple of seconds. This produces a load of 100%.
It will produce the same load (100%) in any other frequency.
>>>
Although, a value is assigned to member name of struct cpudata,
it is never used.
We can safely remove it.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
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.
On 07/23/2014 02:50 AM, Rafael J. Wysocki wrote:
On Monday, June 30, 2014 07:59:32 PM Stratos Karafotis wrote:
Hi all,
This patchset changes slightly the calculation of target frequency to
eliminate the deadband effect (explained in patch 2 changelog) that it
seems to slow down the CPU in low
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
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/x86/kernel
after 0.86s
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 9 +
drivers/cpufreq/cpufreq_governor.c | 18 +-
drivers/cpufreq/cpufreq_governor.h | 1 +
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq
Hi,
Thanks for reviewing.
On 07/11/2016 08:12 πμ, Viresh Kumar wrote:
> For the record, I have never got the original mail with this subject.
I'm sorry for inconvenience. It seems that I had an issue on my mail
server.
> On 06-11-16, 11:19, Stratos Karafotis wrote:
>> Conservat
On 08/11/2016 10:32 πμ, Viresh Kumar wrote:
> On 8 November 2016 at 12:49, Stratos Karafotis wrote:
>> I think we shouldn't. That's why the patch first decreases the frequency
>> by n freq steps (where n the number of deferred periods).
>> Then the normal processing takes pl
On 09/11/2016 07:55 πμ, Viresh Kumar wrote:
> On 08-11-16, 21:25, Stratos Karafotis wrote:
>> But this is the supposed behaviour of conservative governor. We want
>> the CPU to increase the frequency in steps. The patch just resets
>> the frequency to a lower freq
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 12:47 μμ, A
frequency after 0.86s
Signed-off-by: Stratos Karafotis
Acked-by: Viresh Kumar
---
v3 -> v4
- Fix format issues
- Ack by Viresh Kumar
v2 -> v3
- cpufreq_conservative.c: move the calculation below the block that check
the limits
- Calculate the freq_step only once
- Fix the bug introduced in dbs_
The original comment about the frequency increase to maximum is wrong.
Both increase and decrease happen at steps.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq
The original comment about the frequency increase to maximum is wrong.
Both increase and decrease happen at steps.
Signed-off-by: Stratos Karafotis
---
-> v2
Remove a trailing space
drivers/cpufreq/cpufreq_conservative.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --
me_elapsed - idle_time
and
load = 100 * busy / sampling_rate;
Also, remove the 'unlikely' hint because it seems that a deferred update
is a very common case on most modern systems.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_governor.c | 37 +++-
On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
> On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis
> wrote:
>> Conservative governor changes the CPU frequency in steps.
>> That means that if a CPU runs at max frequency, it will need several
>> sampling periods to
On 15/11/2016 12:09 πμ, Rafael J. Wysocki wrote:
> On Mon, Nov 14, 2016 at 10:59 PM, Rafael J. Wysocki wrote:
>> On Mon, Nov 14, 2016 at 10:46 PM, Stratos Karafotis
>> wrote:
>>>
>>>
>>> On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
>>>&g
frequency after 0.86s
Signed-off-by: Stratos Karafotis
---
v2 -> v3
- cpufreq_conservative.c: move the calculation below the block that check
the limits
- Calculate the freq_step only once
- Fix the bug introduced in dbs_update() because of wrong estimation of
'if' conditions
v1 -> v2
- Use c
On 10/11/2016 02:13 πμ, Rafael J. Wysocki wrote:
> On Wed, Nov 9, 2016 at 6:55 AM, Viresh Kumar wrote:
>> On 08-11-16, 21:25, Stratos Karafotis wrote:
>>> But this is the supposed behaviour of conservative governor. We want
>>> the CPU to increase the frequency in s
frequency after 0.86s
Signed-off-by: Stratos Karafotis
---
v1 -> v2
- Use correct terminology in change log
- Change the member variable name from 'deferred_periods' to 'idle_periods'
- Fix format issue
drivers/cpufreq/cpufreq_conservative.c | 14 +-
drivers/cpufreq/cpufreq_governo
Hi,
On 16/09/2016 12:47 μμ, Andreas Herrmann wrote:
> On Wed, Sep 07, 2016 at 10:32:01AM +0530, Viresh Kumar wrote:
>> On 01-09-16, 15:21, Andreas Herrmann wrote:
>>> On Mon, Aug 29, 2016 at 11:31:53AM +0530, Viresh Kumar wrote:
>
I am _really_ worried about such hacks in drivers to negate
after 0.86s
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/cpufreq_conservative.c | 9 +
drivers/cpufreq/cpufreq_governor.c | 18 +-
drivers/cpufreq/cpufreq_governor.h | 1 +
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq
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
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
>>> an
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=0AnMfNYUV1k0ddDdGdlJyUHpqT2xGY1lBOEt2
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
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).
&g
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:
>>>>
>>>
ed-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 ++--
2 files changed, 7 insertions(+), 7
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 present
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
e ! 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 table ite
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
The cpufreq core 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
---
Please note that I was no able to compile test this patch due to
lack of cross compiler
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
---
drivers/mfd/db8500-prcmu.c | 19 ---
1 file changed, 8 insertions(+), 11
Hi Prabhakar,
On 26/04/2014 12:57 μμ, Prabhakar Lad wrote:
> Hi Stratos,
>
> Thanks for the patch,
>
> On Sat, Apr 26, 2014 at 1:45 AM, Stratos Karafotis
> wrote:
>> The cpufreq core now supports the cpufreq_for_each_entry and
>> cpufreq_for_each_valid_entry mac
15326.87700
avg 78.34 258.842 59.18 15318.82650
The total test time reduced by ~2.6%, while the total energy
consumption during a test iteration reduced by ~0.35%
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 15 +++
1 file
301 - 400 of 446 matches
Mail list logo
