Introduce new cpufreq helper macros

PATCH Applied Stratos Karafotis 4 participants 12 messages Apr 25, 2014 – May 7, 2014 SuperH

lore

Share & tools

lore

Stratos Karafotis

author

2014-04-25 20:15 UTC #0 lore raw

v5 cover Introduce new cpufreq helper macros

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 changes to cpufreq core and drivers that use such an iteration procedure.

The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.

This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.

Changelog

v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe
v3 -> v4
- No changes
v2 -> v3
- Better formatting in Documentation
- Fix spell error in comments in cpufreq.h
- Added 'ARM' prefix in patch 3/8 subject as Sekhar Nori suggested
v1 -> v2
- Rearrange patches
- Remove redundant braces
- Fix a newly introduced bug in exynos5440
- Use cpufreq_for_each_valid_entry instead of
cpufreq_for_each_entry in cpufreq_frequency_table_get_index()
- Drop redundant 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 table iteration
ARM: davinci: da850: Use cpufreq_for_each_entry macro for iteration
mips: lemote 2f: Use cpufreq_for_each_entry macro for iteration
mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iteration
thermal: cpu_cooling: Use cpufreq_for_each_valid_entry macro for
iteration
irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration
sh: clk: Use cpufreq_for_each_valid_entry macro for iteration

 Documentation/cpu-freq/cpu-drivers.txt | 19 ++++++++++++
 arch/arm/mach-davinci/da850.c          |  9 +++---
 arch/mips/loongson/lemote-2f/clock.c   | 16 +++-------
 drivers/cpufreq/acpi-cpufreq.c         |  9 +++---
 drivers/cpufreq/arm_big_little.c       | 16 +++++-----
 drivers/cpufreq/cpufreq.c              | 11 +++++++
 drivers/cpufreq/cpufreq_stats.c        | 24 +++++----------
 drivers/cpufreq/dbx500-cpufreq.c       |  8 ++---
 drivers/cpufreq/elanfreq.c             |  9 +++---
 drivers/cpufreq/exynos-cpufreq.c       | 11 +++----
 drivers/cpufreq/exynos5440-cpufreq.c   | 30 +++++++++---------
 drivers/cpufreq/freq_table.c           | 56 +++++++++++++++-------------------
 drivers/cpufreq/longhaul.c             | 11 +++----
 drivers/cpufreq/pasemi-cpufreq.c       | 10 +++---
 drivers/cpufreq/powernow-k6.c          | 14 ++++-----
 drivers/cpufreq/ppc_cbe_cpufreq.c      |  9 +++---
 drivers/cpufreq/s3c2416-cpufreq.c      | 40 +++++++++++-------------
 drivers/cpufreq/s3c64xx-cpufreq.c      | 15 +++------
 drivers/mfd/db8500-prcmu.c             | 19 +++++-------
 drivers/net/irda/sh_sir.c              | 14 +++------
 drivers/sh/clk/core.c                  | 20 +++---------
 drivers/thermal/cpu_cooling.c          | 33 ++++++++------------
 include/linux/cpufreq.h                | 21 +++++++++++++
 23 files changed, 208 insertions(+), 216 deletions(-)

Signature · 1 line

1.9.0

Viresh Kumar

Acked-by on the v5 series

2014-04-29 04:17 UTC #1 lore raw

Quoted 13 lines · Stratos Karafotis

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 drivers that use such an iteration procedure.
The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.
This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.

Quoted 5 lines

Changelog
v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe

Doesn't look much has changed and so it stays as is:

Acked-by Viresh Kumar <[email protected]>

Stratos Karafotis

author

2014-04-29 16:05 UTC #2 lore raw

Quoted 16 lines · Viresh Kumar

Quoted 15 lines · Stratos Karafotis
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 drivers that use such an iteration procedure.
The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.
This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.
Changelog

Quoted 8 lines

Quoted 3 lines
v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe
Doesn't look much has changed and so it stays as is:
Acked-by Viresh Kumar <[email protected]>

Thank you very much!

Stratos Karafotis

Rafael J. Wysocki

Applied

2014-04-29 22:09 UTC #3 lore raw

Quoted 21 lines · Stratos Karafotis

Quoted 20 lines · Viresh Kumar
Quoted 18 lines · Stratos Karafotis
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 drivers that use such an iteration procedure.
The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.
This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.
Changelog
v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe

Quoted 6 lines

Quoted 4 lines
Doesn't look much has changed and so it stays as is:
Acked-by Viresh Kumar <[email protected]>
Thank you very much!

I've applied the series to my bleeding-edge branch, will move it to linux-next after build testing later this week.

Thanks!

Signature · 2 lines

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Stratos Karafotis

author

2014-04-30 15:37 UTC #4 lore raw

Quoted 27 lines · Rafael J. Wysocki

Quoted 26 lines · Stratos Karafotis
Quoted 24 lines · Viresh Kumar
Quoted 13 lines · Stratos Karafotis
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 drivers that use such an iteration procedure.
The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.
This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.
Quoted 5 lines
Changelog
v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe
Doesn't look much has changed and so it stays as is:
Acked-by Viresh Kumar <[email protected]>

Quoted 7 lines

Quoted 1 line
Thank you very much!
I've applied the series to my bleeding-edge branch, will move it to linux-next after build testing later this week.
Thanks!

Thanks so much!

Stratos Karafotis

Geert Uytterhoeven

2014-05-06 15:24 UTC #5 lore raw

In reply to Rafael J. Wysocki

Hi Stratos,

Quoted 24 lines · Rafael J. Wysocki

Quoted 23 lines · Stratos Karafotis
Quoted 22 lines · Viresh Kumar
Quoted 13 lines · Stratos Karafotis
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 drivers that use such an iteration procedure.
The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.
This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.
Quoted 5 lines
Changelog
v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe
Doesn't look much has changed and so it stays as is:

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Acked-by Viresh Kumar <[email protected]>
Thank you very much!
I've applied the series to my bleeding-edge branch, will move it to linux-next after build testing later this week.

This breaks if CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/ non-multiplatform:

drivers/built-in.o: In function `clk_round_parent':
clkdev.c:(.text+0xcf168): undefined reference to cpufreq_next_valid' drivers/built-in.o: In function clk_rate_table_find':
clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' make[3]: *** [vmlinux] Error 1

drivers/sh/clk/core.c (pre-CCF shmobile clock core) calls cpufreq_for_each_valid_entry():

#define cpufreq_for_each_valid_entry(pos, table) \
for (pos = table; cpufreq_next_valid(&pos); pos++)

but cpufreq_next_valid() in drivers/cpufreq/cpufreq.c is not compiled in.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Stratos Karafotis

author

2014-05-06 17:55 UTC #6 lore raw

Hi all,

Quoted 44 lines · Geert Uytterhoeven

Hi Stratos,
Quoted 24 lines · Rafael J. Wysocki
Quoted 23 lines · Stratos Karafotis
Quoted 22 lines · Viresh Kumar
Quoted 13 lines · Stratos Karafotis
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 drivers that use such an iteration procedure.
The motivation was a usage of common procedure to iterate over cpufreq_frequency_table across all drivers and cpufreq core.
This was tested on a x86_64 platform.
Most files compiled successfully but unfortunately I was not able to compile sh_sir.c pasemi_cpufreq.c and ppc_cbe_cpufreq.c due to lack of cross compiler.
Quoted 5 lines
Changelog
v4 -> v5
- Fix warnings in printk format specifier for 32 bit architectures in freq_table.c, longhaul, pasemi, ppc_cbe
Doesn't look much has changed and so it stays as is:
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Acked-by Viresh Kumar <[email protected]>
Thank you very much!
I've applied the series to my bleeding-edge branch, will move it to linux-next after build testing later this week.
This breaks if CONFIG_CPU_FREQ=n, e.g. ARM/shmobile/koelsch/ non-multiplatform:
drivers/built-in.o: In function `clk_round_parent':
clkdev.c:(.text+0xcf168): undefined reference to cpufreq_next_valid' drivers/built-in.o: In function clk_rate_table_find':
clkdev.c:(.text+0xcf820): undefined reference to `cpufreq_next_valid' make[3]: *** [vmlinux] Error 1

Quoted 8 lines

drivers/sh/clk/core.c (pre-CCF shmobile clock core) calls cpufreq_for_each_valid_entry():
#define cpufreq_for_each_valid_entry(pos, table) \
for (pos = table; cpufreq_next_valid(&pos); pos++)
but cpufreq_next_valid() in drivers/cpufreq/cpufreq.c is not compiled in.

My bad. I'm sorry for this. :(

Rafael,
A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies.

So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ:

4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration").

Do I need to send revert patches for the above?

Thanks,
Stratos

Viresh Kumar

2014-05-07 05:23 UTC #7 lore raw

Quoted 5 lines · Stratos Karafotis

My bad. I'm sorry for this. :(
Rafael,
A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies.

That statement was true when we didn't had this problem..

Quoted 4 lines

So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ:
4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration").

This doesn't look right. It can happen to some other drivers as well in future. So, there are two solutions I can think of:
1. move cpufreq_next_valid and rename it to __cpufreq_next_valid(). Also make it inline. Then create two versions of cpufreq_next_valid(), one inlined (only when CONFIG_CPU_FREQ=n) and other one in cpufreq.c (non- inlined)..

But probably that would be called ugly by some people :)

2. Make cpufreq_next_valid() inline and forget about extra space it takes :)

@Rafel: Let me know which one you like :)

Rafael J. Wysocki

2014-05-07 12:56 UTC #8 lore raw

Quoted 20 lines · Viresh Kumar

Quoted 5 lines · Stratos Karafotis
My bad. I'm sorry for this. :(
Rafael,
A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies.
That statement was true when we didn't had this problem..
Quoted 4 lines
So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ:
4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration").
This doesn't look right. It can happen to some other drivers as well in future. So, there are two solutions I can think of:
1. move cpufreq_next_valid and rename it to __cpufreq_next_valid(). Also make it inline. Then create two versions of cpufreq_next_valid(), one inlined (only when CONFIG_CPU_FREQ=n) and other one in cpufreq.c (non- inlined)..

Quoted 5 lines

But probably that would be called ugly by some people :)
2. Make cpufreq_next_valid() inline and forget about extra space it takes :)
@Rafel: Let me know which one you like :)

Signature · 2 lines

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Stratos Karafotis

author

2014-05-07 13:34 UTC #9 lore raw

Hi Rafael,

Quoted 21 lines · Rafael J. Wysocki

Quoted 20 lines · Viresh Kumar
Quoted 5 lines · Stratos Karafotis
My bad. I'm sorry for this. :(
Rafael,
A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies.
That statement was true when we didn't had this problem..
Quoted 4 lines
So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ:
4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration").
This doesn't look right. It can happen to some other drivers as well in future. So, there are two solutions I can think of:
1. move cpufreq_next_valid and rename it to __cpufreq_next_valid(). Also make it inline. Then create two versions of cpufreq_next_valid(), one inlined (only when CONFIG_CPU_FREQ=n) and other one in cpufreq.c (non- inlined)..

Quoted 9 lines

Quoted 5 lines
But probably that would be called ugly by some people :)
2. Make cpufreq_next_valid() inline and forget about extra space it takes :)
@Rafel: Let me know which one you like :)
2.

Do you want me to resend the entire patch set or only patch 1/8?

Thanks,
Stratos

Viresh Kumar

2014-05-07 13:36 UTC #10 lore raw

Quoted 1 line · Stratos Karafotis

Do you want me to resend the entire patch set or only patch 1/8?

Probably a new patch which would make it inline that's it. I don't think he is going to rebase his branch now..

Rafael J. Wysocki

2014-05-07 22:20 UTC #11 lore raw

In reply to Stratos Karafotis

Quoted 28 lines · Stratos Karafotis

Hi Rafael,
Quoted 25 lines · Rafael J. Wysocki
Quoted 24 lines · Viresh Kumar
Quoted 5 lines · Stratos Karafotis
My bad. I'm sorry for this. :(
Rafael,
A solution could be to make cpufreq_next_valid an inline function in cpufreq.h, but as Viresh mentioned this would be very inefficient because of multiple copies.
That statement was true when we didn't had this problem..
Quoted 4 lines
So, maybe it's better to revert the 2 patches that don't depend on CONFIG_CPU_FREQ:
4229e1c61a4a ("sh: clk: Use cpufreq_for_each_valid_entry macro for iteration") and 04ae58645afa ("irda: sh_sir: Use cpufreq_for_each_valid_entry macro for iteration").
This doesn't look right. It can happen to some other drivers as well in future. So, there are two solutions I can think of:
1. move cpufreq_next_valid and rename it to __cpufreq_next_valid(). Also make it inline. Then create two versions of cpufreq_next_valid(), one inlined (only when CONFIG_CPU_FREQ=n) and other one in cpufreq.c (non- inlined)..
But probably that would be called ugly by some people :)
2. Make cpufreq_next_valid() inline and forget about extra space it takes :)

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
@Rafel: Let me know which one you like :)
2.
Do you want me to resend the entire patch set or only patch 1/8?

It's already on a branch that cannot be rebased. Please send me a fix on top of it.

Signature · 2 lines

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.