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 +++---
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 --gi
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
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_
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 ->
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
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
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/cpu
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
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 frequency in ca
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 processin
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:
>> Cons
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
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 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
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 t
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
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
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 to s
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 1500MHz
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:
>>
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 Ka
%
Phoronix 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
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
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
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 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 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;
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 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
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 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:17 μμ, Raf
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:31 AM, Raf
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 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 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 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 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 speci
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 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 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 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
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
70
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_pst
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
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
--- a
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
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
ifies 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 co
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
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 driver
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
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.
>>>
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
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 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 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 was addres
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)
-
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 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 on first it
n function `clk_rate_table_find':
clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid'
make[3]: *** [vmlinux] Error 1
Fix this making cpufreq_next_valid function inline and move it to
cpufreq.h.
Reported-by: Geert Uytterhoeven
Signed-off-by: Stratos Karafotis
---
drivers/cp
Hi Rafael,
On 07/05/2014 04:13 μμ, Rafael J. Wysocki wrote:
> On Wednesday, May 07, 2014 10:53:16 AM Viresh Kumar wrote:
>> On 6 May 2014 23:25, Stratos Karafotis wrote:
>>> My bad. I'm sorry for this. :(
>>>
>>> Rafael,
>>> A solution could b
Hi all,
On 06/05/2014 06:24 μμ, Geert Uytterhoeven wrote:
> Hi Stratos,
>
> On Wed, Apr 30, 2014 at 12:26 AM, Rafael J. Wysocki
> wrote:
>> On Tuesday, April 29, 2014 07:05:17 PM Stratos Karafotis wrote:
>>> On 29/04/2014 07:17 πμ, Viresh Kumar wrote:
>>&
56 and
the decrease in energy consumption ~7.96%
Signed-off-by: Stratos Karafotis
---
Detailed test results can be found in this link:
https://docs.google.com/spreadsheets/d/1xiw8FOswoNFA8seNMz0nYUdhjPPvJ8J2S54kG02dOP8/edit?usp=sharing
drivers/cpufreq/intel_psta
On 02/05/2014 03:26 μμ, Rafael J. Wysocki wrote:
> On Thursday, May 01, 2014 06:48:08 PM Dirk Brandewie wrote:
>> On 05/01/2014 04:18 PM, Rafael J. Wysocki wrote:
>>> On Thursday, May 01, 2014 02:30:42 PM Dirk Brandewie wrote:
>>>> On 05/01/2014 02:00 PM, Stratos Ka
d by ~0.35%
Signed-off-by: Stratos Karafotis
---
Changes v1 -> v2
- Enhance change log as Rafael and Viresh suggested
drivers/cpufreq/intel_pstate.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_p
On 30/04/2014 01:26 πμ, Rafael J. Wysocki wrote:
> On Tuesday, April 29, 2014 07:05:17 PM Stratos Karafotis wrote:
>> On 29/04/2014 07:17 πμ, Viresh Kumar wrote:
>>> On 26 April 2014 01:45, Stratos Karafotis wrote:
>>>> This patch set introduces two freq_table helper
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
st line in this function.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/intel_pstate.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 95b3958..8192ff1 100644
--- a/drivers/cpufreq/intel_psta
alculation include it in
the protected section. This should increase the accuracy of the
calculations.
Tested on Intel i7-3770 CPU @ 3.40GHz.
Benchmarks (Phoronix Linux compilation) show a slightly increase
in performance by ~0.1% and a decrease in power consumption by
~0.13%.
Signed-off-b
On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
> Cc'd Dirk,
>
> On 28 April 2014 03:42, Stratos Karafotis wrote:
>> Currently the driver calculates the next pstate proportional to
>> core_busy factor and reverse proportional to current pstate.
>>
>> Change t
On 29/04/2014 07:17 πμ, Viresh Kumar wrote:
> On 26 April 2014 01:45, Stratos Karafotis wrote:
>> This patch set introduces two freq_table helper macros which
>> can be used for iteration over cpufreq_frequency_table and
>> makes the necessary changes to cpufreq core and dri
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
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
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 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
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 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
- 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
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
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
: 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
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
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_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_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 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
- 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 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 N
On 16/04/2014 07:13 πμ, Simon Horman wrote:
> On Wed, Apr 16, 2014 at 01:27:04AM +0300, Stratos Karafotis wrote:
>> 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
On 16/04/2014 07:01 πμ, Viresh Kumar wrote:
> On 16 April 2014 03:55, Stratos Karafotis wrote:
>> Hi all,
>>
>> This patch set introduces two freq_table helper macros which
>> can be used for iteration over cpufreq_frequency_table and
>> makes the necessary ch
1 - 100 of 223 matches
Mail list logo
