[PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Nishanth Menon]

The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
migrating the cpufreq support only through device tree (part of the effort
to migrate away from non-DT configurations for OMAP). Unfortunately, as already
known, we have a bunch of legacy code and mutually dependent device tree
conversion that is pending.
Key features pending:
A) clock framework transition to DT - this should happen soon, so this series hacks
the clock node for the time being as suggested in review of original series
B) on processors that use voltage controller, voltage processor (VC/VP hardware
loop using I2C_SR path) - we have started work on transitioning them to regulator
framework driven by DT.
C) Adaptive Body Bias and SmartReflex AVS conversion to DT.

As a result of these pending features:
- OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
associated at the moment - fortunately, we boot at highest voltage, so things still
work.
- Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
where certain OPPs need enabling based on efuse programmed bit sequences - since it
is an add-on work, it is not addressed here.

Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
converted to CCF, we could remove the DT regulator requirements there as well.

Key benefit of the series is to allow all relevant TI platforms now to use a single
cpufreq driver and equivalent frameworks in addition be part of the transition to
DT. As a result of this series, CPUFreq feature will not be available for non-DT
boot systems.

Original discussion thread which triggered this series:
	http://marc.info/?l=linux-pm&m=136304313700602&w=2
	https://patchwork.kernel.org/patch/2251841/
	https://patchwork.kernel.org/patch/2251851/

Test coverage:
	test script: http://pastebin.com/MpCRY0SB
Platforms verified:
	beaglebone(rev A6a) - AM33xx compatible
	beagleboard (rev C1D) - OMAP3430 compatible
	omap3-beagle-xm -OMAP3630 compatible
	Pandaboard -(OMAP4430 ES2.3) verified with omapconf
	Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf

Series is based on v3.9-rc2 tag

Also available at:
	https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1
	git link: git://github.com/nmenon/linux-2.6-playground.git
	branch: cpufreq-cpu0-omap-all-v1

Nishanth Menon (8):
  ARM: dts: OMAP34xx: move CPU OPP tables to device tree
  ARM: dts: OMAP36xx: move CPU OPP tables to device tree
  ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
  ARM: dts: OMAP443x: move CPU OPP tables to device tree
  ARM: dts: omap4-panda: move generic sections to panda-common
  ARM: dts: OMAP446x: move CPU OPP tables to device tree
  ARM: OMAP3+: use cpu0-cpufreq driver
  cpufreq: omap: remove omap-cpufreq

 MAINTAINERS                               |    1 -
 arch/arm/boot/dts/omap3-beagle-xm.dts     |    6 +
 arch/arm/boot/dts/omap3-beagle.dts        |    6 +
 arch/arm/boot/dts/omap3-evm.dts           |    6 +
 arch/arm/boot/dts/omap3.dtsi              |   10 +
 arch/arm/boot/dts/omap36xx.dtsi           |   12 ++
 arch/arm/boot/dts/omap4-panda-a4.dts      |    5 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi |  205 ++++++++++++++++++++
 arch/arm/boot/dts/omap4-panda-es.dts      |    5 +-
 arch/arm/boot/dts/omap4-panda.dts         |  200 +-------------------
 arch/arm/boot/dts/omap4.dtsi              |   10 +
 arch/arm/boot/dts/omap446x.dtsi           |   27 +++
 arch/arm/boot/dts/twl4030.dtsi            |    6 +
 arch/arm/mach-omap2/board-generic.c       |    4 +
 arch/arm/mach-omap2/cclock33xx_data.c     |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c     |    2 +-
 arch/arm/mach-omap2/cclock44xx_data.c     |    2 +-
 arch/arm/mach-omap2/opp3xxx_data.c        |   20 --
 arch/arm/mach-omap2/opp4xxx_data.c        |   23 ---
 drivers/cpufreq/Kconfig.arm               |    6 -
 drivers/cpufreq/Makefile                  |    1 -
 drivers/cpufreq/omap-cpufreq.c            |  291 -----------------------------
 22 files changed, 305 insertions(+), 545 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap446x.dtsi
 delete mode 100644 drivers/cpufreq/omap-cpufreq.c

Size change information:
add/remove: 0/0 grow/shrink: 3/5 up/down: 74/-291 (-217)
function                                     old     new   delta
omap_generic_init                             96     140     +44
vermagic                                      49      64     +15
linux_banner                                 130     145     +15
kernel_config_data                         18333   18330      -3
omap443x_opp_def_list                        144      80     -64
omap36xx_opp_def_list                        160      96     -64
omap446x_opp_def_list                        192     112     -80
omap34xx_opp_def_list                        208     128     -80

non-zero DTB size deltas(bytes):
old	new	delta	 filename
8068	8311	+243	omap3-beagle.dtb
8647	8874	+227	omap3-beagle-xm.dtb
7783	8026	+243	omap3-evm.dtb
8000	8183	+183	omap3-tobi.dtb
13646	13771	+125	omap4-panda-a4.dtb
13646	13771	+125	omap4-panda.dtb
13602	13719	+117	omap4-panda-es.dtb
16256	16381	+125	omap4-sdp.dtb
10889	11014	+125	omap4-var-som.dtb

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Regards,
Nishanth Menon
-- 
1.7.9.5

[PATCH 1/8] ARM: dts: OMAP34xx: move CPU OPP tables to device tree

[Nishanth Menon]

Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.

This is in preparation to use generic cpu0-cpufreq driver.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/boot/dts/omap3.dtsi       |   10 ++++++++++
 arch/arm/mach-omap2/opp3xxx_data.c |   11 -----------
 2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9a15066 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,16 @@
 	cpus {
 		cpu@0 {
 			compatible = "arm,cortex-a8";
+			/* OMAP3430 variants OPP1-5 */
+			operating-points = <
+				/* kHz    uV */
+				125000   975000
+				250000  1075000
+				500000  1200000
+				550000  1270000
+				600000  1350000
+			>;
+			clock-latency = <300000>; /* From legacy driver */
 		};
 	};
 
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
index fc67add..1de18c2 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -87,17 +87,6 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = {
 /* OPP data */
 
 static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
-	/* MPU OPP1 */
-	OPP_INITIALIZER("mpu", true, 125000000, OMAP3430_VDD_MPU_OPP1_UV),
-	/* MPU OPP2 */
-	OPP_INITIALIZER("mpu", true, 250000000, OMAP3430_VDD_MPU_OPP2_UV),
-	/* MPU OPP3 */
-	OPP_INITIALIZER("mpu", true, 500000000, OMAP3430_VDD_MPU_OPP3_UV),
-	/* MPU OPP4 */
-	OPP_INITIALIZER("mpu", true, 550000000, OMAP3430_VDD_MPU_OPP4_UV),
-	/* MPU OPP5 */
-	OPP_INITIALIZER("mpu", true, 600000000, OMAP3430_VDD_MPU_OPP5_UV),
-
 	/*
 	 * L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
 	 * almost the same than the one at 83MHz thus providing very little
-- 
1.7.9.5

--
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 1/8] ARM: dts: OMAP34xx: move CPU OPP tables to device tree

[Jon Hunter]

On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> Add DT OPP table for OMAP34xx family of devices. This data is
> decoded by OF with of_init_opp_table() helper function.
> 
> This is in preparation to use generic cpu0-cpufreq driver.

No mention here about what you are removing ;-)

Jon

[PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Nishanth Menon]

Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.

This is in preparation to use generic cpu0-cpufreq driver.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/boot/dts/omap36xx.dtsi    |   12 ++++++++++++
 arch/arm/mach-omap2/opp3xxx_data.c |    9 ---------
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 96bf028..743eaa1 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -15,6 +15,18 @@
 		serial3 = &uart4;
 	};
 
+	cpus {
+		/* OMAP3630 'standard device' variants OPP50 to OPP130 */
+		cpu@0 {
+			operating-points = <
+				/* kHz    uV */
+				300000   975000
+				600000  1075000
+				800000  1200000
+			>;
+			clock-latency = <300000>; /* From omap-cpufreq driver */
+		};
+	};
 	ocp {
 		uart4: serial@49042000 {
 			compatible = "ti,omap3-uart";
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c b/arch/arm/mach-omap2/opp3xxx_data.c
index 1de18c2..cf7b3ab 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -114,15 +114,6 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
 };
 
 static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
-	/* MPU OPP1 - OPP50 */
-	OPP_INITIALIZER("mpu", true,  300000000, OMAP3630_VDD_MPU_OPP50_UV),
-	/* MPU OPP2 - OPP100 */
-	OPP_INITIALIZER("mpu", true,  600000000, OMAP3630_VDD_MPU_OPP100_UV),
-	/* MPU OPP3 - OPP-Turbo */
-	OPP_INITIALIZER("mpu", false, 800000000, OMAP3630_VDD_MPU_OPP120_UV),
-	/* MPU OPP4 - OPP-SB */
-	OPP_INITIALIZER("mpu", false, 1000000000, OMAP3630_VDD_MPU_OPP1G_UV),
-
 	/* L3 OPP1 - OPP50 */
 	OPP_INITIALIZER("l3_main", true, 100000000, OMAP3630_VDD_CORE_OPP50_UV),
 	/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
-- 
1.7.9.5

--
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 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Jon Hunter]

On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> Add DT OPP table for OMAP36xx family of devices. This data is
> decoded by OF with of_init_opp_table() helper function. This
> overrides the default OMAP34xx CPU OPP table definition.

Not sure I following the last sentence. The tables are in a different
dtsi file and only the relevant file should be included, right?

Jon

Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Nishanth Menon]

On 16:44-20130314, Jon Hunter wrote:
> 
> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> > Add DT OPP table for OMAP36xx family of devices. This data is
> > decoded by OF with of_init_opp_table() helper function. This
> > overrides the default OMAP34xx CPU OPP table definition.
> 
> Not sure I following the last sentence. The tables are in a different
> dtsi file and only the relevant file should be included, right?
omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx).
The opp tables introduced by this patch in omap36xx.dtsi will override
the ones defined on omap3.dtsi. Will the following rephrase help clarify
this?

Original:
This overrides the default OMAP34xx CPU OPP table definition.
Suggested;
This overrides the default OMAP34xx CPU OPP table definition in
omap3.dtsi.

-- 
Regards,
Nishanth Menon

Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Jon Hunter]

On 03/15/2013 08:56 AM, Nishanth Menon wrote:
> On 16:44-20130314, Jon Hunter wrote:
>>
>> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
>>> Add DT OPP table for OMAP36xx family of devices. This data is
>>> decoded by OF with of_init_opp_table() helper function. This
>>> overrides the default OMAP34xx CPU OPP table definition.
>>
>> Not sure I following the last sentence. The tables are in a different
>> dtsi file and only the relevant file should be included, right?
> omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx).
> The opp tables introduced by this patch in omap36xx.dtsi will override
> the ones defined on omap3.dtsi. Will the following rephrase help clarify
> this?
> 
> Original:
> This overrides the default OMAP34xx CPU OPP table definition.
> Suggested;
> This overrides the default OMAP34xx CPU OPP table definition in
> omap3.dtsi.

Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not
omap34xx.dtsi. I guess I am not familiar with how the DTC overrides
nodes, however, at least from a readability standpoint it would seem
nice to have the omap3430 opps in a omap3430 specific dtsi and not
omap3.dtsi. However, thats just my opinion.

Cheers
Jon

Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Nishanth Menon]

On 09:26-20130315, Jon Hunter wrote:
> 
> On 03/15/2013 08:56 AM, Nishanth Menon wrote:
> > On 16:44-20130314, Jon Hunter wrote:
> >>
> >> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> >>> Add DT OPP table for OMAP36xx family of devices. This data is
> >>> decoded by OF with of_init_opp_table() helper function. This
> >>> overrides the default OMAP34xx CPU OPP table definition.
> >>
> >> Not sure I following the last sentence. The tables are in a different
> >> dtsi file and only the relevant file should be included, right?
> > omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx).
> > The opp tables introduced by this patch in omap36xx.dtsi will override
> > the ones defined on omap3.dtsi. Will the following rephrase help clarify
> > this?
> > 
> > Original:
> > This overrides the default OMAP34xx CPU OPP table definition.
> > Suggested;
> > This overrides the default OMAP34xx CPU OPP table definition in
> > omap3.dtsi.
> 
> Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not
> omap34xx.dtsi. I guess I am not familiar with how the DTC overrides
> nodes, however, at least from a readability standpoint it would seem
> nice to have the omap3430 opps in a omap3430 specific dtsi and not
> omap3.dtsi. However, thats just my opinion.
most of omap3630 is based off omap3430. I know from an readability point
of view, it might have been good to split that to omap3-common.dtsi,
omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this
point in time to do that. Unless, ofcourse, we'd like to set that up as
an standard for all OMAP SoCs...

-- 
Regards,
Nishanth Menon

Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Jon Hunter]

On 03/15/2013 09:38 AM, Nishanth Menon wrote:
> On 09:26-20130315, Jon Hunter wrote:
>>
>> On 03/15/2013 08:56 AM, Nishanth Menon wrote:
>>> On 16:44-20130314, Jon Hunter wrote:
>>>>
>>>> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
>>>>> Add DT OPP table for OMAP36xx family of devices. This data is
>>>>> decoded by OF with of_init_opp_table() helper function. This
>>>>> overrides the default OMAP34xx CPU OPP table definition.
>>>>
>>>> Not sure I following the last sentence. The tables are in a different
>>>> dtsi file and only the relevant file should be included, right?
>>> omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx).
>>> The opp tables introduced by this patch in omap36xx.dtsi will override
>>> the ones defined on omap3.dtsi. Will the following rephrase help clarify
>>> this?
>>>
>>> Original:
>>> This overrides the default OMAP34xx CPU OPP table definition.
>>> Suggested;
>>> This overrides the default OMAP34xx CPU OPP table definition in
>>> omap3.dtsi.
>>
>> Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not
>> omap34xx.dtsi. I guess I am not familiar with how the DTC overrides
>> nodes, however, at least from a readability standpoint it would seem
>> nice to have the omap3430 opps in a omap3430 specific dtsi and not
>> omap3.dtsi. However, thats just my opinion.
> most of omap3630 is based off omap3430. I know from an readability point
> of view, it might have been good to split that to omap3-common.dtsi,
> omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this
> point in time to do that. Unless, ofcourse, we'd like to set that up as
> an standard for all OMAP SoCs...

How would omap3-common.dtsi be any different from omap3.dtsi? I don't
wish us to go nuts with creating dtsi files either, but having an
omap3430.dtsi does not seem unreasonable to me, but that is just my opinion.

Jon

Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree

[Nishanth Menon]

On 09:58-20130315, Jon Hunter wrote:
> 
> On 03/15/2013 09:38 AM, Nishanth Menon wrote:
> > On 09:26-20130315, Jon Hunter wrote:
> >>
> >> On 03/15/2013 08:56 AM, Nishanth Menon wrote:
> >>> On 16:44-20130314, Jon Hunter wrote:
> >>>>
> >>>> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> >>>>> Add DT OPP table for OMAP36xx family of devices. This data is
> >>>>> decoded by OF with of_init_opp_table() helper function. This
> >>>>> overrides the default OMAP34xx CPU OPP table definition.
> >>>>
> >>>> Not sure I following the last sentence. The tables are in a different
> >>>> dtsi file and only the relevant file should be included, right?
> >>> omap3630.dsi includes omap3.dtsi (which is meant for OMAP34xx).
> >>> The opp tables introduced by this patch in omap36xx.dtsi will override
> >>> the ones defined on omap3.dtsi. Will the following rephrase help clarify
> >>> this?
> >>>
> >>> Original:
> >>> This overrides the default OMAP34xx CPU OPP table definition.
> >>> Suggested;
> >>> This overrides the default OMAP34xx CPU OPP table definition in
> >>> omap3.dtsi.
> >>
> >> Sorry, I just missed that the omap3430 opps were in omap3.dtsi and not
> >> omap34xx.dtsi. I guess I am not familiar with how the DTC overrides
> >> nodes, however, at least from a readability standpoint it would seem
> >> nice to have the omap3430 opps in a omap3430 specific dtsi and not
> >> omap3.dtsi. However, thats just my opinion.
> > most of omap3630 is based off omap3430. I know from an readability point
> > of view, it might have been good to split that to omap3-common.dtsi,
> > omap34xx.dtsi, omap36xx.dtsi etc.. But there is no real need at this
> > point in time to do that. Unless, ofcourse, we'd like to set that up as
> > an standard for all OMAP SoCs...
> 
> How would omap3-common.dtsi be any different from omap3.dtsi? I don't
> wish us to go nuts with creating dtsi files either, but having an
> omap3430.dtsi does not seem unreasonable to me, but that is just my opinion.
considering omap34xx variants, omap343x.dtsi ;). Will do in v2.

-- 
Regards,
Nishanth Menon

[PATCH 3/8] ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU

[Nishanth Menon]

Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP3 platforms.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/boot/dts/omap3-beagle-xm.dts |    6 ++++++
 arch/arm/boot/dts/omap3-beagle.dts    |    6 ++++++
 arch/arm/boot/dts/omap3-evm.dts       |    6 ++++++
 arch/arm/boot/dts/twl4030.dtsi        |    6 ++++++
 4 files changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..7152746 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -13,6 +13,12 @@
 	model = "TI OMAP3 BeagleBoard xM";
 	compatible = "ti,omap3-beagle-xm, ti,omap3-beagle", "ti,omap3";
 
+	cpus {
+		cpu@0 {
+			cpu0-supply = <&vcc>;
+		};
+	};
+
 	memory {
 		device_type = "memory";
 		reg = <0x80000000 0x20000000>; /* 512 MB */
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..8886617 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -13,6 +13,12 @@
 	model = "TI OMAP3 BeagleBoard";
 	compatible = "ti,omap3-beagle", "ti,omap3";
 
+	cpus {
+		cpu@0 {
+			cpu0-supply = <&vcc>;
+		};
+	};
+
 	memory {
 		device_type = "memory";
 		reg = <0x80000000 0x10000000>; /* 256 MB */
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..d36d19f 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -13,6 +13,12 @@
 	model = "TI OMAP3 EVM (OMAP3530, AM/DM37x)";
 	compatible = "ti,omap3-evm", "ti,omap3";
 
+	cpus {
+		cpu@0 {
+			cpu0-supply = <&vcc>;
+		};
+	};
+
 	memory {
 		device_type = "memory";
 		reg = <0x80000000 0x10000000>; /* 256 MB */
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..608f2e6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -23,6 +23,12 @@
 		compatible = "ti,twl4030-wdt";
 	};
 
+	vcc: regulator-vdd1 {
+		compatible = "ti,twl4030-vdd1";
+		regulator-min-microvolt = <600000>;
+		regulator-max-microvolt = <1450000>;
+	};
+
 	vdac: regulator-vdac {
 		compatible = "ti,twl4030-vdac";
 		regulator-min-microvolt = <1800000>;
-- 
1.7.9.5

[PATCH 4/8] ARM: dts: OMAP443x: move CPU OPP tables to device tree

[Nishanth Menon]

Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.

This is in preparation to use generic cpu0-cpufreq driver.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/boot/dts/omap4.dtsi       |   10 ++++++++++
 arch/arm/mach-omap2/opp4xxx_data.c |    8 --------
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..08983a3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,16 @@
 		cpu@0 {
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
+			/* OMAP4430 variants OPP50-OPPNT */
+			operating-points = <
+				/* kHz    uV */
+				300000  1025000
+				600000  1200000
+				800000  1313000
+				1008000 1375000
+			>;
+			clock-latency = <300000>; /* From omap-cpufreq driver */
+			voltage-tolerance = <2>; /* 2 % */
 		};
 		cpu@1 {
 			compatible = "arm,cortex-a9";
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
index 1ef7a3e..478e2ee 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -65,14 +65,6 @@ struct omap_volt_data omap443x_vdd_core_volt_data[] = {
 
 
 static struct omap_opp_def __initdata omap443x_opp_def_list[] = {
-	/* MPU OPP1 - OPP50 */
-	OPP_INITIALIZER("mpu", true, 300000000, OMAP4430_VDD_MPU_OPP50_UV),
-	/* MPU OPP2 - OPP100 */
-	OPP_INITIALIZER("mpu", true, 600000000, OMAP4430_VDD_MPU_OPP100_UV),
-	/* MPU OPP3 - OPP-Turbo */
-	OPP_INITIALIZER("mpu", true, 800000000, OMAP4430_VDD_MPU_OPPTURBO_UV),
-	/* MPU OPP4 - OPP-SB */
-	OPP_INITIALIZER("mpu", true, 1008000000, OMAP4430_VDD_MPU_OPPNITRO_UV),
 	/* L3 OPP1 - OPP50 */
 	OPP_INITIALIZER("l3_main_1", true, 100000000, OMAP4430_VDD_CORE_OPP50_UV),
 	/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
-- 
1.7.9.5

[PATCH 5/8] ARM: dts: omap4-panda: move generic sections to panda-common

[Nishanth Menon]

PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.

Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are supported.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
NOTE: even though this patch was generated with -M, the diff might be a bit
confusing.

 arch/arm/boot/dts/omap4-panda-a4.dts      |    5 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi |  205 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap4-panda-es.dts      |    5 +-
 arch/arm/boot/dts/omap4-panda.dts         |  200 +---------------------------
 4 files changed, 215 insertions(+), 200 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi

diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts
index 75466d2..f89b0ee 100644
--- a/arch/arm/boot/dts/omap4-panda-a4.dts
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -5,7 +5,10 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-/include/ "omap4-panda.dts"
+/dts-v1/;
+
+/include/ "omap4.dtsi"
+/include/ "omap4-panda-common.dtsi"
 
 /* Pandaboard Rev A4+ have external pullups on SCL & SDA */
 &dss_hdmi_pins {
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
new file mode 100644
index 0000000..3a22e09
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/include/ "elpida_ecb240abacn.dtsi"
+
+/ {
+	model = "TI OMAP4 PandaBoard";
+	compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>; /* 1 GB */
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		heartbeat {
+			label = "pandaboard::status1";
+			gpios = <&gpio1 7 0>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		mmc {
+			label = "pandaboard::status2";
+			gpios = <&gpio1 8 0>;
+			linux,default-trigger = "mmc0";
+		};
+	};
+
+	sound: sound {
+		compatible = "ti,abe-twl6040";
+		ti,model = "PandaBoard";
+
+		ti,mclk-freq = <38400000>;
+
+		ti,mcpdm = <&mcpdm>;
+
+		ti,twl6040 = <&twl6040>;
+
+		/* Audio routing */
+		ti,audio-routing =
+			"Headset Stereophone", "HSOL",
+			"Headset Stereophone", "HSOR",
+			"Ext Spk", "HFL",
+			"Ext Spk", "HFR",
+			"Line Out", "AUXL",
+			"Line Out", "AUXR",
+			"HSMIC", "Headset Mic",
+			"Headset Mic", "Headset Mic Bias",
+			"AFML", "Line In",
+			"AFMR", "Line In";
+	};
+};
+
+&omap4_pmx_core {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+			&twl6040_pins
+			&mcpdm_pins
+			&mcbsp1_pins
+			&dss_hdmi_pins
+			&tpd12s015_pins
+	>;
+
+	twl6040_pins: pinmux_twl6040_pins {
+		pinctrl-single,pins = <
+			0xe0 0x3	/* hdq_sio.gpio_127 OUTPUT | MODE3 */
+			0x160 0x100	/* sys_nirq2.sys_nirq2 INPUT | MODE0 */
+		>;
+	};
+
+	mcpdm_pins: pinmux_mcpdm_pins {
+		pinctrl-single,pins = <
+			0xc6 0x108	/* abe_pdm_ul_data.abe_pdm_ul_data INPUT PULLDOWN | MODE0 */
+			0xc8 0x108	/* abe_pdm_dl_data.abe_pdm_dl_data INPUT PULLDOWN | MODE0 */
+			0xca 0x118	/* abe_pdm_frame.abe_pdm_frame INPUT PULLUP | MODE0 */
+			0xcc 0x108	/* abe_pdm_lb_clk.abe_pdm_lb_clk INPUT PULLDOWN | MODE0 */
+			0xce 0x108	/* abe_clks.abe_clks INPUT PULLDOWN | MODE0 */
+		>;
+	};
+
+	mcbsp1_pins: pinmux_mcbsp1_pins {
+		pinctrl-single,pins = <
+			0xbe 0x100	/* abe_mcbsp1_clkx.abe_mcbsp1_clkx INPUT | MODE0 */
+			0xc0 0x108	/* abe_mcbsp1_dr.abe_mcbsp1_dr INPUT PULLDOWN | MODE0 */
+			0xc2 0x8		/* abe_mcbsp1_dx.abe_mcbsp1_dx OUTPUT PULLDOWN | MODE0 */
+			0xc4 0x100	/* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
+		>;
+	};
+
+	dss_hdmi_pins: pinmux_dss_hdmi_pins {
+		pinctrl-single,pins = <
+			0x5a 0x118	/* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
+			0x5c 0x118	/* hdmi_scl.hdmi_scl INPUT PULLUP | MODE 0 */
+			0x5e 0x118	/* hdmi_sda.hdmi_sda INPUT PULLUP | MODE 0 */
+		>;
+	};
+
+	tpd12s015_pins: pinmux_tpd12s015_pins {
+		pinctrl-single,pins = <
+			0x22 0x3	/* gpmc_a17.gpio_41 OUTPUT | MODE3 */
+			0x48 0x3	/* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
+			0x58 0x10b	/* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
+		>;
+	};
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+
+	twl: twl@48 {
+		reg = <0x48>;
+		/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+		interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
+		interrupt-parent = <&gic>;
+	};
+
+	twl6040: twl@4b {
+		compatible = "ti,twl6040";
+		reg = <0x4b>;
+		/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
+		interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
+		interrupt-parent = <&gic>;
+		ti,audpwron-gpio = <&gpio4 31 0>;  /* gpio line 127 */
+
+		vio-supply = <&v1v8>;
+		v2v1-supply = <&v2v1>;
+		enable-active-high;
+	};
+};
+
+/include/ "twl6030.dtsi"
+
+&i2c2 {
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+
+	/*
+	 * Display monitor features are burnt in their EEPROM as EDID data.
+	 * The EEPROM is connected as I2C slave device.
+	 */
+	eeprom@50 {
+		compatible = "ti,eeprom";
+		reg = <0x50>;
+	};
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+};
+
+&mmc1 {
+	vmmc-supply = <&vmmc>;
+	bus-width = <8>;
+};
+
+&mmc2 {
+	status = "disabled";
+};
+
+&mmc3 {
+	status = "disabled";
+};
+
+&mmc4 {
+	status = "disabled";
+};
+
+&mmc5 {
+	ti,non-removable;
+	bus-width = <4>;
+};
+
+&emif1 {
+	cs1-used;
+	device-handle = <&elpida_ECB240ABACN>;
+};
+
+&emif2 {
+	cs1-used;
+	device-handle = <&elpida_ECB240ABACN>;
+};
+
+&mcbsp2 {
+	status = "disabled";
+};
+
+&mcbsp3 {
+	status = "disabled";
+};
+
+&dmic {
+	status = "disabled";
+};
+
+&twl_usb_comparator {
+	usb-supply = <&vusb>;
+};
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..6422d7c 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,10 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-/include/ "omap4-panda.dts"
+/dts-v1/;
+
+/include/ "omap4.dtsi"
+/include/ "omap4-panda-common.dtsi"
 
 /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
 &sound {
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..eeaaefd 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2011-13 Texas Instruments Incorporated - http://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -8,201 +8,5 @@
 /dts-v1/;
 
 /include/ "omap4.dtsi"
-/include/ "elpida_ecb240abacn.dtsi"
+/include/ "omap4-panda-common.dtsi"
 
-/ {
-	model = "TI OMAP4 PandaBoard";
-	compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4";
-
-	memory {
-		device_type = "memory";
-		reg = <0x80000000 0x40000000>; /* 1 GB */
-	};
-
-	leds {
-		compatible = "gpio-leds";
-		heartbeat {
-			label = "pandaboard::status1";
-			gpios = <&gpio1 7 0>;
-			linux,default-trigger = "heartbeat";
-		};
-
-		mmc {
-			label = "pandaboard::status2";
-			gpios = <&gpio1 8 0>;
-			linux,default-trigger = "mmc0";
-		};
-	};
-
-	sound: sound {
-		compatible = "ti,abe-twl6040";
-		ti,model = "PandaBoard";
-
-		ti,mclk-freq = <38400000>;
-
-		ti,mcpdm = <&mcpdm>;
-
-		ti,twl6040 = <&twl6040>;
-
-		/* Audio routing */
-		ti,audio-routing =
-			"Headset Stereophone", "HSOL",
-			"Headset Stereophone", "HSOR",
-			"Ext Spk", "HFL",
-			"Ext Spk", "HFR",
-			"Line Out", "AUXL",
-			"Line Out", "AUXR",
-			"HSMIC", "Headset Mic",
-			"Headset Mic", "Headset Mic Bias",
-			"AFML", "Line In",
-			"AFMR", "Line In";
-	};
-};
-
-&omap4_pmx_core {
-	pinctrl-names = "default";
-	pinctrl-0 = <
-			&twl6040_pins
-			&mcpdm_pins
-			&mcbsp1_pins
-			&dss_hdmi_pins
-			&tpd12s015_pins
-	>;
-
-	twl6040_pins: pinmux_twl6040_pins {
-		pinctrl-single,pins = <
-			0xe0 0x3	/* hdq_sio.gpio_127 OUTPUT | MODE3 */
-			0x160 0x100	/* sys_nirq2.sys_nirq2 INPUT | MODE0 */
-		>;
-	};
-
-	mcpdm_pins: pinmux_mcpdm_pins {
-		pinctrl-single,pins = <
-			0xc6 0x108	/* abe_pdm_ul_data.abe_pdm_ul_data INPUT PULLDOWN | MODE0 */
-			0xc8 0x108	/* abe_pdm_dl_data.abe_pdm_dl_data INPUT PULLDOWN | MODE0 */
-			0xca 0x118	/* abe_pdm_frame.abe_pdm_frame INPUT PULLUP | MODE0 */
-			0xcc 0x108	/* abe_pdm_lb_clk.abe_pdm_lb_clk INPUT PULLDOWN | MODE0 */
-			0xce 0x108	/* abe_clks.abe_clks INPUT PULLDOWN | MODE0 */
-		>;
-	};
-
-	mcbsp1_pins: pinmux_mcbsp1_pins {
-		pinctrl-single,pins = <
-			0xbe 0x100	/* abe_mcbsp1_clkx.abe_mcbsp1_clkx INPUT | MODE0 */
-			0xc0 0x108	/* abe_mcbsp1_dr.abe_mcbsp1_dr INPUT PULLDOWN | MODE0 */
-			0xc2 0x8		/* abe_mcbsp1_dx.abe_mcbsp1_dx OUTPUT PULLDOWN | MODE0 */
-			0xc4 0x100	/* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
-		>;
-	};
-
-	dss_hdmi_pins: pinmux_dss_hdmi_pins {
-		pinctrl-single,pins = <
-			0x5a 0x118	/* hdmi_cec.hdmi_cec INPUT PULLUP | MODE 0 */
-			0x5c 0x118	/* hdmi_scl.hdmi_scl INPUT PULLUP | MODE 0 */
-			0x5e 0x118	/* hdmi_sda.hdmi_sda INPUT PULLUP | MODE 0 */
-		>;
-	};
-
-	tpd12s015_pins: pinmux_tpd12s015_pins {
-		pinctrl-single,pins = <
-			0x22 0x3	/* gpmc_a17.gpio_41 OUTPUT | MODE3 */
-			0x48 0x3	/* gpmc_nbe1.gpio_60 OUTPUT | MODE3 */
-			0x58 0x10b	/* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
-		>;
-	};
-};
-
-&i2c1 {
-	clock-frequency = <400000>;
-
-	twl: twl@48 {
-		reg = <0x48>;
-		/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
-		interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
-		interrupt-parent = <&gic>;
-	};
-
-	twl6040: twl@4b {
-		compatible = "ti,twl6040";
-		reg = <0x4b>;
-		/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
-		interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
-		interrupt-parent = <&gic>;
-		ti,audpwron-gpio = <&gpio4 31 0>;  /* gpio line 127 */
-
-		vio-supply = <&v1v8>;
-		v2v1-supply = <&v2v1>;
-		enable-active-high;
-	};
-};
-
-/include/ "twl6030.dtsi"
-
-&i2c2 {
-	clock-frequency = <400000>;
-};
-
-&i2c3 {
-	clock-frequency = <100000>;
-
-	/*
-	 * Display monitor features are burnt in their EEPROM as EDID data.
-	 * The EEPROM is connected as I2C slave device.
-	 */
-	eeprom@50 {
-		compatible = "ti,eeprom";
-		reg = <0x50>;
-	};
-};
-
-&i2c4 {
-	clock-frequency = <400000>;
-};
-
-&mmc1 {
-	vmmc-supply = <&vmmc>;
-	bus-width = <8>;
-};
-
-&mmc2 {
-	status = "disabled";
-};
-
-&mmc3 {
-	status = "disabled";
-};
-
-&mmc4 {
-	status = "disabled";
-};
-
-&mmc5 {
-	ti,non-removable;
-	bus-width = <4>;
-};
-
-&emif1 {
-	cs1-used;
-	device-handle = <&elpida_ECB240ABACN>;
-};
-
-&emif2 {
-	cs1-used;
-	device-handle = <&elpida_ECB240ABACN>;
-};
-
-&mcbsp2 {
-	status = "disabled";
-};
-
-&mcbsp3 {
-	status = "disabled";
-};
-
-&dmic {
-	status = "disabled";
-};
-
-&twl_usb_comparator {
-	usb-supply = <&vusb>;
-};
-- 
1.7.9.5

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

[PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree

[Nishanth Menon]

OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
Add DT OPP table for OMAP446x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.

This is in preparation to use generic cpu0-cpufreq driver.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/boot/dts/omap4-panda-es.dts |    2 +-
 arch/arm/boot/dts/omap446x.dtsi      |   27 +++++++++++++++++++++++++++
 arch/arm/mach-omap2/opp4xxx_data.c   |   15 ---------------
 3 files changed, 28 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap446x.dtsi

diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts
index 6422d7c..c52455b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ "omap4.dtsi"
+/include/ "omap446x.dtsi"
 /include/ "omap4-panda-common.dtsi"
 
 /* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
diff --git a/arch/arm/boot/dts/omap446x.dtsi b/arch/arm/boot/dts/omap446x.dtsi
new file mode 100644
index 0000000..8f7a080
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP446x SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap4.dtsi"
+
+/ {
+	cpus {
+		/* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
+		cpu@0 {
+			operating-points = <
+				/* kHz    uV */
+				350000   975000
+				700000  1075000
+				920000  1200000
+			>;
+			clock-latency = <300000>; /* From omap-cpufreq driver */
+			voltage-tolerance = <2>; /* 2 % */
+		};
+	};
+};
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-omap2/opp4xxx_data.c
index 478e2ee..4c5c038 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -116,21 +116,6 @@ struct omap_volt_data omap446x_vdd_core_volt_data[] = {
 };
 
 static struct omap_opp_def __initdata omap446x_opp_def_list[] = {
-	/* MPU OPP1 - OPP50 */
-	OPP_INITIALIZER("mpu", true, 350000000, OMAP4460_VDD_MPU_OPP50_UV),
-	/* MPU OPP2 - OPP100 */
-	OPP_INITIALIZER("mpu", true, 700000000, OMAP4460_VDD_MPU_OPP100_UV),
-	/* MPU OPP3 - OPP-Turbo */
-	OPP_INITIALIZER("mpu", true, 920000000, OMAP4460_VDD_MPU_OPPTURBO_UV),
-	/*
-	 * MPU OPP4 - OPP-Nitro + Disabled as the reference schematics
-	 * recommends TPS623631 - confirm and enable the opp in board file
-	 * XXX: May be we should enable these based on mpu capability and
-	 * Exception board files disable it...
-	 */
-	OPP_INITIALIZER("mpu", false, 1200000000, OMAP4460_VDD_MPU_OPPNITRO_UV),
-	/* MPU OPP4 - OPP-Nitro SpeedBin */
-	OPP_INITIALIZER("mpu", false, 1500000000, OMAP4460_VDD_MPU_OPPNITRO_UV),
 	/* L3 OPP1 - OPP50 */
 	OPP_INITIALIZER("l3_main_1", true, 100000000, OMAP4460_VDD_CORE_OPP50_UV),
 	/* L3 OPP2 - OPP100 */
-- 
1.7.9.5

--
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 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree

[Jon Hunter]

On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> OMAP4430 and 4460 have different OPP definitions. So, create an SoC
> variant dtsi file for 4460 and move the OPP definitions to it.

FYI, I had to create a similar file for PMU [1]. However, I called it
omap4460.dtsi and not omap446x.dtsi as there is only one omap446x
device. That should go into to v3.10 and so may be worth basing this on
top. I do like your omap4-panda-common.dtsi that is a nice clean-up.

Cheers
Jon

[1]
http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dts&id=5e64b6b1137a54f353528d6da60071c1ef0043ba

Re: [PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree

[Nishanth Menon]

On 16:49-20130314, Jon Hunter wrote:
> 
> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> > OMAP4430 and 4460 have different OPP definitions. So, create an SoC
> > variant dtsi file for 4460 and move the OPP definitions to it.
> 
> FYI, I had to create a similar file for PMU [1]. However, I called it
> omap4460.dtsi and not omap446x.dtsi as there is only one omap446x
Hmm, guess I was paranoid about marketing folks spinning off another
omap446x variant out into the market. Since it is not yet done, nor
known if they will ever do it, am OK with 4460 convention.
> device. That should go into to v3.10 and so may be worth basing this on
> top. I do like your omap4-panda-common.dtsi that is a nice clean-up.
Thanks on the tip - Sounds good, since this series is based on DT, I
will base my changes on top of for_3.10 branch.
> 
> Cheers
> Jon
> 
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dts&id=5e64b6b1137a54f353528d6da60071c1ef0043ba

-- 
Regards,
Nishanth Menon

[PATCH 7/8] ARM: OMAP3+: use cpu0-cpufreq driver

[Nishanth Menon]

With OMAP3+ and AM33xx supported SoC having defined CPU DT
entries with operating-points defined, we can now
use the SoC generic cpu0-cpufreq driver to start
using it, lets now switch to the generic driver.

As part of this change, switch the dummy clock node to use
cpufreq-cpu0. This is an suggested solution till we have
OMAP clock nodes in DT. Once the DT conversion is complete,
we can then do: clocks = <&dpll_mpu_ck>; or the SoC specific
equivalent.

Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/mach-omap2/board-generic.c   |    4 ++++
 arch/arm/mach-omap2/cclock33xx_data.c |    2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |    2 +-
 arch/arm/mach-omap2/cclock44xx_data.c |    2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..970c6f4 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,10 @@ static void __init omap_generic_init(void)
 		omap4_panda_display_init_of();
 	else if (of_machine_is_compatible("ti,omap4-sdp"))
 		omap_4430sdp_display_init_of();
+	if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+		struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
+		platform_device_register_full(&devinfo);
+	}
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
 	CLK(NULL,	"dpll_core_m5_ck",	&dpll_core_m5_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_core_m6_ck",	&dpll_core_m6_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_ck",		&dpll_mpu_ck,	CK_AM33XX),
-	CLK("cpu0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
+	CLK("cpufreq-cpu0.0",	NULL,			&dpll_mpu_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_mpu_m2_ck",	&dpll_mpu_m2_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_ck",		&dpll_ddr_ck,	CK_AM33XX),
 	CLK(NULL,	"dpll_ddr_m2_ck",	&dpll_ddr_m2_ck,	CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5f68286 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,7 @@ static struct omap_clk omap3xxx_clks[] = {
 	CLK(NULL,	"uart4_ick",	&uart4_ick_am35xx,	CK_AM35XX),
 	CLK(NULL,	"timer_32k_ck",	&omap_32k_fck,  CK_3XXX),
 	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_3XXX),
-	CLK(NULL,	"cpufreq_ck",	&dpll1_ck,	CK_3XXX),
+	CLK("cpufreq-cpu0.0",	NULL,	&dpll1_ck,	CK_3XXX),
 };
 
 static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..6e933e3 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,7 @@ static struct omap_clk omap44xx_clks[] = {
 	CLK("4013a000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013c000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
 	CLK("4013e000.timer",	"timer_sys_ck",	&syc_clk_div_ck,	CK_443X),
-	CLK(NULL,	"cpufreq_ck",	&dpll_mpu_ck,	CK_443X),
+	CLK("cpufreq-cpu0.0",	NULL,	&dpll_mpu_ck,	CK_443X),
 };
 
 int __init omap4xxx_clk_init(void)
-- 
1.7.9.5

[PATCH 8/8] cpufreq: omap: remove omap-cpufreq

[Nishanth Menon]

We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.

Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Benoît Cousson" <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 MAINTAINERS                    |    1 -
 drivers/cpufreq/Kconfig.arm    |    6 -
 drivers/cpufreq/Makefile       |    1 -
 drivers/cpufreq/omap-cpufreq.c |  291 ----------------------------------------
 4 files changed, 299 deletions(-)
 delete mode 100644 drivers/cpufreq/omap-cpufreq.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..d9c11bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5654,7 +5654,6 @@ M:	Kevin Hilman <khilman@ti.com>
 L:	linux-omap@vger.kernel.org
 S:	Maintained
 F:	arch/arm/*omap*/*pm*
-F:	drivers/cpufreq/omap-cpufreq.c
 
 OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT
 M:	Rajendra Nayak <rnayak@ti.com>
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..1cb810a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -2,12 +2,6 @@
 # ARM CPU Frequency scaling drivers
 #
 
-config ARM_OMAP2PLUS_CPUFREQ
-	bool "TI OMAP2+"
-	depends on ARCH_OMAP2PLUS
-	default ARCH_OMAP2PLUS
-	select CPU_FREQ_TABLE
-
 config ARM_S3C2416_CPUFREQ
 	bool "S3C2416 CPU Frequency scaling support"
 	depends on CPU_S3C2416
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..d52076c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ)	+= kirkwood-cpufreq.o
-obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)	+= omap-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
deleted file mode 100644
index 9128c07..0000000
--- a/drivers/cpufreq/omap-cpufreq.c
+++ /dev/null
@@ -1,291 +0,0 @@
-/*
- *  CPU frequency scaling for OMAP using OPP information
- *
- *  Copyright (C) 2005 Nokia Corporation
- *  Written by Tony Lindgren <tony@atomide.com>
- *
- *  Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
- *
- * Copyright (C) 2007-2011 Texas Instruments, Inc.
- * - OMAP3/4 support by Rajendra Nayak, Santosh Shilimkar
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/cpufreq.h>
-#include <linux/delay.h>
-#include <linux/init.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/io.h>
-#include <linux/opp.h>
-#include <linux/cpu.h>
-#include <linux/module.h>
-#include <linux/regulator/consumer.h>
-
-#include <asm/smp_plat.h>
-#include <asm/cpu.h>
-
-/* OPP tolerance in percentage */
-#define	OPP_TOLERANCE	4
-
-static struct cpufreq_frequency_table *freq_table;
-static atomic_t freq_table_users = ATOMIC_INIT(0);
-static struct clk *mpu_clk;
-static struct device *mpu_dev;
-static struct regulator *mpu_reg;
-
-static int omap_verify_speed(struct cpufreq_policy *policy)
-{
-	if (!freq_table)
-		return -EINVAL;
-	return cpufreq_frequency_table_verify(policy, freq_table);
-}
-
-static unsigned int omap_getspeed(unsigned int cpu)
-{
-	unsigned long rate;
-
-	if (cpu >= NR_CPUS)
-		return 0;
-
-	rate = clk_get_rate(mpu_clk) / 1000;
-	return rate;
-}
-
-static int omap_target(struct cpufreq_policy *policy,
-		       unsigned int target_freq,
-		       unsigned int relation)
-{
-	unsigned int i;
-	int r, ret = 0;
-	struct cpufreq_freqs freqs;
-	struct opp *opp;
-	unsigned long freq, volt = 0, volt_old = 0, tol = 0;
-
-	if (!freq_table) {
-		dev_err(mpu_dev, "%s: cpu%d: no freq table!\n", __func__,
-				policy->cpu);
-		return -EINVAL;
-	}
-
-	ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
-			relation, &i);
-	if (ret) {
-		dev_dbg(mpu_dev, "%s: cpu%d: no freq match for %d(ret=%d)\n",
-			__func__, policy->cpu, target_freq, ret);
-		return ret;
-	}
-	freqs.new = freq_table[i].frequency;
-	if (!freqs.new) {
-		dev_err(mpu_dev, "%s: cpu%d: no match for freq %d\n", __func__,
-			policy->cpu, target_freq);
-		return -EINVAL;
-	}
-
-	freqs.old = omap_getspeed(policy->cpu);
-	freqs.cpu = policy->cpu;
-
-	if (freqs.old == freqs.new && policy->cur == freqs.new)
-		return ret;
-
-	/* notifiers */
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
-	}
-
-	freq = freqs.new * 1000;
-	ret = clk_round_rate(mpu_clk, freq);
-	if (IS_ERR_VALUE(ret)) {
-		dev_warn(mpu_dev,
-			 "CPUfreq: Cannot find matching frequency for %lu\n",
-			 freq);
-		return ret;
-	}
-	freq = ret;
-
-	if (mpu_reg) {
-		rcu_read_lock();
-		opp = opp_find_freq_ceil(mpu_dev, &freq);
-		if (IS_ERR(opp)) {
-			rcu_read_unlock();
-			dev_err(mpu_dev, "%s: unable to find MPU OPP for %d\n",
-				__func__, freqs.new);
-			return -EINVAL;
-		}
-		volt = opp_get_voltage(opp);
-		rcu_read_unlock();
-		tol = volt * OPP_TOLERANCE / 100;
-		volt_old = regulator_get_voltage(mpu_reg);
-	}
-
-	dev_dbg(mpu_dev, "cpufreq-omap: %u MHz, %ld mV --> %u MHz, %ld mV\n", 
-		freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
-		freqs.new / 1000, volt ? volt / 1000 : -1);
-
-	/* scaling up?  scale voltage before frequency */
-	if (mpu_reg && (freqs.new > freqs.old)) {
-		r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
-		if (r < 0) {
-			dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
-				 __func__);
-			freqs.new = freqs.old;
-			goto done;
-		}
-	}
-
-	ret = clk_set_rate(mpu_clk, freqs.new * 1000);
-
-	/* scaling down?  scale voltage after frequency */
-	if (mpu_reg && (freqs.new < freqs.old)) {
-		r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
-		if (r < 0) {
-			dev_warn(mpu_dev, "%s: unable to scale voltage down.\n",
-				 __func__);
-			ret = clk_set_rate(mpu_clk, freqs.old * 1000);
-			freqs.new = freqs.old;
-			goto done;
-		}
-	}
-
-	freqs.new = omap_getspeed(policy->cpu);
-
-done:
-	/* notifiers */
-	for_each_cpu(i, policy->cpus) {
-		freqs.cpu = i;
-		cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
-	}
-
-	return ret;
-}
-
-static inline void freq_table_free(void)
-{
-	if (atomic_dec_and_test(&freq_table_users))
-		opp_free_cpufreq_table(mpu_dev, &freq_table);
-}
-
-static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
-{
-	int result = 0;
-
-	mpu_clk = clk_get(NULL, "cpufreq_ck");
-	if (IS_ERR(mpu_clk))
-		return PTR_ERR(mpu_clk);
-
-	if (policy->cpu >= NR_CPUS) {
-		result = -EINVAL;
-		goto fail_ck;
-	}
-
-	policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
-
-	if (!freq_table)
-		result = opp_init_cpufreq_table(mpu_dev, &freq_table);
-
-	if (result) {
-		dev_err(mpu_dev, "%s: cpu%d: failed creating freq table[%d]\n",
-				__func__, policy->cpu, result);
-		goto fail_ck;
-	}
-
-	atomic_inc_return(&freq_table_users);
-
-	result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
-	if (result)
-		goto fail_table;
-
-	cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
-
-	policy->min = policy->cpuinfo.min_freq;
-	policy->max = policy->cpuinfo.max_freq;
-	policy->cur = omap_getspeed(policy->cpu);
-
-	/*
-	 * On OMAP SMP configuartion, both processors share the voltage
-	 * and clock. So both CPUs needs to be scaled together and hence
-	 * needs software co-ordination. Use cpufreq affected_cpus
-	 * interface to handle this scenario. Additional is_smp() check
-	 * is to keep SMP_ON_UP build working.
-	 */
-	if (is_smp())
-		cpumask_setall(policy->cpus);
-
-	/* FIXME: what's the actual transition time? */
-	policy->cpuinfo.transition_latency = 300 * 1000;
-
-	return 0;
-
-fail_table:
-	freq_table_free();
-fail_ck:
-	clk_put(mpu_clk);
-	return result;
-}
-
-static int omap_cpu_exit(struct cpufreq_policy *policy)
-{
-	freq_table_free();
-	clk_put(mpu_clk);
-	return 0;
-}
-
-static struct freq_attr *omap_cpufreq_attr[] = {
-	&cpufreq_freq_attr_scaling_available_freqs,
-	NULL,
-};
-
-static struct cpufreq_driver omap_driver = {
-	.flags		= CPUFREQ_STICKY,
-	.verify		= omap_verify_speed,
-	.target		= omap_target,
-	.get		= omap_getspeed,
-	.init		= omap_cpu_init,
-	.exit		= omap_cpu_exit,
-	.name		= "omap",
-	.attr		= omap_cpufreq_attr,
-};
-
-static int __init omap_cpufreq_init(void)
-{
-	mpu_dev = get_cpu_device(0);
-	if (!mpu_dev) {
-		pr_warning("%s: unable to get the mpu device\n", __func__);
-		return -EINVAL;
-	}
-
-	mpu_reg = regulator_get(mpu_dev, "vcc");
-	if (IS_ERR(mpu_reg)) {
-		pr_warning("%s: unable to get MPU regulator\n", __func__);
-		mpu_reg = NULL;
-	} else {
-		/* 
-		 * Ensure physical regulator is present.
-		 * (e.g. could be dummy regulator.)
-		 */
-		if (regulator_get_voltage(mpu_reg) < 0) {
-			pr_warn("%s: physical regulator not present for MPU\n",
-				__func__);
-			regulator_put(mpu_reg);
-			mpu_reg = NULL;
-		}
-	}
-
-	return cpufreq_register_driver(&omap_driver);
-}
-
-static void __exit omap_cpufreq_exit(void)
-{
-	cpufreq_unregister_driver(&omap_driver);
-}
-
-MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
-MODULE_LICENSE("GPL");
-module_init(omap_cpufreq_init);
-module_exit(omap_cpufreq_exit);
-- 
1.7.9.5

--
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 8/8] cpufreq: omap: remove omap-cpufreq

[Viresh Kumar]

On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon <nm@ti.com> wrote:
> We can now use cpufreq-cpu0 driver using DT entries.
> remove the redundant omap-cpufreq driver from the tree.
> Remove MAINTAINERS file entry for the same as well.
>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: "Benoît Cousson" <b-cousson@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Keerthy <j-keerthy@ti.com>
> Cc: linux-omap@vger.kernel.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: cpufreq@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>  MAINTAINERS                    |    1 -
>  drivers/cpufreq/Kconfig.arm    |    6 -
>  drivers/cpufreq/Makefile       |    1 -
>  drivers/cpufreq/omap-cpufreq.c |  291 ----------------------------------------
>  4 files changed, 299 deletions(-)
>  delete mode 100644 drivers/cpufreq/omap-cpufreq.c

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
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 8/8] cpufreq: omap: remove omap-cpufreq

[Nishanth Menon]

On Thu, Mar 14, 2013 at 11:51 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon <nm@ti.com> wrote:
>> We can now use cpufreq-cpu0 driver using DT entries.
>> remove the redundant omap-cpufreq driver from the tree.
>> Remove MAINTAINERS file entry for the same as well.
>>
>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>> Cc: "Benoīt Cousson" <b-cousson@ti.com>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Shawn Guo <shawn.guo@linaro.org>
>> Cc: Keerthy <j-keerthy@ti.com>
>> Cc: linux-omap@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: cpufreq@vger.kernel.org
>> Cc: linux-pm@vger.kernel.org
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>>  MAINTAINERS                    |    1 -
>>  drivers/cpufreq/Kconfig.arm    |    6 -
>>  drivers/cpufreq/Makefile       |    1 -
>>  drivers/cpufreq/omap-cpufreq.c |  291 ----------------------------------------
>>  4 files changed, 299 deletions(-)
>>  delete mode 100644 drivers/cpufreq/omap-cpufreq.c
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Thanks Viresh, but based on the direction of the discussion going on
(keeping this driver active for non-DT configuration),
I will have to drop this patch in it's entirety.
---
Regards,
Nishanth Menon
--
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 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Jon Hunter]

On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> migrating the cpufreq support only through device tree (part of the effort
> to migrate away from non-DT configurations for OMAP). Unfortunately, as already
> known, we have a bunch of legacy code and mutually dependent device tree
> conversion that is pending.
> Key features pending:
> A) clock framework transition to DT - this should happen soon, so this series hacks
> the clock node for the time being as suggested in review of original series
> B) on processors that use voltage controller, voltage processor (VC/VP hardware
> loop using I2C_SR path) - we have started work on transitioning them to regulator
> framework driven by DT.
> C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
> 
> As a result of these pending features:
> - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
> associated at the moment - fortunately, we boot at highest voltage, so things still
> work.
> - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
> those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
> where certain OPPs need enabling based on efuse programmed bit sequences - since it
> is an add-on work, it is not addressed here.
> 
> Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
> converted to CCF, we could remove the DT regulator requirements there as well.

OMAP has been converted to the common clock framework (CCF). Are you
referring to clock framework transition to DT or something else?

Jon

Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Nishanth Menon]

On 16:42-20130314, Jon Hunter wrote:
> 
> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> > migrating the cpufreq support only through device tree (part of the effort
> > to migrate away from non-DT configurations for OMAP). Unfortunately, as already
> > known, we have a bunch of legacy code and mutually dependent device tree
> > conversion that is pending.
> > Key features pending:
> > A) clock framework transition to DT - this should happen soon, so this series hacks
> > the clock node for the time being as suggested in review of original series
> > B) on processors that use voltage controller, voltage processor (VC/VP hardware
> > loop using I2C_SR path) - we have started work on transitioning them to regulator
> > framework driven by DT.
> > C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
> > 
> > As a result of these pending features:
> > - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
> > associated at the moment - fortunately, we boot at highest voltage, so things still
> > work.
> > - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
> > those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
> > where certain OPPs need enabling based on efuse programmed bit sequences - since it
> > is an add-on work, it is not addressed here.
> > 
> > Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
> > converted to CCF, we could remove the DT regulator requirements there as well.
> 
> OMAP has been converted to the common clock framework (CCF). Are you
> referring to clock framework transition to DT or something else?
I should have been explicit here - we do not have DT entries for clock
nodes for OMAP. For example, compare:
git grep clocks arch/arm/boot/dts/omap*.dts*
Vs
git grep clocks arch/arm/boot/dts/imx*.dts*

The specific comment above was intended to see the following series
equivalent in upstream:

https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/

-- 
Regards,
Nishanth Menon

Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Santosh Shilimkar]

On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> migrating the cpufreq support only through device tree (part of the effort
> to migrate away from non-DT configurations for OMAP). Unfortunately, as already
> known, we have a bunch of legacy code and mutually dependent device tree
> conversion that is pending.
> Key features pending:
> A) clock framework transition to DT - this should happen soon, so this series hacks
> the clock node for the time being as suggested in review of original series
> B) on processors that use voltage controller, voltage processor (VC/VP hardware
> loop using I2C_SR path) - we have started work on transitioning them to regulator
> framework driven by DT.
> C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
> 
> As a result of these pending features:
> - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
> associated at the moment - fortunately, we boot at highest voltage, so things still
> work.
> - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
> those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
> where certain OPPs need enabling based on efuse programmed bit sequences - since it
> is an add-on work, it is not addressed here.
> 
Thanks for looking into it.

> Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
> converted to CCF, we could remove the DT regulator requirements there as well.
> 
> Key benefit of the series is to allow all relevant TI platforms now to use a single
> cpufreq driver and equivalent frameworks in addition be part of the transition to
> DT. As a result of this series, CPUFreq feature will not be available for non-DT
> boot systems.
> 
As commented by Jon on internal thread, I am also against the idea of dropping
non-DT support now. Till we migrate to 100 % DT, it is best to keep support
alive. Especial OMAP3 based devices.

Why don't you take phased approach and have both supported for time being.
Then once we move to DT only, we just drop the non-DT support as we plan
to do for many more stuff.

BTW, we are using only CPUFreq driver before this series as well. I guess you
mean the common CPUFReq drivers used by other ARM SOCs.

Regards,
Santosh

Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Nishanth Menon]

On 10:48-20130315, Santosh Shilimkar wrote:
> On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
> > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> > migrating the cpufreq support only through device tree (part of the effort
> > to migrate away from non-DT configurations for OMAP). Unfortunately, as already
> > known, we have a bunch of legacy code and mutually dependent device tree
> > conversion that is pending.
> > Key features pending:
> > A) clock framework transition to DT - this should happen soon, so this series hacks
> > the clock node for the time being as suggested in review of original series
> > B) on processors that use voltage controller, voltage processor (VC/VP hardware
> > loop using I2C_SR path) - we have started work on transitioning them to regulator
> > framework driven by DT.
> > C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
> > 
> > As a result of these pending features:
> > - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
> > associated at the moment - fortunately, we boot at highest voltage, so things still
> > work.
> > - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
> > those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
> > where certain OPPs need enabling based on efuse programmed bit sequences - since it
> > is an add-on work, it is not addressed here.
> > 
> Thanks for looking into it.
Yes, this should be the next stage to solve.
> 
> > Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
> > converted to CCF, we could remove the DT regulator requirements there as well.
> > 
> > Key benefit of the series is to allow all relevant TI platforms now to use a single
> > cpufreq driver and equivalent frameworks in addition be part of the transition to
> > DT. As a result of this series, CPUFreq feature will not be available for non-DT
> > boot systems.
> > 
> As commented by Jon on internal thread, I am also against the idea of dropping
> non-DT support now. Till we migrate to 100 % DT, it is best to keep support
> alive. Especial OMAP3 based devices.
> 
> Why don't you take phased approach and have both supported for time being.
> Then once we move to DT only, we just drop the non-DT support as we plan
> to do for many more stuff.
> 
> BTW, we are using only CPUFreq driver before this series as well. I guess you
> mean the common CPUFReq drivers used by other ARM SOCs.
I had removed the entries for OPPs and clock nodes used by
omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement
"CPUFreq wont work in non-DT" configuration was accurate.

My intent was as follows:
- This series is driven mainly from maintenance angle - having to maintain
two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c),
ensuring the data is proper in both OPP tables in kernel and DT entries
is sure to cause mayhem sometime. This is not just an pain for OMAP
community, but for cpufreq community as well (since there is absolutely
no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT
world).
- as long as non-DT supported boot provides all features, there is no
real feature incentive to move to DT.

But, that said, there is one path I see possible:
- keep omap-cpufreq alive (BUT I will add a patch that will not let it init
  when in DT entries are present)
- add DT entries for all relevant OMAPs - in DT mode, we will *only*
support cpufreq-cpu0
- All future SoCs will continue to use cpufreq-cpu0 using DT, as was the
alignment I believe.

-- 
Regards,
Nishanth Menon

Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Jon Hunter]

On 03/15/2013 09:21 AM, Nishanth Menon wrote:
> On 10:48-20130315, Santosh Shilimkar wrote:
>> On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
>>> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
>>> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
>>> migrating the cpufreq support only through device tree (part of the effort
>>> to migrate away from non-DT configurations for OMAP). Unfortunately, as already
>>> known, we have a bunch of legacy code and mutually dependent device tree
>>> conversion that is pending.
>>> Key features pending:
>>> A) clock framework transition to DT - this should happen soon, so this series hacks
>>> the clock node for the time being as suggested in review of original series
>>> B) on processors that use voltage controller, voltage processor (VC/VP hardware
>>> loop using I2C_SR path) - we have started work on transitioning them to regulator
>>> framework driven by DT.
>>> C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
>>>
>>> As a result of these pending features:
>>> - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators
>>> associated at the moment - fortunately, we boot at highest voltage, so things still
>>> work.
>>> - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added
>>> those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work,
>>> where certain OPPs need enabling based on efuse programmed bit sequences - since it
>>> is an add-on work, it is not addressed here.
>>>
>> Thanks for looking into it.
> Yes, this should be the next stage to solve.
>>
>>> Note: Somewhere in the future, when we have regulators driven off CCF and OMAP
>>> converted to CCF, we could remove the DT regulator requirements there as well.
>>>
>>> Key benefit of the series is to allow all relevant TI platforms now to use a single
>>> cpufreq driver and equivalent frameworks in addition be part of the transition to
>>> DT. As a result of this series, CPUFreq feature will not be available for non-DT
>>> boot systems.
>>>
>> As commented by Jon on internal thread, I am also against the idea of dropping
>> non-DT support now. Till we migrate to 100 % DT, it is best to keep support
>> alive. Especial OMAP3 based devices.
>>
>> Why don't you take phased approach and have both supported for time being.
>> Then once we move to DT only, we just drop the non-DT support as we plan
>> to do for many more stuff.
>>
>> BTW, we are using only CPUFreq driver before this series as well. I guess you
>> mean the common CPUFReq drivers used by other ARM SOCs.
> I had removed the entries for OPPs and clock nodes used by
> omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement
> "CPUFreq wont work in non-DT" configuration was accurate.
> 
> My intent was as follows:
> - This series is driven mainly from maintenance angle - having to maintain
> two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c),
> ensuring the data is proper in both OPP tables in kernel and DT entries
> is sure to cause mayhem sometime. This is not just an pain for OMAP
> community, but for cpufreq community as well (since there is absolutely
> no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT
> world).
> - as long as non-DT supported boot provides all features, there is no
> real feature incentive to move to DT.

You are missing the point. Before you can migrate people over to DT, you
need to be ready. IMO OMAP is still not quite ready unfortunately.

> But, that said, there is one path I see possible:
> - keep omap-cpufreq alive (BUT I will add a patch that will not let it init
>   when in DT entries are present)
> - add DT entries for all relevant OMAPs - in DT mode, we will *only*
> support cpufreq-cpu0
> - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the
> alignment I believe.

Yes that is what we are doing for other drivers and should be done here.

Jon

Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver

[Nishanth Menon]

On 09:56-20130315, Jon Hunter wrote:
[..]
> > But, that said, there is one path I see possible:
> > - keep omap-cpufreq alive (BUT I will add a patch that will not let it init
> >   when in DT entries are present)
> > - add DT entries for all relevant OMAPs - in DT mode, we will *only*
> > support cpufreq-cpu0
> > - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the
> > alignment I believe.
> 
> Yes that is what we are doing for other drivers and should be done here.
OK. I guess we have not much of a choice with the legacy baggage we
carry around :(. Will redo the series for the same.

-- 
Regards,
Nishanth Menon