[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[Rajendra Nayak]

Hi,

The powerdomain framework today expects to always have a voltagedomain
associated with a given powerdomain. We already have AM33xx which
has no Voltage Controller/Voltage Processor as part of PRCM.
There are more SoCs' to follow starting with AM437x and DRA7xx
which do not have VC/VP.

Instead of adding dummy voltage domain data files, make the powerdomain
framework aware of the fact that some SoCs' might not really have
scalable voltage domains.

Patches are based of 3.10-rc5 and are boot tested on am335x bone.

Rajendra Nayak (2):
  ARM: OMAP2+: Powerdomain: Remove the need to always have a
    voltdm associated to a pwrdm
  ARM: AM33xx: Remove the unused voltagedomain data

 arch/arm/mach-omap2/Makefile                  |    1 -
 arch/arm/mach-omap2/io.c                      |    1 -
 arch/arm/mach-omap2/powerdomain.c             |    5 +++
 arch/arm/mach-omap2/powerdomain.h             |    2 ++
 arch/arm/mach-omap2/prm33xx.c                 |    7 ++++
 arch/arm/mach-omap2/voltage.h                 |    1 -
 arch/arm/mach-omap2/voltagedomains33xx_data.c |   43 -------------------------
 7 files changed, 14 insertions(+), 46 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c

-- 
1.7.9.5

[PATCH 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm

[Rajendra Nayak]

The powerdomain framework expects all powerdomains to be associated with
a corresponding voltagedomain. For some SoCs' (like the already existing AM33xx
family, or for the upcoming AM437x and DRA7 SoCs') which
do not have a Voltage controller/Voltage Processor (neither the SR I2C
bus to communicate with the PMIC) there is no need for a Powerdomain to have
a voltage domain association (since they are really non scaleable, even
though the voltage domains exist in place).

Extend the arch operations to add an api which the powerdomain core can
then use to identify if a voltdm lookup and association for a powerdomain
is really needed.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/powerdomain.c |    5 +++++
 arch/arm/mach-omap2/powerdomain.h |    2 ++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index 86babd7..e233dfc 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,10 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
 	if (_pwrdm_lookup(pwrdm->name))
 		return -EEXIST;
 
+	if (arch_pwrdm && arch_pwrdm->pwrdm_has_voltdm)
+		if (!arch_pwrdm->pwrdm_has_voltdm())
+			goto skip_voltdm;
+
 	voltdm = voltdm_lookup(pwrdm->voltdm.name);
 	if (!voltdm) {
 		pr_err("powerdomain: %s: voltagedomain %s does not exist\n",
@@ -111,6 +115,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
 	pwrdm->voltdm.ptr = voltdm;
 	INIT_LIST_HEAD(&pwrdm->voltdm_node);
 	voltdm_add_pwrdm(voltdm, pwrdm);
+skip_voltdm:
 	spin_lock_init(&pwrdm->_lock);
 
 	list_add(&pwrdm->node, &pwrdm_list);
diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
index 140c360..8ed89de 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -166,6 +166,7 @@ struct powerdomain {
  * @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
  * @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep sleep
  * @pwrdm_wait_transition: Wait for a pd state transition to complete
+ * @pwrdm_has_voltdmi: Check if a voltdm association is needed
  *
  * Regarding @pwrdm_set_lowpwrstchange: On the OMAP2 and 3-family
  * chips, a powerdomain's power state is not allowed to directly
@@ -196,6 +197,7 @@ struct pwrdm_ops {
 	int	(*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
 	int	(*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
 	int	(*pwrdm_wait_transition)(struct powerdomain *pwrdm);
+	int	(*pwrdm_has_voltdm)(void);
 };
 
 int pwrdm_register_platform_funcs(struct pwrdm_ops *custom_funcs);
-- 
1.7.9.5

[PATCH 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

> The powerdomain framework expects all powerdomains to be associated with

s/expects/currently expects/

> a corresponding voltagedomain. For some SoCs' (like the already existing AM33xx
> family, or for the upcoming AM437x and DRA7 SoCs') which
> do not have a Voltage controller/Voltage Processor (neither the SR I2C
> bus to communicate with the PMIC) there is no need for a Powerdomain to have
> a voltage domain association (since they are really non scaleable, even
> though the voltage domains exist in place).

This last phrase inside the parentheses doesn't make sense to me.
Reading that makes me think that the lack of an on-chip voltage domain
means that evn an external regulators can't scale the voltage, which I
don't believe is the case.

> Extend the arch operations to add an api which the powerdomain core can
> then use to identify if a voltdm lookup and association for a powerdomain
> is really needed.

Yes, this idea looks right to me.

In addition to the wording above, a minor nit below...

[...]

> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-omap2/powerdomain.h
> index 140c360..8ed89de 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -166,6 +166,7 @@ struct powerdomain {
>   * @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
>   * @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep sleep
>   * @pwrdm_wait_transition: Wait for a pd state transition to complete
> + * @pwrdm_has_voltdmi: Check if a voltdm association is needed

s/voltdmi/voltdm/

Kevin

[PATCH 2/2] ARM: AM33xx: Remove the unused voltagedomain data

[Rajendra Nayak]

Now that there is a way to tell the powerdomain core about
missing voltage domain control in SoCs', get rid of the dummy
voltage domain data populated for AM33xx devices.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/Makefile                  |    1 -
 arch/arm/mach-omap2/io.c                      |    1 -
 arch/arm/mach-omap2/prm33xx.c                 |    7 ++++
 arch/arm/mach-omap2/voltage.h                 |    1 -
 arch/arm/mach-omap2/voltagedomains33xx_data.c |   43 -------------------------
 5 files changed, 7 insertions(+), 46 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..a4f1d2a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -125,7 +125,6 @@ obj-$(CONFIG_ARCH_OMAP3)		+= voltagedomains3xxx_data.o
 obj-$(CONFIG_ARCH_OMAP4)		+= $(voltagedomain-common)
 obj-$(CONFIG_ARCH_OMAP4)		+= voltagedomains44xx_data.o
 obj-$(CONFIG_SOC_AM33XX)		+= $(voltagedomain-common)
-obj-$(CONFIG_SOC_AM33XX)                += voltagedomains33xx_data.o
 obj-$(CONFIG_SOC_OMAP5)			+= $(voltagedomain-common)
 
 # OMAP powerdomain framework
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..50b93df 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -577,7 +577,6 @@ void __init am33xx_init_early(void)
 	omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE), NULL);
 	omap3xxx_check_revision();
 	ti81xx_check_features();
-	am33xx_voltagedomains_init();
 	am33xx_powerdomains_init();
 	am33xx_clockdomains_init();
 	am33xx_hwmod_init();
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index 44c0d72..7204407 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -320,6 +320,12 @@ static int am33xx_pwrdm_wait_transition(struct powerdomain *pwrdm)
 	return 0;
 }
 
+static int am33xx_check_vcvp(void)
+{
+	/* No VC/VP on am33xx devices */
+	return 0;
+}
+
 struct pwrdm_ops am33xx_pwrdm_operations = {
 	.pwrdm_set_next_pwrst		= am33xx_pwrdm_set_next_pwrst,
 	.pwrdm_read_next_pwrst		= am33xx_pwrdm_read_next_pwrst,
@@ -335,4 +341,5 @@ struct pwrdm_ops am33xx_pwrdm_operations = {
 	.pwrdm_set_mem_onst		= am33xx_pwrdm_set_mem_onst,
 	.pwrdm_set_mem_retst		= am33xx_pwrdm_set_mem_retst,
 	.pwrdm_wait_transition		= am33xx_pwrdm_wait_transition,
+	.pwrdm_has_voltdm		= am33xx_check_vcvp,
 };
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index a0ce4f1..9bf796d 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -169,7 +169,6 @@ int omap_voltage_late_init(void);
 
 extern void omap2xxx_voltagedomains_init(void);
 extern void omap3xxx_voltagedomains_init(void);
-extern void am33xx_voltagedomains_init(void);
 extern void omap44xx_voltagedomains_init(void);
 
 struct voltagedomain *voltdm_lookup(const char *name);
diff --git a/arch/arm/mach-omap2/voltagedomains33xx_data.c b/arch/arm/mach-omap2/voltagedomains33xx_data.c
deleted file mode 100644
index 965458d..0000000
--- a/arch/arm/mach-omap2/voltagedomains33xx_data.c
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * AM33XX voltage domain data
- *
- * 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 as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-
-#include "voltage.h"
-
-static struct voltagedomain am33xx_voltdm_mpu = {
-	.name		= "mpu",
-};
-
-static struct voltagedomain am33xx_voltdm_core = {
-	.name		= "core",
-};
-
-static struct voltagedomain am33xx_voltdm_rtc = {
-	.name		= "rtc",
-};
-
-static struct voltagedomain *voltagedomains_am33xx[] __initdata = {
-	&am33xx_voltdm_mpu,
-	&am33xx_voltdm_core,
-	&am33xx_voltdm_rtc,
-	NULL,
-};
-
-void __init am33xx_voltagedomains_init(void)
-{
-	voltdm_init(voltagedomains_am33xx);
-}
-- 
1.7.9.5

[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[Paul Walmsley]

cc Kevin, Vaibhav

On Thu, 13 Jun 2013, Rajendra Nayak wrote:

> The powerdomain framework today expects to always have a voltagedomain
> associated with a given powerdomain. We already have AM33xx which
> has no Voltage Controller/Voltage Processor as part of PRCM.
> There are more SoCs' to follow starting with AM437x and DRA7xx
> which do not have VC/VP.
> 
> Instead of adding dummy voltage domain data files, make the powerdomain
> framework aware of the fact that some SoCs' might not really have
> scalable voltage domains.

Fine with me in principle if AM335x doesn't support voltage scaling.  
Vaibhav, if this is okay for you, please ack it.  

Then, in terms of merging, probably Kevin would be the right person for 
this since he's done much of the voltagedomain work.


- Paul

[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[Nishanth Menon]

On 02:46-20130614, Paul Walmsley wrote:
> cc Kevin, Vaibhav
> 
> On Thu, 13 Jun 2013, Rajendra Nayak wrote:
> 
> > The powerdomain framework today expects to always have a voltagedomain
> > associated with a given powerdomain. We already have AM33xx which
> > has no Voltage Controller/Voltage Processor as part of PRCM.
> > There are more SoCs' to follow starting with AM437x and DRA7xx
> > which do not have VC/VP.
> > 
> > Instead of adding dummy voltage domain data files, make the powerdomain
> > framework aware of the fact that some SoCs' might not really have
> > scalable voltage domains.
> 
> Fine with me in principle if AM335x doesn't support voltage scaling.  
> Vaibhav, if this is okay for you, please ack it.  
just a nitpick :)
There is no VFSM auto scaling to retention voltage, nor is VC-VP IP
available here, but that does not mean DVFS voltage scaling does not
exist - it is done with traditional regulator framework using regular
shared I2C.

We now seem to be moving to a generation of SoCs where VC-VP has been
dumped in favor of allowing integration with PMIC which may talk SPI/I2C
over standard interfaces - this allows us to reach better product
options, but gives up on extreme low power scenarios we had seen in the
past on OMAP.
Overall, I love this idea.
Acked-by: Nishanth Menon <nm@ti.com>
> 
> Then, in terms of merging, probably Kevin would be the right person for 
> this since he's done much of the voltagedomain work.
-- 
Regards,
Nishanth Menon

[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> cc Kevin, Vaibhav
>
> On Thu, 13 Jun 2013, Rajendra Nayak wrote:
>
>> The powerdomain framework today expects to always have a voltagedomain
>> associated with a given powerdomain. We already have AM33xx which
>> has no Voltage Controller/Voltage Processor as part of PRCM.
>> There are more SoCs' to follow starting with AM437x and DRA7xx
>> which do not have VC/VP.
>> 
>> Instead of adding dummy voltage domain data files, make the powerdomain
>> framework aware of the fact that some SoCs' might not really have
>> scalable voltage domains.
>
> Fine with me in principle if AM335x doesn't support voltage scaling.  
> Vaibhav, if this is okay for you, please ack it.  
>
> Then, in terms of merging, probably Kevin would be the right person for 
> this since he's done much of the voltagedomain work.

Yeah, I'll take this series after the minor issues I commented on are
fixed, and Vaivhav ack's the AM33xx parts.

Kevin

[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Friday, June 14, 2013 7:31 PM
> To: Paul Walmsley
> Cc: Nayak, Rajendra; Hiremath, Vaibhav; linux-omap at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 0/2] Remove unused voltagedomain data for AM33xx
> 
> Paul Walmsley <paul@pwsan.com> writes:
> 
> > cc Kevin, Vaibhav
> >
> > On Thu, 13 Jun 2013, Rajendra Nayak wrote:
> >
> >> The powerdomain framework today expects to always have a
> voltagedomain
> >> associated with a given powerdomain. We already have AM33xx which
> >> has no Voltage Controller/Voltage Processor as part of PRCM.
> >> There are more SoCs' to follow starting with AM437x and DRA7xx
> >> which do not have VC/VP.
> >>
> >> Instead of adding dummy voltage domain data files, make the
> powerdomain
> >> framework aware of the fact that some SoCs' might not really have
> >> scalable voltage domains.
> >
> > Fine with me in principle if AM335x doesn't support voltage scaling.
> > Vaibhav, if this is okay for you, please ack it.
> >
> > Then, in terms of merging, probably Kevin would be the right person
> for
> > this since he's done much of the voltagedomain work.
> 
> Yeah, I'll take this series after the minor issues I commented on are
> fixed, and Vaivhav ack's the AM33xx parts.
> 

Yeup, Feel free to add my Ack here.


Thanks,
Vaibhav 

[PATCH 0/2] Remove unused voltagedomain data for AM33xx

[Rajendra Nayak]

On Monday 17 June 2013 10:38 AM, Hiremath, Vaibhav wrote:
> 
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
>> owner at vger.kernel.org] On Behalf Of Kevin Hilman
>> Sent: Friday, June 14, 2013 7:31 PM
>> To: Paul Walmsley
>> Cc: Nayak, Rajendra; Hiremath, Vaibhav; linux-omap at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH 0/2] Remove unused voltagedomain data for AM33xx
>>
>> Paul Walmsley <paul@pwsan.com> writes:
>>
>>> cc Kevin, Vaibhav
>>>
>>> On Thu, 13 Jun 2013, Rajendra Nayak wrote:
>>>
>>>> The powerdomain framework today expects to always have a
>> voltagedomain
>>>> associated with a given powerdomain. We already have AM33xx which
>>>> has no Voltage Controller/Voltage Processor as part of PRCM.
>>>> There are more SoCs' to follow starting with AM437x and DRA7xx
>>>> which do not have VC/VP.
>>>>
>>>> Instead of adding dummy voltage domain data files, make the
>> powerdomain
>>>> framework aware of the fact that some SoCs' might not really have
>>>> scalable voltage domains.
>>>
>>> Fine with me in principle if AM335x doesn't support voltage scaling.
>>> Vaibhav, if this is okay for you, please ack it.
>>>
>>> Then, in terms of merging, probably Kevin would be the right person
>> for
>>> this since he's done much of the voltagedomain work.
>>
>> Yeah, I'll take this series after the minor issues I commented on are
>> fixed, and Vaivhav ack's the AM33xx parts.
>>
> 
> Yeup, Feel free to add my Ack here.

Thanks Vaibhav, I will add your and Nishanths' ack for this series
and repost a v2 addressing Kevins comments.

regards,
Rajendra
> 
> 
> Thanks,
> Vaibhav 
>