[PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

[PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

[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 <felipe.balbi@nokia.com>.

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

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

[Paul Walmsley]

From: Felipe Balbi <felipe.balbi@nokia.com>

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

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
[paul@pwsan.com: commit message updated; changed rate variable name]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/clock2xxx.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index d0e3fb7..ce6742f 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -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 */

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

[Paul Walmsley]

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

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
---
 arch/arm/mach-omap2/opp2420_data.c |   38 +++++++++++++++++++-----------------
 arch/arm/mach-omap2/opp2430_data.c |   30 ++++++++++++++--------------
 2 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/opp2420_data.c b/arch/arm/mach-omap2/opp2420_data.c
index 126a939..e6dda69 100644
--- a/arch/arm/mach-omap2/opp2420_data.c
+++ b/arch/arm/mach-omap2/opp2420_data.c
@@ -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 */
diff --git a/arch/arm/mach-omap2/opp2430_data.c b/arch/arm/mach-omap2/opp2430_data.c
index edb8167..1b9596a 100644
--- a/arch/arm/mach-omap2/opp2430_data.c
+++ b/arch/arm/mach-omap2/opp2430_data.c
@@ -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 */

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

[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 <felipe.balbi@nokia.com>.  Thanks also
for comments on the patch from Felipe.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
---
 arch/arm/mach-omap2/clock2xxx.c |   45 ++++++++++++++++++++++++++++++++-------
 1 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index ce6742f..3bfd045 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -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;
 

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

[Paul Walmsley]

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

Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index 3bfd045..74f5586 100644
--- a/arch/arm/mach-omap2/clock2xxx.c
+++ b/arch/arm/mach-omap2/clock2xxx.c
@@ -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
 };
 
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index a64d84c..d9f8c84 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -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
 
 /*-------------------------------------------------------------------------*/
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index f8ddbdd..6d3d333 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -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;
 }
diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
index 309b6d1..94fe2a0 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -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;

Re: [PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [100105 09:35]:
> 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 <felipe.balbi@nokia.com>.
> 
> 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.

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

Regards,

Tony

> 
> 
> - 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

[Paul Walmsley]

On Tue, 5 Jan 2010, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [100105 09:35]:
> > 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 <felipe.balbi@nokia.com>.
> > 
> > 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.
> 
> 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

Re: [PATCH v2 0/4] OMAP2xxx clock/CPUFreq: fix compilation errors; clean up

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [100105 10:20]:
> On Tue, 5 Jan 2010, Tony Lindgren wrote:
> 
> > * Paul Walmsley <paul@pwsan.com> [100105 09:35]:
> > > 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 <felipe.balbi@nokia.com>.
> > > 
> > > 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.
> > 
> > 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

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

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array,
> so this patch ensures that it is freed if CPUFreq terminates.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>

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

Kevin


> ---
>  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(-)
>
> diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
> index 3bfd045..74f5586 100644
> --- a/arch/arm/mach-omap2/clock2xxx.c
> +++ b/arch/arm/mach-omap2/clock2xxx.c
> @@ -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
>  };
>  
> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> index a64d84c..d9f8c84 100644
> --- a/arch/arm/plat-omap/clock.c
> +++ b/arch/arm/plat-omap/clock.c
> @@ -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
>  
>  /*-------------------------------------------------------------------------*/
> diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
> index f8ddbdd..6d3d333 100644
> --- a/arch/arm/plat-omap/cpu-omap.c
> +++ b/arch/arm/plat-omap/cpu-omap.c
> @@ -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;
>  }
> diff --git a/arch/arm/plat-omap/include/plat/clock.h b/arch/arm/plat-omap/include/plat/clock.h
> index 309b6d1..94fe2a0 100644
> --- a/arch/arm/plat-omap/include/plat/clock.h
> +++ b/arch/arm/plat-omap/include/plat/clock.h
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Paul Walmsley]

On Wed, 6 Jan 2010, Kevin Hilman wrote:

> Paul Walmsley <paul@pwsan.com> writes:
> 
> > OMAP2xxx uses a dynamically-allocated cpufreq_frequency_table array,
> > so this patch ensures that it is freed if CPUFreq terminates.
> >
> > Signed-off-by: Paul Walmsley <paul@pwsan.com>
> 
> 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