cpufreq: OMAP updates for v3.4

GIT PULL Kevin Hilman 3 participants 8 messages Mar 7, 2012 – Mar 15, 2012

lore

Share & tools

lore

Kevin Hilman

author

2012-03-07 20:20 UTC #0 lore raw

Dave,

Please pull the following OMAP CPUfreq driver changes for v3.4.

Thanks,

Kevin

The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:

Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/cpufreq

for you to fetch changes up to 42daffd2d6c665716d442d518022ecaad17ddf64:

cpufreq: OMAP: specify range for voltage scaling (2012-03-02 13:55:57 -0800)

----------------------------------------------------------------
Afzal Mohammed (1):
cpufreq: OMAP: specify range for voltage scaling

Kevin Hilman (1):
cpufreq: OMAP: scale voltage along with frequency

Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables

 drivers/cpufreq/Kconfig.arm    |    5 +++
 drivers/cpufreq/Makefile       |    2 +-
 drivers/cpufreq/omap-cpufreq.c |   72 +++++++++++++++++++++++++++++++++++++---
 3 files changed, 73 insertions(+), 6 deletions(-)

Dave Jones

2012-03-07 20:30 UTC #1 lore raw

Quoted 3 lines · Kevin Hilman

Dave,
Please pull the following OMAP CPUfreq driver changes for v3.4.

pulled, thanks.

Dave

Kevin Hilman

author

2012-03-15 17:00 UTC #2 lore raw

Hi Dave,

Quoted 6 lines · Dave Jones

Quoted 3 lines · Kevin Hilman
Dave,
Please pull the following OMAP CPUfreq driver changes for v3.4.
pulled, thanks.

Looks like these got pulled into your fixes branch, but I don't see them in linux-next? Are these on their way upstream?

Kevin

Grazvydas Ignotas

2012-03-14 16:41 UTC #3 lore raw

In reply to Kevin Hilman

Quoted 26 lines · Kevin Hilman

Dave,
Please pull the following OMAP CPUfreq driver changes for v3.4.
Thanks,
Kevin
The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:
Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/cpufreq
for you to fetch changes up to 42daffd2d6c665716d442d518022ecaad17ddf64:
cpufreq: OMAP: specify range for voltage scaling (2012-03-02 13:55:57 -0800)
----------------------------------------------------------------
Afzal Mohammed (1):
cpufreq: OMAP: specify range for voltage scaling

Quoted 5 lines

Kevin Hilman (1):
cpufreq: OMAP: scale voltage along with frequency
Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables

It seems this one got messed up, it says "default ARCH_OMAP2PLUS" instead of depends.
Can it be dropped and resent, or do we need a fixup patch?

Signature · 5 lines

Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dave Jones

2012-03-14 16:44 UTC #4 lore raw

Quoted 6 lines · Grazvydas Ignotas

Quoted 6 lines
Afzal Mohammed (1):
cpufreq: OMAP: specify range for voltage scaling
Kevin Hilman (1):
cpufreq: OMAP: scale voltage along with frequency

Quoted 6 lines

Quoted 2 lines
Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables
It seems this one got messed up, it says "default ARCH_OMAP2PLUS" instead of depends.
Can it be dropped and resent, or do we need a fixup patch?

Please send a follow-up patch if necessary.

Dave

Kevin Hilman

author

2012-03-14 17:22 UTC #5 lore raw

In reply to Grazvydas Ignotas

Grazvydas Ignotas <[email protected]> writes:

[...]

Quoted 5 lines

Quoted 2 lines
Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables
It seems this one got messed up, it says "default ARCH_OMAP2PLUS" instead of depends.

That was intentional. What do you think is messed up about it?

It's the same as saying:

depends on ARCH_OMAP2PLUS
default y

Kevin

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Grazvydas Ignotas

2012-03-14 17:38 UTC #6 lore raw

Quoted 10 lines · Kevin Hilman

Grazvydas Ignotas <[email protected]> writes:
[...]
Quoted 5 lines
Quoted 2 lines
Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables
It seems this one got messed up, it says "default ARCH_OMAP2PLUS" instead of depends.

Quoted 6 lines

That was intentional. What do you think is messed up about it?
It's the same as saying:
depends on ARCH_OMAP2PLUS
default y

Hm, somehow I've never encountered this syntax, but it more looks like it means "default y if ARCH_OMAP2PLUS" instead of that.

Checked this with menuconfig now:
default ARCH_OMAP2PLUS
resolves to:
ARCH_HAS_CPUFREQ [=y] && CPU_FREQ [=y] && ARM [=y]

..which might cause build break when OMAP is not selected, and

depends on ARCH_OMAP2PLUS
default y
resolves to:
ARCH_HAS_CPUFREQ [=y] && CPU_FREQ [=y] && ARM [=y] && ARCH_OMAP2PLUS [=y]

..which should be randconfig friendly.

Signature · 5 lines

Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kevin Hilman

author

2012-03-15 14:25 UTC #7 lore raw

Quoted 26 lines · Grazvydas Ignotas

Quoted 10 lines · Kevin Hilman
Grazvydas Ignotas <[email protected]> writes:
[...]
Quoted 5 lines
Quoted 2 lines
Russell King (1):
cpufreq: OMAP driver depends CPUfreq tables
It seems this one got messed up, it says "default ARCH_OMAP2PLUS" instead of depends.
Quoted 6 lines
That was intentional. What do you think is messed up about it?
It's the same as saying:
depends on ARCH_OMAP2PLUS
default y
Hm, somehow I've never encountered this syntax, but it more looks like it means "default y if ARCH_OMAP2PLUS" instead of that.
Checked this with menuconfig now:
default ARCH_OMAP2PLUS
resolves to:
ARCH_HAS_CPUFREQ [=y] && CPU_FREQ [=y] && ARM [=y]

Quoted 8 lines

..which might cause build break when OMAP is not selected, and
depends on ARCH_OMAP2PLUS
default y
resolves to:
ARCH_HAS_CPUFREQ [=y] && CPU_FREQ [=y] && ARM [=y] && ARCH_OMAP2PLUS [=y]
..which should be randconfig friendly.

Yeah, you're right. Feel free to send a patch using your comments above to describe that the current form is not randconfig friendly.

Kevin