| Message ID | 87y5rci2na.fsf@ti.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Mar 07, 2012 at 12:20:41PM -0800, Kevin Hilman wrote: > Dave, > > Please pull the following OMAP CPUfreq driver changes for v3.4. pulled, thanks. Dave
On Wed, Mar 7, 2012 at 10:20 PM, Kevin Hilman <khilman@ti.com> wrote: > 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 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?
On Wed, Mar 14, 2012 at 06:41:51PM +0200, Grazvydas Ignotas wrote: > > 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 > > 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
Grazvydas Ignotas <notasas@gmail.com> writes: [...] >> 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
On Wed, Mar 14, 2012 at 7:22 PM, Kevin Hilman <khilman@ti.com> wrote: > Grazvydas Ignotas <notasas@gmail.com> writes: > > [...] > >>> 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 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.
Grazvydas Ignotas <notasas@gmail.com> writes: > On Wed, Mar 14, 2012 at 7:22 PM, Kevin Hilman <khilman@ti.com> wrote: >> Grazvydas Ignotas <notasas@gmail.com> writes: >> >> [...] >> >>>> 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 > > 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. 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
Hi Dave, On 03/07/2012 12:30 PM, Dave Jones wrote: > On Wed, Mar 07, 2012 at 12:20:41PM -0800, Kevin Hilman wrote: > > 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
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(-)