Skip to contentSkip to conversation

OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

PATCH In review Paul Walmsley 3 participants 10 messages Jan 5, 2010 – Jan 7, 2010

Subsystems (4)
lore
Share & tools
lore

Paul Walmsley

author maintainer
#0 lore raw

v2 cover OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

Hello,

This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi <[email protected]>.

Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at:

http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/

Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP.

This second version also incorporates some comments from Felipe.

- Paul

---

Felipe Balbi (1):
OMAP2xxx clock: clk2xxx.c doesn't compile if CPUFREQ is enabled

Paul Walmsley (3):
OMAP2xxx OPP: clean up comments in OPP data
OMAP2 clock: dynamically allocate CPUFreq frequency table OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table

 arch/arm/mach-omap2/clock2xxx.c         |   57 ++++++++++++++++++++++++++-----
 arch/arm/mach-omap2/opp2420_data.c      |   38 +++++++++++----------
 arch/arm/mach-omap2/opp2430_data.c      |   30 ++++++++--------
 arch/arm/plat-omap/clock.c              |   10 +++++
 arch/arm/plat-omap/cpu-omap.c           |    1 +
 arch/arm/plat-omap/include/plat/clock.h |    2 +
 6 files changed, 96 insertions(+), 42 deletions(-)
author maintainer
#1 lore raw

PATCH v2 1/4 OMAP2xxx clock: clk2xxx.c doesn't compile if CPUFREQ is enabled

From: Felipe Balbi <[email protected]>

if we enable CPUFREQ we can't build omap2 for two reasons, one of them is fixed by the patch below.

It's failing because the __must_be_array() check in ARRAY_SIZE() is failing and printing the following message:

arch/arm/mach-omap2/clock2xxx.c:453: error: negative width in bit-field '<anonymous>'

[[email protected]: commit message updated; changed rate variable name]
---
 arch/arm/mach-omap2/clock2xxx.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/clock2xxx.c +4 -1
index d0e3fb7..ce6742f 100644
@@ -455,12 +455,15 @@ static struct cpufreq_frequency_table freq_table[ARRAY_SIZE(rate_table)];
 void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 {
 	struct prcm_config *prcm;
+	long sys_ck_rate;
 	int i = 0;
 
+	sys_ck_rate = clk_get_rate(sclk);
+
 	for (prcm = rate_table; prcm->mpu_speed; prcm++) {
 		if (!(prcm->flags & cpu_mask))
 			continue;
-		if (prcm->xtal_speed != sys_ck.rate)
+		if (prcm->xtal_speed != sys_ck_rate)
 			continue;
 
 		/* don't put bypass rates in table */
author maintainer
#2 lore raw

PATCH v2 2/4 OMAP2xxx OPP: clean up comments in OPP data

In reply to Paul Walmsley

Revise some of the comments in the OMAP2xxx OPP data for clarity.

Cc Richard Woodruff <[email protected]>
---
 arch/arm/mach-omap2/opp2420_data.c |   38 +++++++++++++++++++-----------------
 arch/arm/mach-omap2/opp2430_data.c |   30 ++++++++++++++--------------
 2 files changed, 35 insertions(+), 33 deletions(-)
arch/arm/mach-omap2/opp2420_data.c +20 -18
index 126a939..e6dda69 100644
@@ -9,45 +9,47 @@
  * The OMAP2 processor can be run at several discrete 'PRCM configurations'.
  * These configurations are characterized by voltage and speed for clocks.
  * The device is only validated for certain combinations. One way to express
- * these combinations is via the 'ratio's' which the clocks operate with
+ * these combinations is via the 'ratios' which the clocks operate with
  * respect to each other. These ratio sets are for a given voltage/DPLL
- * setting. All configurations can be described by a DPLL setting and a ratio
- * There are 3 ratio sets for the 2430 and X ratio sets for 2420.
- *
- * 2430 differs from 2420 in that there are no more phase synchronizers used.
- * They both have a slightly different clock domain setup. 2420(iva1,dsp) vs
- * 2430 (iva2.1, NOdsp, mdm)
+ * setting. All configurations can be described by a DPLL setting and a ratio.
  *
  * XXX Missing voltage data.
+ * XXX Missing 19.2MHz sys_clk rate sets (needed for N800/N810)
  *
  * THe format described in this file is deprecated.  Once a reasonable
  * OPP API exists, the data in this file should be converted to use it.
  *
  * This is technically part of the OMAP2xxx clock code.
+ *
+ * Considerable work is still needed to fully support dynamic frequency
+ * changes on OMAP2xxx-series chips.  Readers interested in such a
+ * project are encouraged to review the Maemo Diablo RX-34 and RX-44
+ * kernel source at:
+ *     http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/
  */
 
 #include "opp2xxx.h"
 #include "sdrc.h"
 #include "clock.h"
 
-/*-------------------------------------------------------------------------
- * Key dividers which make up a PRCM set. Ratio's for a PRCM are mandated.
+/*
+ * Key dividers which make up a PRCM set. Ratios for a PRCM are mandated.
  * xtal_speed, dpll_speed, mpu_speed, CM_CLKSEL_MPU,
  * CM_CLKSEL_DSP, CM_CLKSEL_GFX, CM_CLKSEL1_CORE, CM_CLKSEL1_PLL,
  * CM_CLKSEL2_PLL, CM_CLKSEL_MDM
  *
- * Filling in table based on H4 boards and 2430-SDPs variants available.
- * There are quite a few more rates combinations which could be defined.
+ * Filling in table based on H4 boards available.  There are quite a
+ * few more rate combinations which could be defined.
  *
- * When multiple values are defined the start up will try and choose the
- * fastest one. If a 'fast' value is defined, then automatically, the /2
- * one should be included as it can be used.	Generally having more that
- * one fast set does not make sense, as static timings need to be changed
- * to change the set.	 The exception is the bypass setting which is
- * availble for low power bypass.
+ * When multiple values are defined the start up will try and choose
+ * the fastest one. If a 'fast' value is defined, then automatically,
+ * the /2 one should be included as it can be used.  Generally having
+ * more than one fast set does not make sense, as static timings need
+ * to be changed to change the set.  The exception is the bypass
+ * setting which is available for low power bypass.
  *
  * Note: This table needs to be sorted, fastest to slowest.
- *-------------------------------------------------------------------------*/
+ **/
 const struct prcm_config omap2420_rate_table[] = {
 	/* PRCM I - FAST */
 	{S12M, S660M, S330M, RI_CM_CLKSEL_MPU_VAL,		/* 330MHz ARM */
arch/arm/mach-omap2/opp2430_data.c +15 -15
index edb8167..1b9596a 100644
@@ -1,5 +1,5 @@
 /*
- * opp2420_data.c - old-style "OPP" table for OMAP2420
+ * opp2430_data.c - old-style "OPP" table for OMAP2430
  *
  * Copyright (C) 2005-2009 Texas Instruments, Inc.
  * Copyright (C) 2004-2009 Nokia Corporation
@@ -9,16 +9,16 @@
  * The OMAP2 processor can be run at several discrete 'PRCM configurations'.
  * These configurations are characterized by voltage and speed for clocks.
  * The device is only validated for certain combinations. One way to express
- * these combinations is via the 'ratio's' which the clocks operate with
+ * these combinations is via the 'ratios' which the clocks operate with
  * respect to each other. These ratio sets are for a given voltage/DPLL
- * setting. All configurations can be described by a DPLL setting and a ratio
- * There are 3 ratio sets for the 2430 and X ratio sets for 2420.
+ * setting. All configurations can be described by a DPLL setting and a ratio.
  *
  * 2430 differs from 2420 in that there are no more phase synchronizers used.
  * They both have a slightly different clock domain setup. 2420(iva1,dsp) vs
  * 2430 (iva2.1, NOdsp, mdm)
  *
  * XXX Missing voltage data.
+ * XXX Missing 19.2MHz sys_clk rate sets.
  *
  * THe format described in this file is deprecated.  Once a reasonable
  * OPP API exists, the data in this file should be converted to use it.
@@ -30,24 +30,24 @@
 #include "sdrc.h"
 #include "clock.h"
 
-/*-------------------------------------------------------------------------
- * Key dividers which make up a PRCM set. Ratio's for a PRCM are mandated.
+/*
+ * Key dividers which make up a PRCM set. Ratios for a PRCM are mandated.
  * xtal_speed, dpll_speed, mpu_speed, CM_CLKSEL_MPU,
  * CM_CLKSEL_DSP, CM_CLKSEL_GFX, CM_CLKSEL1_CORE, CM_CLKSEL1_PLL,
  * CM_CLKSEL2_PLL, CM_CLKSEL_MDM
  *
- * Filling in table based on H4 boards and 2430-SDPs variants available.
- * There are quite a few more rates combinations which could be defined.
+ * Filling in table based on 2430-SDPs variants available.  There are
+ * quite a few more rate combinations which could be defined.
  *
- * When multiple values are defined the start up will try and choose the
- * fastest one. If a 'fast' value is defined, then automatically, the /2
- * one should be included as it can be used.	Generally having more that
- * one fast set does not make sense, as static timings need to be changed
- * to change the set.	 The exception is the bypass setting which is
- * availble for low power bypass.
+ * When multiple values are defined the start up will try and choose
+ * the fastest one. If a 'fast' value is defined, then automatically,
+ * the /2 one should be included as it can be used.  Generally having
+ * more than one fast set does not make sense, as static timings need
+ * to be changed to change the set.  The exception is the bypass
+ * setting which is available for low power bypass.
  *
  * Note: This table needs to be sorted, fastest to slowest.
- *-------------------------------------------------------------------------*/
+ */
 const struct prcm_config omap2430_rate_table[] = {
 	/* PRCM #4 - ratio2 (ES2.1) - FAST */
 	{S13M, S798M, S399M, R2_CM_CLKSEL_MPU_VAL,		/* 399MHz ARM */
author maintainer
#3 lore raw

PATCH v2 3/4 OMAP2 clock: dynamically allocate CPUFreq frequency table

In reply to Paul Walmsley

Dynamically allocate the CPUFreq frequency table on OMAP2xxx chips. This fixes some compilation problems, since the kernel may not know what chip it is running on until boot-time. This also reduces the size of the CPUFreq frequency table.

Problem reported by Felipe Balbi <[email protected]>. Thanks also for comments on the patch from Felipe.

---
 arch/arm/mach-omap2/clock2xxx.c |   45 ++++++++++++++++++++++++++++++++-------
 1 files changed, 37 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/clock2xxx.c +37 -8
index ce6742f..3bfd045 100644
@@ -449,14 +449,16 @@ int omap2_select_table_rate(struct clk *clk, unsigned long rate)
 #ifdef CONFIG_CPU_FREQ
 /*
  * Walk PRCM rate table and fillout cpufreq freq_table
+ * XXX This should be replaced by an OPP layer in the near future
  */
-static struct cpufreq_frequency_table freq_table[ARRAY_SIZE(rate_table)];
+static struct cpufreq_frequency_table *freq_table;
 
 void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 {
-	struct prcm_config *prcm;
+	const struct prcm_config *prcm;
 	long sys_ck_rate;
 	int i = 0;
+	int tbl_sz = 0;
 
 	sys_ck_rate = clk_get_rate(sclk);
 
@@ -470,17 +472,44 @@ void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 		if (prcm->dpll_speed == prcm->xtal_speed)
 			continue;
 
-		freq_table[i].index = i;
-		freq_table[i].frequency = prcm->mpu_speed / 1000;
-		i++;
+		tbl_sz++;
 	}
 
-	if (i == 0) {
-		printk(KERN_WARNING "%s: failed to initialize frequency "
-		       "table\n", __func__);
+	/*
+	 * XXX Ensure that we're doing what CPUFreq expects for this error
+	 * case and the following one
+	 */
+	if (tbl_sz == 0) {
+		pr_warning("%s: no matching entries in rate_table\n",
+			   __func__);
 		return;
 	}
 
+	/* Include the CPUFREQ_TABLE_END terminator entry */
+	tbl_sz++;
+
+	freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) * tbl_sz,
+			     GFP_KERNEL);
+	if (!freq_table) {
+		pr_err("%s: could not kzalloc frequency table\n", __func__);
+		return;
+	}
+
+	for (prcm = rate_table; prcm->mpu_speed; prcm++) {
+		if (!(prcm->flags & cpu_mask))
+			continue;
+		if (prcm->xtal_speed != sys_ck_rate)
+			continue;
+
+		/* don't put bypass rates in table */
+		if (prcm->dpll_speed == prcm->xtal_speed)
+			continue;
+
+		freq_table[i].index = i;
+		freq_table[i].frequency = prcm->mpu_speed / 1000;
+		i++;
+	}
+
 	freq_table[i].index = i;
 	freq_table[i].frequency = CPUFREQ_TABLE_END;
 
author maintainer
#4 lore raw

PATCH v2 4/4 OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table

In reply to Paul Walmsley

OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array, so this patch ensures that it is freed if CPUFreq terminates.

---
 arch/arm/mach-omap2/clock2xxx.c         |    7 +++++++
 arch/arm/plat-omap/clock.c              |   10 ++++++++++
 arch/arm/plat-omap/cpu-omap.c           |    1 +
 arch/arm/plat-omap/include/plat/clock.h |    2 ++
 4 files changed, 20 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/clock2xxx.c +7 -0
index 3bfd045..74f5586 100644
@@ -515,6 +515,12 @@ void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 
 	*table = &freq_table[0];
 }
+
+void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+	kfree(freq_table);
+}
+
 #endif
 
 struct clk_functions omap2_clk_functions = {
@@ -526,6 +532,7 @@ struct clk_functions omap2_clk_functions = {
 	.clk_disable_unused	= omap2_clk_disable_unused,
 #ifdef	CONFIG_CPU_FREQ
 	.clk_init_cpufreq_table	= omap2_clk_init_cpufreq_table,
+	.clk_exit_cpufreq_table	= omap2_clk_exit_cpufreq_table,
 #endif
 };
 
arch/arm/plat-omap/clock.c +10 -0
index a64d84c..d9f8c84 100644
@@ -329,6 +329,16 @@ void clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 		arch_clock->clk_init_cpufreq_table(table);
 	spin_unlock_irqrestore(&clockfw_lock, flags);
 }
+
+void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&clockfw_lock, flags);
+	if (arch_clock->clk_exit_cpufreq_table)
+		arch_clock->clk_exit_cpufreq_table(table);
+	spin_unlock_irqrestore(&clockfw_lock, flags);
+}
 #endif
 
 /*-------------------------------------------------------------------------*/
arch/arm/plat-omap/cpu-omap.c +1 -0
index f8ddbdd..6d3d333 100644
@@ -134,6 +134,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 
 static int omap_cpu_exit(struct cpufreq_policy *policy)
 {
+	clk_exit_cpufreq_table(&freq_table);
 	clk_put(mpu_clk);
 	return 0;
 }
arch/arm/plat-omap/include/plat/clock.h +2 -0
index 309b6d1..94fe2a0 100644
@@ -119,6 +119,7 @@ struct clk_functions {
 	void		(*clk_disable_unused)(struct clk *clk);
 #ifdef CONFIG_CPU_FREQ
 	void		(*clk_init_cpufreq_table)(struct cpufreq_frequency_table **);
+	void		(*clk_exit_cpufreq_table)(struct cpufreq_frequency_table **);
 #endif
 };
 
@@ -135,6 +136,7 @@ extern unsigned long followparent_recalc(struct clk *clk);
 extern void clk_enable_init_clocks(void);
 #ifdef CONFIG_CPU_FREQ
 extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
+extern void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table);
 #endif
 
 extern const struct clkops clkops_null;
#5 lore raw

Re: [PATCH v2 4/4] OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table

Quoted 4 lines · Paul Walmsley

OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array, so this patch ensures that it is freed if CPUFreq terminates.

Minor nit, but shouldn't this be just folded into PATCH 3/4 since you add the dynamic allocation there?

Kevin

Quoted 91 lines
---
 arch/arm/mach-omap2/clock2xxx.c         |    7 +++++++
 arch/arm/plat-omap/clock.c              |   10 ++++++++++
 arch/arm/plat-omap/cpu-omap.c           |    1 +
 arch/arm/plat-omap/include/plat/clock.h |    2 ++
 4 files changed, 20 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/clock2xxx.c +7 -0
index 3bfd045..74f5586 100644
@@ -515,6 +515,12 @@ void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 
 	*table = &freq_table[0];
 }
+
+void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+	kfree(freq_table);
+}
+
 #endif
 
 struct clk_functions omap2_clk_functions = {
@@ -526,6 +532,7 @@ struct clk_functions omap2_clk_functions = {
 	.clk_disable_unused	= omap2_clk_disable_unused,
 #ifdef	CONFIG_CPU_FREQ
 	.clk_init_cpufreq_table	= omap2_clk_init_cpufreq_table,
+	.clk_exit_cpufreq_table	= omap2_clk_exit_cpufreq_table,
 #endif
 };
 
arch/arm/plat-omap/clock.c +10 -0
index a64d84c..d9f8c84 100644
@@ -329,6 +329,16 @@ void clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
 		arch_clock->clk_init_cpufreq_table(table);
 	spin_unlock_irqrestore(&clockfw_lock, flags);
 }
+
+void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&clockfw_lock, flags);
+	if (arch_clock->clk_exit_cpufreq_table)
+		arch_clock->clk_exit_cpufreq_table(table);
+	spin_unlock_irqrestore(&clockfw_lock, flags);
+}
 #endif
 
 /*-------------------------------------------------------------------------*/
arch/arm/plat-omap/cpu-omap.c +1 -0
index f8ddbdd..6d3d333 100644
@@ -134,6 +134,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy)
 
 static int omap_cpu_exit(struct cpufreq_policy *policy)
 {
+	clk_exit_cpufreq_table(&freq_table);
 	clk_put(mpu_clk);
 	return 0;
 }
arch/arm/plat-omap/include/plat/clock.h +2 -1
index 309b6d1..94fe2a0 100644
@@ -119,6 +119,7 @@ struct clk_functions {
 	void		(*clk_disable_unused)(struct clk *clk);
 #ifdef CONFIG_CPU_FREQ
 	void		(*clk_init_cpufreq_table)(struct cpufreq_frequency_table **);
+	void		(*clk_exit_cpufreq_table)(struct cpufreq_frequency_table **);
 #endif
 };
 
@@ -135,6 +136,7 @@ extern unsigned long followparent_recalc(struct clk *clk);
 extern void clk_enable_init_clocks(void);
 #ifdef CONFIG_CPU_FREQ
 extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
+extern void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table);
 #endif
 
 extern const struct clkops clkops_null;
 
 
--

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

author maintainer
#6 lore raw

Re: [PATCH v2 4/4] OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table

Quoted 9 lines · Kevin Hilman
Quoted 4 lines · Paul Walmsley

OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array, so this patch ensures that it is freed if CPUFreq terminates.

Minor nit, but shouldn't this be just folded into PATCH 3/4 since you add the dynamic allocation there?

I guess it's a matter of taste. Maybe this is what Felipe was talking about.

The addition of clk_exit_cpufreq_table belongs in a separate patch. So I will split that part out and put it earlier in the series.

- Paul

maintainer
#7 lore raw
In reply to Paul Walmsley
Quoted 11 lines · Paul Walmsley

Hello,

This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi <[email protected]>.

Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at:

Quoted 6 lines

http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/

Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP.

This second version also incorporates some comments from Felipe.

These look good to me, can you please send them one more time with LAKML Cc'd for a quick review there?

Regards,

Tony

Quoted 28 lines

- Paul

---

Felipe Balbi (1):
OMAP2xxx clock: clk2xxx.c doesn't compile if CPUFREQ is enabled

Paul Walmsley (3):
OMAP2xxx OPP: clean up comments in OPP data
OMAP2 clock: dynamically allocate CPUFreq frequency table OMAP clock/CPUFreq: avoid leaking the CPUFreq frequency table

 arch/arm/mach-omap2/clock2xxx.c         |   57 ++++++++++++++++++++++++++-----
 arch/arm/mach-omap2/opp2420_data.c      |   38 +++++++++++----------
 arch/arm/mach-omap2/opp2430_data.c      |   30 ++++++++--------
 arch/arm/plat-omap/clock.c              |   10 +++++
 arch/arm/plat-omap/cpu-omap.c           |    1 +
 arch/arm/plat-omap/include/plat/clock.h |    2 +
 6 files changed, 96 insertions(+), 42 deletions(-)

--
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

author maintainer
#8 lore raw
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Paul Walmsley

Hello,

This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi <[email protected]>.

Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at:

http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/

Quoted 7 lines
Quoted 4 lines

Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP.

This second version also incorporates some comments from Felipe.

These look good to me, can you please send them one more time with LAKML Cc'd for a quick review there?

Yes, I plan to send them there along with some other queued fixes for another .33-rc fixes series.

- Paul

maintainer
#9 lore raw
Quoted 19 lines · Paul Walmsley
Quoted 17 lines · Tony Lindgren
Quoted 16 lines · Paul Walmsley

Hello,

This series fixes several compilation errors for OMAP2xxx chips when CONFIG_CPU_FREQ is set. These were reported and partially fixed by Felipe Balbi <[email protected]>.

Considerable work is still needed to fully support dynamic frequency changes on OMAP2xxx-series chips. Readers interested in such a project are encouraged to review the Maemo Diablo RX-34 and RX-44 kernel source at:

http://repository.maemo.org/pool/diablo/free/k/kernel-source-diablo/

Boot-tested on N800 with n8x0_defconfig with CONFIG_CPU_FREQ; compile-tested for 2430SDP.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

This second version also incorporates some comments from Felipe.

These look good to me, can you please send them one more time with LAKML Cc'd for a quick review there?

Yes, I plan to send them there along with some other queued fixes for another .33-rc fixes series.

OK, thanks.

Tony