[PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table

[PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

Since the cpufreq table is dependant on the prmcu fw, it make sense to
keep the table there. Moreover since the cpufreq is already a mfd child
device added by the prcmu this make even more logic.

The next step after these patches will be to implement an "arm_clk" to be
used from cpufreq to update the opp instead of using the prcmu opp API directly.
This will then remove the last hard dependency to the prcmu API from cpufreq.

Ulf Hansson (4):
  ARM: ux500: Remove cpufreq platform device
  mfd: db8500: Provide cpufreq table as platform data
  cpufreq: db8500: Register as a platform driver
  cpufreq: db8500: Fetch cpufreq table from platform data

 arch/arm/mach-ux500/cpu-db8500.c |    6 ---
 drivers/cpufreq/db8500-cpufreq.c |   87 +++++++++++++++++++-------------------
 drivers/mfd/db8500-prcmu.c       |   22 ++++++++++
 3 files changed, 66 insertions(+), 49 deletions(-)

-- 
1.7.10

[PATCH 1/4] ARM: ux500: Remove cpufreq platform device

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

The cpufreq device is already added from the prcmu driver as
a mfd child device.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 arch/arm/mach-ux500/cpu-db8500.c |    6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index bcdfe6b..41b2779 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -214,9 +214,6 @@ struct device * __init u8500_init_devices(struct ab8500_platform_data *ab8500)
 	db8500_add_gpios(parent);
 	db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
 
-	platform_device_register_data(parent,
-		"cpufreq-u8500", -1, NULL, 0);
-
 	for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
 		platform_devs[i]->dev.parent = parent;
 
@@ -236,9 +233,6 @@ struct device * __init u8500_of_init_devices(void)
 
 	db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
 
-	platform_device_register_data(parent,
-		"cpufreq-u8500", -1, NULL, 0);
-
 	u8500_dma40_device.dev.parent = parent;
 
 	/*
-- 
1.7.10

[PATCH 2/4] mfd: db8500: Provide cpufreq table as platform data

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

The cpufreq table needs dynamically update due to what the PRCMU
firmware is supporting. The table is then provided through to the
mfd child device as platform data.

Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/mfd/db8500-prcmu.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index bac4876..163d1b3 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -31,6 +31,7 @@
 #include <linux/mfd/abx500/ab8500.h>
 #include <linux/regulator/db8500-prcmu.h>
 #include <linux/regulator/machine.h>
+#include <linux/cpufreq.h>
 #include <asm/hardware/gic.h>
 #include <mach/hardware.h>
 #include <mach/irqs.h>
@@ -3001,6 +3002,15 @@ static struct regulator_init_data db8500_regulators[DB8500_NUM_REGULATORS] = {
 	},
 };
 
+/* CPU FREQ table, may be changed due to if MAX_OPP is supported. */
+static struct cpufreq_frequency_table db8500_cpufreq_table[] = {
+	{ .frequency = 200000, .index = ARM_EXTCLK,},
+	{ .frequency = 400000, .index = ARM_50_OPP,},
+	{ .frequency = 800000, .index = ARM_100_OPP,},
+	{ .frequency = CPUFREQ_TABLE_END,}, /* To be used for MAX_OPP. */
+	{ .frequency = CPUFREQ_TABLE_END,},
+};
+
 static struct resource ab8500_resources[] = {
 	[0] = {
 		.start	= IRQ_DB8500_AB8500,
@@ -3019,6 +3029,8 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 	{
 		.name = "cpufreq-u8500",
 		.of_compatible = "stericsson,cpufreq-u8500",
+		.platform_data = &db8500_cpufreq_table,
+		.pdata_size = sizeof(db8500_cpufreq_table),
 	},
 	{
 		.name = "ab8500-core",
@@ -3029,6 +3041,14 @@ static struct mfd_cell db8500_prcmu_devs[] = {
 	},
 };
 
+static void db8500_prcmu_update_cpufreq(void)
+{
+	if (prcmu_has_arm_maxopp()) {
+		db8500_cpufreq_table[3].frequency = 1000000;
+		db8500_cpufreq_table[3].index = ARM_MAX_OPP;
+	}
+}
+
 /**
  * prcmu_fw_init - arch init call for the Linux PRCMU fw init logic
  *
@@ -3073,6 +3093,8 @@ static int __devinit db8500_prcmu_probe(struct platform_device *pdev)
 	if (cpu_is_u8500v20_or_later())
 		prcmu_config_esram0_deep_sleep(ESRAM0_DEEP_SLEEP_STATE_RET);
 
+	db8500_prcmu_update_cpufreq();
+
 	err = mfd_add_devices(&pdev->dev, 0, db8500_prcmu_devs,
 			      ARRAY_SIZE(db8500_prcmu_devs), NULL, 0, NULL);
 	if (err) {
-- 
1.7.10

[PATCH 3/4] cpufreq: db8500: Register as a platform driver

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

To fetch the mfd child device we register the cpufreq driver
as a platform driver.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/cpufreq/db8500-cpufreq.c |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
index 74b830b..7d61a6c 100644
--- a/drivers/cpufreq/db8500-cpufreq.c
+++ b/drivers/cpufreq/db8500-cpufreq.c
@@ -8,10 +8,12 @@
  * Author: Jonas Aaberg <jonas.aberg@stericsson.com>
  *
  */
+#include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/cpufreq.h>
 #include <linux/delay.h>
 #include <linux/slab.h>
+#include <linux/platform_device.h>
 #include <linux/mfd/dbx500-prcmu.h>
 #include <mach/id.h>
 
@@ -159,12 +161,28 @@ static struct cpufreq_driver db8500_cpufreq_driver = {
 	.attr   = db8500_cpufreq_attr,
 };
 
+static int db8500_cpufreq_probe(struct platform_device *pdev)
+{
+	return cpufreq_register_driver(&db8500_cpufreq_driver);
+}
+
+static struct platform_driver db8500_cpufreq_plat_driver = {
+	.driver = {
+		.name = "cpufreq-u8500",
+		.owner = THIS_MODULE,
+	},
+	.probe = db8500_cpufreq_probe,
+};
+
 static int __init db8500_cpufreq_register(void)
 {
 	if (!cpu_is_u8500_family())
 		return -ENODEV;
 
 	pr_info("cpufreq for DB8500 started\n");
-	return cpufreq_register_driver(&db8500_cpufreq_driver);
+	return platform_driver_register(&db8500_cpufreq_plat_driver);
 }
 device_initcall(db8500_cpufreq_register);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("cpufreq driver for DB8500");
-- 
1.7.10

[PATCH 4/4] cpufreq: db8500: Fetch cpufreq table from platform data

[Ulf Hansson]

From: Ulf Hansson <ulf.hansson@linaro.org>

By fetching the table as platform data we do not need the internally
hardcoded cpufreq table anymore.

Moreover the corresponding arm_opp idx2opp table, used for mapping
frequency to correct opp bits is also removed. This due to that the
opp bits is put directly in the index field of the cpufreq table.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/cpufreq/db8500-cpufreq.c |   67 ++++++++++++++------------------------
 1 file changed, 25 insertions(+), 42 deletions(-)

diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
index 7d61a6c..dea9a49 100644
--- a/drivers/cpufreq/db8500-cpufreq.c
+++ b/drivers/cpufreq/db8500-cpufreq.c
@@ -17,36 +17,7 @@
 #include <linux/mfd/dbx500-prcmu.h>
 #include <mach/id.h>
 
-static struct cpufreq_frequency_table freq_table[] = {
-	[0] = {
-		.index = 0,
-		.frequency = 200000,
-	},
-	[1] = {
-		.index = 1,
-		.frequency = 400000,
-	},
-	[2] = {
-		.index = 2,
-		.frequency = 800000,
-	},
-	[3] = {
-		/* Used for MAX_OPP, if available */
-		.index = 3,
-		.frequency = CPUFREQ_TABLE_END,
-	},
-	[4] = {
-		.index = 4,
-		.frequency = CPUFREQ_TABLE_END,
-	},
-};
-
-static enum arm_opp idx2opp[] = {
-	ARM_EXTCLK,
-	ARM_50_OPP,
-	ARM_100_OPP,
-	ARM_MAX_OPP
-};
+static struct cpufreq_frequency_table *freq_table;
 
 static struct freq_attr *db8500_cpufreq_attr[] = {
 	&cpufreq_freq_attr_scaling_available_freqs,
@@ -88,7 +59,7 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
 		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
 
 	/* request the PRCM unit for opp change */
-	if (prcmu_set_arm_opp(idx2opp[idx])) {
+	if (prcmu_set_arm_opp(freq_table[idx].index)) {
 		pr_err("db8500-cpufreq:  Failed to set OPP level\n");
 		return -EINVAL;
 	}
@@ -102,25 +73,30 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
 
 static unsigned int db8500_cpufreq_getspeed(unsigned int cpu)
 {
-	int i;
+	int i = 0;
 	/* request the prcm to get the current ARM opp */
-	for (i = 0; prcmu_get_arm_opp() != idx2opp[i]; i++)
-		;
-	return freq_table[i].frequency;
+	int opp = prcmu_get_arm_opp();
+
+	while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
+		if (opp == freq_table[i].index)
+			return freq_table[i].frequency;
+		i++;
+	}
+
+	/* We could not find a corresponding opp frequency. */
+	return 0;
 }
 
 static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
 {
-	int i, res;
-
-	BUILD_BUG_ON(ARRAY_SIZE(idx2opp) + 1 != ARRAY_SIZE(freq_table));
-
-	if (prcmu_has_arm_maxopp())
-		freq_table[3].frequency = 1000000;
+	int i = 0;
+	int res;
 
 	pr_info("db8500-cpufreq : Available frequencies:\n");
-	for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
+	while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
 		pr_info("  %d Mhz\n", freq_table[i].frequency/1000);
+		i++;
+	}
 
 	/* get policy fields based on the table */
 	res = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -163,6 +139,13 @@ static struct cpufreq_driver db8500_cpufreq_driver = {
 
 static int db8500_cpufreq_probe(struct platform_device *pdev)
 {
+	freq_table = dev_get_platdata(&pdev->dev);
+
+	if (!freq_table) {
+		pr_err("db8500-cpufreq: Failed to fetch cpufreq table\n");
+		return -ENODEV;
+	}
+
 	return cpufreq_register_driver(&db8500_cpufreq_driver);
 }
 
-- 
1.7.10

[PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table

[Jonas Aaberg]

All patches look good.

Acked-by: Jonas Aaberg <jonas.aberg@stericsson.com>

On 09/28/2012 04:16 PM, Ulf HANSSON wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
> 
> Since the cpufreq table is dependant on the prmcu fw, it make sense to
> keep the table there. Moreover since the cpufreq is already a mfd child
> device added by the prcmu this make even more logic.
> 
> The next step after these patches will be to implement an "arm_clk" to be
> used from cpufreq to update the opp instead of using the prcmu opp API directly.
> This will then remove the last hard dependency to the prcmu API from cpufreq.
> 
> Ulf Hansson (4):
>   ARM: ux500: Remove cpufreq platform device
>   mfd: db8500: Provide cpufreq table as platform data
>   cpufreq: db8500: Register as a platform driver
>   cpufreq: db8500: Fetch cpufreq table from platform data
> 
>  arch/arm/mach-ux500/cpu-db8500.c |    6 ---
>  drivers/cpufreq/db8500-cpufreq.c |   87 +++++++++++++++++++-------------------
>  drivers/mfd/db8500-prcmu.c       |   22 ++++++++++
>  3 files changed, 66 insertions(+), 49 deletions(-)
> 

[PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table

[Linus Walleij]

On Fri, Sep 28, 2012 at 4:16 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Since the cpufreq table is dependant on the prmcu fw, it make sense to
> keep the table there. Moreover since the cpufreq is already a mfd child
> device added by the prcmu this make even more logic.

Better there than elsewhere.

> The next step after these patches will be to implement an "arm_clk" to be
> used from cpufreq to update the opp instead of using the prcmu opp API directly.
> This will then remove the last hard dependency to the prcmu API from cpufreq.

Sounds like a plan.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Is this going to be merged through the cpufreq tree or the MFD tree?

Yours,
Linus Walleij

[PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table

[Ulf Hansson]

On 2 October 2012 13:45, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Sep 28, 2012 at 4:16 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Since the cpufreq table is dependant on the prmcu fw, it make sense to
>> keep the table there. Moreover since the cpufreq is already a mfd child
>> device added by the prcmu this make even more logic.
>
> Better there than elsewhere.
>
>> The next step after these patches will be to implement an "arm_clk" to be
>> used from cpufreq to update the opp instead of using the prcmu opp API directly.
>> This will then remove the last hard dependency to the prcmu API from cpufreq.
>
> Sounds like a plan.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Is this going to be merged through the cpufreq tree or the MFD tree?

Good question! Actually I would prefer to go through Mike Turquette
clock tree, if he feel it is OK of course.
My idea is then get the Ack from Rafael for cpufreq patches and from
Samuel for the mfd patches.

The reason for doing this in a quite complicated manner is that my
soon upcoming clock and mfd patches will functionality wise depend on
these patches, and don't want to be sitting around and waiting for a
new rc before being able to push the next series.

Kind regards
Ulf Hansson

[PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table

[Rafael J. Wysocki]

On Wednesday 03 of October 2012 12:12:05 Ulf Hansson wrote:
> On 2 October 2012 13:45, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Fri, Sep 28, 2012 at 4:16 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> >
> >> From: Ulf Hansson <ulf.hansson@linaro.org>
> >>
> >> Since the cpufreq table is dependant on the prmcu fw, it make sense to
> >> keep the table there. Moreover since the cpufreq is already a mfd child
> >> device added by the prcmu this make even more logic.
> >
> > Better there than elsewhere.
> >
> >> The next step after these patches will be to implement an "arm_clk" to be
> >> used from cpufreq to update the opp instead of using the prcmu opp API directly.
> >> This will then remove the last hard dependency to the prcmu API from cpufreq.
> >
> > Sounds like a plan.
> >
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > Is this going to be merged through the cpufreq tree or the MFD tree?
> 
> Good question! Actually I would prefer to go through Mike Turquette
> clock tree, if he feel it is OK of course.
> My idea is then get the Ack from Rafael for cpufreq patches and from
> Samuel for the mfd patches.
> 
> The reason for doing this in a quite complicated manner is that my
> soon upcoming clock and mfd patches will functionality wise depend on
> these patches, and don't want to be sitting around and waiting for a
> new rc before being able to push the next series.

The cpufreq patches look good to me, please feel free to tag them as ACKed by me.

Thanks,
Rafael


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