[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Tero Kristo]

Hi,

Seems like MPU DVFS does not scale the voltages currently with DT boot,
due to missing mapping between regulator -> VCVP. Fixed this by adding
support for platform data in the TWL regulator DT case + adding platform
data quirk for the same. This same already works in the legacy boot, the
platform data is passed fine.

Tested on omap3-beagle by measuring the MPU voltage rail.

OMAP4+ platforms do not currently register DVFS regulator, so this set by
itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
for OMAP4460.)

-Tero

[REPOST PATCH 1/2] ARM: OMAP3+: TWL: add support for mapping platform data via pdata-quirks

[Tero Kristo]

Device tree based boot does not currently support DVFS voltage scaling,
as the VC/VP mapping is broken. This patch adds support to provide
platform data in the device tree boot case also, basically to pass the
function pointers to the vc/vp core for voltage changes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
---
 arch/arm/mach-omap2/pdata-quirks.c |    8 ++--
 arch/arm/mach-omap2/twl-common.c   |   88 ++++++++++++++++++++++++++++++++----
 arch/arm/mach-omap2/twl-common.h   |    2 +
 3 files changed, 84 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 90c88d4..03e4a86 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -311,10 +311,10 @@ void omap_auxdata_legacy_init(struct device *dev)
 	if (dev->platform_data)
 		return;
 
-	if (strcmp("twl4030-gpio", dev_name(dev)))
-		return;
-
-	dev->platform_data = &twl_gpio_auxdata;
+	if (!strcmp("twl4030-gpio", dev_name(dev)))
+		dev->platform_data = &twl_gpio_auxdata;
+	else
+		dev->platform_data = omap_twl_match_regulator(dev);
 }
 
 /*
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..50f6d33 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -210,17 +210,37 @@ static struct twl_regulator_driver_data omap3_vdd2_drvdata = {
 	.set_voltage = twl_set_voltage,
 };
 
+struct pmic_drvdata_config {
+	const char *voltdm;
+	struct twl_regulator_driver_data *data;
+};
+
+static struct pmic_drvdata_config twl4030_vdd1 = {
+	.voltdm = "mpu_iva",
+	.data = &omap3_vdd1_drvdata,
+};
+
+static struct pmic_drvdata_config twl4030_vdd2 = {
+	.voltdm = "core",
+	.data = &omap3_vdd2_drvdata,
+};
+
+struct twl_regulator_driver_data
+*omap_pmic_get_drvdata(struct pmic_drvdata_config *conf)
+{
+	conf->data->data = voltdm_lookup(conf->voltdm);
+	return conf->data;
+}
+
 void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
 				  u32 pdata_flags, u32 regulators_flags)
 {
 	if (!pmic_data->vdd1) {
-		omap3_vdd1.driver_data = &omap3_vdd1_drvdata;
-		omap3_vdd1_drvdata.data = voltdm_lookup("mpu_iva");
+		omap3_vdd1.driver_data = omap_pmic_get_drvdata(&twl4030_vdd1);
 		pmic_data->vdd1 = &omap3_vdd1;
 	}
 	if (!pmic_data->vdd2) {
-		omap3_vdd2.driver_data = &omap3_vdd2_drvdata;
-		omap3_vdd2_drvdata.data = voltdm_lookup("core");
+		omap3_vdd2.driver_data = omap_pmic_get_drvdata(&twl4030_vdd2);
 		pmic_data->vdd2 = &omap3_vdd2;
 	}
 
@@ -440,6 +460,21 @@ static struct twl_regulator_driver_data omap4_vdd3_drvdata = {
 	.set_voltage = twl_set_voltage,
 };
 
+static struct pmic_drvdata_config twl6030_vdd1 = {
+	.voltdm = "mpu",
+	.data = &omap4_vdd1_drvdata,
+};
+
+static struct pmic_drvdata_config twl6030_vdd2 = {
+	.voltdm = "iva",
+	.data = &omap4_vdd2_drvdata,
+};
+
+static struct pmic_drvdata_config twl6030_vdd3 = {
+	.voltdm = "core",
+	.data = &omap4_vdd3_drvdata,
+};
+
 static struct regulator_consumer_supply omap4_v1v8_supply[] = {
 	REGULATOR_SUPPLY("vio", "1-004b"),
 };
@@ -475,24 +510,57 @@ static struct regulator_init_data omap4_v2v1_idata = {
 	.consumer_supplies	= omap4_v2v1_supply,
 };
 
+static struct of_device_id twl_regulator_ids[] = {
+	{ .compatible = "ti,twl4030-vdd1", .data = &twl4030_vdd1, },
+	{ .compatible = "ti,twl4030-vdd2", .data = &twl4030_vdd2, },
+	{ .compatible = "ti,twl6030-vdd1", .data = &twl6030_vdd1, },
+	{ .compatible = "ti,twl6030-vdd2", .data = &twl6030_vdd2, },
+	{ .compatible = "ti,twl6030-vdd3", .data = &twl6030_vdd3, },
+	{}
+};
+
+/**
+ * omap_twl_match_regulator - match regulator against a device
+ * @dev: device to check for regulator match
+ *
+ * Checks if the device provided is a supported regulator device. If yes,
+ * will initialize the corresponding platform data structure for it and
+ * return it for the caller to use. Returns NULL if not supported,
+ * a pointer to the regulator platform data struct otherwise.
+ */
+void *omap_twl_match_regulator(struct device *dev)
+{
+	const struct of_device_id *match;
+	struct pmic_drvdata_config *conf;
+
+	if (!dev->of_node)
+		return NULL;
+
+	match = of_match_node(twl_regulator_ids, dev->of_node);
+
+	if (!match)
+		return NULL;
+
+	conf = (struct pmic_drvdata_config *)match->data;
+
+	return omap_pmic_get_drvdata(conf);
+}
+
 void __init omap4_pmic_get_config(struct twl4030_platform_data *pmic_data,
 				  u32 pdata_flags, u32 regulators_flags)
 {
 	if (!pmic_data->vdd1) {
-		omap4_vdd1.driver_data = &omap4_vdd1_drvdata;
-		omap4_vdd1_drvdata.data = voltdm_lookup("mpu");
+		omap4_vdd1.driver_data = omap_pmic_get_drvdata(&twl6030_vdd1);
 		pmic_data->vdd1 = &omap4_vdd1;
 	}
 
 	if (!pmic_data->vdd2) {
-		omap4_vdd2.driver_data = &omap4_vdd2_drvdata;
-		omap4_vdd2_drvdata.data = voltdm_lookup("iva");
+		omap4_vdd2.driver_data = omap_pmic_get_drvdata(&twl6030_vdd2);
 		pmic_data->vdd2 = &omap4_vdd2;
 	}
 
 	if (!pmic_data->vdd3) {
-		omap4_vdd3.driver_data = &omap4_vdd3_drvdata;
-		omap4_vdd3_drvdata.data = voltdm_lookup("core");
+		omap4_vdd3.driver_data = omap_pmic_get_drvdata(&twl6030_vdd3);
 		pmic_data->vdd3 = &omap4_vdd3;
 	}
 
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b392ade 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -55,6 +55,8 @@ void omap4_pmic_init(const char *pmic_type,
 		    struct twl4030_platform_data *pmic_data,
 		    struct i2c_board_info *devices, int nr_devices);
 
+void *omap_twl_match_regulator(struct device *dev);
+
 void omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
 			   u32 pdata_flags, u32 regulators_flags);
 
-- 
1.7.9.5

[REPOST PATCH 2/2] regulator: twl: use platform data in the DT based boot also

[Tero Kristo]

This allows to pass platform information during a DT boot also, currently
this is completely ignored. Needed for supporting the platform specific
regulator set_voltage / get_voltage ops for the SMPS regulators.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
---
 drivers/regulator/twl-regulator.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 0b4f866..2c4fa06 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1103,9 +1103,9 @@ static int twlreg_probe(struct platform_device *pdev)
 	if (match) {
 		template = match->data;
 		id = template->desc.id;
+		drvdata = dev_get_platdata(&pdev->dev);
 		initdata = of_get_regulator_init_data(&pdev->dev,
 						      pdev->dev.of_node);
-		drvdata = NULL;
 	} else {
 		id = pdev->id;
 		initdata = dev_get_platdata(&pdev->dev);
-- 
1.7.9.5

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Enric Balletbo Serra]

Hi,

2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
> Hi,
>
> Seems like MPU DVFS does not scale the voltages currently with DT boot,
> due to missing mapping between regulator -> VCVP. Fixed this by adding
> support for platform data in the TWL regulator DT case + adding platform
> data quirk for the same. This same already works in the legacy boot, the
> platform data is passed fine.
>
> Tested on omap3-beagle by measuring the MPU voltage rail.
>
> OMAP4+ platforms do not currently register DVFS regulator, so this set by
> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
> for OMAP4460.)
>
> -Tero
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tony proposed in the IRC apply this patch series in order to solve the
following error messages with kernel 3.17

[    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
vdd_mpu_iva
[    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
[    2.541564] omap2_set_init_voltage: unable to find boot up OPP for vdd_core
[    2.551208] omap2_set_init_voltage: unable to set vdd_core

I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
should these patches solve these errors ? Did you resolve these errors
on your Beagleboard ?

Cheers,
   Enric

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Tero Kristo]

On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
> Hi,
>
> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>> Hi,
>>
>> Seems like MPU DVFS does not scale the voltages currently with DT boot,
>> due to missing mapping between regulator -> VCVP. Fixed this by adding
>> support for platform data in the TWL regulator DT case + adding platform
>> data quirk for the same. This same already works in the legacy boot, the
>> platform data is passed fine.
>>
>> Tested on omap3-beagle by measuring the MPU voltage rail.
>>
>> OMAP4+ platforms do not currently register DVFS regulator, so this set by
>> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
>> for OMAP4460.)
>>
>> -Tero
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Tony proposed in the IRC apply this patch series in order to solve the
> following error messages with kernel 3.17
>
> [    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
> vdd_mpu_iva
> [    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
> [    2.541564] omap2_set_init_voltage: unable to find boot up OPP for vdd_core
> [    2.551208] omap2_set_init_voltage: unable to set vdd_core
>
> I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
> should these patches solve these errors ? Did you resolve these errors
> on your Beagleboard ?

These prints are caused by something else: namely the fact that 
beagleboard rev C4+ boots up at 720MHz. This OPP is not supported by the 
kernel and quelches out the warning prints.

This should be fixed by modifying the OPP tables under the dtsi files, 
however the nasty thing is not all beagleboards support 720MHz OPP. You 
either need to specify a dts file for beagle-revC4 or do some kernel 
magic to manually disable the 720MHz OPP on non-supported boards.

-Tero

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Enric Balletbo Serra]

2014-10-17 7:55 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
> On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
>>
>> Hi,
>>
>> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>
>>> Hi,
>>>
>>> Seems like MPU DVFS does not scale the voltages currently with DT boot,
>>> due to missing mapping between regulator -> VCVP. Fixed this by adding
>>> support for platform data in the TWL regulator DT case + adding platform
>>> data quirk for the same. This same already works in the legacy boot, the
>>> platform data is passed fine.
>>>
>>> Tested on omap3-beagle by measuring the MPU voltage rail.
>>>
>>> OMAP4+ platforms do not currently register DVFS regulator, so this set by
>>> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
>>> for OMAP4460.)
>>>
>>> -Tero
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>> Tony proposed in the IRC apply this patch series in order to solve the
>> following error messages with kernel 3.17
>>
>> [    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
>> vdd_mpu_iva
>> [    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
>> [    2.541564] omap2_set_init_voltage: unable to find boot up OPP for
>> vdd_core
>> [    2.551208] omap2_set_init_voltage: unable to set vdd_core
>>
>> I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
>> should these patches solve these errors ? Did you resolve these errors
>> on your Beagleboard ?
>
>
> These prints are caused by something else: namely the fact that beagleboard
> rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and
> quelches out the warning prints.
>
> This should be fixed by modifying the OPP tables under the dtsi files,
> however the nasty thing is not all beagleboards support 720MHz OPP. You
> either need to specify a dts file for beagle-revC4 or do some kernel magic
> to manually disable the 720MHz OPP on non-supported boards.
>

Adding and modifying some printk looks the problem is because it can't
find the device opp.

[    2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp
[    2.542755] omap2_set_init_voltage: unable to find boot up OPP for
vdd_mpu_iva (clk = dpll1_ck - freq = 600000000)
[    2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva

[    2.562957] platform 68000000.ocp: dev_pm_opp_find_freq_ceil: can't
find device opp
[    2.573333] omap2_set_init_voltage: unable to find boot up OPP for
vdd_core (clk = l3_ick - freq = 200000000)
[    2.584442] omap2_set_init_voltage: unable to set vdd_core


The of_init_opp_table who reads the 'operating-points" from dtb is
called after. Should be called before?

[    2.592834] cpu cpu0: of_init_opp_table: init_opp_table



> -Tero

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Tero Kristo]

On 10/17/2014 02:55 PM, Enric Balletbo Serra wrote:
> 2014-10-17 7:55 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>> On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
>>>
>>> Hi,
>>>
>>> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>>
>>>> Hi,
>>>>
>>>> Seems like MPU DVFS does not scale the voltages currently with DT boot,
>>>> due to missing mapping between regulator -> VCVP. Fixed this by adding
>>>> support for platform data in the TWL regulator DT case + adding platform
>>>> data quirk for the same. This same already works in the legacy boot, the
>>>> platform data is passed fine.
>>>>
>>>> Tested on omap3-beagle by measuring the MPU voltage rail.
>>>>
>>>> OMAP4+ platforms do not currently register DVFS regulator, so this set by
>>>> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
>>>> for OMAP4460.)
>>>>
>>>> -Tero
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>> Tony proposed in the IRC apply this patch series in order to solve the
>>> following error messages with kernel 3.17
>>>
>>> [    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
>>> vdd_mpu_iva
>>> [    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>> [    2.541564] omap2_set_init_voltage: unable to find boot up OPP for
>>> vdd_core
>>> [    2.551208] omap2_set_init_voltage: unable to set vdd_core
>>>
>>> I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
>>> should these patches solve these errors ? Did you resolve these errors
>>> on your Beagleboard ?
>>
>>
>> These prints are caused by something else: namely the fact that beagleboard
>> rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and
>> quelches out the warning prints.
>>
>> This should be fixed by modifying the OPP tables under the dtsi files,
>> however the nasty thing is not all beagleboards support 720MHz OPP. You
>> either need to specify a dts file for beagle-revC4 or do some kernel magic
>> to manually disable the 720MHz OPP on non-supported boards.
>>
>
> Adding and modifying some printk looks the problem is because it can't
> find the device opp.
>
> [    2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp
> [    2.542755] omap2_set_init_voltage: unable to find boot up OPP for
> vdd_mpu_iva (clk = dpll1_ck - freq = 600000000)
> [    2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva
>
> [    2.562957] platform 68000000.ocp: dev_pm_opp_find_freq_ceil: can't
> find device opp
> [    2.573333] omap2_set_init_voltage: unable to find boot up OPP for
> vdd_core (clk = l3_ick - freq = 200000000)
> [    2.584442] omap2_set_init_voltage: unable to set vdd_core
>
>
> The of_init_opp_table who reads the 'operating-points" from dtb is
> called after. Should be called before?
>
> [    2.592834] cpu cpu0: of_init_opp_table: init_opp_table
>

What is the board revision you got? Looks like it boots up at 600/200MHz.

You can also try tweaking around the tables under opp3xxx_data.c, not 
sure if these are initialized in the correct order either. However, the 
lack of these tables and the warnings mentioned do not prevent cpufreq 
from working, cpufreq is dependant on the DT tables. That being said, I 
am not sure if the legacy OPP tables are even needed anymore on DT boot...

-Tero

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Enric Balletbo Serra]

2014-10-17 14:35 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
> On 10/17/2014 02:55 PM, Enric Balletbo Serra wrote:
>>
>> 2014-10-17 7:55 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>
>>> On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Seems like MPU DVFS does not scale the voltages currently with DT boot,
>>>>> due to missing mapping between regulator -> VCVP. Fixed this by adding
>>>>> support for platform data in the TWL regulator DT case + adding
>>>>> platform
>>>>> data quirk for the same. This same already works in the legacy boot,
>>>>> the
>>>>> platform data is passed fine.
>>>>>
>>>>> Tested on omap3-beagle by measuring the MPU voltage rail.
>>>>>
>>>>> OMAP4+ platforms do not currently register DVFS regulator, so this set
>>>>> by
>>>>> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
>>>>> for OMAP4460.)
>>>>>
>>>>> -Tero
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>>>>> in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> Tony proposed in the IRC apply this patch series in order to solve the
>>>> following error messages with kernel 3.17
>>>>
>>>> [    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
>>>> vdd_mpu_iva
>>>> [    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>>> [    2.541564] omap2_set_init_voltage: unable to find boot up OPP for
>>>> vdd_core
>>>> [    2.551208] omap2_set_init_voltage: unable to set vdd_core
>>>>
>>>> I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
>>>> should these patches solve these errors ? Did you resolve these errors
>>>> on your Beagleboard ?
>>>
>>>
>>>
>>> These prints are caused by something else: namely the fact that
>>> beagleboard
>>> rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and
>>> quelches out the warning prints.
>>>
>>> This should be fixed by modifying the OPP tables under the dtsi files,
>>> however the nasty thing is not all beagleboards support 720MHz OPP. You
>>> either need to specify a dts file for beagle-revC4 or do some kernel
>>> magic
>>> to manually disable the 720MHz OPP on non-supported boards.
>>>
>>
>> Adding and modifying some printk looks the problem is because it can't
>> find the device opp.
>>
>> [    2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp
>> [    2.542755] omap2_set_init_voltage: unable to find boot up OPP for
>> vdd_mpu_iva (clk = dpll1_ck - freq = 600000000)
>> [    2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>
>> [    2.562957] platform 68000000.ocp: dev_pm_opp_find_freq_ceil: can't
>> find device opp
>> [    2.573333] omap2_set_init_voltage: unable to find boot up OPP for
>> vdd_core (clk = l3_ick - freq = 200000000)
>> [    2.584442] omap2_set_init_voltage: unable to set vdd_core
>>
>>
>> The of_init_opp_table who reads the 'operating-points" from dtb is
>> called after. Should be called before?
>>
>> [    2.592834] cpu cpu0: of_init_opp_table: init_opp_table
>>
>
> What is the board revision you got? Looks like it boots up at 600/200MHz.
>

Well, about board revision I'm using IGEPv2 not Beagleboard. And my
board should be able to run up to 1GHz. Is 1GHz supported ?

> You can also try tweaking around the tables under opp3xxx_data.c, not sure
> if these are initialized in the correct order either. However, the lack of
> these tables and the warnings mentioned do not prevent cpufreq from working,
> cpufreq is dependant on the DT tables. That being said, I am not sure if the
> legacy OPP tables are even needed anymore on DT boot...
>

Right, I've checked and cpufreq seems to work. Does this means that
following call is not needed anymore ?

arch/arm/mach-omap2/opp3xxx_data.c:171:omap_device_initcall(omap3_opp_init);

Thanks,
  Enric


> -Tero
>

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Nishanth Menon]

On 10/17/2014 07:48 AM, Enric Balletbo Serra wrote:
> 2014-10-17 14:35 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>> On 10/17/2014 02:55 PM, Enric Balletbo Serra wrote:
>>>
>>> 2014-10-17 7:55 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>>
>>>> On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Seems like MPU DVFS does not scale the voltages currently with DT boot,
>>>>>> due to missing mapping between regulator -> VCVP. Fixed this by adding
>>>>>> support for platform data in the TWL regulator DT case + adding
>>>>>> platform
>>>>>> data quirk for the same. This same already works in the legacy boot,
>>>>>> the
>>>>>> platform data is passed fine.
>>>>>>
>>>>>> Tested on omap3-beagle by measuring the MPU voltage rail.
>>>>>>
>>>>>> OMAP4+ platforms do not currently register DVFS regulator, so this set
>>>>>> by
>>>>>> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
>>>>>> for OMAP4460.)
>>>>>>
>>>>>> -Tero
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>>>>>> in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> Tony proposed in the IRC apply this patch series in order to solve the
>>>>> following error messages with kernel 3.17
>>>>>
>>>>> [    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
>>>>> vdd_mpu_iva
>>>>> [    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>>>> [    2.541564] omap2_set_init_voltage: unable to find boot up OPP for
>>>>> vdd_core
>>>>> [    2.551208] omap2_set_init_voltage: unable to set vdd_core
>>>>>
>>>>> I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
>>>>> should these patches solve these errors ? Did you resolve these errors
>>>>> on your Beagleboard ?
>>>>
>>>>
>>>>
>>>> These prints are caused by something else: namely the fact that
>>>> beagleboard
>>>> rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and
>>>> quelches out the warning prints.
>>>>
>>>> This should be fixed by modifying the OPP tables under the dtsi files,
>>>> however the nasty thing is not all beagleboards support 720MHz OPP. You
>>>> either need to specify a dts file for beagle-revC4 or do some kernel
>>>> magic
>>>> to manually disable the 720MHz OPP on non-supported boards.
>>>>
>>>
>>> Adding and modifying some printk looks the problem is because it can't
>>> find the device opp.
>>>
>>> [    2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp
>>> [    2.542755] omap2_set_init_voltage: unable to find boot up OPP for
>>> vdd_mpu_iva (clk = dpll1_ck - freq = 600000000)
>>> [    2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>>
>>> [    2.562957] platform 68000000.ocp: dev_pm_opp_find_freq_ceil: can't
>>> find device opp
>>> [    2.573333] omap2_set_init_voltage: unable to find boot up OPP for
>>> vdd_core (clk = l3_ick - freq = 200000000)
>>> [    2.584442] omap2_set_init_voltage: unable to set vdd_core
>>>
>>>
>>> The of_init_opp_table who reads the 'operating-points" from dtb is
>>> called after. Should be called before?
>>>
>>> [    2.592834] cpu cpu0: of_init_opp_table: init_opp_table
>>>
>>
>> What is the board revision you got? Looks like it boots up at 600/200MHz.
>>
> 
> Well, about board revision I'm using IGEPv2 not Beagleboard. And my
> board should be able to run up to 1GHz. Is 1GHz supported ?

NO. 1GHz cannot not be supported by the chip until we have avs
class1.5 and ABB integrated into a proper cpufreq/dvfs solution.

we have tried multiple times in upstream to present a solution

you are welcome to read up on
https://bugzilla.kernel.org/show_bug.cgi?id=58541 to see why similar
frequency was not enabled on omap4 (as an example).

> 
>> You can also try tweaking around the tables under opp3xxx_data.c, not sure
>> if these are initialized in the correct order either. However, the lack of
>> these tables and the warnings mentioned do not prevent cpufreq from working,
>> cpufreq is dependant on the DT tables. That being said, I am not sure if the
>> legacy OPP tables are even needed anymore on DT boot...
>>
> 
> Right, I've checked and cpufreq seems to work. Does this means that
> following call is not needed anymore ?
> 
> arch/arm/mach-omap2/opp3xxx_data.c:171:omap_device_initcall(omap3_opp_init);


only after we have pure DT only boot for OMAP3. we are supposed to
support legacy mode for omap3 as well for now.

-- 
Regards,
Nishanth Menon

[REPOST PATCH 0/2] ARM: OMAP3+: VCVP mapping fixes to get DVFS working

[Tero Kristo]

On 10/17/2014 03:48 PM, Enric Balletbo Serra wrote:
> 2014-10-17 14:35 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>> On 10/17/2014 02:55 PM, Enric Balletbo Serra wrote:
>>>
>>> 2014-10-17 7:55 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>>
>>>> On 10/16/2014 05:21 PM, Enric Balletbo Serra wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> 2014-10-10 16:06 GMT+02:00 Tero Kristo <t-kristo@ti.com>:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Seems like MPU DVFS does not scale the voltages currently with DT boot,
>>>>>> due to missing mapping between regulator -> VCVP. Fixed this by adding
>>>>>> support for platform data in the TWL regulator DT case + adding
>>>>>> platform
>>>>>> data quirk for the same. This same already works in the legacy boot,
>>>>>> the
>>>>>> platform data is passed fine.
>>>>>>
>>>>>> Tested on omap3-beagle by measuring the MPU voltage rail.
>>>>>>
>>>>>> OMAP4+ platforms do not currently register DVFS regulator, so this set
>>>>>> by
>>>>>> itself does not fix OMAP4 (needs the TPS MPU regulator added to DT etc.
>>>>>> for OMAP4460.)
>>>>>>
>>>>>> -Tero
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>>>>>> in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> Tony proposed in the IRC apply this patch series in order to solve the
>>>>> following error messages with kernel 3.17
>>>>>
>>>>> [    2.522949] omap2_set_init_voltage: unable to find boot up OPP for
>>>>> vdd_mpu_iva
>>>>> [    2.533721] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>>>> [    2.541564] omap2_set_init_voltage: unable to find boot up OPP for
>>>>> vdd_core
>>>>> [    2.551208] omap2_set_init_voltage: unable to set vdd_core
>>>>>
>>>>> I'm using omap3-igep0020, I didn't mesure the MPU voltage rail but
>>>>> should these patches solve these errors ? Did you resolve these errors
>>>>> on your Beagleboard ?
>>>>
>>>>
>>>>
>>>> These prints are caused by something else: namely the fact that
>>>> beagleboard
>>>> rev C4+ boots up at 720MHz. This OPP is not supported by the kernel and
>>>> quelches out the warning prints.
>>>>
>>>> This should be fixed by modifying the OPP tables under the dtsi files,
>>>> however the nasty thing is not all beagleboards support 720MHz OPP. You
>>>> either need to specify a dts file for beagle-revC4 or do some kernel
>>>> magic
>>>> to manually disable the 720MHz OPP on non-supported boards.
>>>>
>>>
>>> Adding and modifying some printk looks the problem is because it can't
>>> find the device opp.
>>>
>>> [    2.532836] cpu cpu0: dev_pm_opp_find_freq_ceil: can't find device opp
>>> [    2.542755] omap2_set_init_voltage: unable to find boot up OPP for
>>> vdd_mpu_iva (clk = dpll1_ck - freq = 600000000)
>>> [    2.554931] omap2_set_init_voltage: unable to set vdd_mpu_iva
>>>
>>> [    2.562957] platform 68000000.ocp: dev_pm_opp_find_freq_ceil: can't
>>> find device opp
>>> [    2.573333] omap2_set_init_voltage: unable to find boot up OPP for
>>> vdd_core (clk = l3_ick - freq = 200000000)
>>> [    2.584442] omap2_set_init_voltage: unable to set vdd_core
>>>
>>>
>>> The of_init_opp_table who reads the 'operating-points" from dtb is
>>> called after. Should be called before?
>>>
>>> [    2.592834] cpu cpu0: of_init_opp_table: init_opp_table
>>>
>>
>> What is the board revision you got? Looks like it boots up at 600/200MHz.
>>
>
> Well, about board revision I'm using IGEPv2 not Beagleboard. And my
> board should be able to run up to 1GHz. Is 1GHz supported ?

Oh I see. Kernel doesn't support anything above 600MHz yet for OMAP3, as 
none of the OPPs have kernel data.

>
>> You can also try tweaking around the tables under opp3xxx_data.c, not sure
>> if these are initialized in the correct order either. However, the lack of
>> these tables and the warnings mentioned do not prevent cpufreq from working,
>> cpufreq is dependant on the DT tables. That being said, I am not sure if the
>> legacy OPP tables are even needed anymore on DT boot...
>>
>
> Right, I've checked and cpufreq seems to work. Does this means that
> following call is not needed anymore ?
>
> arch/arm/mach-omap2/opp3xxx_data.c:171:omap_device_initcall(omap3_opp_init);

That is still needed, as some boards do not have DT data for them. That 
initializes the legacy OPPs in that case.

-Tero

[REPOST PATCH 1/2] ARM: OMAP3+: TWL: add support for mapping platform data via pdata-quirks

[Mark Brown]

On Fri, Oct 10, 2014 at 05:06:28PM +0300, Tero Kristo wrote:

> -	dev->platform_data = &twl_gpio_auxdata;
> +	if (!strcmp("twl4030-gpio", dev_name(dev)))
> +		dev->platform_data = &twl_gpio_auxdata;
> +	else
> +		dev->platform_data = omap_twl_match_regulator(dev);

Looking at this idiom here I'd expect that we'd be adding another string
comparison here?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141107/de6c774f/attachment.sig>

[REPOST PATCH 1/2] ARM: OMAP3+: TWL: add support for mapping platform data via pdata-quirks

[Tero Kristo]

On 11/07/2014 05:22 PM, Mark Brown wrote:
> On Fri, Oct 10, 2014 at 05:06:28PM +0300, Tero Kristo wrote:
>
>> -	dev->platform_data = &twl_gpio_auxdata;
>> +	if (!strcmp("twl4030-gpio", dev_name(dev)))
>> +		dev->platform_data = &twl_gpio_auxdata;
>> +	else
>> +		dev->platform_data = omap_twl_match_regulator(dev);
>
> Looking at this idiom here I'd expect that we'd be adding another string
> comparison here?

We are actually doing an of_match_node call within the 
twl_match_regulator. However, we had a short offline discussion with 
Tony, and this whole function should be fixed to check node 
compatibility instead of dev_name. I will be posting a new version that 
does this once I have time to look at it.

What do you think of patch #2 though? Thats more interesting for the 
regulator driver purposes and if you NAK that one, the floor goes under 
this whole approach.

-Tero