RE: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 5:52 PM
To: Gulati, Shweta
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public ML
as well.
shweta.gul...@ti.com wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulatishweta.gul...@ti.com
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
---
The patch is generated on top of Kevin's PM branch. It's needed for SR
functionality on the current pm branch. Have tested SR with this patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, 110),
+ OPP_INITIALIZER(mpu, true, 3, 93),
/* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, 120),
+ OPP_INITIALIZER(mpu, true, 6, 110),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
Actually no. The latest voltage layer pushed uses these voltages. Also
We have been having this setting in the internal android code base for
some time now without anybody having issues. So till the new voltages
are conveyed officially, these remain the official voltage.
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, 126),
+ OPP_INITIALIZER(mpu, true, 8, 126),
I disagree. This is not $subject. Also - not all boards will be capable
of supporting all higher frequencies rt? - remember the 3630 experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
I am not sure about this for OMAP4. Have you come across a board
where these OPPs cannot be supported? We have been enabling these
OPPs internally now for quite some time across all OMAP4 boards.
But still if you guys are paranoid about boards breaking, I am ok
With keeping these OPPs disabled by default. But then anybody running
the mainline code with a 800Mhz or 1GHz x-loader, will see a couple
of warns in the kernel code.
Regards
Thara
/* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 100800, 135),
+ OPP_INITIALIZER(mpu, true, 100800, 135),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1, 93),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 8:29 PM
To: Gopinath, Thara
Cc: Gulati, Shweta; l-o
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
Gopinath, Thara had written, on 01/06/2011 08:52 AM, the following:
-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 06, 2011 5:52 PM
To: Gulati, Shweta
Cc: linux-omap@vger.kernel.org; Gopinath, Thara
Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
it is pretty unfortunate that I have to NAK this patch in the public
ML
as well.
shweta.gul...@ti.com wrote, on 01/06/2011 12:27 AM:
From: Shweta Gulatishweta.gul...@ti.com
There is a mismatch in voltages specified in OPP table of MPU
and voltage specified in voltage table 'omap44xx_vdd_mpu_volt_data'
This Patch corrects MPU OPP Table as
well as enable OPP-Turbo and OPP-SB for MPU by default.
Signed-off-by: Thara Gopinathth...@ti.com
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
---
The patch is generated on top of Kevin's PM branch. It's needed for
SR
functionality on the current pm branch. Have tested SR with this
patch
with different OPP configurations from boot loader.
arch/arm/mach-omap2/opp4xxx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c b/arch/arm/mach-
omap2/opp4xxx_data.c
index a11fa56..4f35361 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -25,13 +25,13 @@
static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
-OPP_INITIALIZER(mpu, true, 3, 110),
+OPP_INITIALIZER(mpu, true, 3, 93),
/* MPU OPP2 - OPP100 */
-OPP_INITIALIZER(mpu, true, 6, 120),
+OPP_INITIALIZER(mpu, true, 6, 110),
Did we finalize on the nominal voltages yet?
As of yesterday's discussion, we were still debating about the actual
voltage at OMAP ball level, while there is a secondary voltage called
cap voltage - we have been discussing on this for some time. I suggest
strongly that we dont touch this for the time being (the voltage in
mainline is slightly higher - let it be so till the h/w folks finalize
things).
Actually no. The latest voltage layer pushed uses these voltages. Also
Arrgh... another reason to avoid messy duplicate tables!!
Oh there is a patch in my bag where we use a single macro for each voltage
across the voltage and opp layer!! Not yet posted because I am waiting for
voltage layer to be merged.
We have been having this setting in the internal android code base for
some time now without anybody having issues. So till the new voltages
are conveyed officially, these remain the official voltage.
Funny,
how many versions of internal code bases are present?
http://dev.omapzoom.org/?p=santosh/kernel-omap4-
base.git;a=blob;f=arch/arm/mach-
omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a
What are you complaining about here? I thought Shweta's patch
was making the mpu entries in the opp table similar to the
ones in the link above. Anything I am missing?
/* MPU OPP3 - OPP-Turbo */
-OPP_INITIALIZER(mpu, false, 8, 126),
+OPP_INITIALIZER(mpu, true, 8, 126),
I disagree. This is not $subject. Also - not all boards will be
capable
of supporting all higher frequencies rt? - remember the 3630
experience?
is'nt it wiser to enable it based on board capabilities - e.g. similar
to the patch I did for beagle XM yesterday - we wont be able to enable
higher frequencies on SDP3630 as we have not guarenteed with PDN
analysis that it is ok.
I am not sure about this for OMAP4. Have you come across a board
where these OPPs cannot be supported? We have been enabling these
OPPs internally now for quite some time across all OMAP4 boards.
*all* as in how many? SDP/Blaze, Panda and??? How many boards are
available which is in production?
All as in SDP, Blaze and Panda, today by default we boot up at 1 Ghz.
I have not heard of anybody asking to lower the frequencies. If you are
talking about any customer board, I am not the person to comment.
Regards
Thara
But still if you guys are paranoid about boards breaking, I am ok
With keeping these OPPs disabled by default. But then anybody running
the mainline code with a 800Mhz or 1GHz x-loader, will see a couple
of warns in the kernel code.
You do have the option of enabling the frequency for specific boards
like SDP/Blaze (e.g. if you have h/w team's signoff that these can do
high frequencies - and I think they do).
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table
-Original Message- From: Menon, Nishanth Sent: Thursday, January 06, 2011 8:49 PM To: Gopinath, Thara Cc: Gulati, Shweta; l-o Subject: Re: [PATCH] OMAP4 PM: To correct voltages in MPU OPP Table Gopinath, Thara had written, on 01/06/2011 09:09 AM, the following: [..] Actually no. The latest voltage layer pushed uses these voltages. Also Arrgh... another reason to avoid messy duplicate tables!! Oh there is a patch in my bag where we use a single macro for each voltage across the voltage and opp layer!! Not yet posted because I am waiting for voltage layer to be merged. I think I would find that patch interesting - Just fyi, the SR series is already in omap-for-linus branch and slated for .38-rc1, so feel free to post additional changes. Yes I will post it. We have been having this setting in the internal android code base for some time now without anybody having issues. So till the new voltages are conveyed officially, these remain the official voltage. Funny, how many versions of internal code bases are present? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=blob;f=arch/arm/mach- omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a What are you complaining about here? I thought Shweta's patch was making the mpu entries in the opp table similar to the ones in the link above. Anything I am missing? Yes, I am lost as to what the official voltage at PMIC level is for each OPP for OMAP4 is now :(! there are half a dozen trees out there - Ubuntu kernel, generic linux tree, android kernel tree etc - so the claim of one tree containing official table is kinda interesting as one wonders what one gets with other trees ;). Are you sure all these tree do not have the same voltage values for mpu rail on OMAP4? Because as far as I am aware I am the one who has been writing this code and I have never used any other values. So then it is kind of interesting! /* MPU OPP3 - OPP-Turbo */ - OPP_INITIALIZER(mpu, false, 8, 126), + OPP_INITIALIZER(mpu, true, 8, 126), I disagree. This is not $subject. Also - not all boards will be capable of supporting all higher frequencies rt? - remember the 3630 experience? is'nt it wiser to enable it based on board capabilities - e.g. similar to the patch I did for beagle XM yesterday - we wont be able to enable higher frequencies on SDP3630 as we have not guarenteed with PDN analysis that it is ok. I am not sure about this for OMAP4. Have you come across a board where these OPPs cannot be supported? We have been enabling these OPPs internally now for quite some time across all OMAP4 boards. *all* as in how many? SDP/Blaze, Panda and??? How many boards are available which is in production? All as in SDP, Blaze and Panda, today by default we boot up at 1 Ghz. I have not heard of anybody asking to lower the frequencies. If you are talking about any customer board, I am not the person to comment. Right, so lets keep it disabled for the moment as it does not even match $subject and violates the concept of a single patch doing a single thing - enabling higher frequencies at this point of time is premature IMHO. Ah! I am not debating the subject vs content issue here at all! You are very much in the right regarding that. All I am asking is is there a genuine issue in enabling the higher OPP's for mpu on OMAP4 today. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Adding T2 enabling of smartreflex
-Original Message-
From: Menon, Nishanth
Sent: Monday, January 03, 2011 9:22 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com;
p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH] OMAP3: PM: Adding T2 enabling of smartreflex
Thara Gopinath had written, on 12/31/2010 02:07 AM, the following:
The smartreflex bit on twl4030 needs to be enabled by default
irrespective
of whether smartreflex module is enabled on the OMAP side or not.
This is because without this bit enabled the voltage scaling through
vp forceupdate does not function properly on OMAP3.
s/does not function properly/ does not function ;)
SR I2C is used for forceupdate/vc bypass modes - so neither will
function without switching t2 mode.
T2 voltages could be set in quiet a few methods:
a) Synchronized Scaling Hardware Strategy (ENABLE_VMODE = 1) (for OMAP2
and I had worked on one OMAP3430 product which used this as well) using
VDD1_VFLOOR and VDD1_VROOF
b) Direct Strategy Software Scaling Mode (ENABLE_VMODE = 0) (Smart
reflex disabled) - VDD1_VSEL
c) using smart reflex - as done below - allows OMAP with smart reflex
hardware wired to the twl to use that functionality.
Blindly setting it to smartreflex mode is not correct IMHO. It might
work on SDP and few TI and non-TI platforms, but not all.
Yes you are right. The SR I2C needs to be enabled for vp force update
and vc bypass method of voltage scaling as well as for smartreflex
feature. Are you telling that there are platforms out there using OMAP3
and T2 and still using VMODE or VSEL. As far as I am aware our h/w folks
themselves do not recommend these methods.
Regards
Thara
Signed-off-by: Thara Gopinath th...@ti.com
---
This patch is against LO master and has been
tested on OMAP3430 SDP and OMAP2430 SDP.
arch/arm/mach-omap2/omap_twl.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 15f8c6c..a59f36b 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -58,7 +58,9 @@
static bool is_offset_valid;
static u8 smps_offset;
+#define TWL4030_DCDC_GLOBAL_CFG0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -256,6 +258,7 @@ int __init omap4_twl_init(void)
int __init omap3_twl_init(void)
{
struct voltagedomain *voltdm;
+ u8 temp;
if (!cpu_is_omap34xx())
return -ENODEV;
@@ -267,6 +270,19 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
+ /*
+* The smartreflex bit on twl4030 needs to be enabled by
+* default irrespective of whether smartreflex module is
+* enabled on the OMAP side or not. This is because without
+* this bit enabled the voltage scaling through
+* vp forceupdate does not function properly on OMAP3.
+*/
+ twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ temp |= SMARTREFLEX_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: PM: Adding T2 enabling of smartreflex
-Original Message-
From: Hilman, Kevin
Sent: Wednesday, January 05, 2011 4:18 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Menon, Nishanth
Subject: Re: [PATCH] OMAP3: PM: Adding T2 enabling of smartreflex
Thara Gopinath th...@ti.com writes:
The smartreflex bit on twl4030 needs to be enabled by default
irrespective
of whether smartreflex module is enabled on the OMAP side or not.
This is because without this bit enabled the voltage scaling through
vp forceupdate does not function properly on OMAP3.
Based on Nishanth's comments, the abofe statements need a little more
justification.
What is probably needed is some default setting (possibly this one) but
with the possibility of board code to disable this if needed.
Yes. If we need to support the other means of voltage scaling, we definitely
need to override this bit from board files. I am not so convinced that we need
to support them though. IMHO, this patch can still go in with change in the
comment and if needed, there can be another patch with an API in omap_twl.c
allowing overriding/ enabling-disabling of sr - i2c bit on
the T2 side.
Regards
Thara
Kevin
Signed-off-by: Thara Gopinath th...@ti.com
---
This patch is against LO master and has been
tested on OMAP3430 SDP and OMAP2430 SDP.
arch/arm/mach-omap2/omap_twl.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 15f8c6c..a59f36b 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -58,7 +58,9 @@
static bool is_offset_valid;
static u8 smps_offset;
+#define TWL4030_DCDC_GLOBAL_CFG0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -256,6 +258,7 @@ int __init omap4_twl_init(void)
int __init omap3_twl_init(void)
{
struct voltagedomain *voltdm;
+ u8 temp;
if (!cpu_is_omap34xx())
return -ENODEV;
@@ -267,6 +270,19 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
+ /*
+* The smartreflex bit on twl4030 needs to be enabled by
+* default irrespective of whether smartreflex module is
+* enabled on the OMAP side or not. This is because without
+* this bit enabled the voltage scaling through
+* vp forceupdate does not function properly on OMAP3.
+*/
+ twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ temp |= SMARTREFLEX_ENABLE;
+ twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP DVFS rebase
Hello All, I have rebased the available DVFS code for OMAP tree against LO master which contains the latest OMAP voltage layer and smartreflex changes and hosted it at http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=shortlog;h=refs/heads/pm-dvfs head - pm-dvfs Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/12] OMAP4: clock data: Add missing DPLL x2 clock nodes
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, December 22, 2010 7:17 AM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Gopinath, Thara; Nayak, Rajendra; Cousson, Benoit
Subject: Re: [PATCH 03/12] OMAP4: clock data: Add missing DPLL x2 clock
nodes
On Mon, 13 Dec 2010, Paul Walmsley wrote:
From: Thara Gopinath th...@ti.com
This patch extends the OMAP4 clock data to include
various x2 clock nodes between DPLL and HS dividers as the
clock framework skips a x2 while calculating the dpll locked
frequency.
The clock database extensions are autogenerated using
the scripts maintained by Benoit Cousson.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
[p...@pwsan.com: fixed merge conflicts against v2.6.37-rc5]
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
This patch has been updated to drop dpll_mpu_x2_ck. According to Benoît
there is no need for this clock because there are no users of it, and the
script has been updated accordingly.
dpll_mpu_x2_ck was added to maintain the compatibility with other dpll
nodes. You can drop it if there is no use for it and you perceive no use
for it in OMAP4.
Regards
Thara
- Paul
From: Thara Gopinath th...@ti.com
Date: Tue, 21 Dec 2010 18:11:05 -0700
Subject: [PATCH] OMAP4: clock data: Add missing DPLL x2 clock nodes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This patch extends the OMAP4 clock data to include
various x2 clock nodes between DPLL and HS dividers as the
clock framework skips a x2 while calculating the dpll locked
frequency.
The clock database extensions are autogenerated using
the scripts maintained by Benoit Cousson.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
[p...@pwsan.com: fixed merge conflicts against v2.6.37-rc5; dropped
dpll_mpu_x2_ck on advice from Benoît]
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 415 -
-
1 files changed, 240 insertions(+), 175 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
omap2/clock44xx_data.c
index 305019c4..7c8d7f4 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -275,11 +275,63 @@ static struct clk dpll_abe_ck = {
.set_rate = omap3_noncore_dpll_set_rate,
};
+static struct clk dpll_abe_x2_ck = {
+ .name = dpll_abe_x2_ck,
+ .parent = dpll_abe_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
+static const struct clksel_rate div31_1to31_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 2, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 3, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 4, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 5, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 6, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 7, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 8, .val = 8, .flags = RATE_IN_4430 },
+ { .div = 9, .val = 9, .flags = RATE_IN_4430 },
+ { .div = 10, .val = 10, .flags = RATE_IN_4430 },
+ { .div = 11, .val = 11, .flags = RATE_IN_4430 },
+ { .div = 12, .val = 12, .flags = RATE_IN_4430 },
+ { .div = 13, .val = 13, .flags = RATE_IN_4430 },
+ { .div = 14, .val = 14, .flags = RATE_IN_4430 },
+ { .div = 15, .val = 15, .flags = RATE_IN_4430 },
+ { .div = 16, .val = 16, .flags = RATE_IN_4430 },
+ { .div = 17, .val = 17, .flags = RATE_IN_4430 },
+ { .div = 18, .val = 18, .flags = RATE_IN_4430 },
+ { .div = 19, .val = 19, .flags = RATE_IN_4430 },
+ { .div = 20, .val = 20, .flags = RATE_IN_4430 },
+ { .div = 21, .val = 21, .flags = RATE_IN_4430 },
+ { .div = 22, .val = 22, .flags = RATE_IN_4430 },
+ { .div = 23, .val = 23, .flags = RATE_IN_4430 },
+ { .div = 24, .val = 24, .flags = RATE_IN_4430 },
+ { .div = 25, .val = 25, .flags = RATE_IN_4430 },
+ { .div = 26, .val = 26, .flags = RATE_IN_4430 },
+ { .div = 27, .val = 27, .flags = RATE_IN_4430 },
+ { .div = 28, .val = 28, .flags = RATE_IN_4430 },
+ { .div = 29, .val = 29, .flags = RATE_IN_4430 },
+ { .div = 30, .val = 30, .flags = RATE_IN_4430 },
+ { .div = 31, .val = 31, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel dpll_abe_m2x2_div[] = {
+ { .parent = dpll_abe_x2_ck, .rates = div31_1to31_rates },
+ { .parent = NULL },
+};
+
static struct clk dpll_abe_m2x2_ck = {
.name = dpll_abe_m2x2_ck,
- .parent = dpll_abe_ck,
+ .parent = dpll_abe_x2_ck,
+ .clksel = dpll_abe_m2x2_div,
+ .clksel_reg = OMAP4430_CM_DIV_M2_DPLL_ABE,
+ .clksel_mask= OMAP4430_DPLL_CLKOUT_DIV_MASK,
.ops
RE: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, December 17, 2010 7:01 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand; Menon, Nishanth Subject: Re: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support Hi Thara, Thara Gopinath th...@ti.com writes: This patch series introduces smartreflex and voltage driver support for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. [...] This patch series has been tested on OMAP3430 SDP with omap2plus_defconfig with the following menuconfig options enabled. Any testing on 3630? System type - TI OMAP Implementations - Smartreflex Support System type - TI OMAP Implementations - Class 3 mode of Smartreflex Implementation Major Changes in v5 - Rebased to k.org 2.6.37-rc3 - Rebased to Nishant Menon's latest opp patches - Voltage pmic info structure extended to include a vast set of PMIC dependent parameters. - Smartreflex software n-target values support removed from the kernel. Instead n-target values are exposed as debugfs entries which can be written into by the user if needed. - Introduced a new file arch/arm/mach-omap2/omap_twl.c for specifying OMAP and TWL related info for the voltage layer. - Remove default enabling of smartreflex autocompensation during boot on OMAP3430 ES3.1 chips. Instead an API is provided that can be called from board files in case autocompensation needs to be enabled during boot up itself. - Other review comments on v4 This series is looking good. I have a couple minor comments on specific patches. Hello Kevin, Thanks for the review! Also, it needs (hopefully only) one more rebase/repost. First, a few things have changed at the PRCM API level that need to be updated. I have a untested patch (below) that should fix this for you, that you'll need to split and apply to the OMAP3 and OMAP4 voltage driver patches. You have forgotten to attach the patch! Can you please share it. To test with those changes, you can rebase onto my pm-core branch, which contains not only the PRCM API changes, but also Nishanth's latest OPP branch, and several other clock, hwmod, PM core changes queued for 2.6.38 Second, please also Cc the linux-arm-kernel mailing list, so if/when we merge this into linux-omap, it doesn't need a last minute repost. I will CC linux-arm when I am posting the next version Regards Thaa -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: pm.c correct the initcall for an early init.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, December 14, 2010 6:37 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, December 02, 2010 7:03 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. Thara Gopinath th...@ti.com writes: omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation Why postcore? there are several other inicalls earlier than device_initcall. Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their init, we will again have to bump up the init priority of this fn. It is a good thing to do this early on in the boot cycle rather than later. OK, please describe this in more detail the changelog. Ok Will repost Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, December 08, 2010 10:05 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following: [..] And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime. On production system (OS users): they should'nt be using this. is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents. Nishant, The issue here is most of these parameters are one time setting (during init) and need not be changed at all if the user does not wish to over-ride them for debug purpose. Hence the need for the checks (not double-hooks). But I agree with your point that let us get the basic in the kernel.org in some form. So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. Regards Thara --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Menon, Nishanth Sent: Thursday, December 09, 2010 4:54 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara wrote, on 12/09/2010 03:43 AM: -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Wednesday, December 08, 2010 10:05 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara had written, on 12/08/2010 10:18 AM, the following: [..] And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, Glancing at the debug entries being overidden, as developer (debug users) working for tweaking parameters for their platform - yes - we will need some mechanism to runtime tweak and see the behavior without needing to rebuild the kernel everytime. On production system (OS users): they should'nt be using this. is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Lets get the basics in kernel.org in some form! IMHO, all this double knobs are un-necessary overheads in codeflow for development only code- just provide the debugfs entries that reflect the data in their original structures, use the original structures everytime we go to a new transition (aka if you change the params in debugfs, they dont take effect till you do another transition).. but that is just my 2cents. Nishant, The issue here is most of these parameters are one time setting (during init) and need not be changed at all if the user does not wish to over-ride them for debug purpose. Hence the need for the checks (not double-hooks). But I agree If they are init time thingy, then why not set it up so that when some one echo's to the debugfs, it writes to the register as well? That way you dont need to add runtime check and the debug developer does'nt need to worry about echo 1 magic_control_sys_fs_file (just kidding). Yes but then for it the debugfs set get APIs should have access to the data structures which stores the register offset etc. Today I am using a single API to set any parameter any vdd. This will have to change. Maybe one API per parameter. I cannot currently think of any better solution :-)! with your point that let us get the basic in the kernel.org in some form. So for this first version that we plan to push to kernel.org, I plan to expose out these parameters to user space but not allow a write access to them. The write access part can be added later whenever required. Sure.. at this point, anything that actually works is welcome :) Ok :-) ! Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, November 16, 2010 3:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath th...@ti.com writes: This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. The voltage parameters can be viewed at /debug/voltage/vdd_x/parameter and the smartreflex parameters can be viewed at /debug/vdd_x/smartreflex/parameter To enable overriding of these parameters from user side, write 1 into /debug/voltage/vdd_x/override_volt_params Please just git rid of any sort of override parameter from sysfs. Instead, you can detect in the sysfs code itself if any parameters were changed and then set the vdd-user_override flag. But in the sys-fs code I do not have access to vdd. How do I then set this flag? But when will I unset this flag?? You can't. And, AFAICT, it wasn't clear from the current code or docs whether this could work or was expected to work either, e.g., if you set override_volt_params back to zero, to the original values all get reused? If you want to provide this feature, then it should be documented and made clear that this is an intended goal. Thinking about this more, the main thing I don't like about this approach is that the active code paths (enable disable) have to check each time if any of these values have been overidden. Rather than have several places in the active code paths where this override value is checked, there the sysfs methods should simply update the values that are used by the core code. This way, the core would not need to know about where the values came from (defalts, volt_data, user override, etc.) If you want to provide a way to revert this, then maybe writing -1 will should switch that value back to the HW default, or volt_data default. Kevin, Benoit, Nishant et al, Without this override flag today there is no direct way of allowing user to write into these parameters. My question is, is there a need for the parameters to be over-written from the user-space? If yes, I need ideas on how to implement it with using override_volt_params ! Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: pm.c correct the initcall for an early init.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, December 02, 2010 7:03 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: pm.c correct the initcall for an early init. Thara Gopinath th...@ti.com writes: omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation Why postcore? there are several other inicalls earlier than device_initcall. Because the init in omap_device is a core_initcall. With respect to opp layer, making this anything above device_initcall will work. But then tomorrow some other module needs these generic devices in their init, we will again have to bump up the init priority of this fn. It is a good thing to do this early on in the boot cycle rather than later. Also, does this actually work? Is the driver core initialized at postcore_initcall time such that omap_devices w/platform_device creation actually works? Yes by post_initcall the omap_device initializations would have happened. In fact these initializations happen as core_initcall. Kevin Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 59ca03b..6ec2ee1 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -143,5 +143,5 @@ static int __init omap2_common_pm_init(void) return 0; } -device_initcall(omap2_common_pm_init); +postcore_initcall(omap2_common_pm_init); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP PM: Optimize cpufreq transition latency
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Turquette, Mike Sent: Wednesday, December 01, 2010 1:20 AM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS vishwanath...@ti.com wrote: Currently cpufreq transition latency value does not really reflect the actual OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer expiry. With this change, performance of ondemand governor is improved when tested using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand performance as 40% of performance governor, and with this patch it's around 70% (using below procedure). cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/ Command used for performance testing: cpufreq-bench -l 5 -s 10 -x 5 -y 10 -g ondemand -r 5 -n 5 - v Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/plat-omap/cpu-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 = 100755 arch/arm/plat-omap/cpu-omap.c diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); - /* FIXME: what's the actual transition time? */ - policy-cpuinfo.transition_latency = 300 * 1000; + /* Program the actual transition time for worstcase */ + policy-cpuinfo.transition_latency = 30 * 1000; Vishwa, This is a frequent periodic timer. Does a smaller value have any affect on CPUidle wakeups? I thought this is a deferred timer and so should not affect the cpuidle thread at all. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Wednesday, December 01, 2010 9:01 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com
Subject: RE: [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, October 29, 2010 9:08 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
VDD1.
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
index 6f85f75..241fac5 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -350,6 +350,23 @@ static struct omap_volt_data
omap44xx_vdd_core_volt_data[] = {
{.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
0x16},
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 120, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 127, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 135, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
I think you have already given these comments on the list. Any ways I am
incorporating them.
Regards
Thara
Vishwa
+
/* By default VPFORCEUPDATE is the chosen method of voltage scaling
*/
static bool voltscale_vpforceupdate = true;
@@ -574,6 +591,8 @@ static void __init
omap3_vdd_data_configure(struct omap_vdd_info *vdd)
vdd-volt_data = omap34xx_vdd1_volt_data;
vdd-volt_data_count =
ARRAY_SIZE(omap34xx_vdd1_volt_data);
+ vdd-dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd-nr_dep_vdd =
ARRAY_SIZE(omap34xx_vdd1_dep_info);
}
vdd-vp_reg.tranxdone_status =
OMAP3430_VP1_TRANXDONE_ST_MASK;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:00 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3 Thara Gopinath th...@ti.com writes: This patch adds voltage driver support for OMAP3. The driver allows configuring the voltage controller and voltage processors during init and exports APIs to enable/disable voltage processors, scale voltage and reset voltage. The driver also maintains the global voltage table on a per VDD basis which contains the various voltages supported by the VDD along with per voltage dependent data like smartreflex n-target value, errminlimit and voltage processor errorgain. The driver allows scaling of VDD voltages either through vc bypass method or through vp forceupdate method the choice being configurable through the board file. This patch contains code originally in linux omap pm branch smartreflex driver. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath th...@ti.com All comments below are cut-and-paste from v3 review, and were not addressed in this update. --- arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/voltage.c | 1158 + arch/arm/plat-omap/include/plat/voltage.h | 141 3 files changed, 1301 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/voltage.c create mode 100644 arch/arm/plat-omap/include/plat/voltage.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 0b6d9af..bfdabcc 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -51,7 +51,8 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o pm_bus.o +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \ + cpuidle34xx.o pm_bus.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c new file mode 100644 index 000..5aa5109 --- /dev/null +++ b/arch/arm/mach-omap2/voltage.c @@ -0,0 +1,1158 @@ +/* + * OMAP3/OMAP4 Voltage Management Routines + * + * Author: Thara Gopinath th...@ti.com + * + * Copyright (C) 2007 Texas Instruments, Inc. + * Rajendra Nayak rna...@ti.com + * Lesly A M x0080...@ti.com + * + * Copyright (C) 2008 Nokia Corporation + * Kalle Jokiniemi + * + * Copyright (C) 2010 Texas Instruments, Inc. + * Thara Gopinath th...@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 linux/delay.h +#include linux/io.h +#include linux/clk.h +#include linux/err.h +#include linux/debugfs.h +#include linux/slab.h + +#include plat/common.h +#include plat/voltage.h + +#include prm-regbits-34xx.h + +#define VP_IDLE_TIMEOUT200 +#define VP_TRANXDONE_TIMEOUT 300 +#define VOLTAGE_DIR_SIZE 16 + +static struct dentry *voltage_dir; +/* PRM voltage module */ +static u32 volt_mod; There's no need for this to be a global, this should be a member of vdd_info (or the voltage domain.) That means the read/write functions will have to take an additional argument (vdd or voltdm) but that's cleaner to me. Kevin, The voltage_read and voltage_write APIs are used not only for the per vdd registers. We also access the vc registers through them and passing vdd or voltdm is not an option. Two options we have are 1. Keep the existing implementation 2. Have volt_mod/prm_mod per vdd basis in the omap_vdd_info struct. Introduce a new struct for storing vc parameters per SoC basis and have a prm_mod there also. Scrap voltage_read and voltage_write APIs and use prm_read and prm_write instead. The last step is because we do not want a voltage_read / voltage_write which looks exactly similar to prm_read/prm_write and do nothing but call into prm_read/prm_write. Do let me know your thoughts as I m in the midst of the rework. I am assuming you would prefer option 2 and proceeding :-)! Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, November 11, 2010 12:30 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for
OMAP3
[resend with thinned out response, since original reply was determined
to be spam by vger.kernel.org. wondering that tells me about my review
style... ]
Thara Gopinath th...@ti.com writes:
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
All comments below are cut-and-paste from v3 review, and were not
addressed in this update.
Hello Kevin,
Thanks for the review. I thought I had fixed most of the v3 comments
except the ones about the n-target values. Sorry if I had missed some.
[...]
--- /dev/null
+++ b/arch/arm/mach-omap2/voltage.c
@@ -0,0 +1,1158 @@
+/*
+ * OMAP3/OMAP4 Voltage Management Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ * Lesly A M x0080...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@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 linux/delay.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/debugfs.h
+#include linux/slab.h
+
+#include plat/common.h
+#include plat/voltage.h
+
+#include prm-regbits-34xx.h
+
+#define VP_IDLE_TIMEOUT200
+#define VP_TRANXDONE_TIMEOUT 300
+#define VOLTAGE_DIR_SIZE 16
+
+static struct dentry *voltage_dir;
+/* PRM voltage module */
+static u32 volt_mod;
There's no need for this to be a global, this should be a member of
vdd_info (or the voltage domain.) That means the read/write functions
will have to take an additional argument (vdd or voltdm) but that's
cleaner to me.
Ok.
[...]
+/* OMAP3 specific voltage init functions */
+/*
+ * Intializes the voltage controller registers with the PMIC and board
+ * specific parameters and voltage setup times for OMAP3. If the board
+ * file does not populate the voltage controller parameters through
+ * omap3_pm_init_vc, default values specified in vc_config is used.
+ */
+static void __init omap3_init_voltagecontroller(void)
I'd like to see consistent naming. Elsewhere in the code, things are
named with either a vdd, vc or vp prefix. Let's keep that here and call
this omap3_vc_init(), and for VP below, s/init_voltagecontroller/vp_init/
Will rename
[...]
+ /*
+* Sys clk rate is require to calculate vp timeout value and
+* smpswaittimemin and smpswaittimemax.
+*/
+ sys_ck = clk_get(NULL, sys_ck);
+ if (IS_ERR(sys_ck)) {
+ pr_warning(%s: Could not get the sys clk to calculate
+ various vdd_%s params\n, __func__, vdd-voltdm.name);
+ return;
+ }
+ sys_clk_speed = clk_get_rate(sys_ck);
+ clk_put(sys_ck);
+ /* Divide to avoid overflow */
+ sys_clk_speed /= 1000;
+
+ /* Nominal/Reset voltage of the VDD */
+ vdd-nominal_volt = vdd-curr_volt = 120;
This should be a #define someplace, something like OMAP3_VDDx_RESET_VOL
or similar. Ideally with a TRM/doc reference to where it comes from.
I'm a little confused. Is this a hardware reset value? or a software
reset value which is part of this layer.
It's a little confusing, since if this is a hardware reset voltage why
does init_voltageprocessor() have to write it to the VP during init?
Even better, rather than hard code this, it would be even better if it
just picked one of the nominal voltages from the volt_data table.
Yes this is the default voltage at which the hardware will boot up.
I had to add this since some errata workarounds requires the vdd to be put to
this level even though this level might not correspond to any opp. The voltage
scaling
RE: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 7/9] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath th...@ti.com writes: This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. The voltage parameters can be viewed at /debug/voltage/vdd_x/parameter and the smartreflex parameters can be viewed at /debug/vdd_x/smartreflex/parameter To enable overriding of these parameters from user side, write 1 into /debug/voltage/vdd_x/override_volt_params Please just git rid of any sort of override parameter from sysfs. Instead, you can detect in the sysfs code itself if any parameters were changed and then set the vdd-user_override flag. But when will I unset this flag?? Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/6] OMAP4: Adding voltage driver support
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, November 11, 2010 12:52 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 2/6] OMAP4: Adding voltage driver support
Thara Gopinath th...@ti.com writes:
OMAP4 has three scalable voltage domains vdd_mpu, vdd_iva
and vdd_core. This patch adds the voltage tables and other
configurable voltage processor and voltage controller
settings to control these three scalable domains in OMAP4.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+/*
+ * Structures containing OMAP4430 voltage supported and various
+ * data associated with it per voltage domain basis. Smartreflex Ntarget
+ * values are left as 0 as they have to be populated by smartreflex
+ * driver after reading the efuse.
+ */
+static struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
+ {.volt_nominal = 93, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
+ {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain = 0x16},
+ {.volt_nominal = 126, .sr_errminlimit = 0xFA, .vp_errgain = 0x23},
+ {.volt_nominal = 135, .sr_errminlimit = 0xFA, .vp_errgain = 0x27},
+};
+
+static struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
+ {.volt_nominal = 93, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
+ {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain = 0x16},
+ {.volt_nominal = 126, .sr_errminlimit = 0xFA, .vp_errgain = 0x23},
+};
+
+static struct omap_volt_data omap44xx_vdd_core_volt_data[] = {
+ {.volt_nominal = 93, .sr_errminlimit = 0xF4, .vp_errgain = 0x0C},
+ {.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain = 0x16},
+};
As mentioned in previous reviews, the standard is to write hex value
using lower case letters. Please fix this up in the both OMAP3 4 series.
Ok. Sorry for missing this.
[...]
+/* Sets up all the VDD related info for OMAP4 */
+static void __init omap4_vdd_data_configure(struct omap_vdd_info *vdd)
+{
+ struct clk *sys_ck;
+ u32 sys_clk_speed, timeout_val, waittime;
+
+ if (!strcmp(vdd-voltdm.name, mpu)) {
+ vdd-vp_reg.vlimitto_vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN;
+ vdd-vp_reg.vlimitto_vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX;
+ vdd-volt_data = omap44xx_vdd_mpu_volt_data;
+ vdd-volt_data_count = ARRAY_SIZE(omap44xx_vdd_mpu_volt_data);
+ vdd-vp_reg.tranxdone_status =
+ OMAP4430_VP_MPU_TRANXDONE_ST_MASK;
+ vdd-cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_MPU_L_OFFSET;
+ vdd-vdd_sr_reg = OMAP4_VDD_MPU_SR_VOLT_REG;
+ } else if (!strcmp(vdd-voltdm.name, core)) {
+ vdd-vp_reg.vlimitto_vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN;
+ vdd-vp_reg.vlimitto_vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX;
+ vdd-volt_data = omap44xx_vdd_core_volt_data;
+ vdd-volt_data_count = ARRAY_SIZE(omap44xx_vdd_core_volt_data);
+ vdd-vp_reg.tranxdone_status =
+ OMAP4430_VP_CORE_TRANXDONE_ST_MASK;
+ vdd-cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_CORE_L_OFFSET;
+ vdd-vdd_sr_reg = OMAP4_VDD_CORE_SR_VOLT_REG;
+ } else if (!strcmp(vdd-voltdm.name, iva)) {
+ vdd-vp_reg.vlimitto_vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN;
+ vdd-vp_reg.vlimitto_vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX;
+ vdd-volt_data = omap44xx_vdd_iva_volt_data;
+ vdd-volt_data_count = ARRAY_SIZE(omap44xx_vdd_iva_volt_data);
+ vdd-vp_reg.tranxdone_status =
+ OMAP4430_VP_IVA_TRANXDONE_ST_MASK;
+ vdd-cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_IVA_L_OFFSET;
+ vdd-vdd_sr_reg = OMAP4_VDD_IVA_SR_VOLT_REG;
+ } else {
+ pr_warning(%s: vdd_%s does not exisit in OMAP4\n,
+ __func__, vdd-voltdm.name);
+ return;
+ }
+
+ /*
+* Sys clk rate is require to calculate vp timeout value and
+* smpswaittimemin and smpswaittimemax.
+*/
+ sys_ck = clk_get(NULL, sys_clkin_ck);
+ if (IS_ERR(sys_ck)) {
+ pr_warning(%s: Could not get the sys clk to calculate
+ various vdd_%s params\n, __func__, vdd-voltdm.name);
+ return;
+ }
+ sys_clk_speed = clk_get_rate(sys_ck);
+ clk_put(sys_ck);
+
+ /* Divide to avoid overflow */
+ sys_clk_speed /= 1000;
+
+ /* Nominal/Reset voltage of the VDD */
+ vdd-nominal_volt = vdd-curr_volt = 120;
same comment as from OMAP3 series.
Will take care
[...]
/* Generic voltage init functions */
static void __init init_voltageprocessor(struct omap_vdd_info *vdd)
{
@@ -753,6 +945,14 @@ static int vp_forceupdate_scale_voltage(struct
omap_vdd_info *vdd,
vc_cmd_on_mask = OMAP3430_VC_CMD_ON_MASK;
prm_irqst_reg_offs = OMAP3_PRM_IRQSTATUS_MPU_OFFSET
RE: [PATCH v2 04/14] OMAP: Introduce API to register a device with a voltagedomain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, November 11, 2010 6:19 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 04/14] OMAP: Introduce API to register a device with a
voltagedomain
Thara Gopinath th...@ti.com writes:
This patch adds an API in the voltage layer that
can be used during omap_device_build to register the built
device with the voltage domain. This API is to be typically called
only once per device during the device registeration. This approach
makes it easy during dvfs to scale all the devices associated with
a voltage domain and then scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
/* Generic voltage init functions */
@@ -1240,6 +1251,40 @@ int omap_voltage_add_request(struct voltagedomain
*voltdm, struct device *dev,
return 0;
}
+int omap_voltage_add_dev(struct voltagedomain *voltdm, struct device *dev)
minor nit: I prefer this be a 'register' function,
e.g. omap_voltage_register (or _register_dev)
_register_dev. Will rename.
[...]
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
omap/omap_device.c
index abe933c..7c902a6 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -86,6 +86,7 @@
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/voltage.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -453,6 +454,17 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
for (i = 0; i oh_cnt; i++) {
hwmods[i]-od = od;
_add_optional_clock_alias(od, hwmods[i]);
+ if (hwmods[i]-vdd_name) {
Use:
if (!is_early_device hwmods[i]-vdd_name)
+ struct omap_hwmod *oh = hwmods[i];
+ struct voltagedomain *voltdm;
+
+ if (is_early_device)
+ continue;
and drop this check
Ok
+ voltdm = omap_voltage_domain_lookup(oh-vdd_name);
+ if (!omap_voltage_add_dev(voltdm, od-pdev.dev))
+ oh-voltdm = voltdm;
+ }
}
if (ret)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 05/14] OMAP: Introduce device specific set rate and get rate in omap_device structure
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, November 12, 2010 4:29 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 05/14] OMAP: Introduce device specific set rate and
get rate in omap_device structure
Thara Gopinath th...@ti.com writes:
This patch extends the omap_device structure to contain
pointers to scale the operating rate of the
device and to retrieve the operating rate of the device.
This patch also adds the three new APIs in the omap device layer
namely omap_device_set_rate that can be called to set a new operating
rate for a device, omap_device_get_rate that can be called to retrieve
the operating frequency for a device and omap_device_populate_rate_fns
to populte the device specific set_rate and get_rate API's.
The omap_device_set_rate and omap_device_get_rate does some routine error
checks and finally calls into the device specific set_rate
and get_rate APIs populated through omap_device_populate_rate_fns.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |9 +
arch/arm/plat-omap/omap_device.c | 49
+
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index 28e2d1a..2a37345 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -50,6 +50,8 @@ extern struct device omap_device_parent;
* @hwmods: (one .. many per omap_device)
* @hwmods_cnt: ARRAY_SIZE() of @hwmods
* @pm_lats: ptr to an omap_device_pm_latency table
+ * @set_rate: fn ptr to change the operating rate.
+ * @get_rate: fn ptr to retrieve the current operating rate.
* @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
* @pm_lat_level: array index of the last odpl entry executed - -1 if
never
* @dev_wakeup_lat: dev wakeup latency in nanoseconds
@@ -67,6 +69,8 @@ struct omap_device {
struct platform_device pdev;
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
minor nit, but I prefer the function pointers at the end.
Ok
u32 dev_wakeup_lat;
u32 _dev_wakeup_lat_limit;
u8 pm_lats_cnt;
@@ -107,6 +111,11 @@ void __iomem *omap_device_get_rt_va(struct omap_device
*od);
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
+int omap_device_set_rate(struct device *dev, unsigned long freq);
+unsigned long omap_device_get_rate(struct device *dev);
+void omap_device_populate_rate_fns(struct device *dev,
+ int (*set_rate)(struct device *dev, unsigned long rate),
+ unsigned long (*get_rate) (struct device *dev));
how about omap_device_register_callbacks()
I am ok. But then the name will not specify what kind of
callbacks.
/* Other */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
omap/omap_device.c
index 7c902a6..ffe06eb 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -785,6 +785,55 @@ int omap_device_enable_clocks(struct omap_device *od)
return 0;
}
+int omap_device_set_rate(struct device *dev, unsigned long freq)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
pdev = to_platform_device(dev)
This helper is already defined in platform_device.h.
Ok
+ od = _find_by_pdev(pdev);
+
+ if (!od-set_rate) {
+ dev_err(dev, %s: No set_rate API for scaling device\n,
+ __func__);
+ return -ENODATA;
+ }
+
+ return od-set_rate(dev, freq);
+}
+
+unsigned long omap_device_get_rate(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
pdev = to_platform_device(dev)
+ od = _find_by_pdev(pdev);
+
+
+ if (!od-get_rate) {
+ dev_err(dev, %s: No get rate API for the device\n,
+ __func__);
+ return 0;
+ }
+
+ return od-get_rate(dev);
+}
+
+void omap_device_populate_rate_fns(struct device *dev,
+ int (*set_rate)(struct device *dev, unsigned long rate),
+ unsigned long (*get_rate) (struct device *dev))
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
pdev = to_platform_device(dev)
Ok
+ od
RE: [PATCH v2 06/14] OMAP: Voltage layer changes to support DVFS.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, November 12, 2010 5:04 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 06/14] OMAP: Voltage layer changes to support DVFS.
Thara Gopinath th...@ti.com writes:
This patch introduces an API to take in the voltage domain and the
new voltage as parameter and to scale all the scalable devices
associated with the the voltage domain to the rate corresponding to the
new voltage and scale the voltage domain to the new voltage.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 72
+
arch/arm/plat-omap/include/plat/voltage.h |7 +++
2 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6c2e4ef..458f8c1 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -27,9 +27,11 @@
#include linux/spinlock.h
#include linux/plist.h
#include linux/slab.h
+#include linux/opp.h
#include plat/common.h
#include plat/voltage.h
+#include plat/omap_device.h
#include prm-regbits-34xx.h
#include prm44xx.h
@@ -1678,6 +1680,76 @@ struct voltagedomain
*omap_voltage_domain_lookup(char *name)
}
/**
+ * omap_voltage_scale : API to scale the devices associated with a
+ * voltage domain vdd voltage.
+ * @volt_domain : the voltage domain to be scaled
+ * @volt : the new voltage for the voltage domain
+ *
+ * This API runs through the list of devices associated with the
+ * voltage domain and scales the device rates to those corresponding
+ * to the new voltage of the voltage domain. This API also scales
+ * the voltage domain voltage to the new value. Returns 0 on success
+ * else the error value.
+ */
+int omap_voltage_scale(struct voltagedomain *voltdm, unsigned long volt)
+{
+ unsigned long curr_volt;
+ int is_volt_scaled = 0;
+ struct omap_vdd_info *vdd;
+ struct omap_vdd_dev_list *temp_dev;
+
+ if (!voltdm || IS_ERR(voltdm)) {
+ pr_warning(%s: VDD specified does not exist!\n, __func__);
+ return -EINVAL;
+ }
+
+ vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
+
+ mutex_lock(vdd-scaling_mutex);
+
+ curr_volt = omap_voltage_get_nom_volt(voltdm);
+
+ if (curr_volt == volt) {
+ is_volt_scaled = 1;
+ } else if (curr_volt volt) {
+ omap_voltage_scale_vdd(voltdm, volt);
+ is_volt_scaled = 1;
+ }
+
+ list_for_each_entry(temp_dev, vdd-dev_list, node) {
+ struct device *dev;
+ struct opp *opp;
+ unsigned long freq;
+
+ dev = temp_dev-dev;
+
+ opp = opp_find_voltage(dev, volt);
+ if (IS_ERR(opp)) {
+ dev_err(dev, %s: Unable to find OPP for
+ volt%ld\n, __func__, volt);
+ continue;
+ }
+
+ freq = opp_get_freq(opp);
+
+ if (freq == omap_device_get_rate(dev)) {
+ dev_warn(dev, %s: Already at the requested
+ rate %ld\n, __func__, freq);
Does this need to be a warning? This happens relatively often and is normal.
This should probably just be removed in favor of
if (freq != omap_device_get_rate(dev))
omap_device_set_rate(dev, freq);
Yes. There are other warnings also in the dvfs code
which could be removed. Will remove them all in the next
version
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/6] OMAP4: Add the new voltage to vsel calculation formula
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, November 04, 2010 10:54 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; khil...@deeprootsystems.com;
Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 1/6] OMAP4: Add the new voltage to vsel calculation
formula
* Thara Gopinath th...@ti.com [101027 09:07]:
TWL6030 the power IC used along with OMAP4 in OMAP4 SDPs,
blaze boards and panda boards has a different formula
from that of TWL4030 for voltage to vsel and
vsel to voltage calculation. This patch implements the new
formula depending on the PMIC type.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp_twl_tps.c | 71
++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/opp_twl_tps.c b/arch/arm/plat-
omap/opp_twl_tps.c
index 4448fc5..358b67b 100644
--- a/arch/arm/plat-omap/opp_twl_tps.c
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -15,9 +15,16 @@
#include linux/module.h
+#include linux/i2c/twl.h
+
#include plat/opp_twl_tps.h
#include plat/voltage.h
+static bool is_offset_valid;
+static u8 smps_offset;
+
+#define REG_SMPS_OFFSET 0xE0
+
/**
* omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
* @vsel: TWL/TPS VSEL value to convert
@@ -27,6 +34,38 @@
*/
unsigned long omap_twl_vsel_to_uv(const u8 vsel)
{
+ if (twl_class_is_6030()) {
+ /*
+* In TWL6030 depending on the value of SMPS_OFFSET
+* efuse register the voltage range supported in
+* standard mode can be either between 0.6V - 1.3V or
+* 0.7V - 1.4V. In TWL6030 ES1.0 SMPS_OFFSET efuse
+* is programmed to all 0's where as starting from
+* TWL6030 ES1.1 the efuse is programmed to 1
+*/
+ if (!is_offset_valid) {
+ twl_i2c_read_u8(TWL6030_MODULE_ID0, smps_offset, 0xE0);
+ is_offset_valid = true;
+ }
+
+ if (smps_offset 0x8) {
+ return vsel - 1) * 125) + 7000)) * 100;
+ } else {
+ /*
+* In case of the supported voltage range being
+* between 0.6V - 1.3V, there is not specific
+* formula for voltage to vsel conversion above
+* 1.3V. There are special hardcoded values for
+* voltages above 1.3V. Currently we are hardcodig
+* only for 1.35 V which is used for 1GH OPP for
+* OMAP4430.
+*/
+ if (vsel == 0x3A)
+ return 135;
+ return vsel - 1) * 125) + 6000)) * 100;
+ }
+ }
+
return (((vsel * 125) + 6000)) * 100;
}
Here too you will want to restructure things a bit so you can avoid
adding the if twl_class_is_whatever else if tests. Usually the best
way is to set separate functions for different chips during the init.
Hello Tony,
Thanks for the review.
There is another comment for this patch to drop this file all-together
and move this code to drivers/mfd/twl-core.c. Will take care of your
comment in the new location
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 3/6] OMAP4: PM: Program correct init voltages for scalable VDDs
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Thursday, November 04, 2010 10:50 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; khil...@deeprootsystems.com;
Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 3/6] OMAP4: PM: Program correct init voltages for
scalable VDDs
Hi Thara,
* Thara Gopinath th...@ti.com [101027 09:08]:
By default the system boots up at nominal voltage for every
voltage domain in the system. This patch puts vdd_mpu, vdd_iva
and vdd_core to the correct boot up voltage as per the opp tables
specified. This patch implements this by matching the rate of
the main clock of the voltage domain with the opp table and
picking up the correct voltage.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 353e155..0651667 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -211,6 +211,10 @@ static int __init omap2_common_pm_init(void)
if (cpu_is_omap34xx()) {
omap2_set_init_voltage(mpu, dpll1_ck, mpu_dev);
omap2_set_init_voltage(core, l3_ick, l3_dev);
+ } else if (cpu_is_omap44xx()) {
+ omap2_set_init_voltage(mpu, dpll_mpu_ck, mpu_dev);
+ omap2_set_init_voltage(core, l3_div_ck, l3_dev);
+ omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva_dev);
}
omap_pm_if_init();
In general, we want to avoid adding these if cpu_is_ompa34xx else if
things all over the place. That makes the code hard to maintain and
requires patching all over the place to add support for new omaps.
Instead, please do something like this:
static int __init omap_common_whatever_init(struct whatever_data *d)
{
...
return 0;
}
static int __init omap3_whatever_init(void)
{
struct whatever_data *d;
if (!cpu_is_omap34xx())
return -ENODEV;
/* Initialize omap3 specific things */
...
return omap_common_whatever_init(d);
}
device_initcall(omap3_whatever_init);
static int __init omap4_whatever_init(void)
{
struct whatever_data *d;
if (!cpu_is_omap44xx())
return -ENODEV;
/* Initialize omap4 specific things */
...
return omap_common_whatever_init(d);
}
device_initcall(omap4_whatever_init);
...
This way the common code stays readable and does not need
to be patched when support for new omaps is added. Also the
code for unselected omaps gets optimized out and an extra
level of code indentation is left out.
Yes. Will take care of this in the next version
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message-
From: Sripathy, Vishwanath
Sent: Thursday, November 11, 2010 11:30 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sawant,
Anand
Subject: RE: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for
OMAP3
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for
OMAP3
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/voltage.c | 1158
+
arch/arm/plat-omap/include/plat/voltage.h | 141
3 files changed, 1301 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/voltage.c
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
omap2/Makefile
index 0b6d9af..bfdabcc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -51,7 +51,8 @@ obj-$(CONFIG_ARCH_OMAP2) +=
sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
cpuidle34xx.o pm_bus.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
+ cpuidle34xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
new file mode 100644
index 000..5aa5109
--- /dev/null
+++ b/arch/arm/mach-omap2/voltage.c
@@ -0,0 +1,1158 @@
+/*
+ * OMAP3/OMAP4 Voltage Management Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ * Lesly A M x0080...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@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 linux/delay.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/debugfs.h
+#include linux/slab.h
+
+#include plat/common.h
+#include plat/voltage.h
+
+#include prm-regbits-34xx.h
+
+#define VP_IDLE_TIMEOUT200
+#define VP_TRANXDONE_TIMEOUT 300
+#define VOLTAGE_DIR_SIZE 16
+
+static struct dentry *voltage_dir;
+/* PRM voltage module */
+static u32 volt_mod;
+
+/* Voltage processor register offsets */
+struct vp_reg_offs {
+ u8 vpconfig;
+ u8 vstepmin;
+ u8 vstepmax;
+ u8 vlimitto;
+ u8 vstatus;
+ u8 voltage;
+};
+
+/* Voltage Processor bit field values, shifts and masks */
+struct vp_reg_val {
+ /* VPx_VPCONFIG */
+ u32 vpconfig_erroroffset;
+ u16 vpconfig_errorgain;
+ u32 vpconfig_errorgain_mask;
+ u8 vpconfig_errorgain_shift;
+ u32 vpconfig_initvoltage_mask;
+ u8 vpconfig_initvoltage_shift;
+ u32 vpconfig_timeouten;
+ u32 vpconfig_initvdd;
+ u32 vpconfig_forceupdate;
+ u32 vpconfig_vpenable;
+ /* VPx_VSTEPMIN */
+ u8 vstepmin_stepmin;
+ u16 vstepmin_smpswaittimemin;
+ u8 vstepmin_stepmin_shift;
+ u8 vstepmin_smpswaittimemin_shift;
+ /* VPx_VSTEPMAX */
+ u8 vstepmax_stepmax;
+ u16 vstepmax_smpswaittimemax;
+ u8 vstepmax_stepmax_shift;
+ u8 vstepmax_smpswaittimemax_shift;
+ /* VPx_VLIMITTO */
+ u16 vlimitto_vddmin;
+ u16 vlimitto_vddmax;
+ u16 vlimitto_timeout;
+ u16 vlimitto_vddmin_shift;
+ u16 vlimitto_vddmax_shift;
+ u16 vlimitto_timeout_shift;
+ /* PRM_IRQSTATUS*/
+ u32
RE: [PATCH v2] OMAP4: Extend clock database.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, November 10, 2010 5:54 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit Subject: Re: [PATCH v2] OMAP4: Extend clock database. Thara Gopinath th...@ti.com writes: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. The clock databse extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Thara Gopinath th...@ti.com The subject could be a bit more descriptive here, something like: OMAP4: clock: add various DPLL x2 clock nodes or something similar. Will fix and post V3 Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP4: Extend clock database.
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Saturday, October 30, 2010 3:07 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; Cousson, Benoit Subject: Re: [PATCH v2] OMAP4: Extend clock database. Thara, On Wed, 27 Oct 2010, Thara Gopinath wrote: This patch extends the OMAP4 clock data to include various x2 clock nodes as the clock framework skips a *2 whie calculating the dpll locked frequency. The clock databse extensions are autogenerated using the scripts maintained by Benoit Cousson. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/clock44xx_data.c | 427 -- 1 files changed, 248 insertions(+), 179 deletions(-) diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach- omap2/clock44xx_data.c index 1599836..94896af 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -17,10 +17,6 @@ * 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. - * - * XXX Some of the ES1 clocks have been removed/changed; once support - * is added for discriminating clocks by ES level, these should be added back - * in. */ Please don't remove this comment unless you're also adding the ES1 clocks back. Hello Paul, I did not remove this. The script did :-). But I will manually add it back and post v3. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
-Original Message-
From: Varadarajan, Charulatha
Sent: Thursday, October 28, 2010 11:09 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: RE: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Gopinath, Thara
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 3/9] OMAP3: PM: Adding smartreflex device file.
This patch adds support for device registration of various
smartreflex module present in the system. This patch introduces
the platform data for smartreflex devices which include
the efused and test n-target vaules, module enable/disable
pointers and a parameter to indicate whether smartreflex
autocompensation needs to be enabled on init or not.
Currently auocompensation is enabled on init by default
for OMAP3430 ES3.1 chip.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/sr_device.c | 177
+++
2 files changed, 178 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/sr_device.c
snip
+
+static int sr_dev_init(struct omap_hwmod *oh, void *user)
Since *user is unused, you may rename it to *unused
Ok will do.
+{
+ struct omap_sr_data *sr_data;
+ struct omap_sr_dev_data *sr_dev_data;
+ struct omap_device *od;
+ char *name = smartreflex;
+ static int i;
+
+ sr_data = kzalloc(sizeof(struct omap_sr_data), GFP_KERNEL);
+ if (!sr_data) {
+ pr_err(%s: Unable to allocate memory for %s
sr_data.Error!\n,
+ __func__, oh-name);
+ return -ENOMEM;
+ }
+
+ sr_dev_data = (struct omap_sr_dev_data *)oh-dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err(%s: dev atrribute is NULL\n, __func__);
+ goto exit;
+ }
+
+ /*
+* OMAP3430 ES3.1 chips by default come with Efuse burnt
+* with parameters required for full functionality of
+* smartreflex AVS feature like ntarget values , sennenable
+* and senpenable. So enable the SR AVS feature during boot up
+* itself if it is a OMAP3430 ES3.1 chip.
+*/
+ sr_data-enable_on_init = false;
+ if (cpu_is_omap343x())
+ if (omap_rev() == OMAP3430_REV_ES3_1)
+ sr_data-enable_on_init = true;
+
+ sr_data-voltdm =
omap_voltage_domain_lookup(sr_dev_data-vdd_name);
+ if (IS_ERR(sr_data-voltdm)) {
+ pr_err(%s: Unable to get voltage domain
pointer for VDD %s\n,
+ __func__, sr_dev_data-vdd_name);
+ goto exit;
+ }
+
+ sr_dev_data-volts_supported = omap_voltage_get_volttable(
+ sr_data-voltdm, sr_dev_data-volt_data);
+ if (!sr_dev_data-volts_supported) {
+ pr_warning(%s: No Voltage table registerd fo VDD%d.
+ Something really wrong\n\n, __func__, i + 1);
+ goto exit;
+ }
+
+ sr_set_nvalues(sr_dev_data, sr_data);
+
+ od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
+ omap_sr_latency,
+ ARRAY_SIZE(omap_sr_latency), 0);
Patch 4 should come before patch 3 in the series. Otherwise, this
would fail during a git-bisect.
Why?? All patches individually compile and boot.
+ if (IS_ERR(od))
+ pr_warning(%s: Could not build omap_device for
%s: %s.\n\n,
+ __func__, name, oh-name);
Return error.
+exit:
+ i++;
+ kfree(sr_data);
+ return 0;
+}
+
+static int __init omap_devinit_smartreflex(void)
+{
+ return omap_hwmod_for_each_by_class(smartreflex,
sr_dev_init, NULL);
+}
+device_initcall(omap_devinit_smartreflex);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
-Original Message-
From: Varadarajan, Charulatha
Sent: Thursday, October 28, 2010 11:09 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD MPU and the
other associated with VDD CORE.
This patch adds support for smartreflex driver. The driver
is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP
implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debug/voltage/vdd_X/smartreflex/autocomp
To disable smartreflex autocompensation feature
echo 0 /debug/voltage/vdd_X/smartreflex/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 975
+
arch/arm/plat-omap/Kconfig| 36 +
arch/arm/plat-omap/include/plat/smartreflex.h | 271 +++
4 files changed, 1283 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
snip
+static int __init omap_sr_probe(struct platform_device *pdev)
+{
+ struct omap_sr *sr_info = kzalloc(sizeof(struct
omap_sr), GFP_KERNEL);
+ struct omap_device *odev = to_omap_device(pdev);
Patch3 should be ordered before patch2 in your series. Otherwise,
this would fail during a git-bisect.
Again why ?? All patches individually compile and boot.
+ struct omap_sr_data *pdata = pdev-dev.platform_data;
+ struct resource *mem, *irq;
+ struct dentry *vdd_dbg_dir, *dbg_dir;
+ int ret = 0;
+
+ if (!sr_info) {
+ dev_err(pdev-dev, %s: unable to allocate sr_info\n,
+ __func__);
+ return -ENOMEM;
+ }
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: platform data
missing\n, __func__);
+ return -EINVAL;
+ }
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(pdev-dev, %s: no mem resource\n, __func__);
+ ret = -ENODEV;
+ goto err_free_devinfo;
+ }
+
+ irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+
+ pm_runtime_enable(pdev-dev);
+
+ sr_info-pdev = pdev;
+ sr_info-srid = pdev-id;
+ sr_info-voltdm = pdata-voltdm;
+ sr_info-autocomp_active = false;
+ sr_info-ip_type = odev-hwmods[0]-class-rev;
I am not sure if it is okay to get hwmods-info in the driver.
To avoid too many indirections, it can be obtained before
omap_device_build() of the device and passed to the driver.
mmm. yep we could do it also. Maybe Kevin/Benoit needs to confirm the
correct way of doing this.
Regards
Thara
+ sr_info-base = ioremap(mem-start, resource_size(mem));
+ if (!sr_info-base) {
+ dev_err(pdev-dev, %s: ioremap fail\n, __func__);
+ ret = -ENOMEM;
+ goto err_release_region;
+ }
snip
-V Charulatha
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 0/9] OMAP3: Adding Smartreflex and Voltage driver support
-Original Message- From: Menon, Nishanth Sent: Wednesday, October 27, 2010 10:51 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 0/9] OMAP3: Adding Smartreflex and Voltage driver support Gopinath, Thara had written, on 10/27/2010 11:10 AM, the following: This patch series introduces smartreflex and voltage driver support for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage control for real-time voltage adjustments. [..] thanks for the revamped set You are most welcome!! This patch series is based against lo-master with the following additional patches applied. https://patchwork.kernel.org/patch/266911/ https://patchwork.kernel.org/patch/266921/ https://patchwork.kernel.org/patch/266931/ https://patchwork.kernel.org/patch/183712/ https://patchwork.kernel.org/patch/285872/ The entire series with the dependencies are available at http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=summary head: thara-pm-sr This patch series has been tested on OMAP3430 SDP with omap2plus_defconfig with the following menuconfig options enabled. System type - TI OMAP Implementations - Smartreflex Support System type - TI OMAP Implementations - Class 3 mode of Smartreflex Implementation Thanks for hosting the branch, Looking at: Again glad tat u liked it:-) http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=shortlog;h=refs/heads/thara- pm-sr I am guessing DVFS is missing in this branch? Is it possible to give it a test drive? Yes.. This is exactly what I am trying to do. Will keep you updated. Also curious should: OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code should probably be dropped with OMAP3: PM: Register TWL4030 pmic info with the voltage ? Hmm.. Last time I suggested moving the contents of this patch to twl-core.c Nobody seemed to much keen. Hence I retained the plat-omap/opp-twl-tpl.c file. In fact OMAP3: PM: Register TWL4030 pmic info with the voltage registers the params from plat-omap/opp-twl-tpl.c. But if we have a consensus I will just drop this patch and have the pmic params passed from twl-core.c. [...] my 2cents: If that tree were organized based on branches which depend on each other it will be easier to identify the dependencies :) probably: kernel.org (now that l-o is merged - potential 2.6.37-rc1) |- clock patches -\ |- DVFS series-| |- OMAP OPP series | |-merged-based - |-voltage layer SR series perhaps |- twl optimization |- board changes *** final code *** Just 2 cents to make it easier for folks who are not in PM mostly to see how everything falls together in place.. I agree. But then I need some five patches on top of potential 2.6.37-rc1, which are not present in any branch. Are you asking me to generate separate branches for all these patches? Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
-Original Message-
From: Varadarajan, Charulatha
Sent: Friday, October 29, 2010 10:23 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: RE: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Wednesday, October 27, 2010 9:41 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson,
Benoit; Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v4 2/9] OMAP3: PM: Adding smartreflex driver support.
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD MPU and the
other associated with VDD CORE.
This patch adds support for smartreflex driver. The driver
is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP
implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debug/voltage/vdd_X/smartreflex/autocomp
To disable smartreflex autocompensation feature
echo 0 /debug/voltage/vdd_X/smartreflex/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 975
+
arch/arm/plat-omap/Kconfig| 36 +
arch/arm/plat-omap/include/plat/smartreflex.h | 271 +++
4 files changed, 1283 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
snip
+static int __init omap_sr_probe(struct platform_device *pdev)
+{
+ struct omap_sr *sr_info = kzalloc(sizeof(struct
omap_sr), GFP_KERNEL);
+ struct omap_device *odev = to_omap_device(pdev);
Patch3 should be ordered before patch2 in your series. Otherwise,
this would fail during a git-bisect.
Again why ?? All patches individually compile and boot.
omap_device_build() for this device is being done in the next patch.
Hence I gave this input. But I believe that this does not harm because
the probe would not get called. Correct me if I am wrong.
Exactly probe will not get called. So I do not think the patch ordering
needs to change.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, October 22, 2010 10:22 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Gopinath, Thara th...@ti.com writes: Thara Gopinath th...@ti.com writes: This patch adds debug support to the voltage and smartreflex drivers. This means a whole bunch of voltage processor and smartreflex parameters are now visible through the pm debugfs. By default only a read of these parameters are permitted. If you need to write into them then echo 1 /pm_debug/enable_sr_vp_debug Why a read-only interface by default? As a debug interface it seems redundant to have to enable it. Read-only interface by default so that we can read these values from user space even if we do not want to manipulate it from user-side. If we do not want to manipulate it from the user-side, then simply don't write to it. Remember, this is a debug interface, not a primary interface. I think the enable_sr_vp_debug flag should disappear, and it should be a read/write interface. If the values are changed via debugfs, then set some per-SR instance flag that can be checked. Basically, the current code is confusing because you're using the the flag called 'enable' to determine whether the user *might have* written the values. [...] + /* +* Getting vp errorgain based on the voltage. If the debug option is +* enabled allow the override of errorgain from user side. +*/ As suggested in earlier comment, please use a specific flag that this has been overridden instead of the 'debug enabled' flag (which should disappear, IMO) What do you mean by a separate flag. You want a flag to be maintained for just this purpose ? Yes. I want a flag to be maintained *specifically* for this purpose, instead of using a much more general flag that only means a user *might* have overridden the values, use one that specifically means a user *has* overridden the values. Hello Kevin, I tried this. Couple of questions/concerns I have. 1. If you take a look at the definition of these debugfs parameters, the omap_vdd_info struct is not passed as an argument. The actual variables are the parameters. I am not sure how to extract omap_vdd_info from this. Maybe container_of will help, but then it will be clumsy. Same concern for smartreflex err_minlimit variable. There is no way to get the sr instance except use container of which I am not sure will work or not 2.Also in voltage layer we export out eight parameters tat can be over-ridden from the user side. I do not think we should be maintaining one flag per variable. The design will be too very clumsy. Regards Thara Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization from board files.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, October 22, 2010 10:08 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization from board files. Gopinath, Thara th...@ti.com writes: This patch enables smartreflex class3 functionality for OMAP3430SDP, OMAP3630SDP, ZOOM2 and ZOOM3 boards. This patch doesn't touch 3630sdp. Signed-off-by: Thara Gopinath th...@ti.com I'm having some doubts about whether this should be done by board files or not. Seems like the general case will be that by default will be SoC specific, and only boards that want something other than the default class should need to override this. Thoughts? I agree. I wanted this to be a default initcall and one to enable the menuconfig option for the required class driver.. But Nishant wanted this from board files. And I want both. :) If we have consensus in removing this init from board file, I am cool with it. I want to suport a kernel that could be built with all possible classes supported. e.g. an omap3/4 kernel that has both class 1.5 and class 3 support. If both are enabled in Kconfig, then either could be used. We'll have to pick one as the default initcall (e.g. highest class present), but if a board file chooses to call a different one, that should override the default one. We can pick class 3 by default and make it a late_initcall. This way if the board files choose to call some other class init, that class ddriver would be registered. Smartreflex driver sr_register_class API will ensure that only one class is registered. The second registeration will fail. What say ?? Regards, Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 01/11] OMAP: PM: Export the main pm debugfs directory
-Original Message-
From: Cousson, Benoit
Sent: Monday, October 25, 2010 3:00 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com;
Sripathy, Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 01/11] OMAP: PM: Export the main pm debugfs directory
On 9/22/2010 4:45 PM, Gopinath, Thara wrote:
This patch makes generic pm_debug directory global
so that other drivers can include it and use it to create
sub-entries.
That should not be needed, if we expose voltage debugfs entry in the top
level directly.
Agreed. I am ok with exposing the voltage debugfs entry at the top level.
Regards
Thara
Benoit
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/pm-debug.c |3 +++
arch/arm/mach-omap2/pm.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-
debug.c
index af00c17..390f1c6 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -42,6 +42,7 @@ u32 enable_off_mode;
u32 sleep_while_idle;
u32 wakeup_timer_seconds;
u32 wakeup_timer_milliseconds;
+struct dentry *pm_dbg_main_dir;
#define DUMP_PRM_MOD_REG(mod, reg)\
regs[reg_count].name = #mod . #reg; \
@@ -641,6 +642,8 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(wakeup_timer_milliseconds,
S_IRUGO | S_IWUGO, d,wakeup_timer_milliseconds,
pm_dbg_option_fops);
+
+ pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f3ba1e6..c06cedd 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -55,6 +55,7 @@ extern int omap2_pm_debug;
#define omap2_pm_dump(mode, resume, us) do {} while (0);
#define omap2_pm_wakeup_on_timer(seconds, milliseconds) do {} while (0);
#define omap2_pm_debug0
+#define pm_dbg_main_dir0
#endif
#if defined(CONFIG_CPU_IDLE)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 04/11] OMAP3: PM: Adding smartreflex device file.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 22, 2010 10:02 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 04/11] OMAP3: PM: Adding smartreflex device file.
Gopinath, Thara th...@ti.com writes:
On Wed, 2010-09-22 at 20:15 +0530, Thara Gopinath wrote:
This patch adds support for device registration of various
smartreflex module present in the system. This patch introduces
the platform data for smartreflex devices which include
the efused and test n-target vaules, module enable/disable
pointers and a parameter to indicate whether smartreflex
autocompensation needs to be enabled on init or not.
Currently auocompensation is enabled on init by default
for OMAP3430 ES3.1 chip.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+sr_data-voltdm =
omap_voltage_domain_get(sr_dev_data-vdd_name);
+if (IS_ERR(sr_data-voltdm)) {
+pr_err(%s: Unable to get voltage domain pointer for VDD
%s\n,
+__func__, sr_dev_data-vdd_name);
+goto exit;
+}
+
+sr_dev_data-volts_supported = omap_voltage_get_volttable(
+sr_data-voltdm, sr_dev_data-volt_data);
+if (!sr_dev_data-volts_supported) {
+pr_warning(%s: No Voltage table registerd fo VDD%d.
+Something really wrong\n\n, __func__, i + 1);
+goto exit;
+}
+
+sr_set_nvalues(sr_dev_data, sr_data);
First question: why does this N-value init need to be done in the device
init? It seems better to be a part of the SR driver probe.
OMAP3 and OMAP4 has different ways of reading the efuse registers. I
would like it to be in device file so that we can have the necessary
checks. The driver should not be bothered about getting of the
n-values.
Bothered? The driver's job is to probe the HW. The device code
can tell the driver where the N-values are located (register offsets,
via platform_data), but IMO, should not be reading the values from HW.
But then we will have to put cpu_is_omap34xx() and cpu_is_omap44xx() checks in
the driver. Also omap_ctrl_readl API will have to be used from the driver.
Second, this section took me quite some time to understand, as it seems
to blur the lines of device and driver but also how it interacts with
the voltage layer.
sr_set_nvalues() is directly manipulating structures that are internal
to the voltage layer. It also makes assumptions about the ordering of
volt_data structs in the voltage layer.
Strictly speaking neither the sr_nvalue or sr_errminlimit fields of
volt_data are not used at all in the voltage layer, but only in the SR
layer, so ideally they should really stay in the SR layer.
I think what is needed here is a cleaner way for the SR layer to connect
the N-values to a voltage. The current method of manipulating voltage
layer structs inside the SR layer is not acceptable. Since the n-values
are fixed in HW (per SoC), what I suggest is simply having a field like
'efuse_id' or something in volt_data. Then, the smart reflex layer can
lookup and index all the efuse values during probe, and when sr_enable
is called, it looks up the nvalue based on efuse_id.
I assume that the sr_errminlimit could also be set based on efuse_id,
and therefore remain contained within the SR layer, but I'm not sure I
like that idea any better than keeping it inside volt_data. For now,
I'll let you make the call on errminlimit, but I really want to see the
N-value stuff isolated in the SR layer.
I do not understand your proposal here? What kind of variable is efuse-id??
Sorry, it was kind of rambling. I'll try again...
Currently, omap_volt_data (in the voltage layer) includes SR N-value
field:
struct omap_volt_data {
u32 volt_nominal;
u32 sr_nvalue;
u8 sr_errminlimit;
u8 vp_errgain;
};
but sr_nvalue is not used in the voltage layer at all.
This choice has led to the SR device init code having to populate
internal structures of the voltage layer. That is what I don't like.
(I have a similar problem with the presence of sr_errminlimit in the
omap_volt_data, because it's not used in the voltage layer either.)
So my suggestion was to remove the sr_nvalue field and replace it with
something like an efuse_id field. Since n-values are directly connected
with HW registers, this is a simple mapping.
This way, the voltage layer does not know about the exact N-value
(because it doesn't care), ll the voltage layer needs to know is
which efuse to use for this voltage.
Yes. But then voltage layer will not know about the efuse id as well. They are
passed as dev attribute from hwmod file today. Are you telling remove them and
hardcode them in voltage layer?
As for implementation, in the SR driver, probe could read the N-values
from HW
RE: [PATCH v3 03/11] OMAP3: PM: Adding smartreflex driver support.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, October 14, 2010 5:34 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 03/11] OMAP3: PM: Adding smartreflex driver support.
Thara Gopinath th...@ti.com writes:
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD1 and the
other associated with VDD2.
s/VDD1/MPU/
s/VDD2/CORE/
Will correct.
This patch adds support for smartreflex driver. The driver is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debugfs/pm_debug/smartreflex/sr_X/autocomp
To disable smartreflex autocompensation feature
echo 0 /debugfs/pm_debug/smartreflex/sr_X/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 1003
+
arch/arm/plat-omap/Kconfig| 32 +
arch/arm/plat-omap/include/plat/smartreflex.h | 277 +++
4 files changed, 1313 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4f74f2b..8dd32a7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
cpuidle34xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
omap2/smartreflex.c
new file mode 100644
index 000..7fc3138
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -0,0 +1,1003 @@
+/*
+ * OMAP SmartReflex Voltage Control
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Lesly A M x0080...@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 linux/interrupt.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/debugfs.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+
+#include plat/omap_device.h
+#include plat/common.h
+#include plat/smartreflex.h
+
+#include pm.h
+
+#define SMARTREFLEX_NAME_LEN 16
+#define SR_DISABLE_TIMEOUT 200
+
+struct dentry *sr_dbg_dir;
+
+struct omap_sr {
+ int srid;
+ boolsr_enable;
sr_enabled is a better name
Ok.
+ boolautocomp_active;
+ int ip_type;
+ u32 clk_length;
+ u32 err_weight;
+ u32 err_minlimit;
+ u32 err_maxlimit;
+ u32 accum_data;
+ u32 senn_avgweight;
+ u32 senp_avgweight;
+ unsigned intirq;
+ void __iomem*base;
+ struct platform_device *pdev;
+ struct list_headnode;
+ struct voltagedomain*voltdm;
+};
+
+/* sr_list contains all the instances of smartreflex module */
+static LIST_HEAD(sr_list);
+
+static struct omap_smartreflex_class_data *sr_class;
+static struct omap_smartreflex_pmic_data
RE: [PATCH v3 02/11] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Thursday, October 14, 2010 11:35 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 02/11] OMAP3: PM: Adding voltage driver support for
OMAP3
On Wed, 2010-09-22 at 20:15 +0530, Thara Gopinath wrote:
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+/*
+ * Omap3630 specific VP register values. Maybe these need to come from
+ * board file or PMIC data structure
+ */
+#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18
+#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3C
+#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18
+#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30
+
+/* TODO OMAP4 VP register values if the same file is used for OMAP4*/
+
+/**
+ * voltagedomain - omap voltage domain global structure
+ * @name : Name of the voltage domain which can be used as a unique
+ * identifier.
+ */
+struct voltagedomain {
+ char *name;
+};
Minor: to keep the voltagedomain stuff somewhat separate from the rest
of the voltage layer API, I suggest putting the voltage domain APIs
here:
struct voltagedomain *omap_voltage_domain_get(char *name);
You mean just move up the signature, right? I do not think the entire API can
be moved here as it uses some static data structures in voltage.c
However, I think this function shoul be called _lookup instead of _get
to continue the naming conventions of the powerdomain and clockdomain
code.
I will rename the API.
Regards
Thara
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 04/11] OMAP3: PM: Adding smartreflex device file.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Friday, October 15, 2010 12:59 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 04/11] OMAP3: PM: Adding smartreflex device file.
On Wed, 2010-09-22 at 20:15 +0530, Thara Gopinath wrote:
This patch adds support for device registration of various
smartreflex module present in the system. This patch introduces
the platform data for smartreflex devices which include
the efused and test n-target vaules, module enable/disable
pointers and a parameter to indicate whether smartreflex
autocompensation needs to be enabled on init or not.
Currently auocompensation is enabled on init by default
for OMAP3430 ES3.1 chip.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/sr_device.c | 174
+++
2 files changed, 175 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/sr_device.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8dd32a7..abc377a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -56,7 +56,7 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
cpuidle34xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
-obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
+obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-
omap2/sr_device.c
new file mode 100644
index 000..606da59
--- /dev/null
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -0,0 +1,174 @@
+/*
+ * OMAP3/OMAP4 smartreflex device file
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Based originally on code from smartreflex.c
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Lesly A M x0080...@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 linux/err.h
+#include linux/slab.h
+
+#include plat/control.h
+#include plat/omap_device.h
+#include plat/smartreflex.h
+#include plat/voltage.h
+
+static struct omap_device_pm_latency omap_sr_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST
+ },
+};
+
+#ifdef OMAP_SMARTREFLEX_TESTING
+/*
+ * Hard coded nvalues for testing purposes for OMAP3430,
+ * may cause device to hang!
+ */
+static void __init sr_set_nvalues(struct omap_sr_dev_data *dev_data,
+ struct omap_sr_data *sr_data)
+{
+ int i;
+
+ if (!dev_data || !dev_data-volts_supported ||
+ !dev_data-volt_data || !dev_data-test_nvalues) {
+ pr_warning(%s: Bad parameters! dev_data = %x,
+ dev_data-volts_supported = %x,
+ dev_data-volt_data = %x,
+ dev_data-test_nvalues = %x\n, __func__,
+ (unsigned int)dev_data, dev_data-volts_supported,
+ (unsigned int)dev_data-volt_data,
+ (unsigned int)dev_data-test_nvalues);
+ return;
+ }
+
+ sr_data-senn_mod = dev_data-test_sennenable;
+ sr_data-senp_mod = dev_data-test_senpenable;
+ for (i = 0; i dev_data-volts_supported; i++)
+ dev_data-volt_data[i].sr_nvalue = dev_data-test_nvalues[i];
+}
+#else
+/* Read EFUSE values from control registers for OMAP3430 */
+static void __init sr_set_nvalues(struct omap_sr_dev_data *dev_data,
+ struct omap_sr_data *sr_data)
+{
+ int i;
+
+ if (!dev_data || !dev_data-volts_supported || !dev_data-volt_data ||
+ !dev_data-efuse_nvalues_offs) {
+ pr_warning(%s: Bad parameters! dev_data = %x,
+ dev_data-volts_supported = %x,
+ dev_data-volt_data = %x,
+ dev_data-efuse_nvalues_offs = %x\n, __func__,
+ (unsigned int)dev_data, dev_data-volts_supported,
+ (unsigned int)dev_data-volt_data,
+ (unsigned int)dev_data-efuse_nvalues_offs);
+ return;
+ }
+
+ /*
+* From OMAP3630 onwards there are no efuse registers for senn_mod
RE: [PATCH v3 06/11] OMAP3: PM: Adding smartreflex class3 driver
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 15, 2010 4:39 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 06/11] OMAP3: PM: Adding smartreflex class3 driver
Thara Gopinath th...@ti.com writes:
Smartreflex Class3 implementation continuously monitors
silicon performance and instructs the Voltage Processors
to increase or decrease the voltage.
This patch adds smartreflex class 3 driver. This driver hooks
up with the generic smartreflex driver smartreflex.c to abstract
out class specific implementations out of the generic driver.
Signed-off-by: Thara Gopinath th...@ti.com
Some minor comments below...
Thanks for the review!
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex-class3.c | 61
++
arch/arm/mach-omap2/smartreflex-class3.h | 23 +++
arch/arm/plat-omap/Kconfig |9
4 files changed, 94 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex-class3.c
create mode 100644 arch/arm/mach-omap2/smartreflex-class3.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index abc377a..4f6139c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
+obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c b/arch/arm/mach-
omap2/smartreflex-class3.c
new file mode 100644
index 000..f1ade08
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -0,0 +1,61 @@
+/*
+ * Smart reflex Class 3 specific implementations
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@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 plat/smartreflex.h
+
+#include smartreflex-class3.h
+
+static int sr_class3_enable(struct voltagedomain *voltdm)
+{
+ unsigned long volt = 0;
minor: '= 0' assignment not needed as it's immediately assigned in the
next line.
Ok.
+ volt = omap_voltage_get_nom_volt(voltdm);
+ if (!volt) {
+ pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
+ __func__, voltdm-name);
+ return -ENODATA;
+ }
+
+ omap_vp_enable(voltdm);
+ return sr_enable(voltdm, volt);
+}
+
+static int sr_class3_disable(struct voltagedomain *voltdm, int
is_volt_reset)
+{
+ omap_vp_disable(voltdm);
+ sr_disable(voltdm);
+ if (is_volt_reset)
+ omap_voltage_reset(voltdm);
+
+ return 0;
+}
+
+static int sr_class3_configure(struct voltagedomain *voltdm)
+{
+ return sr_configure_errgen(voltdm);
+}
+
+/* SR class3 structure */
+static struct omap_smartreflex_class_data class3_data = {
+ .enable = sr_class3_enable,
+ .disable = sr_class3_disable,
+ .configure = sr_class3_configure,
+ .class_type = SR_CLASS3,
+};
+
+/* Smartreflex CLASS3 init API to be called from board file */
s/CLASS3/Class 3/
Will correct
+int __init sr_class3_init(void)
+{
+ pr_info(SmartReflex CLASS3 initialized\n);
ditto
Will correct
+ return sr_register_class(class3_data);
+}
diff --git a/arch/arm/mach-omap2/smartreflex-class3.h b/arch/arm/mach-
omap2/smartreflex-class3.h
new file mode 100644
index 000..4d86037
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex-class3.h
@@ -0,0 +1,23 @@
+/*
+ * Smartreflex Class 3 Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@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.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_SMARTREFLEXCLASS3_H
+#define __ARCH_ARM_MACH_OMAP2_SMARTREFLEXCLASS3_H
+
+#ifdef CONFIG_OMAP_SMARTREFLEX_CLASS3
+int sr_class3_init(void);
+#else
+static int sr_class3_init(void) { return 0; }
+#endif
+
+#endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 8056349..af7acc9 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -67,6 +67,15 @@ config OMAP_SMARTREFLEX_TESTING
WARNING: Enabling
RE: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization from board files.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 15, 2010 5:20 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 09/11] OMAP3: PM: Smartreflex Class3 initialization
from board files.
Thara Gopinath th...@ti.com writes:
This patch enables smartreflex class3 functionality for OMAP3430SDP,
OMAP3630SDP, ZOOM2 and ZOOM3 boards.
This patch doesn't touch 3630sdp.
Signed-off-by: Thara Gopinath th...@ti.com
I'm having some doubts about whether this should be done by board files or
not. Seems like the general case will be that by default will be SoC
specific, and only boards that want something other than the default
class should need to override this.
Thoughts?
I agree. I wanted this to be a default initcall and one to enable the
menuconfig option for the required class driver.. But Nishant wanted this from
board files. If we have consensus in removing this init from board file, I am
cool with it.
Regards
Thara
Kevin
---
arch/arm/mach-omap2/board-3430sdp.c |2 ++
arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
omap2/board-3430sdp.c
index 67b95b5f..9a04a2e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -47,6 +47,7 @@
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
#include pm.h
+#include smartreflex-class3.h
#define CONFIG_DISABLE_HFCLK 1
@@ -813,6 +814,7 @@ static void __init omap_3430sdp_init(void)
sdp3430_display_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
+ sr_class3_init();
}
MACHINE_START(OMAP_3430SDP, OMAP3430 3430SDP board)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-
omap2/board-zoom-peripherals.c
index 6b39849..98dffc6 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -26,6 +26,7 @@
#include mux.h
#include hsmmc.h
+#include smartreflex-class3.h
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -282,4 +283,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ sr_class3_init();
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 10/11] OMAP3: PM: Program correct init voltages for VDD1 and VDD2
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 15, 2010 5:23 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 10/11] OMAP3: PM: Program correct init voltages for
VDD1 and VDD2
Thara Gopinath th...@ti.com writes:
By default the system boots up at nominal voltage for every
voltage domain in the system. This patch puts VDD1 and VDD2
to the correct boot up voltage as per the opp tables specified.
This patch implements this by matching the rate of the main clock
of the voltage domain with the opp table and picking up the correct
voltage.
Signed-off-by: Thara Gopinath th...@ti.com
For de-coupling the init from OPP, I like this approach better. Thanks.
Most welcome!!
Minor comment below...
---
arch/arm/mach-omap2/pm.c | 67
+-
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 71c5a77..86c7bf1 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/err.h
+#include linux/clk.h
#include plat/omap-pm.h
#include plat/omap_device.h
@@ -20,6 +21,7 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
+#include plat/voltage.h
#include pm.h
@@ -138,12 +140,75 @@ err:
return ret;
}
+/*
+ * This is to be called during init to put the various voltage
+ * domains to the voltage as per the opp table. Typically we boot up
+ * at the nominal voltage. So this function finds out the rate of
+ * the clock associated with the voltage domain, finds out the correct
+ * opp entry and puts the voltage domain to the voltage specifies
+ * in the opp entry
+ */
+static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
+ struct device *dev)
+{
+ struct voltagedomain *voltdm;
+ struct clk *_clk;
s/_clk/clk/
Will it not conflict with struct clk??
Regards
Thara
+ struct omap_opp *opp;
+ unsigned long freq, bootup_volt;
+
+ if (!vdd_name || !clk_name || !dev) {
+ printk(KERN_ERR %s: Invalid parameters!\n, __func__);
+ goto exit;
+ }
+
+ voltdm = omap_voltage_domain_get(vdd_name);
+ if (IS_ERR(voltdm)) {
+ printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
+ __func__, vdd_name);
+ goto exit;
+ }
+
+ _clk = clk_get(NULL, clk_name);
+ if (IS_ERR(_clk)) {
+ printk(KERN_ERR %s: unable to get clk %s\n,
+ __func__, clk_name);
+ goto exit;
+ }
+
+ freq = _clk-rate;
+ opp = opp_find_freq_ceil(dev, freq);
+ if (IS_ERR(opp)) {
+ printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
+ __func__, vdd_name);
+ goto exit;
+ }
+
+ bootup_volt = opp_get_voltage(opp);
+ if (!bootup_volt) {
+ printk(KERN_ERR %s: unable to find voltage corresponding
+ to the bootup OPP for vdd_%s\n, __func__, vdd_name);
+ goto exit;
+ }
+
+ omap_voltage_scale_vdd(voltdm, bootup_volt);
+
+ return 0;
+
+exit:
+ printk(KERN_ERR %s: Unable to put vdd_%s to its init voltage\n\n,
+ __func__, vdd_name);
+ return -EINVAL;
+}
+
static int __init omap2_common_pm_init(void)
{
omap2_init_processor_devices();
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx()) {
omap3_pm_init_opp_table();
+ omap2_set_init_voltage(mpu, dpll1_ck, mpu_dev);
+ omap2_set_init_voltage(core, l3_ick, l3_dev);
+ }
omap_pm_if_init();
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures.
-Original Message- From: Cousson, Benoit Sent: Saturday, September 18, 2010 3:43 PM To: Gopinath, Thara Cc: Kevin Hilman; Paul Walmsley; linux-omap@vger.kernel.org; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures. Hi Thara, On 9/17/2010 4:55 PM, Gopinath, Thara wrote: From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, September 16, 2010 8:58 PM Gopinath, Tharath...@ti.com writes: From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 03, 2010 5:12 AM Thara Gopinathth...@ti.com writes: This patch extends the device opp structure to contain pointers to scale the operating rate of the device and to retrieve the operating rate of the device. This patch also adds the three new APIs in the opp layer namely opp_set_rate that can be called to set a new operating rate for a device, opp_get_rate that can be called to retrieve the operating frequency for a device and opp_populate_rate_fns to populte the device specific set_rate and get_rate API's. The opp_set_rate and opp_get_rate does some routine error checks and finally calls into the device specific set_rate and get_rate APIs populated through opp_populate_rate_fns. Signed-off-by: Thara Gopinathth...@ti.com As I think about this more, I'm not sure the OPP layer is the right layer for the get/set rate functions. The OPP layer is currently just the data store for OPP data. To me, these set/get functions are better associated directly with an omap_device instead of an OPP. For instance, the new OPP APIs are a bit confusing in terms of OPPs. e.g: opp_get_rate(). What is the rate of an OPP, and what's the difference with opp_get_freq()? What's really happening is the rate is being changed for a device, and the need for specific hooks are at the device level, not the OPP level. For example, this current approach would not scale if you needed multiple devices in the same domain that each needed custom set_rate/get_rate hooks. So instead, what about adding custom hooks at the omap_device level? They could be registered at omap_device_build() time in the device specific code. This is exactly what I had in my mind when I started implementing this. But then Paul said hwmod or omap_device is not the place to keep it. IIRC, Paul's concern was that *hwmod* was not the right place for this (and I agree.) However, I think omap_device is the right place for this. Paul? Also I do not want the set rate get rate APIs for devices that require changes dividers in the PRCM clock module to be spread out in the system. Makes it very very difficult to debug. If we agree to add the set_rate and get_rate in the omap_device structure, I would like to have one more API in the omap_device layer to register these APIs device wise. Thus we can keep these set rate and get rate APIs in one single file. Agreed. And those functions should be in the respective device-specific file, where the omap_device_build() etc are done for that device. Hello Kevin, I basically agree with all your other suggestions except this. I do not think device files are the correct place for this. For starters definitely mpu, l3 and iva devices are not built from any device file. I do not like the idea of device set rate APIs spread across different files. I don't not understand the reason? If we need to add specific device function for mpu, l3, or iva, we can easily add a file to contain that. BTW, thanks to work done by Santosh and Felipe we will probably soon introduce a l3 driver that will allow to handle interconnect errors. We will thus have a real device for l3 as well. A device set_rate is clearly device specific. If a device will have to play with its own internal dividers along with PRCM dividers, that code still belong to the device. I do not see the need nor the advantage to centralize that? You will end-up with a huge file that every driver owners will have to hack in order to add set_rate support for their device. At device build time, IP with set_rate support will just add non-null parameters to the omap_device_build(), et voila. For the debug point of view, you can just add a new sysfs entry for scalable devices that will allow you to track scalable device vs regular ones. Hello Benoit/Kevin, Most of the devices need not scale any internal dividers. For devices that need to scale internal dividers, I agree that the set_rate and get_rate should come from the devices file. But for other devices that involve only PRCM dividers, I do not think they should be bothered with implementing these APIs and maintaining them. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 04/11] OMAP4: Extend clock data.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 29, 2010 4:39 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v2 04/11] OMAP4: Extend clock data.
Thara Gopinath th...@ti.com writes:
This patch extends the OMAP4 clock data to include
various x2 clockc nodes as the clock framework
skips a *2 whie calculating the dpll locked frequency.
Signed-off-by: Thara Gopinath th...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Please post this as a separate patch, and Paul can queue for 2.6.37.
Ok I will post this as a separate patch.
Regards
Thara
Thanks,
Kevin
---
arch/arm/mach-omap2/clock44xx_data.c | 40 +++---
---
1 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-
omap2/clock44xx_data.c
index edf2c28..3652fda 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -481,14 +481,21 @@ static struct clk dpll_core_m5_ck = {
.set_rate = omap2_clksel_set_rate,
};
+static struct clk dpll_core_m5x2_ck = {
+ .name = dpll_core_m5x2_ck,
+ .parent = dpll_core_m5_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
static const struct clksel div_core_div[] = {
- { .parent = dpll_core_m5_ck, .rates = div2_1to2_rates },
+ { .parent = dpll_core_m5x2_ck, .rates = div2_1to2_rates },
{ .parent = NULL },
};
static struct clk div_core_ck = {
.name = div_core_ck,
- .parent = dpll_core_m5_ck,
+ .parent = dpll_core_m5x2_ck,
.clksel = div_core_div,
.clksel_reg = OMAP4430_CM_CLKSEL_CORE,
.clksel_mask= OMAP4430_CLKSEL_CORE_MASK,
@@ -507,13 +514,13 @@ static const struct clksel_rate div4_1to8_rates[] = {
};
static const struct clksel div_iva_hs_clk_div[] = {
- { .parent = dpll_core_m5_ck, .rates = div4_1to8_rates },
+ { .parent = dpll_core_m5x2_ck, .rates = div4_1to8_rates },
{ .parent = NULL },
};
static struct clk div_iva_hs_clk = {
.name = div_iva_hs_clk,
- .parent = dpll_core_m5_ck,
+ .parent = dpll_core_m5x2_ck,
.clksel = div_iva_hs_clk_div,
.clksel_reg = OMAP4430_CM_BYPCLK_DPLL_IVA,
.clksel_mask= OMAP4430_CLKSEL_0_1_MASK,
@@ -525,7 +532,7 @@ static struct clk div_iva_hs_clk = {
static struct clk div_mpu_hs_clk = {
.name = div_mpu_hs_clk,
- .parent = dpll_core_m5_ck,
+ .parent = dpll_core_m5x2_ck,
.clksel = div_iva_hs_clk_div,
.clksel_reg = OMAP4430_CM_BYPCLK_DPLL_MPU,
.clksel_mask= OMAP4430_CLKSEL_0_1_MASK,
@@ -651,6 +658,13 @@ static struct clk dpll_iva_m4_ck = {
.set_rate = omap2_clksel_set_rate,
};
+static struct clk dpll_iva_m4x2_ck = {
+ .name = dpll_iva_m4x2_ck,
+ .parent = dpll_iva_m4_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
static struct clk dpll_iva_m5_ck = {
.name = dpll_iva_m5_ck,
.parent = dpll_iva_ck,
@@ -663,6 +677,13 @@ static struct clk dpll_iva_m5_ck = {
.set_rate = omap2_clksel_set_rate,
};
+static struct clk dpll_iva_m5x2_ck = {
+ .name = dpll_iva_m5x2_ck,
+ .parent = dpll_iva_m5_ck,
+ .ops= clkops_null,
+ .recalc = omap3_clkoutx2_recalc,
+};
+
/* DPLL_MPU */
static struct dpll_data dpll_mpu_dd = {
.mult_div1_reg = OMAP4430_CM_CLKSEL_DPLL_MPU,
@@ -1350,7 +1371,7 @@ static struct clk dsp_fck = {
.enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = tesla_clkdm,
- .parent = dpll_iva_m4_ck,
+ .parent = dpll_iva_m4x2_ck,
.recalc = followparent_recalc,
};
@@ -1725,7 +1746,7 @@ static struct clk iva_fck = {
.enable_reg = OMAP4430_CM_IVAHD_IVAHD_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = ivahd_clkdm,
- .parent = dpll_iva_m5_ck,
+ .parent = dpll_iva_m5x2_ck,
.recalc = followparent_recalc,
};
@@ -2089,7 +2110,7 @@ static struct clk sl2if_ick = {
.enable_reg = OMAP4430_CM_IVAHD_SL2_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
.clkdm_name = ivahd_clkdm,
- .parent = dpll_iva_m5_ck,
+ .parent = dpll_iva_m5x2_ck,
.recalc = followparent_recalc,
};
@@ -2782,6 +2803,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dpll_core_m2_ck, dpll_core_m2_ck,
CK_443X),
CLK(NULL, ddrphy_ck,ddrphy_ck,
CK_443X),
CLK(NULL, dpll_core_m5_ck
RE: [PATCH v3 03/11] OMAP3: PM: Adding smartreflex driver support.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 29, 2010 5:01 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 03/11] OMAP3: PM: Adding smartreflex driver support.
Thara Gopinath th...@ti.com writes:
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD1 and the
other associated with VDD2.
This patch adds support for smartreflex driver. The driver is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debugfs/pm_debug/smartreflex/sr_X/autocomp
To disable smartreflex autocompensation feature
echo 0 /debugfs/pm_debug/smartreflex/sr_X/autocomp
where X can be mpu, core , iva etc.
[...]
+static void sr_set_regfields(struct omap_sr *sr)
+{
+ /*
+* For time being these values are defined in smartreflex.h
+* and populated during init. May be they can be moved to board
+* file or pmic specific data structure. In that case these structure
+* fields will have to be populated using the pdata or pmic structure.
+*/
+ if (cpu_is_omap34xx()) {
+ sr-err_weight = OMAP3430_SR_ERRWEIGHT;
+ sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
+ sr-accum_data = OMAP3430_SR_ACCUMDATA;
+ if (!(strcmp(sr-voltdm-name, mpu))) {
+ sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
+ sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
+ } else {
+ sr-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
+ sr-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
+ }
+ }
+ /* TODO: 3630 and Omap4 specific bit field values */
This comment is still present even after the OMAP4 series is applied.
[...]
+/*
+ * 3430 specific values. Maybe these should be passed from board file or
+ * pmic structures.
+ */
+#define OMAP3430_SR_ACCUMDATA 0x1f4
+
+#define OMAP3430_SR1_SENPAVGWEIGHT 0x03
+#define OMAP3430_SR1_SENNAVGWEIGHT 0x03
+
+#define OMAP3430_SR2_SENPAVGWEIGHT 0x01
+#define OMAP3430_SR2_SENNAVGWEIGHT 0x01
+
+#define OMAP3430_SR_ERRWEIGHT 0x04
+#define OMAP3430_SR_ERRMAXLIMIT0x02
+
+/* TODO:3630/OMAP4 values if it has to come from this file */
ditto
It's best to just not put these kind of things into the code in the
first place, they tend to be forgotten and stale quickly.
Will fix this and post V4.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 07/11] OMAP3: PM: Adding T2 enabling of smartreflex support
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, September 29, 2010 5:38 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: Re: [PATCH v3 07/11] OMAP3: PM: Adding T2 enabling of smartreflex
support
Thara Gopinath th...@ti.com writes:
This patch adds support in the twl4030 driver to hook up
the API enabling smartreflex support on PMIC side with the
smartreflex driver. Without this the OMAP smartreflex modules
will not function.
Signed-off-by: Thara Gopinath th...@ti.com
This one should be a separate patch with a subject something like
mfd: twl4030: add SmartReflex support
and the changelog should indicate its dependency on this SR/voltage
series.
Do you mean to say this patch should not be a part of this series at all ??
Regards
Thara
Kevin
---
drivers/mfd/twl-core.c |7 +--
drivers/mfd/twl4030-power.c | 29 +
include/linux/i2c/twl.h |1 +
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 720e099..677b903 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1009,8 +1009,11 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
clocks_init(client-dev, pdata-clock);
/* load power event scripts */
- if (twl_has_power() pdata-power)
- twl4030_power_init(pdata-power);
+ if (twl_has_power()) {
+ twl4030_power_sr_init();
+if (pdata-power)
+ twl4030_power_init(pdata-power);
+ }
/* Maybe init the T2 Interrupt subsystem */
if (client-irq
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..6d0ad2d 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -31,6 +31,8 @@
#include asm/mach-types.h
+#include plat/smartreflex.h
+
static u8 twl4030_start_script_address = 0x2b;
#define PWR_P1_SW_EVENTS 0x10
@@ -63,6 +65,10 @@ static u8 twl4030_start_script_address = 0x2b;
#define R_MEMORY_ADDRESS PHY_TO_OFF_PM_MASTER(0x59)
#define R_MEMORY_DATA PHY_TO_OFF_PM_MASTER(0x5a)
+/* Smartreflex Control */
+#define R_DCDC_GLOBAL_CFG PHY_TO_OFF_PM_RECEIVER(0x61)
+#define CFG_ENABLE_SRFLX 0x08
+
#define R_PROTECT_KEY 0x0E
#define R_KEY_10xC0
#define R_KEY_20x0C
@@ -511,6 +517,29 @@ int twl4030_remove_script(u8 flags)
return err;
}
+/* API to enable smrtreflex on Triton side */
+static void twl4030_smartreflex_init(void)
+{
+ int ret = 0;
+ u8 read_val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, read_val,
+ R_DCDC_GLOBAL_CFG);
+ read_val |= CFG_ENABLE_SRFLX;
+ ret |= twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, read_val,
+ R_DCDC_GLOBAL_CFG);
+}
+
+struct omap_smartreflex_pmic_data twl4030_sr_data = {
+ .sr_pmic_init = twl4030_smartreflex_init,
+};
+
+void __init twl4030_power_sr_init()
+{
+ /* Register the SR init API with the Smartreflex driver */
+ omap_sr_register_pmic(twl4030_sr_data);
+}
+
void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
{
int err = 0;
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 6de90bf..b02011e 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -550,6 +550,7 @@ struct twl4030_power_data {
};
extern void twl4030_power_init(struct twl4030_power_data
*triton2_scripts);
+extern void twl4030_power_sr_init(void);
extern int twl4030_remove_script(u8 flags);
struct twl4030_codec_audio_data {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, September 30, 2010 4:50 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers Thara Gopinath th...@ti.com writes: [...] diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat- omap/include/plat/voltage.h index 99836a1..8978d33 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -14,6 +14,11 @@ #ifndef __ARCH_ARM_MACH_OMAP2_VOLTAGE_H #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H +extern u32 enable_sr_vp_debug; +#ifdef CONFIG_PM_DEBUG +extern struct dentry *pm_dbg_main_dir; +#endif + #define VOLTSCALE_VPFORCEUPDATE1 #define VOLTSCALE_VCBYPASS 2 This belongs in PATCH 1/11 and belongs in pm.h, not voltage.h as it's a feature of the PM debug layer, not the voltage layer. Yes indeed!! Will fix this in v4 Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 03/11] OMAP4: Add the new voltage to vsel calculation formula
-Original Message-
From: Manuel, Lesly Arackal
Sent: Monday, September 27, 2010 9:44 AM
To: Gopinath, Thara; linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand
Subject: RE: [PATCH v2 03/11] OMAP4: Add the new voltage to vsel calculation
formula
Hi Thara,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Thara Gopinath
Sent: Saturday, September 25, 2010 6:21 PM
To: linux-omap@vger.kernel.org
Cc: khil...@deeprootsystems.com; p...@pwsan.com; b-cous...@ti.com;
vishwanath...@ti.com; saw...@ti.com; Thara Gopinath
Subject: [PATCH v2 03/11] OMAP4: Add the new voltage to vsel calculation
formula
TWL6030 the power IC used along with OMAP4 in OMAP4 SDPs,
blaze boards and panda boards has a different formula
from that of TWL4030 for voltage to vsel and
vsel to voltage calculation. This patch implements the new
formula depending on the PMIC type.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp_twl_tps.c | 71
++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/opp_twl_tps.c b/arch/arm/plat-
omap/opp_twl_tps.c
index 4448fc5..358b67b 100644
--- a/arch/arm/plat-omap/opp_twl_tps.c
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -15,9 +15,16 @@
#include linux/module.h
+#include linux/i2c/twl.h
+
#include plat/opp_twl_tps.h
#include plat/voltage.h
+static bool is_offset_valid;
+static u8 smps_offset;
+
+#define REG_SMPS_OFFSET 0xE0
+
/**
* omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
* @vsel: TWL/TPS VSEL value to convert
@@ -27,6 +34,38 @@
*/
unsigned long omap_twl_vsel_to_uv(const u8 vsel)
{
+ if (twl_class_is_6030()) {
+ /*
+* In TWL6030 depending on the value of SMPS_OFFSET
+* efuse register the voltage range supported in
+* standard mode can be either between 0.6V - 1.3V or
+* 0.7V - 1.4V. In TWL6030 ES1.0 SMPS_OFFSET efuse
+* is programmed to all 0's where as starting from
+* TWL6030 ES1.1 the efuse is programmed to 1
+*/
+ if (!is_offset_valid) {
+ twl_i2c_read_u8(TWL6030_MODULE_ID0, smps_offset,
0xE0);
+ is_offset_valid = true;
+ }
Is it necessary to do the i2c read each time to check the smps_offset?
OR it can be done one time initially.
Hello Lesly,
It is not done every time. It is only done the first time omap_twl_vsel_to_uv
or omap_twl_uv_to_vsel is called. If is_offset_valid, we do not read the
register
via i2c interface.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, September 16, 2010 8:50 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit Subject: Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver. Gopinath, Thara th...@ti.com writes: [...] + * omap_voltage_add_userreq : API to keep track of various requests to + * scale the VDD and returns the best possible + * voltage the VDD can be put to. + * @volt_domain: pointer to the voltage domain. + * @dev : the device pointer. + * @volt : the voltage which is requested by the device. + * + * This API is to be called before the actual voltage scaling is + * done to determine what is the best possible voltage the VDD can + * be put to. This API adds the device dev in the user list of the + * vdd volt_domain with volt as the requested voltage. The user list + * is a plist with the priority element absolute voltage values. + * The API then finds the maximum of all the requested voltages for + * the VDD and returns it back through volt pointer itself. + * Returns error value in case of any errors. + */ +int omap_voltage_add_userreq(struct voltagedomain *voltdm, struct device *dev, +unsigned long *volt) How about just omap_voltage_add_request() Also, do we need both voltdm and dev? With your other patches, can't we look up the voltm based on dev? Or, is there a need for a device to add a request in a voltage domain other than the one to which it belongs? Also, how does one remove a voltage request? Hello Kevin, I could rename this API to what you have suggested. Yes we do need voltdm and dev. Let us say I have three devices in a voltdm and I need to maintain a request for each of these devices. OK, thanks for clarifying. When a omap_device_set_rate API is called by the device to lower its rate the voltage request will automatically get lowered. OK, but what about removing a request when a device no longer has any voltage constraints. Hi Kevin, The devices will use omap_device_set_rate to lower their frequency. This will in turn call the use counting API in voltage layer and add which in turn will remove the old request for the device and add the new request which will be for a lower voltage. Hence releasing gets taken care of. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 16, 2010 8:52 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list
associated with a voltage
domain
Gopinath, Thara th...@ti.com writes:
[...]
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+int *dev_count)
+{
+struct device_opp *dev_opp;
+struct device **dev_list;
+int count = 0, i = 0;
+
+list_for_each_entry(dev_opp, dev_opp_list, node) {
+if (!dev_opp-oh-vdd_name)
+continue;
+
+if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
+dev_opp-oh-voltdm = voltdm;
Couldn't we assign the voltdm at opp_add() time since you added it as
part of the hwmod?
We cannot as the voltage layer is not initialized at the point of opp_add.
Having said this, today voltage layer is dependent on opp layer only to
figure out
the current nominal voltage from the opp table. If that can be some how
decoupled we
can initialize voltage layer early on and implement this.
We could decouple the voltage init into and early init and late init to
handle this.
Hello Kevin,
Yes we could. In fact I do not like the idea of voltage layer dependent
on opp layer itself. So here is my proposal. Maintain a variable in the main
per vdd structure omap_vdd_info curr_volt which will get updated each time a
voltage scale is attempted. Now the only issue is during boot up how does the
voltage
layer know what voltage each vdd should be put into ? A piece of code can be
implemented in pm34xx.c/pm44xx.c init functions to read the clock rate
associated
with each vdd , call into the opp layer to get the corresponding
voltage ( basically the sequence we do today everytime in voltage layer
when the API to get nominal voltage is called) and call omap_voltage_scale_vdd
with
the corresponding voltage. This way we can fully decouple voltage laye from opp
layer
and make voltage init an early_initcall. We might still need a late_initcall to
register
debugfs entries though.
What is your take on this ?
Regards
Thara
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
-Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 7:37 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Gopinath, Thara had written, on 09/16/2010 08:51 AM, the following: -Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 5:45 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Gopinath, Thara had written, on 09/16/2010 05:40 AM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, September 16, 2010 3:27 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code From: Paul Walmsley p...@pwsan.com The OPP layer code should be independent of the PMIC, introduce the TWL/TPS-specific code out to its own file. Hello Kevin, I have been using this code for a while now. I really do not think wee need a separate file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage This split introduces a PMIC level abstraction already. Do you have a suggestion which file it should go to? It is definitely not part of opp.c, not part of other existing twl files as well. the job of this file was to introduce conversion routines which can be used by any layer (voltage layer if need be - it used to be srf and smartreflex before).. in fact one of your voltage layer patches introduces capability for 6030 as well http://marc.info/?l=linux-omapm=128213020927919w=2 Yes one of my patches has introduces this coz I had no other way to add OMAP4 support. But I still do not understand why cant these APIs be implemented in twl-core.c or twl4030-power.c? Why there? Twl power does regulator operations not conversion operations. core is not the place either as it is function independent. Hello Nishant, Why do you say core is not the place. For me core is exactly the place. It is the PMIC driver file. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, August 28, 2010 5:23 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage
domain instance in the
voltage driver.
Thara Gopinath th...@ti.com writes:
This patch introduces a user list of devices associated with each
voltage domain instance. The user list is implemented using plist
structure with priority node populated with the voltage values.
This patch also adds an API which will take in a device and
requested voltage as parameters, adds the info to the user list
and returns back the maximum voltage requested by all the user
devices. This can be used anytime to get the voltage that the
voltage domain instance can be transitioned into.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 94
+
arch/arm/plat-omap/include/plat/voltage.h |2 +
2 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6a07fe9..4624250 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -24,6 +24,9 @@
#include linux/clk.h
#include linux/err.h
#include linux/debugfs.h
+#include linux/spinlock.h
+#include linux/plist.h
+#include linux/slab.h
#include plat/omap-pm.h
#include plat/omap34xx.h
@@ -95,6 +98,20 @@ struct vp_reg_val {
};
/**
+ * omap_vdd_user_list - The per vdd user list
+ *
+ * @dev: The device asking for the vdd to be set at a
particular
+ * voltage
+ * @node : The list head entry
+ * @volt : The voltage requested by the device dev
+ */
+struct omap_vdd_user_list {
+ struct device *dev;
+ struct plist_node node;
+ u32 volt;
+};
+
+/**
* omap_vdd_info - Per Voltage Domain info
*
* @volt_data : voltage table having the distinct voltages
supported
@@ -105,6 +122,9 @@ struct vp_reg_val {
* vp registers
* @volt_clk : the clock associated with the vdd.
* @opp_dev: the 'struct device' associated with this vdd.
+ * @user_lock : the lock to be used by the plist user_list
+ * @user_list : the list head maintaining the various users
+ * of this vdd with the voltage requested by each user.
* @volt_data_count: Number of distinct voltages supported by this
vdd.
* @nominal_volt : Nominal voltaged for this vdd.
* cmdval_reg : Voltage controller cmdval register.
@@ -117,6 +137,9 @@ struct omap_vdd_info{
struct clk *volt_clk;
struct device *opp_dev;
struct voltagedomain voltdm;
+ spinlock_t user_lock;
+ struct plist_head user_list;
+ struct mutex scaling_mutex;
int volt_data_count;
unsigned long nominal_volt;
u8 cmdval_reg;
@@ -785,11 +808,18 @@ static void __init vdd_data_configure(struct
omap_vdd_info *vdd)
struct dentry *vdd_debug;
char name[16];
#endif
+
if (cpu_is_omap34xx())
omap3_vdd_data_configure(vdd);
else if (cpu_is_omap44xx())
omap4_vdd_data_configure(vdd);
+ /* Init the plist */
+ spin_lock_init(vdd-user_lock);
+ plist_head_init(vdd-user_list, vdd-user_lock);
+ /* Init the DVFS mutex */
+ mutex_init(vdd-scaling_mutex);
+
#ifdef CONFIG_PM_DEBUG
strcpy(name, vdd_);
strcat(name, vdd-voltdm.name);
@@ -1142,6 +1172,70 @@ unsigned long omap_vp_get_curr_volt(struct
voltagedomain *voltdm)
}
/**
+ * omap_voltage_add_userreq : API to keep track of various requests to
+ * scale the VDD and returns the best possible
+ * voltage the VDD can be put to.
+ * @volt_domain: pointer to the voltage domain.
+ * @dev : the device pointer.
+ * @volt : the voltage which is requested by the device.
+ *
+ * This API is to be called before the actual voltage scaling is
+ * done to determine what is the best possible voltage the VDD can
+ * be put to. This API adds the device dev in the user list of the
+ * vdd volt_domain with volt as the requested voltage. The user list
+ * is a plist with the priority element absolute voltage values.
+ * The API then finds the maximum of all the requested voltages for
+ * the VDD and returns it back through volt pointer itself.
+ * Returns error value in case of any errors.
+ */
+int omap_voltage_add_userreq(struct voltagedomain *voltdm, struct device
*dev,
+ unsigned long *volt)
How about just omap_voltage_add_request()
Also, do we need both voltdm and dev? With your other patches, can't we
look up the voltm based on dev? Or, is there a need for a device to add
a request in a voltage domain other than the one to which it belongs?
Also, how
RE: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, August 28, 2010 6:23 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list
associated with a voltage
domain
Thara Gopinath th...@ti.com writes:
This patch adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
I think this should be done in two steps.
During init, each OPP
---
arch/arm/plat-omap/include/plat/opp.h |9 +
arch/arm/plat-omap/opp.c | 28
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 0e580ed..a4c1669 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -18,6 +18,7 @@
#include linux/cpufreq.h
#include plat/common.h
+#include plat/voltage.h
/**
* struct omap_opp_def - OMAP OPP Definition
@@ -86,6 +87,9 @@ int opp_disable(struct omap_opp *opp);
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count);
#else
static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
{
@@ -149,5 +153,10 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
{
}
+static inline struct device **opp_init_voltage_params(
+ struct voltagedomain *voltdm, int *dev_count)
+{
+}
+
#endif /* CONFIG_PM */
#endif /* __ASM_ARM_OMAP_OPP_H */
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index a3dea82..72dd62a 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -502,3 +502,31 @@ void opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
}
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count)
+{
+ struct device_opp *dev_opp;
+ struct device **dev_list;
+ int count = 0, i = 0;
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (!dev_opp-oh-vdd_name)
+ continue;
+
+ if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
+ dev_opp-oh-voltdm = voltdm;
Couldn't we assign the voltdm at opp_add() time since you added it as
part of the hwmod?
We cannot as the voltage layer is not initialized at the point of opp_add.
Having said this, today voltage layer is dependent on opp layer only to figure
out
the current nominal voltage from the opp table. If that can be some how
decoupled we
can initialize voltage layer early on and implement this.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 02, 2010 6:04 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand; Cousson, Benoit
Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list
associated with a voltage
domain
Thara Gopinath th...@ti.com writes:
This patch adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
I don't think the OPP layer is the right place for this after all.
How about something like this in the voltage layer:
omap_voltage_add_device(struct voltagedomain *voltdm, struct device *dev)
During omap_device_build(), if the hwmod has a voltage domain, it
calls this function to register it with the voltage layer.
This mandates voltage layer to be initialized before the first omap_device_build
has happened. I think that is going to be a very confusing sequencing. Also
today
voltage layer init happens later in the system.
This function then creates a list (internal to voltage layer) of all the
devices in a voltage domain rather than having to query the OPP layer
for it.
Kevin
---
arch/arm/plat-omap/include/plat/opp.h |9 +
arch/arm/plat-omap/opp.c | 28
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 0e580ed..a4c1669 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -18,6 +18,7 @@
#include linux/cpufreq.h
#include plat/common.h
+#include plat/voltage.h
/**
* struct omap_opp_def - OMAP OPP Definition
@@ -86,6 +87,9 @@ int opp_disable(struct omap_opp *opp);
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count);
#else
static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
{
@@ -149,5 +153,10 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
{
}
+static inline struct device **opp_init_voltage_params(
+ struct voltagedomain *voltdm, int *dev_count)
+{
+}
+
#endif /* CONFIG_PM */
#endif /* __ASM_ARM_OMAP_OPP_H */
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index a3dea82..72dd62a 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -502,3 +502,31 @@ void opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
}
+
+struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
+ int *dev_count)
+{
+ struct device_opp *dev_opp;
+ struct device **dev_list;
+ int count = 0, i = 0;
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (!dev_opp-oh-vdd_name)
+ continue;
+
+ if (!strcmp(dev_opp-oh-vdd_name, voltdm-name)) {
+ dev_opp-oh-voltdm = voltdm;
+ count++;
+ }
+ }
+
+ dev_list = kzalloc(sizeof(struct device *) * count, GFP_KERNEL);
+
+ list_for_each_entry(dev_opp, dev_opp_list, node) {
+ if (dev_opp-oh-voltdm == voltdm)
+ dev_list[i++] = dev_opp-dev;
+ }
+
+ *dev_count = count;
+ return dev_list;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, September 03, 2010 5:12 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit Subject: Re: [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures. Thara Gopinath th...@ti.com writes: This patch extends the device opp structure to contain pointers to scale the operating rate of the device and to retrieve the operating rate of the device. This patch also adds the three new APIs in the opp layer namely opp_set_rate that can be called to set a new operating rate for a device, opp_get_rate that can be called to retrieve the operating frequency for a device and opp_populate_rate_fns to populte the device specific set_rate and get_rate API's. The opp_set_rate and opp_get_rate does some routine error checks and finally calls into the device specific set_rate and get_rate APIs populated through opp_populate_rate_fns. Signed-off-by: Thara Gopinath th...@ti.com As I think about this more, I'm not sure the OPP layer is the right layer for the get/set rate functions. The OPP layer is currently just the data store for OPP data. To me, these set/get functions are better associated directly with an omap_device instead of an OPP. For instance, the new OPP APIs are a bit confusing in terms of OPPs. e.g: opp_get_rate(). What is the rate of an OPP, and what's the difference with opp_get_freq()? What's really happening is the rate is being changed for a device, and the need for specific hooks are at the device level, not the OPP level. For example, this current approach would not scale if you needed multiple devices in the same domain that each needed custom set_rate/get_rate hooks. So instead, what about adding custom hooks at the omap_device level? They could be registered at omap_device_build() time in the device specific code. This is exactly what I had in my mind when I started implementing this. But then Paul said hwmod or omap_device is not the place to keep it. Also I do not want the set rate get rate APIs for devices that require changes dividers in the PRCM clock module to be spread out in the system. Makes it very very difficult to debug. If we agree to add the set_rate and get_rate in the omap_device structure, I would like to have one more API in the omap_device layer to register these APIs device wise. Thus we can keep these set rate and get rate APIs in one single file. Also if we move these hooks to omap_device struct we will need to rename the current omap_device_set_rate (the main API) to omap_device_scale and introduce a new omap_device_set_rate which just finds out the omap device from the passed dev pointer and does a od-set_rate. Similarly for get rate also. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Thursday, September 16, 2010 3:27 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
From: Nishanth Menon n...@ti.com
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.
Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Discussions and comments from:
http://marc.info/?l=linux-omapm=126033945313269w=2
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
incorporated.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
Cc: Roberto Granados Dorado x0095...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Documentation/arm/OMAP/omap_pm| 83 ++
arch/arm/plat-omap/Makefile |5 +
arch/arm/plat-omap/include/plat/opp.h | 145 +++
arch/arm/plat-omap/opp.c | 461
+
4 files changed, 694 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..6527cdf 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,86 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+ ... do things ..
+ omap3_pm_init_opp_table()
+ .. customizations and other things ..
+ omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is
RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs
-Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 4:02 PM To: Gopinath, Thara; Kevin Hilman; linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gopinath, Thara [...] diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat- omap/include/plat/opp.h new file mode 100644 index 000..997b56e --- /dev/null +++ b/arch/arm/plat-omap/include/plat/opp.h [..] + +#ifdef CONFIG_PM + [..] +struct omap_opp *opp_find_freq_ceil(struct device *dev, unsigned long *freq); + +int opp_add(const struct omap_opp_def *opp_def); + +int opp_enable(struct omap_opp *opp); + +int opp_disable(struct omap_opp *opp); + +void opp_init_cpufreq_table(struct device *dev, + struct cpufreq_frequency_table **table); +#else Hello Kevin, IN case of CONFIG_PM not being defined the else part will cause a compilation break as the signature of these APIs defined in the else part do not match with the signature in the if part. Thanks for the catch. Will send a patch for this. I learnt this the hard way by actually hitting the issue :-)!! Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Thursday, September 16, 2010 3:27 AM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
From: Paul Walmsley p...@pwsan.com
The OPP layer code should be independent of the PMIC,
introduce the TWL/TPS-specific code out to its own file.
Hello Kevin,
I have been using this code for a while now. I really do not think wee need a
separate
file for implementing the vsel to voltage in (uV) and vice versa formulas.
Today only voltage
layer is interested in these conversions. Voltage layer has a structure that
can be populated with
the information required from the PMIC. We only need to add two more function
pointers to this structure. This info can then be passed from the actual PMIC
driver file. This will make it much
more simpler for OMAP4 where we have different formulas between different
revisions of PMIC. Also
in the omap voltage code we will no longer have to hard code
omap_twl_vsel_to_uv and omap_twl_uv_to_vsel. So please consider dropping this
patch from this series.
Regards
Thara
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/include/plat/opp_twl_tps.h | 21 +
arch/arm/plat-omap/opp_twl_tps.c | 41
+
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h
create mode 100644 arch/arm/plat-omap/opp_twl_tps.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index c718a0a..a88879c 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# OPP support in (OMAP3+ only at the moment)
ifdef CONFIG_PM
obj-$(CONFIG_ARCH_OMAP3) += opp.o
+obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o
endif
# omap_device support (OMAP2+ only at the moment)
diff --git a/arch/arm/plat-omap/include/plat/opp_twl_tps.h b/arch/arm/plat-
omap/include/plat/opp_twl_tps.h
new file mode 100644
index 000..8784e5f
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
@@ -0,0 +1,21 @@
+/*
+ * opp_twl_tps.h - TWL/TPS-specific headers for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ *
+ * 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.
+ *
+ * XXX This code belongs as part of some other TWL/TPS code.
+ */
+#ifndef _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+#define _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+
+#include linux/kernel.h
+
+unsigned long omap_twl_vsel_to_uv(const u8 vsel);
+u8 omap_twl_uv_to_vsel(unsigned long uV);
+
+#endif
diff --git a/arch/arm/plat-omap/opp_twl_tps.c
b/arch/arm/plat-omap/opp_twl_tps.c
new file mode 100644
index 000..112f106
--- /dev/null
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -0,0 +1,41 @@
+/*
+ * opp_twl_tps.c - TWL/TPS-specific functions for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * 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.
+ *
+ * XXX This code should be part of some other TWL/TPS code.
+ */
+
+#include plat/opp_twl_tps.h
+
+/**
+ * omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
+ * @vsel: TWL/TPS VSEL value to convert
+ *
+ * Returns the microvolts DC that the TWL/TPS family of PMICs should
+ * generate when programmed with @vsel.
+ */
+unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return (((vsel * 125) + 6000)) * 100;
+}
+
+/**
+ * omap_twl_uv_to_vsel - convert microvolts DC to TWL/TPS VSEL value
+ * @uv: microvolts DC to convert
+ *
+ * Returns the VSEL value necessary for the TWL/TPS family of PMICs to
+ * generate an output voltage equal to or greater than @uv microvolts DC.
+ */
+u8 omap_twl_uv_to_vsel(unsigned long uv)
+{
+ /* Round up to higher voltage */
+ return DIV_ROUND_UP(uv - 60, 12500);
+}
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-OPP][PATCH] OMAP: Modifying the frequency comparison logic.
-Original Message- From: Menon, Nishanth Sent: Thursday, August 26, 2010 6:00 AM To: Kevin Hilman Cc: Gopinath, Thara; linux-omap@vger.kernel.org Subject: RE: [PM-OPP][PATCH] OMAP: Modifying the frequency comparison logic. -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, August 25, 2010 5:41 PM To: Menon, Nishanth Cc: Gopinath, Thara; linux-omap@vger.kernel.org Subject: Re: [PM-OPP][PATCH] OMAP: Modifying the frequency comparison logic. Menon, Nishanth n...@ti.com writes: From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, August 24, 2010 4:14 PM Menon, Nishanth n...@ti.com writes: thara gopinath th...@ti.com writes: From: Thara Gopinath th...@ti.com [...] The above is not correct as we expect the framework to return back the opp table entry corresponding to 266 Mhz. [...] b. Do the comparison in Mhz in the opp layer rather than in Hz. This would mean we will divide the rate passed into the opp layer API and the rates stored in the opp tables by 100 to get the rates in Mhz and do the necessary comparision. In this approach any vague frequency like 266.045Mhz will get mapped to 266 Mhz in the opp table. But if the passed rate is 267 Mhz, the opp framework will still rerturn an error or the next highest opp table entry This patch implements solution b. The scenario mentioned above is esp true for OMAP4 dpll_iva where we do end up with such weird frequencies due to sys clk being at 38.4 Mhz. I agree that solution b is better, although it makes the '_exact' function a bit less exact. :/ solution b is fine with me, but the kerneldoc for these find functions should be updated to describe the new matching technique. I agree, I suggest one improvement though - the search accuracy will vary Based on the silicon rev, one size will probably not fit every silicon and Domains we have - I suggest having accuracy as a parameter as part of domain Registration/configurable parameter e.g. + unsigned long rate = temp_opp-rate / 100; Will probably configurable to the exactness we expect to handle per domain/silicon family. The more I think about, I think we should leave the 'exact' find the way it is, especially as we move to device OPPs we will probably want to have more precise matching. What about adding another function that does a find closest? Just my 2cents: With accuracy as a param? Why would you need accuracy for find closest? How close should closest be? There has to be a parameter for this - something like as close as 10Mhz, but beyond the match fails. Currently this patch introduces a hardcoded accuracy which could be Carried forward. But, On different silicon the deltas due to sysclk can vary - there is no silver bullet algo we can write which will be accurate for all silicon and domain combination.. Further, is'nt ceil and floor functions we have a more specific Implementation of closest? in the sense, it says closest to which Direction - up or down.. [...] Rest of the discussion seems aligned. Hello Kevin, I am not sure about the conclusion of this discussion. For me we should avoid putting possible weird frequencies like 266789501.. Hence the round off to /10^6. If on some platforms due to sys clk we have frequency 267 instead of 266, I would prefer to edit the opp table through the opp framework APIs. This is my opinion. I may not have fully understood the concerns discussed in this forum. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code
-Original Message- From: Menon, Nishanth Sent: Thursday, September 16, 2010 5:45 PM To: Gopinath, Thara Cc: Kevin Hilman; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code Gopinath, Thara had written, on 09/16/2010 05:40 AM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, September 16, 2010 3:27 AM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: [PATCH 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code From: Paul Walmsley p...@pwsan.com The OPP layer code should be independent of the PMIC, introduce the TWL/TPS-specific code out to its own file. Hello Kevin, I have been using this code for a while now. I really do not think wee need a separate file for implementing the vsel to voltage in (uV) and vice versa formulas. Today only voltage This split introduces a PMIC level abstraction already. Do you have a suggestion which file it should go to? It is definitely not part of opp.c, not part of other existing twl files as well. the job of this file was to introduce conversion routines which can be used by any layer (voltage layer if need be - it used to be srf and smartreflex before).. in fact one of your voltage layer patches introduces capability for 6030 as well http://marc.info/?l=linux-omapm=128213020927919w=2 Yes one of my patches has introduces this coz I had no other way to add OMAP4 support. But I still do not understand why cant these APIs be implemented in twl-core.c or twl4030-power.c? layer is interested in these conversions. Voltage layer has a structure that can be populated with the information required from the PMIC. We only need to add two more function pointers to this structure. This info can then be passed from the actual PMIC driver file. This will make it much more simpler for OMAP4 where we have different formulas between different revisions of PMIC. Also in the omap voltage code we will no longer have to hard code omap_twl_vsel_to_uv and omap_twl_uv_to_vsel. I think the problem is with the voltage layer (which has not been posted upstream) which is using hard coded function pointer. What the patchset should have done is to introduce function pointers registration from twl_tps.c to voltage layer and voltage layer should ideally been using function pointers by itself. So please consider dropping this patch from this series. I think I disagree - rationale for having this separated as a pmic specific file is still sound, only the implementation of the future framework should have changed (it should be using function pointers instead of hardcoded function names). in fact I can add additional suggestion for the voltage layer: the pmic selection should be done from a board file - This will allow voltage layer to handle numerous PMICs and combination of PMICs controlling various domains as well.. the only neat way to handle it is ofcourse using function pointers. Exactly if voltage layer has to use a func ptr, why not let them be populated by the PMIC driver files directly? PS: Suggestion - please fix your mailer to round off for 70/80 char. Will try. - might be good to point folks to rfc patchset for voltage layer to give context. https://patchwork.kernel.org/patch/119429/ -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 4/8] OMAP3: PM: Adding smartreflex device file.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Tuesday, September 14, 2010 9:33 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand; Derrick, David Subject: Re: [PATCHv2 4/8] OMAP3: PM: Adding smartreflex device file. Gopinath, Thara th...@ti.com writes: [...] +sr_data-device_enable = omap_device_enable; +sr_data-device_shutdown = omap_device_shutdown; +sr_data-device_idle = omap_device_idle; Please drop these and use runtime PM as suggested in previous patch. At this stage I am not sure whether we should make smartreflex patches dependent on runtime pm. I would like to do the conversion once and for all once runtime pm is up streamed. Using runtime PM instead of the sr_data- calls will simplify this patch. Also, runtime PM core for OMAP will be merged this merge window. If you use my 'pm-core' branch for testing, you will have it included in your baseline, along with all the other things that are targeted for merge in 2.6.37. Is this branch latest kernel + stuff targeted for 2.6.37 ?? Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 1/8] OMAP: PM: Allowing an early init of pm debugfs driver.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, August 25, 2010 3:52 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand; Derrick, David Subject: Re: [PATCHv2 1/8] OMAP: PM: Allowing an early init of pm debugfs driver. On Tue, 2010-08-24 at 15:16 -0700, Kevin Hilman wrote: Thara Gopinath th...@ti.com writes: This patch changes the pm_db_init from arch initcall to a postcore initcall. With arch initcall, it is impossible for pm driver that gets initialized prior to this driver to use one of the pm debug fs entries during its init. Making it a postcore initcall ensures that this drver gets initialized early on before any pm drivers. Instead of tinkering with initcall ordering, how about calling the pm debug init from pm.c ignore this comment, pm.c is a device_initcall, so wont solve your problem. But I'd still like to know what PM drivers are being initialized so early they need this to be a postcore_initcall. It is needed from voltage and smartreflex layers for adding the debugfs entries. But considering these inits have been moved to device_initcall or late_initcall may be This change is no longer relevant. Thanks for catching this. Regards Thara Kevin
RE: [PATCHv2 8/8] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, August 25, 2010 5:23 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand;
Derrick, David
Subject: Re: [PATCHv2 8/8] OMAP3: PM: Adding debug support to Voltage and
Smartreflex drivers
Thara Gopinath th...@ti.com writes:
This patch adds debug support to the voltage and smartreflex drivers.
This means a whole bunch of voltage processor and smartreflex
parameters are now visible through the pm debugfs. By default
only a read of these parameters are permitted. If you need to
write into them then
echo 1 /pm_debug/enable_sr_vp_debug
The voltage parameters can be viewed at
/pm_debug/voltage/vdd_x/parameter
and the smartreflex parameters can be viewed at
/pm_debug/smartreflex/sr_x/parameter
where x is mpu or core for OMAP3.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm-debug.c| 13 ++
arch/arm/mach-omap2/smartreflex.c | 40 ++-
arch/arm/mach-omap2/voltage.c | 164
-
arch/arm/plat-omap/include/plat/smartreflex.h |1 -
arch/arm/plat-omap/include/plat/voltage.h |5 +
5 files changed, 216 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index fed8da1..b748baa 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -31,6 +31,7 @@
#include plat/board.h
#include plat/powerdomain.h
#include plat/clockdomain.h
+#include plat/voltage.h
#include prm.h
#include cm.h
@@ -556,6 +557,16 @@ static int option_set(void *data, u64 val)
if (option == enable_off_mode)
omap3_pm_off_mode_enable(val);
+ if (option == enable_sr_vp_debug val)
+ pr_notice(Beware that enabling this option will allow user
+ to override the system defined vp and sr parameters
+ All the updated parameters will take effect next
+ time smartreflex is enabled. Also this option
+ disables the automatic vp errorgain and sr errormin
+ limit changes as per the voltage. Users will have
+ to explicitly write values into the debug fs
+ entries corresponding to these if they want to see
+ them changing according to the VDD voltage\n);
return 0;
}
@@ -609,6 +620,8 @@ static int __init pm_dbg_init(void)
sleep_while_idle, pm_dbg_option_fops);
(void) debugfs_create_file(wakeup_timer_seconds, S_IRUGO | S_IWUGO, d,
wakeup_timer_seconds, pm_dbg_option_fops);
+ (void) debugfs_create_file(enable_sr_vp_debug, S_IRUGO | S_IWUGO, d,
+ enable_sr_vp_debug, pm_dbg_option_fops);
pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 1c871ae..bc611d1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -547,8 +547,13 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
return -ENODATA;
}
- /* errminlimit is opp dependent and hence linked to voltage */
- sr-err_minlimit = volt_data-sr_errminlimit;
+ /*
+* errminlimit is opp dependent and hence linked to voltage
+* if the debug option is enabled, the user might have over ridden
+* this parameter so do not get it from voltage table
+*/
+ if (!enable_sr_vp_debug)
+ sr-err_minlimit = volt_data-sr_errminlimit;
/* Enable the clocks */
if (!sr-is_sr_enable) {
@@ -812,8 +817,32 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return 0;
}
+static int omap_sr_params_show(void *data, u64 *val)
+{
+ u32 *param = data;
+
+ *val = *param;
+ return 0;
+}
+
+static int omap_sr_params_store(void *data, u64 val)
+{
+ if (enable_sr_vp_debug) {
+ u32 *option = data;
+ *option = val;
+ } else {
+ pr_notice(%s: DEBUG option not enabled!\n \
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
+ }
+ return 0;
+}
+
DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
omap_sr_autocomp_store, %llu\n);
+
+DEFINE_SIMPLE_ATTRIBUTE(sr_params_fops, omap_sr_params_show,
+ omap_sr_params_store, %llu\n);
#endif
static int __init omap_smartreflex_probe(struct platform_device *pdev)
@@ -884,6 +913,13 @@ static int __init omap_smartreflex_probe(struct
platform_device *pdev)
dbg_dir = debugfs_create_dir(name, sr_dbg_dir);
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUGO, dbg_dir,
(void *)sr_info, pm_sr_fops
RE: [PATCHv2 2/8] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, August 25, 2010 5:32 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand;
Derrick, David
Subject: Re: [PATCHv2 2/8] OMAP3: PM: Adding voltage driver support for OMAP3
Thara Gopinath th...@ti.com writes:
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
This is looking pretty good. Mostly minor style issues left to correct.
Thanks for the review.
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/voltage.c | 1119
+
arch/arm/plat-omap/include/plat/voltage.h | 132
3 files changed, 1253 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/voltage.c
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 63b2d88..1c095cf 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -49,7 +49,8 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \
+ cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
new file mode 100644
index 000..cb0fcac
--- /dev/null
+++ b/arch/arm/mach-omap2/voltage.c
@@ -0,0 +1,1119 @@
+/*
+ * OMAP3/OMAP4 Voltage Management Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ * Lesly A M x0080...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@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 linux/pm.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+
+#include plat/omap-pm.h
+#include plat/omap34xx.h
+#include plat/opp.h
+#include plat/opp_twl_tps.h
+#include plat/clock.h
+#include plat/common.h
+#include plat/voltage.h
+
+#include prm-regbits-34xx.h
+
+#define VP_IDLE_TIMEOUT200
+#define VP_TRANXDONE_TIMEOUT 300
+
+/* PRM voltage module */
+static u32 volt_mod;
+
+/* Voltage processor register offsets */
+struct vp_reg_offs {
+ u8 vpconfig;
+ u8 vstepmin;
+ u8 vstepmax;
+ u8 vlimitto;
+ u8 vstatus;
+ u8 voltage;
+};
+
+/* Voltage Processor bit field values, shifts and masks */
+struct vp_reg_val {
+ /* VPx_VPCONFIG */
+ u32 vpconfig_erroroffset;
+ u16 vpconfig_errorgain;
+ u32 vpconfig_errorgain_mask;
+ u8 vpconfig_errorgain_shift;
+ u32 vpconfig_initvoltage_mask;
+ u8 vpconfig_initvoltage_shift;
+ u32 vpconfig_timeouten;
+ u32 vpconfig_initvdd;
+ u32 vpconfig_forceupdate;
+ u32 vpconfig_vpenable;
+ /* VPx_VSTEPMIN */
+ u8 vstepmin_stepmin;
+ u16 vstepmin_smpswaittimemin;
+ u8 vstepmin_stepmin_shift;
+ u8 vstepmin_smpswaittimemin_shift;
+ /* VPx_VSTEPMAX */
+ u8 vstepmax_stepmax;
+ u16 vstepmax_smpswaittimemax;
+ u8 vstepmax_stepmax_shift;
+ u8 vstepmax_smpswaittimemax_shift;
+ /* VPx_VLIMITTO */
+ u16 vlimitto_vddmin;
+ u16 vlimitto_vddmax;
+ u16 vlimitto_timeout;
+ u16 vlimitto_vddmin_shift;
+ u16 vlimitto_vddmax_shift;
+ u16 vlimitto_timeout_shift;
+ /* PRM_IRQSTATUS*/
+ u32 tranxdone_status;
+};
+
+/**
+ * omap_vdd_info - Per Voltage Domain info
+ *
+ * @volt_data : voltage table having the distinct voltages
supported
RE: [PATCHv2 4/8] OMAP3: PM: Adding smartreflex device file.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 3:57 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand;
Derrick, David
Subject: Re: [PATCHv2 4/8] OMAP3: PM: Adding smartreflex device file.
Thara Gopinath th...@ti.com writes:
This patch adds support for device registration of various
smartreflex module present in the system. This patch introduces
the platform data for smartreflex devices which include
the efused and test n-target vaules, module enable/disable
pointers and a parameter to indicate whether smartreflex
autocompensation needs to be enabled on init or not.
Currently auocompensation is enabled on init by default
for OMAP3430 ES3.1 chip.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/sr_device.c | 185
+++
2 files changed, 186 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/sr_device.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0754886..f259bb8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -53,7 +53,7 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
-obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
+obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/sr_device.c
b/arch/arm/mach-omap2/sr_device.c
new file mode 100644
index 000..3bd0170
--- /dev/null
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -0,0 +1,185 @@
+/*
+ * OMAP3/OMAP4 smartreflex device file
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Based originally on code from smartreflex.c
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Lesly A M x0080...@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 linux/err.h
+#include linux/slab.h
+
+#include plat/control.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/opp.h
+#include plat/smartreflex.h
+#include plat/voltage.h
+
+static struct omap_device_pm_latency omap_sr_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST
+ },
+};
+
+/* Read EFUSE values from control registers for OMAP3430 */
+static void __init sr_read_efuse(struct omap_sr_dev_data *dev_data,
+ struct omap_sr_data *sr_data)
+{
+ int i;
+
+ if (!dev_data || !dev_data-volts_supported || !dev_data-volt_data ||
+ !dev_data-efuse_nvalues_offs) {
+ pr_warning(%s: Bad parameters! dev_data = %x,
+ dev_data-volts_supported = %x,
+ dev_data-volt_data = %x,
+ dev_data-efuse_nvalues_offs = %x\n, __func__,
+ (unsigned int)dev_data, dev_data-volts_supported,
+ (unsigned int)dev_data-volt_data,
+ (unsigned int)dev_data-efuse_nvalues_offs);
+ return;
+ }
+
+ /*
+* From OMAP3630 onwards there are no efuse registers for senn_mod
+* and senp_mod. They have to be 0x1 by default.
+*/
+ if (!dev_data-efuse_sr_control) {
+ sr_data-senn_mod = 0x1;
+ sr_data-senp_mod = 0x1;
+ } else {
+ sr_data-senn_mod =
+ ((omap_ctrl_readl(dev_data-efuse_sr_control)
+ (0x3 dev_data-sennenable_shift))
+ dev_data-sennenable_shift);
+ sr_data-senp_mod =
+ ((omap_ctrl_readl(dev_data-efuse_sr_control)
+ (0x3 dev_data-senpenable_shift))
+ dev_data-senpenable_shift);
+ }
+
+ for (i = 0; i dev_data-volts_supported; i++)
+ dev_data-volt_data[i].sr_nvalue = omap_ctrl_readl(
+ dev_data-efuse_nvalues_offs[i]);
+}
+
+/*
+ * Hard coded nvalues for testing purposes for OMAP3430,
+ * may cause device to hang!
+ */
+static void __init sr_set_testing_nvalues(struct omap_sr_dev_data
*dev_data,
+ struct omap_sr_data *sr_data)
+{
+ int i
RE: [PATCHv2 3/8] OMAP3: PM: Adding smartreflex driver support.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 3:52 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand;
Derrick, David
Subject: Re: [PATCHv2 3/8] OMAP3: PM: Adding smartreflex driver support.
Thara Gopinath th...@ti.com writes:
SmartReflex modules do adaptive voltage control for real-time
voltage adjustments. With Smartreflex the power supply voltage
can be adapted to the silicon performance(manufacturing process,
temperature induced performance, age induced performance etc).
There are differnet classes of smartreflex implementation.
Class-0: Manufacturing Test Calibration
Class-1: Boot-Time Software Calibration
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration
Class-4: Fully Integrated Power Management
OMAP3 has two smartreflex modules one associated with VDD1 and the
other associated with VDD2.
This patch adds support for smartreflex driver. The driver is designed
for Class-1 , Class-2 and Class-3 support and is a platform driver.
Smartreflex driver can be enabled through a Kconfig option
SmartReflex support under System type-TI OMAP implementations menu.
Smartreflex autocompensation feature can be enabled runtime through
a debug fs option.
To enable smartreflex autocompensation feature
echo 1 /debugfs/pm_debug/smartreflex/sr_X/autocomp
To disable smartreflex autocompensation feature
echo 0 /debugfs/pm_debug/smartreflex/sr_X/autocomp
where X can be mpu, core , iva etc.
This patch contains code originally in linux omap pm branch.
Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex.c | 973
+
arch/arm/plat-omap/Kconfig| 32 +
arch/arm/plat-omap/include/plat/smartreflex.h | 286
4 files changed, 1292 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c095cf..0754886 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
voltage.o \
cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
new file mode 100644
index 000..1c871ae
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -0,0 +1,973 @@
+/*
+ * OMAP SmartReflex Voltage Control
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Lesly A M x0080...@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 linux/init.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/kobject.h
+#include linux/i2c/twl.h
+#include linux/io.h
+#include linux/list.h
+#include linux/debugfs.h
+#include linux/delay.h
+#include linux/slab.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/common.h
+#include plat/smartreflex.h
+
+#define SMARTREFLEX_NAME_LEN 16
+#define SR_DISABLE_TIMEOUT 200
+
+#ifdef CONFIG_PM_DEBUG
+struct dentry *sr_dbg_dir;
+#endif
+
+struct omap_sr {
+ int srid;
+ int is_sr_enable;
sr_enabled would be a better name, and should be a bool
OK
+ int is_autocomp_active;
drop the 'is_' prefix, and should be a bool
OK
+ int sr_ip_type;
can drop the 'sr_' prefix.
OK
+ u32 clk_length;
+ u32 err_weight;
+ u32 err_minlimit;
+ u32 err_maxlimit;
+ u32 accum_data;
+ u32 senn_avgweight;
+ u32 senp_avgweight;
+ unsigned intirq;
+ void __iomem*base;
+ struct platform_device *pdev;
+ struct list_headnode
RE: [PATCHv2 6/8] OMAP3: PM: Adding smartreflex class3 driver
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, August 26, 2010 4:01 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand; Derrick, David Subject: Re: [PATCHv2 6/8] OMAP3: PM: Adding smartreflex class3 driver Thara Gopinath th...@ti.com writes: Smartreflex Class3 implementation continuously monitors silicon performance and instructs the Voltage Processors to increase or decrease the voltage. This patch adds smartreflex class 3 driver. This driver hooks up with the generic smartreflex driver smartreflex.c to abstract out class specific implementations out of the generic driver. Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-3430sdp.c |2 + arch/arm/mach-omap2/board-3630sdp.c |2 + arch/arm/mach-omap2/board-zoom3.c|2 + I think this should be board-zoom-peripherals.c so it is enabled for Zoom2 also. arch/arm/mach-omap2/smartreflex-class3.c | 61 ++ arch/arm/mach-omap2/smartreflex-class3.h | 23 +++ arch/arm/plat-omap/Kconfig |9 Please separate this into the 2 patches. One for the class driver, and a second to modify the board files. Will do this. Regards Thara Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP: omap_device: make all devices a child of a new omap_bus device
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Wednesday, September 01, 2010 5:33 AM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com
Subject: [PATCH 2/2] OMAP: omap_device: make all devices a child of a new
omap_bus device
From: Kevin Hilman khil...@ti.com
In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new omap_bus device.
Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.
Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.
In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform
Hello Kevin,
Couple of minor queries/comments below.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 18 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index bad4c3d..26d0c10 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -36,6 +36,8 @@
#include plat/omap_hwmod.h
+extern struct device omap_bus;
+
Why is this extern declaration needed? Is it later on
to check in runtime pm code pdev-dev.parent == omap_bus??
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN0
#define OMAP_DEVICE_STATE_ENABLED1
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 7f05f49..3e215fa 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -463,8 +463,11 @@ int omap_early_device_register(struct omap_device *od)
*/
int omap_device_register(struct omap_device *od)
{
+ struct platform_device *pdev = od-pdev;
+
pr_debug(omap_device: %s: registering\n, od-pdev.name);
+ pdev-dev.parent = omap_bus;
What if device_register(omap_bus) has returned an
error? Do we still go ahead with assigning omap_bus
as parent?
return platform_device_register(od-pdev);
}
@@ -737,3 +740,18 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+struct device omap_bus = {
+ .init_name = omap,
+};
+
+static int __init omap_device_init(void)
+{
+ int error = 0;
Is the initialization to 0 needed?
+
+ printk(%s:\n, __func__);
Spurious printk???
Regards
Thara
+ error = device_register(omap_bus);
+
+ return error;
+}
+core_initcall(omap_device_init);
--
1.7.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 Clock CPU frequency
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of msin...@eastcoreng.com Sent: Monday, August 30, 2010 12:33 AM To: linux-omap@vger.kernel.org Subject: OMAP3 Clock CPU frequency Kevin Hilman wrote: FWIW, the SR hwmods are still not enabling by default because the clock fwk fails due to missing clockdomain. I've been manually working around by adding .clkdm_name = wkup_clkdm, to sr*_fck, but I know that's not the correct fix. Kevin That only seems to eliminate the warning. I'm seeing omap_hwmod: sr1_hwmod: cannot be enabled (3) because oh-prcm.omap2 is Null on the call to omap2_cm_wait_module_ready() cpufreq changing does not occur. Which version of these patches are you using? The V2 version does have oh-prcm.omap2 populated for smartreflex. Regards Thara
RE: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Shubhrajyoti D
Sent: Tuesday, August 24, 2010 10:58 AM
To: linux-omap@vger.kernel.org
Cc: Datta, Shubhrajyoti
Subject: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
omap 4430sdp board support for the GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 61
+++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..85b0e0c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
@@ -40,6 +41,8 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON 48
#define ETH_KS8851_QUART 138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO188
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -77,11 +80,47 @@ static struct gpio_led sdp4430_gpio_leds[] = {
};
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+ {
+ .desc = Proximity Sensor,
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+ .active_low = 0,
+ }
+};
+
static struct gpio_led_platform_data sdp4430_led_data = {
.leds = sdp4430_gpio_leds,
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static int omap_prox_activate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ return 0;
+}
+
+static void omap_prox_deactivate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+ .buttons= sdp4430_gpio_keys,
+ .nbuttons = ARRAY_SIZE(sdp4430_gpio_keys),
+ .enable = omap_prox_activate,
+ .disable= omap_prox_deactivate,
+};
+
+static struct platform_device sdp4430_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_gpio_keys_data,
+ },
+};
+
static struct platform_device sdp4430_leds_gpio = {
.name = leds-gpio,
.id = -1,
@@ -161,6 +200,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
};
@@ -426,6 +466,26 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+static void __init omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(%s:failed to request GPIO %d, error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 0);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+ }
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
@@ -448,6 +508,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_sfh7741prox_init();
Hello Shubro,
I believe you are calling omap_sfh7741prox_init at the end of omap_4430sdp_init
which means your sdp4430_gpio_keys_device is registered much before this.
This could mean that the probe of your gpio-keys driver could get called before
omap_sfh7741prox_init. Assume this is the case and your probe calls into
pdata-enable
or pdata-disable which is omap_prox_activate/omap_prox_deactivate as per this
patch, these API's will try accessing gpio APIs for OMAP4_SFH7741_ENABLE_GPIO
without
a gpio_request happening for this pin as omap_sfh7741prox_init is called later.
Maybe such a case might never arise. But I would say you should do a
request_gpio for
OMAP4_SFH7741_ENABLE_GPIO before the driver probe is called.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 1/2 v2] omap3: sr: fix memory leak and simplify the code
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, August 25, 2010 2:55 AM To: Menon, Nishanth; Gopinath, Thara Cc: linux-omap; Artem Bityutskiy; Peter p2 De Schrijver Subject: Re: [PM-SR][PATCH 1/2 v2] omap3: sr: fix memory leak and simplify the code Nishanth Menon n...@ti.com writes: From: Artem Bityutskiy artem.bityuts...@nokia.com This patch fixes the following problem indicated by kmemleak: kmemleak: unreferenced object 0xdf93c280 (size 64): kmemleak: backtrace: kmemleak: [c00df6d4] create_object+0x104/0x200 kmemleak: [c00d7638] kmem_cache_alloc+0xe4/0xf4 kmemleak: [c000fc38] omap_devinit_smartreflex+0x44/0x244 kmemleak: [c003a33c] do_one_initcall+0x5c/0x1b8 kmemleak: [c00083fc] kernel_init+0x94/0x110 kmemleak: [c003ba04] kernel_thread_exit+0x0/0x8 The reason is that 'omap_devinit_smartreflex()' allocates 'sr_data', then passes it to 'omap_device_build()', which 'kmemdup()'s it and uses the copy. But 'omap_devinit_smartreflex()' never frees 'sr_data'. This patch make 'sr_data' to be a stack variable, which eliminates the memory leak and simplifies the code a bit. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com, Cc: Peter p2 De Schrijver peter.de-schrij...@nokia.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Acked-by: Nishanth Menon n...@ti.com --- Changes from V1: rebased to latest pm-sr branch default of sr_data set to 0 to make it equivalent to kzalloc NOTE: this probably should be squashed when being send upstream along with rest of SR series Thara, you appear to have fixed this problem differently in your latest series. Looks like you just ensured kfree() was always done, correct? In the future, it would be helpful if you would reply to these proposed fixes on the list so we know if they are incorporated or handled differently. Yes.. you r correct.. I missed replying on this one. Sorry for the confusion. Will take care of this in future. It is indeed fixed by ensuring kfree() always. Regards, Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP4: pm.c extensions for OMAP4 support
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, August 25, 2010 4:43 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant,
Anand
Subject: Re: [PATCH v2] OMAP4: pm.c extensions for OMAP4 support
On Tue, 2010-08-24 at 14:58 -0700, Kevin Hilman wrote:
Thara Gopinath th...@ti.com writes:
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.
Signed-off-by: Thara Gopinath th...@ti.com
---
v2: Removed fixing of l3_main hwmod for OMAP4 as Benoit has
already submitted a pach fixing the same.
OK, applying this to pm-fixes.
No second thought, not yet...
arch/arm/mach-omap2/pm.c | 19 ++-
arch/arm/plat-omap/include/plat/common.h |3 ++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..a98b5e8 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -21,8 +21,9 @@
static struct omap_device_pm_latency *pm_lats;
static struct device *mpu_dev;
-static struct device *dsp_dev;
+static struct device *iva_dev;
static struct device *l3_dev;
+static struct device *dsp_dev;
struct device *omap2_get_mpuss_device(void)
{
@@ -30,10 +31,10 @@ struct device *omap2_get_mpuss_device(void)
return mpu_dev;
}
-struct device *omap2_get_dsp_device(void)
+struct device *omap2_get_iva_device(void)
{
- WARN_ON_ONCE(!dsp_dev);
- return dsp_dev;
+ WARN_ON_ONCE(!iva_dev);
+ return iva_dev;
}
struct device *omap2_get_l3_device(void)
@@ -42,6 +43,13 @@ struct device *omap2_get_l3_device(void)
return l3_dev;
}
+struct device *omap4_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+EXPORT_SYMBOL(omap4_get_dsp_device);
+
/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
static int _init_omap_device(char *name, struct device **new_dev)
{
@@ -69,7 +77,8 @@ static int _init_omap_device(char *name, struct device
**new_dev)
static void omap2_init_processor_devices(void)
{
_init_omap_device(mpu, mpu_dev);
- _init_omap_device(iva, dsp_dev);
+ _init_omap_device(iva, iva_dev);
+ _init_omap_device(dsp, dsp_dev);
this one causes the noisy WARN to be tirggered on !OMAP4. Since !OMAP4
doesn't have a DSP, we shouldn't be warning users about a missing dsp
hwmod.
Hello Kevin,
I will put a OMAP4 check across this and repost.
Regards
Thara
Kevin
_init_omap_device(l3_main, l3_dev);
}
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..c45dbb9 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -91,7 +91,8 @@ void omap3_map_io(void);
})
extern struct device *omap2_get_mpuss_device(void);
-extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
+extern struct device *omap4_get_dsp_device(void);
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
RE: OMAP3 Clock CPU frequency
-Original Message- From: Matt Singer [mailto:msin...@eastcoreng.com] Sent: Monday, August 30, 2010 6:02 PM To: Gopinath, Thara; linux-omap@vger.kernel.org Subject: RE: OMAP3 Clock CPU frequency Is it in mainline yet or still a patch? Hello Matt, It is not in mainline and is only a patch series. Link to the series http://marc.info/?l=linux-omapm=128170725127719w=2 Link to the specific patch http://marc.info/?l=linux-omapm=128170725327731w=2 Hope this helps you. One advice to you would be not to top post while replying to the mailing list. It is a bad etiquette. Regards Thara -Original Message- From: Gopinath, Thara [mailto:th...@ti.com] Sent: Monday, August 30, 2010 6:29 AM To: msin...@eastcoreng.com; linux-omap@vger.kernel.org Subject: RE: OMAP3 Clock CPU frequency -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of msin...@eastcoreng.com Sent: Monday, August 30, 2010 12:33 AM To: linux-omap@vger.kernel.org Subject: OMAP3 Clock CPU frequency Kevin Hilman wrote: FWIW, the SR hwmods are still not enabling by default because the clock fwk fails due to missing clockdomain. I've been manually working around by adding .clkdm_name = wkup_clkdm, to sr*_fck, but I know that's not the correct fix. Kevin That only seems to eliminate the warning. I'm seeing omap_hwmod: sr1_hwmod: cannot be enabled (3) because oh-prcm.omap2 is Null on the call to omap2_cm_wait_module_ready() cpufreq changing does not occur. Which version of these patches are you using? The V2 version does have oh-prcm.omap2 populated for smartreflex. Regards Thara No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3093 - Release Date: 08/29/10 14:34:00 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
felipe.ba...@nokia.com
Sent: Wednesday, August 18, 2010 11:50 AM
To: Samuel Ortiz
Cc: linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; Tony Lindgren;
Andrew Morton; Felipe
Balbi
Subject: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h
From: Felipe Balbi felipe.ba...@nokia.com
use the new definitions on twl header for code
consistency.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
drivers/mfd/twl-core.c | 21 +
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 720e099..9689ecf 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -202,12 +202,6 @@
/* Few power values */
#define R_CFG_BOOT 0x05
-#define R_PROTECT_KEY0x0E
-
-/* access control values for R_PROTECT_KEY */
-#define KEY_UNLOCK1 0xce
-#define KEY_UNLOCK2 0xec
-#define KEY_LOCK 0x00
/* some fields in R_CFG_BOOT */
#define HFCLK_FREQ_19p2_MHZ (1 0)
@@ -846,8 +840,8 @@ static inline int __init protect_pm_master(void)
{
int e = 0;
- e = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_LOCK,
- R_PROTECT_KEY);
+ e = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0,
+ TWL4030_PM_MASTER_PROTECT_KEY);
Hello Felipe,
R_PROTECT_KEY offset is 0xE where as the new TWL4030_PM_MASTER_PROTECT_KEY
is defined as 0xd. I have not checked the trm to see which is correct. But
I hope this is a conscious change. Else we will end up breaking the
functionality.
Also if this is a conscious change may be you should mention it in the patch
description. This comment applies to all other places where R_PROTECT_KEY has
been replaced with TWL4030_PM_MASTER_PROTECT_KEY in this patch as well as in
patch 3/4 and patch 4/4.
Regards
Thara
return e;
}
@@ -855,10 +849,13 @@ static inline int __init unprotect_pm_master(void)
{
int e = 0;
- e |= twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_UNLOCK1,
- R_PROTECT_KEY);
- e |= twl_i2c_write_u8(TWL_MODULE_PM_MASTER, KEY_UNLOCK2,
- R_PROTECT_KEY);
+ e |= twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER,
+ TWL4030_PM_MASTER_KEY_CFG1,
+ TWL4030_PM_MASTER_PROTECT_KEY);
+ e |= twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER,
+ TWL4030_PM_MASTER_KEY_CFG2,
+ TWL4030_PM_MASTER_PROTECT_KEY);
+
return e;
}
--
1.7.2.1.6.g61bf12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP2PLUS dpll rate calculation.
Hello Paul/Kevin, Recently I noticed that the dpll rate calculation code in arch/arm/mach-omap2/clkt_dpll.c is as follows dpll_clk = (long long)dd-clk_ref-rate * dpll_mult; do_div(dpll_clk, dpll_div + 1); But the actual trm for both OMAP3 and OMAP4 (I believe this is true for OMAP2 also) shows that the dpll output rate should be calculated as ref_clk * 2 * M / (N + 1). We have not been hit by this bug in OMAP2 / OMAP3 as we have always had a X node X2 node for all the post dividers. And for the X2 node we do a *2 of the parent clock rate. This is again not according to spec as X2 nodes are direct derivatives from the dpll clock with just a post divider in between. Where as as per the spec the X nodes have to be /2 from the dpll clock rate in addition to applying the post divider. But now in OMAP4 clock data base in auto generated. The auto generation does not generate a X node and a X2 node for the post dividers. It just generates one node and it expects it's rate to be dpll clock rate / post divider. But then these nodes now reflect wrong rates as the dpll clock rate itself is /2. Hence all the child clocks start displaying a wrong rate. This issue can be solved in two ways. 1. Add explicit X2 nodes for all the post dividers let them be the parent to rest of the child clocks for OMAP4. Before doing this I would like to understand why the dpll rate calculation is not done according to the spec. 2. Correct the dpll rate calculation as per the spec. But then this change will be intrusive. We will have to modify the OMAP2 and OMAP3 clock data base accordingly. (Lot of X nodes can disappear). Do let me know your take on this. Regards Thara Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h
-Original Message- From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Wednesday, August 18, 2010 12:29 PM To: Gopinath, Thara Cc: Balbi Felipe (Nokia-MS/Helsinki); Samuel Ortiz; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org; Tony Lindgren; Andrew Morton Subject: Re: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h On Wed, Aug 18, 2010 at 08:32:57AM +0200, ext Gopinath, Thara wrote: R_PROTECT_KEY offset is 0xE where as the new TWL4030_PM_MASTER_PROTECT_KEY is defined as 0xd. I have not checked the trm to see which is correct. But you can use either 0xc0|0x0c or 0xce|0xec, both will work are unlock keys. No I am not talking about the key values. I was talking about the register offset for TWL4030_PM_MASTER_PROTECT_KEY. My question is, is it ok for it to be 0xd or 0xe. Earlier we were using 0xd and in the new implementation it has been changed to 0xe. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h
-Original Message- From: Gopinath, Thara Sent: Wednesday, August 18, 2010 12:33 PM To: 'felipe.ba...@nokia.com' Cc: Samuel Ortiz; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; Tony Lindgren; Andrew Morton Subject: RE: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h -Original Message- From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Wednesday, August 18, 2010 12:29 PM To: Gopinath, Thara Cc: Balbi Felipe (Nokia-MS/Helsinki); Samuel Ortiz; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org; Tony Lindgren; Andrew Morton Subject: Re: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h On Wed, Aug 18, 2010 at 08:32:57AM +0200, ext Gopinath, Thara wrote: R_PROTECT_KEY offset is 0xE where as the new TWL4030_PM_MASTER_PROTECT_KEY is defined as 0xd. I have not checked the trm to see which is correct. But you can use either 0xc0|0x0c or 0xce|0xec, both will work are unlock keys. No I am not talking about the key values. I was talking about the register offset for TWL4030_PM_MASTER_PROTECT_KEY. My question is, is it ok for it to be 0xd or 0xe. Earlier we were using 0xd and in the new implementation it has been changed to 0xe. Typo. Earlier we were using 0xe and in the new implementation it has been changed to 0xd. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h
-Original Message- From: Felipe Balbi [mailto:felipe.ba...@nokia.com] Sent: Wednesday, August 18, 2010 12:46 PM To: Balbi Felipe (Nokia-MS/Helsinki) Cc: Gopinath, Thara; Samuel Ortiz; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org; Tony Lindgren; Andrew Morton Subject: Re: [PATCH 2/4] mfd: twl-core: switch over to defines in twl.h Hi, On Wed, Aug 18, 2010 at 09:10:22AM +0200, Balbi Felipe (Nokia-MS/Helsinki) wrote: On Wed, Aug 18, 2010 at 09:03:44AM +0200, ext Gopinath, Thara wrote: No I am not talking about the key values. I was talking about the register offset for TWL4030_PM_MASTER_PROTECT_KEY. My question is, is it ok for it to be 0xd or 0xe. Earlier we were using 0xd and in the new implementation it has been changed to 0xe. Typo. Earlier we were using 0xe and in the new implementation it has been changed to 0xd. you're right, I'm not sure how I came up with that value since the TRM shows 0x0e, maybe a copypaste error. Will change patch 1. ok, it's because there's no register 0x0a. And I missed that when defined the register space. Good catch, thanks. I wonder why it didn't fail to write to that register address :-? 0xd is a valid register offset. Hence no crash. Anyways I saw your new patch. Looks ok to me. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP4: pm.c extensions for OMAP4 support
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 16, 2010 7:23 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com;
Sripathy, Vishwanath;
Sawant, Anand
Subject: Re: [PATCH] OMAP4: pm.c extensions for OMAP4 support
Hi Thara,
On 8/16/2010 11:26 AM, Thara Gopinath wrote:
OMAP4 has an iva device and a dsp devcice where as OMAP2/3
has only an iva device. In this file the iva device in the
system is registered under the name dsp_dev and the API
to retrieve the iva device is omap2_get_dsp_device.
This patch renames the dsp_dev to iva_dev, renames
omap2_get_dsp_device to omap2_get_iva_device,
registers dsp_dev for OMAP4 and adds a new API
omap4_get_dsp_device to retrieve the dep_dev.
This patch also registers the device l3_main_1 as the l3
device in case of OMAP4 and retains traditional l3_main
in case of OMAP2/3
This bug is already fixed in the following patch:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-
pm.git;a=commit;h=71a4efad2196d0c52485aa397093c6791a6995f1
Ok. I did not see this. But rests of the changes are still valid.
I will send a V2 skipping this part.
Regards
Thara
Regards,
Benoit
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/pm.c | 24 ++--
arch/arm/plat-omap/include/plat/common.h |3 ++-
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 68f9f2e..0331290 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -21,8 +21,9 @@
static struct omap_device_pm_latency *pm_lats;
static struct device *mpu_dev;
-static struct device *dsp_dev;
+static struct device *iva_dev;
static struct device *l3_dev;
+static struct device *dsp_dev;
struct device *omap2_get_mpuss_device(void)
{
@@ -30,10 +31,10 @@ struct device *omap2_get_mpuss_device(void)
return mpu_dev;
}
-struct device *omap2_get_dsp_device(void)
+struct device *omap2_get_iva_device(void)
{
- WARN_ON_ONCE(!dsp_dev);
- return dsp_dev;
+ WARN_ON_ONCE(!iva_dev);
+ return iva_dev;
}
struct device *omap2_get_l3_device(void)
@@ -42,6 +43,13 @@ struct device *omap2_get_l3_device(void)
return l3_dev;
}
+struct device *omap4_get_dsp_device(void)
+{
+ WARN_ON_ONCE(!dsp_dev);
+ return dsp_dev;
+}
+EXPORT_SYMBOL(omap4_get_dsp_device);
+
/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
static int _init_omap_device(char *name, struct device **new_dev)
{
@@ -69,8 +77,12 @@ static int _init_omap_device(char *name, struct device
**new_dev)
static void omap2_init_processor_devices(void)
{
_init_omap_device(mpu,mpu_dev);
- _init_omap_device(iva,dsp_dev);
- _init_omap_device(l3_main,l3_dev);
+ _init_omap_device(iva,iva_dev);
+ _init_omap_device(dsp,dsp_dev);
+ if (cpu_is_omap44xx())
+ _init_omap_device(l3_main_1,l3_dev);
+ else
+ _init_omap_device(l3_main,l3_dev);
}
static int __init omap2_common_pm_init(void)
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..c45dbb9 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -91,7 +91,8 @@ void omap3_map_io(void);
})
extern struct device *omap2_get_mpuss_device(void);
-extern struct device *omap2_get_dsp_device(void);
+extern struct device *omap2_get_iva_device(void);
extern struct device *omap2_get_l3_device(void);
+extern struct device *omap4_get_dsp_device(void);
#endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Friday, August 06, 2010 4:30 PM To: Gopinath, Thara Cc: Menon, Nishanth; linux-omap; Kevin Hilman Subject: Re: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error On 08/06/2010 02:24 AM, Gopinath, Thara wrote: -Original Message- From: Menon, Nishanth Sent: Friday, August 06, 2010 3:54 AM To: linux-omap Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara Subject: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error sr_dev_init should return error on error conditions Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Thara Gopinathth...@ti.com Signed-off-by: Nishanth Menonn...@ti.com --- arch/arm/mach-omap2/sr_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c index 6f70da6..8fb60d8 100644 --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -162,7 +162,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) __func__, i + 1); i++; kfree(sr_data); - return 0; + return -ENODATA; } sr_set_nvalues(sr_dev_data, sr_data); od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data), @@ -172,6 +172,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) pr_warning(%s: Could not build omap_device for %s: %s.\n\n, __func__, name, oh-name); kfree(sr_data); + return PTR_ERR(od); } NAK for this change. This API is called from omap_hwmod_for_each_by_class for every smartreflex module. If This API returns an error omap_hwmod_for_each_by_class will exit without looping over rest of the smartreflex modules. This means a error for one smartreflex module will prevent rest of the smartreflex modules to be initialized. We do not want this. Hence this API returns 0 for non-availability of data for a smartreflex module. why do we want this behavior(aka continue with as many modules as you can enable)? h/wmod data structure are NOT meant to be corrupted if they are, what guarentee do we have that the rest of the sr module data structures have the right hwmods(even if they passed device_build?).. if they are, what is the point in enabling SR in half the domains - we should flag this as an error to developer and get him to fix it instead of encouraging this slipping by half a dozen developers as only sr_l3 failed or something similar.. It could be a typo that is causing one hwmod to fail. Also I disagree with the point that we cannot enable sr for one voltage domain alone. There are two or three separate voltage domains in the system so that they can be controlled and configured independent of each other. Also if one of the sr modules fail registration we do flag the error in today's code plus if the debug fs is enabled the entry for the failed sr module will be missing. I think that is enough of error handling and flagging. Regards Thara Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Nishanth Menon
Sent: Friday, August 06, 2010 4:38 PM
To: Gopinath, Thara
Cc: Menon, Nishanth; linux-omap; Kevin Hilman
Subject: Re: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_
On 08/06/2010 02:42 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_
Few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do .
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Thara Gopinathth...@ti.com
Signed-off-by: Nishanth Menonn...@ti.com
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 148e4d4..3431fa3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -253,8 +253,9 @@ static int vp_debug_set(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
}
I do not think this is needed as these fns get called only from user space.
have you tried working on someone else's unfamiliar code and grepping
for a warning message at the middle of the night because some developer
forgot to give a %s:..., __func__ with half a dozen people watching
behind your back to know it's meaning because the product is hitting the
shelves the next day? Instead of being able to use cscope and pop the
function in and go straight to it and understand what is happening?? I
believe there are few in this list who had the fortune to be in that sitn..
Well that is my motivation here. if driver reports a warning to kernel
syslog, well, I expect the log to contain the function name for me to
maintain faster.
Bingo!! Kudos on managing to prove that you are a cut above the rest. Poor moi
wont understand at all as moi do not work at all!!
But unless there are others in the community who feel that this is absolutely
necessary I am not pulling this in. For me you do a
cat /debug/pm_debgsome entry and get an error it is easy to figure out in the
kernel
with the limited experience I have working on linux kernel.
Regards
Thara
Regards
Thara
return 0;
}
@@ -265,7 +266,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
vsel = voltage_read_reg(info-vp_offs.voltage_reg);
- pr_notice(curr_vsel = %x\n, vsel);
+ pr_notice(%s: curr_vsel = %x\n, __func__, vsel);
*val = vsel * 12500 + 60;
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
-Original Message-
From: Menon, Nishanth
Sent: Wednesday, August 11, 2010 5:08 PM
To: Gopinath, Thara
Cc: Nishanth Menon; linux-omap; Eduardo Valentin; Kevin Hilman; Paul
Walmsley; Nayak, Rajendra;
Premi, Sanjeev; Tony Lindgren
Subject: Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
On 08/11/2010 06:23 AM, Gopinath, Thara wrote:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Wednesday, August 11, 2010 4:14 PM
To: Gopinath, Thara
Cc: Menon, Nishanth; linux-omap; Eduardo Valentin; Kevin Hilman; Paul
Walmsley; Nayak, Rajendra;
Premi, Sanjeev; Tony Lindgren
Subject: Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
On 08/11/2010 04:12 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Wednesday, August 11, 2010 7:47 AM
To: linux-omap
Cc: Menon, Nishanth; Eduardo Valentin; Kevin Hilman; Paul Walmsley;
Nayak, Rajendra; Premi,
Sanjeev;
Gopinath, Thara; Tony Lindgren
Subject: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
Make opp3xx data which is registered with the opp layer
dependent purely on CONFIG_PM as opp layer and pm.c users
are CONFIG_PM dependent not cpufreq dependent.
so we rename the data definition to opp3xxx_data.c (inline with what
we have for omap2), also move the build definition to be under
the existing CONFIG_PM build instead of CPUFREQ.
Cc: Eduardo Valentineduardo.valen...@nokia.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Rajendra Nayakrna...@ti.com
Cc: Sanjeev Premipr...@ti.com
Cc: Thara Gopinathth...@ti.com
Cc: Tony Lindgrent...@atomide.com
Signed-off-by: Nishanth Menonn...@ti.com
---
Note:
This takes care of the discussion on opp file renaming and making
it independent of cpufreq, unless I missed something else
arch/arm/mach-omap2/Makefile |5 +
.../mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} |0
2 files changed, 1 insertions(+), 4 deletions(-)
rename arch/arm/mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} (100%)
Is this part of PM-OPP branch? Also I was thinking of reusing the same
file for OMAP4.
this defines the opp data base and would be part of pm-opp branch. the
idea of rename was this:
a) be clear that this is not dependent on cpufreq alone.
I do not understand this. This files is not present in PM-OPP branch. But
you have a patch
modifying it against PM-OPP branch. Am I looking at a wrong version of PM-OPP
branch?
you got me curious as well, my apologies, I had assumed things were how
they were before :( Looks like Kevin shuffled things around and the data
by itself is in cpufreq branch:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=shortlog;h=refs/heads/pm-
cpufreq
ergo, Kevin, do we need this cpufreq branch to contain the opp data:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-
pm.git;a=commitdiff;h=9f6847282f65cdcd26d740e6ae6afadc3ee00233
and related changes could potentially be pulled into the same pm-opp series?
b) use the same convention in arch/arm/mach-omap2/ like omap2's opp data
files which could be converted to use the opp layer now instead of
having it's own opp layer. and maybe hopefully omap1 as well..
c) when we do specific product build, it makes sense to have arch
specific files as it makes not much reason to carry the omap4/2
definitions(even if init_data).
No reason why we should have a different file for OMAP4. So a better
name than opp3xxx_data.c?
why do we need to have it in the same file? Remember, 3630,3430 are
under OMAP3 family, but omap4 is considered a different arch.
Code is more or less the same. Is that not a sufficient reason to reuse a
file ?
I dont really care as long as opp layer is usable by mpurate without
depending on cpufreq and it is maintainable without going to if else
nightmare. But personally, I dont see really reusuable code in that file
(other than doing an opp addition in a loop) it could result eventually
in a large amount of code redundancy and maintenance nightmare with
OMAP4 variants coming in.
Why do you say maintenance nightmare? It is going to be one opp table per SoC.
Anyways, Kevin what is your take on this?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Wednesday, August 11, 2010 4:14 PM
To: Gopinath, Thara
Cc: Menon, Nishanth; linux-omap; Eduardo Valentin; Kevin Hilman; Paul
Walmsley; Nayak, Rajendra;
Premi, Sanjeev; Tony Lindgren
Subject: Re: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
On 08/11/2010 04:12 AM, Gopinath, Thara wrote:
-Original Message-
From: Menon, Nishanth
Sent: Wednesday, August 11, 2010 7:47 AM
To: linux-omap
Cc: Menon, Nishanth; Eduardo Valentin; Kevin Hilman; Paul Walmsley;
Nayak, Rajendra; Premi,
Sanjeev;
Gopinath, Thara; Tony Lindgren
Subject: [PM-OPP][PATCH 2/2] omap3: opp: make independent of cpufreq
Make opp3xx data which is registered with the opp layer
dependent purely on CONFIG_PM as opp layer and pm.c users
are CONFIG_PM dependent not cpufreq dependent.
so we rename the data definition to opp3xxx_data.c (inline with what
we have for omap2), also move the build definition to be under
the existing CONFIG_PM build instead of CPUFREQ.
Cc: Eduardo Valentineduardo.valen...@nokia.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: Rajendra Nayakrna...@ti.com
Cc: Sanjeev Premipr...@ti.com
Cc: Thara Gopinathth...@ti.com
Cc: Tony Lindgrent...@atomide.com
Signed-off-by: Nishanth Menonn...@ti.com
---
Note:
This takes care of the discussion on opp file renaming and making
it independent of cpufreq, unless I missed something else
arch/arm/mach-omap2/Makefile |5 +
.../mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} |0
2 files changed, 1 insertions(+), 4 deletions(-)
rename arch/arm/mach-omap2/{cpufreq34xx.c = opp3xxx_data.c} (100%)
Is this part of PM-OPP branch? Also I was thinking of reusing the same file
for OMAP4.
this defines the opp data base and would be part of pm-opp branch. the
idea of rename was this:
a) be clear that this is not dependent on cpufreq alone.
I do not understand this. This files is not present in PM-OPP branch. But you
have a patch modifying it against PM-OPP branch. Am I looking at a wrong
version of PM-OPP branch?
b) use the same convention in arch/arm/mach-omap2/ like omap2's opp data
files which could be converted to use the opp layer now instead of
having it's own opp layer. and maybe hopefully omap1 as well..
c) when we do specific product build, it makes sense to have arch
specific files as it makes not much reason to carry the omap4/2
definitions(even if init_data).
No reason why we should have a different file for OMAP4. So a better name
than opp3xxx_data.c?
why do we need to have it in the same file? Remember, 3630,3430 are
under OMAP3 family, but omap4 is considered a different arch.
Code is more or less the same. Is that not a sufficient reason to reuse a file
?
Regards,
Nishanth Menon
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 04/12] omap3: sr: device: cleanup pr_xxx
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 04/12] omap3: sr: device: cleanup pr_xxx
Strings in c dont need to be split accross multiple lines with \
. instead they can be put as abc def and it is equivalent to
abc def.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index dbf7603..7d13704 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -151,8 +151,9 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_dev_data-volts_supported = omap_get_voltage_table(i,
sr_dev_data-volt_data);
if (!sr_dev_data-volts_supported) {
- pr_warning(%s: No Voltage table registerd fo VDD%d.Something \
- really wrong\n\n, __func__, i + 1);
+ pr_warning(%s: No Voltage table registerd fo VDD%d.
+ Something is really wrong\n,
+ __func__, i + 1);
Taken in.
Regards
Thara
i++;
kfree(sr_data);
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error
-Original Message- From: Menon, Nishanth Sent: Friday, August 06, 2010 3:54 AM To: linux-omap Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara Subject: [PM-SR][PATCH 06/12] omap3: sr: device: fail sr_dev_init should return error sr_dev_init should return error on error conditions Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Thara Gopinath th...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/sr_device.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c index 6f70da6..8fb60d8 100644 --- a/arch/arm/mach-omap2/sr_device.c +++ b/arch/arm/mach-omap2/sr_device.c @@ -162,7 +162,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) __func__, i + 1); i++; kfree(sr_data); - return 0; + return -ENODATA; } sr_set_nvalues(sr_dev_data, sr_data); od = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data), @@ -172,6 +172,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user) pr_warning(%s: Could not build omap_device for %s: %s.\n\n, __func__, name, oh-name); kfree(sr_data); + return PTR_ERR(od); } NAK for this change. This API is called from omap_hwmod_for_each_by_class for every smartreflex module. If This API returns an error omap_hwmod_for_each_by_class will exit without looping over rest of the smartreflex modules. This means a error for one smartreflex module will prevent rest of the smartreflex modules to be initialized. We do not want this. Hence this API returns 0 for non-availability of data for a smartreflex module. Regards Thara i++; return 0; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 07/12] omap3: sr: device: make omap_sr_latency static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 07/12] omap3: sr: device: make omap_sr_latency static
omap_sr_latency definition does not need to be exposed to the world
but we cant make it __init data as the pointer is stored in odev
to be used beyond basic kernel boot.
also fixes sparse warning:
arch/arm/mach-omap2/sr_device.c:32:31: warning: symbol 'omap_sr_latency' was
not declared. Should it
be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 8fb60d8..e81 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -29,7 +29,7 @@
#include voltage.h
-struct omap_device_pm_latency omap_sr_latency[] = {
+static struct omap_device_pm_latency omap_sr_latency[] = {
{
.deactivate_func = omap_device_idle_hwmods,
.activate_func = omap_device_enable_hwmods,
Taken in
Regards
Thara
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 05/12] omap3: sr: device: check for dev_attr
In the unlikely case that hwmod database is messed up, dont crash
report error and attempt to recover.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/sr_device.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 7d13704..6f70da6 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -130,6 +130,12 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
}
sr_dev_data = (struct omap_sr_dev_data *)oh-dev_attr;
+ if (unlikely(!sr_dev_data)) {
+ pr_err(%s: Bad oh-dev_attr!\n, __func__);
+ kfree(sr_data);
+ return -EINVAL;
+ }
Taken in after modifications as per the reply for patch 06/12
Regards
Thara
+
/*
* OMAP3430 ES3.1 chips by default come with Efuse burnt
* with parameters required for full functionality of
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 12/12] omap3: sr: class3: make class3_data static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 12/12] omap3: sr: class3: make class3_data static
we dont expose the structure to the world, so this should be static
however, since sr core does not take a copy of the same, we cant make
it __init data.
fixes sparse warning:
arch/arm/mach-omap2/smartreflex-class3.c:50:36: warning: symbol 'class3_data'
was not declared.
Should it be static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index f3b766f..530b2f0 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -47,7 +47,7 @@ static int sr_class3_configure(int id)
}
/* SR class3 structure */
-struct omap_smartreflex_class_data class3_data = {
+static struct omap_smartreflex_class_data class3_data = {
.enable = sr_class3_enable,
.disable = sr_class3_disable,
.configure = sr_class3_configure,
Taken in
Regards
Thara
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 02/12] omap3: voltage: make required variables static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 02/12] omap3: voltage: make required variables static
debugfs voltage_dir - used only by voltage layer and no reason for
others to add data to it, so make it static.
volt_mod have no business being exposed as global. make it static
we dont expose omap3_vp_offs to the world and is __init data,
so make it static.
This fixes sparse warnings:
arch/arm/mach-omap2/voltage.c:42:15: warning: symbol 'voltage_dir' was not
declared. Should it be
static?
arch/arm/mach-omap2/voltage.c:49:5: warning: symbol 'volt_mod' was not
declared. Should it be static?
arch/arm/mach-omap2/voltage.c:130:27: warning: symbol 'omap3_vp_offs' was not
declared. Should it be
static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Note: i had initially considered splitting these into three seperate patches,
but these are too trivial.
arch/arm/mach-omap2/voltage.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3431fa3..1a3d00d 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -39,14 +39,14 @@
#define VP_TRANXDONE_TIMEOUT 300
#ifdef CONFIG_PM_DEBUG
-struct dentry *voltage_dir;
+static struct dentry *voltage_dir;
#endif
/* VP SR debug support */
u32 enable_sr_vp_debug;
/* PRM voltage module */
-u32 volt_mod;
+static u32 volt_mod;
/* Voltage processor register offsets */
struct vp_reg_offs {
@@ -127,7 +127,7 @@ static struct omap_vdd_info *vdd_info;
static int no_scalable_vdd;
/* OMAP3 VP register offsets and other definitions */
-struct __init vp_reg_offs omap3_vp_offs[] = {
+static struct __init vp_reg_offs omap3_vp_offs[] = {
This change is no longer valid after the patch converting vdd id's to
names. Rest of the two changes have been taken in.
Regards,
Thara
/* VP1 */
{
.vpconfig_reg = OMAP3_PRM_VP1_CONFIG_OFFSET,
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_xxxx
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 01/12] omap3: voltage: cleanup pr_
Few more pr_ need cleanup for printing the function name and
not using multiline prints when c allows us to do .
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/voltage.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 148e4d4..3431fa3 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -253,8 +253,9 @@ static int vp_debug_set(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
}
I do not think this is needed as these fns get called only from user space.
Regards
Thara
return 0;
}
@@ -265,7 +266,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
u8 vsel;
vsel = voltage_read_reg(info-vp_offs.voltage_reg);
- pr_notice(curr_vsel = %x\n, vsel);
+ pr_notice(%s: curr_vsel = %x\n, __func__, vsel);
*val = vsel * 12500 + 60;
return 0;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 08/12] omap3: sr: cleanup pr_xxx
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 08/12] omap3: sr: cleanup pr_xxx
pr_xxx family is not informative for debug unless one decides
to grep the code, instead print the function to help debug
easier on the field.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 57fc9b2..d63691b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -804,8 +804,9 @@ static int omap_sr_params_store(void *data, u64 val)
u32 *option = data;
*option = val;
} else {
- pr_notice(DEBUG option not enabled!\n \
- echo 1 pm_debug/enable_sr_vp_debug - to enable\n);
+ pr_notice(%s: DEBUG option not enabled!
+ echo 1 pm_debug/enable_sr_vp_debug to enable\n,
+ __func__);
}
Accepted and will be collated with rest of the patches.
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 09/12] omap3: sr: enable/disable sr only if required
We dont need to go down the path of enabling/disabling the SR
if we dont need to. do some sanity check and trigger if needed
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d63691b..9b5a10e 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -778,15 +778,26 @@ static int omap_sr_autocomp_show(void *data, u64 *val)
static int omap_sr_autocomp_store(void *data, u64 val)
{
struct omap_sr *sr_info = (struct omap_sr *) data;
+ u32 value = (u32) val;
if (!sr_info) {
pr_warning(%s: omap_sr struct for SR not found\n, __func__);
return -EINVAL;
}
- if (!val)
- sr_stop_vddautocomp(sr_info);
- else
- sr_start_vddautocomp(sr_info);
+
+ /* Sanity check */
+ if (value (value != 1)) {
+ pr_err(%s: invalid value %d\n, __func__, value);
+ return -EINVAL;
+ }
Will take this in.
+
+ /* change only if needed */
+ if (sr_info-is_autocomp_active ^ value) {
I do not think this is necessary. sr_start_vddautocomp and sr_stop_vddautocomp
will take care of
enabling and disabling intelligently.
Regards
Thara
+ if (!val)
+ sr_stop_vddautocomp(sr_info);
+ else
+ sr_start_vddautocomp(sr_info);
+ }
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 10/12] omap3: sr: export sr_dbg_dir
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 10/12] omap3: sr: export sr_dbg_dir
sr_dbg_dir is currently used privately in smartreflex.c, however,
smartreflex class drivers could store their own debugfs entries there
as well.
This also fixes the sparse warning:
arch/arm/mach-omap2/smartreflex.c:44:15: warning: symbol 'sr_dbg_dir' was not
declared. Should it be
static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/include/plat/smartreflex.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h b/arch/arm/plat-
omap/include/plat/smartreflex.h
index 1105db0..df58026 100644
--- a/arch/arm/plat-omap/include/plat/smartreflex.h
+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
@@ -263,6 +263,11 @@ int omap_sr_register_class(struct
omap_smartreflex_class_data *class_data);
/* API to register the pmic specific data with the smartreflex driver. */
void omap_sr_register_pmic(struct omap_smartreflex_pmic_data *pmic_data);
+
+#ifdef CONFIG_PM_DEBUG
+extern struct dentry *sr_dbg_dir;
+#endif
Will take this in
Regards
Thara
+
#else
static inline void omap_smartreflex_enable(int srid) {}
static inline void omap_smartreflex_disable(int srid) {}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PM-SR][PATCH 11/12] omap3: sr: sr_exit should be static
-Original Message-
From: Menon, Nishanth
Sent: Friday, August 06, 2010 3:54 AM
To: linux-omap
Cc: Menon, Nishanth; Kevin Hilman; Gopinath, Thara
Subject: [PM-SR][PATCH 11/12] omap3: sr: sr_exit should be static
sr_exit has no business being a public function.
fixes sparse:
arch/arm/mach-omap2/smartreflex.c:959:13: warning: symbol 'sr_exit' was not
declared. Should it be
static?
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9b5a10e..a723ac7 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -968,7 +968,7 @@ static int __init sr_init(void)
return 0;
}
-void __exit sr_exit(void)
+static void __exit sr_exit(void)
Will collate this.
{
platform_driver_unregister(smartreflex_driver);
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 05, 2010 2:36 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand;
Basak, Partha
Subject: Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device
specific set rate and get
rate in device opp structures.
Gopinath, Thara th...@ti.com writes:
@@ -385,6 +380,11 @@ int opp_add(const struct omap_opp_def *opp_def)
dev_opp-oh = oh;
dev_opp-dev = oh-od-pdev.dev;
+dev_opp-vdd_name = kzalloc(strlen(opp_def-vdd_name) +
1,
+GFP_KERNEL);
+strcpy(dev_opp-vdd_name, opp_def-vdd_name);
Since this is user-defined data/string, should probably have a max
strlen and use strncpy.
I did not get this. What is the problem with the strlen here ?
It's more of a paranoia issue than a technical issue. I don't like
blindly using strlen on strings that are user-configurable. I guess,
since they're coming from the OPP table, they're not terribly
configurable, so it's probably not a big deal.
However, since opp_add() is already doing one kzalloc, I think it's
probably cleaner to just to make this field a fixed lenght and
then use strncpy():
#define VDD_NAME_LEN 8
struct device_opp {
...
char vdd_name[VDD_NAME_LEN];
...
}
Gotcha! Will incorporate in V2.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 0/7] OMAP: Basic DVFS framework
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, August 04, 2010 5:20 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand; Basak, Partha Subject: Re: [RFC 0/7] OMAP: Basic DVFS framework Thara Gopinath th...@ti.com writes: This patch series is RFC for support of Dynamic Voltage and Frequency Scaling (DVFS) for OMAP devices. DVFS is a technique that uses the optimal operating frequency and voltage to allow a task to be performed in the required amount of time. OMAP processors have voltage domains whose voltage can be scaled to various levels depending on which the operating frequencies of certain devices belonging to the domain will also need to be scaled. This voltage frequency tuple is known as Operating Performance Point (OPP). A device can have multiple OPP's. Also a voltage domain could be shared between multiple devices. Also there could be dependencies between various voltage domains for maintaining system performance like VDDX should be at voltage v1 when VDDY is at voltage v2. The design of this framework take into account all the above mentioned points. To summarize the basic design of DVFS framework:- 1. Have device opp tables for each device whose operating frequency can be scaled. This is easy now due to the existance of hwmod layer which allow storing of device specific info. The device opp tables contain the opp pairs (frequency voltage tuples), the voltage domain pointer to which the device belongs to, the device specific set_rate and get_rate API's which will do the actual scaling of the device frequency and retrieve the current device frequency. 2. Introduce use counting on a per VDD basis. This is to take care multiple requests to scale a VDD. The VDD will be scaled to the maximum of the voltages requested. 3. Keep track of all scalable devices belonging to a particular voltage domain the voltage layer. 4. Generic API in the omap device layer which can be called by anybody to scale a device opp. This API will take in the device pointer and frequency to which the device needs to be scaled to. This API will then internally find out the voltage domain to which the device belongs to and the voltage to which the voltage domain needs to be put to for the device to be scaled to the new frequency from the device opp table. Then this API will call into the newly introduced API in voltage layer (as mentioned in 2) to see if there are other requests for the associated voltage domain to be at a voltage higher than the current chosen one. If not this API will go ahead and scale the voltage domain to the new voltage, run through the list of all scalable devices belonging to this voltage domain and scale them to the appropriate frequencies using the set_rate pointer in the device opp table.s Work pending - 1. Handle inter VDD dependencies. 2. Add OMAP4 support. Contributors to conceptualization of the design include Benoit Cousson b-cous...@ti.com, Kevin Hilman khil...@deeprootsystems.com, Paul Wamsley p...@pwsan.com, Vishwanath Sripathy vishwanath...@ti.com Parthasarathy Basak p-bas...@ti.com Anand Sawant saw...@ti.com This patch series is primarily based of pm-sr branch of kevin's PM tree due to it's dependency on the newly introduced opp and voltage layer. On top of this branch I had to apply a few patches to test out dvfs using cpufreq framework. The following are the link to these additional patches. https://patchwork.kernel.org/patch/107876/ This patch does not apply directly to the current pm-sr branch, and also had some review comments to be addressed. http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap- pm.git;a=commit;h=aa14cb9937e67c48f760c99a3c7fb3b2e7f5e623 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap- pm.git;a=commit;h=8f1298921d10789bb2f0a2d56cd3b92d844a1450 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap- pm.git;a=commit;h=10474ce3b07949d791b419aad433590e072e7159 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap- pm.git;a=commit;h=52fd40b873f8cd5aaea2d01d86ef35017c207eba http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap- pm.git;a=commit;h=57a2e45ff4a596a175aba27ae55a2b0d99adc3b5 This looks like the current pm-cpufreq branch. Did you just merge pm-cpufreq or manually apply these? I had to apply the cpufreq patches manually. If I remember correct I posted this series on PM-SR branch with the above mentioned patches applied manually. After this I migrated to latest kernel.org kernel where I again applied some hwmod/device API's, opp layer, cpufreq layer and voltage/sr series patches manually. I will be posting out a new version of voltage/sr layer patches against kernel.org shortly. Can you please make this available using a git tree
RE: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
-Original Message-
From: Cousson, Benoit
Sent: Monday, August 02, 2010 5:41 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com; p...@pwsan.com;
Sripathy, Vishwanath;
Sawant, Anand; Basak, Partha
Subject: Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device
specific set rate and get
rate in device opp structures.
Hi Thara,
On 7/2/2010 12:18 PM, Gopinath, Thara wrote:
This patch extends the device opp structure to contain
info about the voltage domain to which the device belongs to
and to contain pointers to scale the operating rate of the
device. This patch also adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/plat-omap/include/plat/opp.h | 37 +-
arch/arm/plat-omap/opp.c | 47
+---
2 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 893731f..15e1e70 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -16,6 +16,7 @@
#includelinux/err.h
#includelinux/cpufreq.h
+#includelinux/clk.h
#includeplat/common.h
@@ -38,21 +39,45 @@
*/
struct omap_opp_def {
char *hwmod_name;
+ char *vdd_name;
vdd should be an attribute of hwmod. For one hwmod in a soc we will
always have the same vdd.
That will avoid to duplicate information and to have to populate that in
each OPP entry (cf patch 6).
I also do not like the duplication of info in the opp tables. I was not sure
about introducing this in the hwmod layer. I could surely do this for the
vdd name and voltage domain pointer.
unsigned long freq;
unsigned long u_volt;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
We might already discussed that, but why should we store that per OPP?
Cannot we store that per device?
Paul had concerns regarding this. These are not h/w or h/w interface related
info
in any manner. One good point is that even though these pointers are duplicated
in
the init opp tables, during init the device opp tables are built and only one
copy
is maintained. But I agree this does not look too very good.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, August 04, 2010 6:03 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand;
Basak, Partha
Subject: Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device
specific set rate and get
rate in device opp structures.
Thara Gopinath th...@ti.com writes:
This patch extends the device opp structure to contain
info about the voltage domain to which the device belongs to
and to contain pointers to scale the operating rate of the
device. This patch also adds an API in the opp layer that
can be used by the voltage layer to get a list of all the
scalable devices belonging to a particular voltage domain.
This API is to be typically called only once by the voltage
layer per voltage domain instance and the device list should
be stored. This approach makes it easy during dvfs to scale
all the devices associated with a voltage domain and then
scale the voltage domain.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/include/plat/opp.h | 37 +-
arch/arm/plat-omap/opp.c | 47
+---
2 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 893731f..15e1e70 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -16,6 +16,7 @@
#include linux/err.h
#include linux/cpufreq.h
+#include linux/clk.h
#include plat/common.h
@@ -38,21 +39,45 @@
*/
struct omap_opp_def {
char *hwmod_name;
+ char *vdd_name;
unsigned long freq;
unsigned long u_volt;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+
bool enabled;
};
+struct device_opp {
+ struct list_head node;
+ char *vdd_name;
+
+ struct omap_hwmod *oh;
+ struct device *dev;
+ struct omap_volt_domain *volt_domain;
+
+ struct list_head opp_list;
+ u32 opp_count;
+ u32 enabled_opp_count;
+
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+};
I don't like moving the definition of this struct out. This exposes the
implmentation details of the OPP layer that are subject to change.
A quick glance shows you need to access the volt_domain field and the
new function pointers.
The voltage domain should be part of the hwmod as suggested by Benoit,
and an API created to get the voltage domain from the hwmod.
For the get/set rate functions, maybe new OPP layer API should be
created access those functions. opp_[get|set]_rate()?
Yes I could do this.
/*
* Initialization wrapper used to define an OPP.
* To point at the end of a terminator of a list of OPPs,
* use OMAP_OPP_DEF(0, 0, 0)
*/
-#define OMAP_OPP_DEF(_hwmod_name, _enabled, _freq, _uv)\
+#define OMAP_OPP_DEF(_hwmod_name, _vdd_name, _set_rate, _get_rate, \
+ _enabled, _freq, _uv) \
{ \
.hwmod_name = _hwmod_name, \
+ .vdd_name = _vdd_name,\
+ .set_rate = _set_rate,\
+ .get_rate = _get_rate,\
.enabled= _enabled, \
.freq = _freq,\
.u_volt = _uv, \
@@ -77,6 +102,8 @@ struct omap_opp *opp_find_freq_ceil(struct device *dev,
unsigned long *freq);
struct omap_opp *opp_find_voltage(struct device *dev, unsigned long volt);
+struct device_opp *opp_find_dev_opp(struct device *dev);
+
int opp_add(const struct omap_opp_def *opp_def);
int opp_enable(struct omap_opp *opp);
@@ -89,6 +116,9 @@ u8 __deprecated opp_get_opp_id(struct omap_opp *opp);
void opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+
+struct device **opp_init_voltage_params(struct omap_volt_domain
*volt_domain,
+ int *dev_count);
#else
static inline unsigned long opp_get_voltage(const struct omap_opp *opp)
{
@@ -124,6 +154,11 @@ static inline struct omap_opp
*opp_find_freq_ceil(struct omap_opp *oppl,
return ERR_PTR(-EINVAL);
}
+static inline struct device_opp *opp_find_dev_opp(struct device *dev)
+{
+ return ERR_PTR(-EINVAL);
+}
+
static inline struct omap_opp *opp_add(struct omap_opp *oppl,
const struct omap_opp_def *opp_def)
{
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 070ff5b..9bc53e8 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -22,6 +22,7 @@
#include plat/opp_twl_tps.h
#include plat/opp.h
#include plat/omap_device.h
+#include plat/voltage.h
/**
* struct omap_opp - OMAP OPP description
RE: [PM-SR] [PATCH] OMAP: PM: Remove the usage of vdd id's.
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, June 25, 2010 11:56 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PM-SR] [PATCH] OMAP: PM: Remove the usage of vdd id's. Thara Gopinath th...@ti.com writes: This patch removes the usage of vdd and sr id alltogether. This is achieved by introducing a separte voltage domain per VDD and hooking this up with the voltage and smartreflex internal info structure. Any user of voltage or smartreflex layer should call into omap_volt_domain_get to get the voltage domain handle and make use of this to call into the various exported API's. Great, I'm glad to see those gone. Minor comment on naming: In current code, we currently have struct clockdomain *clkdm; struct powerdomain *pwrdm; so, for consistency, I'd suggest using struct voltagedomain *voltdm; instead of this: struct omap_volt_domain *volt_domain; Also, it looks like your 'struct omap_vdd_info' is the real struct that represents a voltage domain. Maybe you're planning this already, but I suggest you get rid of omap_vdd_info and just move all that stuff into the voltagedomain. Again, that will probably create a diff with a ton of renames, so this should just be part of your V2 series. Are you sure? Because omap_vdd_info contains all the internal details about the voltage domains. Do we really want to expose it? IMHO omap_vdd_info should remain as internal structure instead of exposing it out. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] twl4030 reboot workaround
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Rapoport Sent: Friday, July 30, 2010 12:41 AM To: Mikko Rapeli Cc: linux-omap@vger.kernel.org; Turquette, Mike; sa...@linux.intel.com Subject: Re: [PATCH v2] twl4030 reboot workaround Hi On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli ext-mikko.rap...@nokia.com wrote: From: Mikko Rapeli ext-mikko.rap...@nokia.com Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2 Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting in the sleep script being executed on TWL4030. This usually results in VDD1 VDD2 voltage collapse while ROM code is executing, followed by an MPU Watch Dog reset or worse, an irrecoverable hang. I had a similar issue when my system hanged on hard reset when there was a TWL sleep script installed. The workaround I've found was to install the sleep script immediately before entering the suspend state and remove the script on the resume path. If you think that such approach is appropriate I can send a patch. How do you hit the off state(Vdd's at 0 V) in the idle path then? Or do you do this every time in the idle thread also? Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] twl4030 reboot workaround
-Original Message- From: Turquette, Mike Sent: Saturday, July 31, 2010 12:09 AM To: Gopinath, Thara Cc: Mike Rapoport; Mikko Rapeli; linux-omap@vger.kernel.org; sa...@linux.intel.com Subject: Re: [PATCH v2] twl4030 reboot workaround Gopinath, Thara wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike Rapoport Sent: Friday, July 30, 2010 12:41 AM To: Mikko Rapeli Cc: linux-omap@vger.kernel.org; Turquette, Mike; sa...@linux.intel.com Subject: Re: [PATCH v2] twl4030 reboot workaround Hi On Thu, Jul 29, 2010 at 9:41 AM, Mikko Rapeli ext-mikko.rap...@nokia.com wrote: From: Mikko Rapeli ext-mikko.rap...@nokia.com Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2 Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting in the sleep script being executed on TWL4030. This usually results in VDD1 VDD2 voltage collapse while ROM code is executing, followed by an MPU Watch Dog reset or worse, an irrecoverable hang. I had a similar issue when my system hanged on hard reset when there was a TWL sleep script installed. The workaround I've found was to install the sleep script immediately before entering the suspend state and remove the script on the resume path. If you think that such approach is appropriate I can send a patch. How do you hit the off state(Vdd's at 0 V) in the idle path then? Or do you do this every time in the idle thread also? I do not think it is appropriate to add/remove the sleep script before/after every OFF mode case. The script should be programmed once and left alone EXCEPT in the case of warm reset. If there are other corner cases where SYS_OFFMODE goes low, then we should cover those with similar fixes to the warm reset fix, but in general I think the policy should be to leave the scripts alone once programmed Dynamically programming/removing the scripts around OFF transitions increases software overhead for those transitions even more which is very undesirable. This was exactly my concern. The latency increase due to the dynamic addition and removal of sleep scripts around off transitions might not be justifiable. Maybe Mike does not want to hit 0V for Vdd's in the idle thread in which case it can be acceptable to dynamically add the script in the system suspend path and remove it in the resume path. Else I also do not think this approach is acceptable. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
