Re: [PATCH V4] OMAP3+: SR Layer Cleanup
Hi, On Tue, May 24, 2011 at 5:22 PM, Cousson, Benoit b-cous...@ti.com wrote: On 5/23/2011 6:40 AM, Gulati, Shweta wrote: Benoit, On Fri, May 20, 2011 at 7:19 PM, Cousson, Benoitb-cous...@ti.com wrote: Hi Shweta, On 5/13/2011 8:27 AM, Gulati, Shweta wrote: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulatishweta.gul...@ti.com Acked by: Nishanth Menonn...@ti.com Cc: Benoit Coussonb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com --- V4: Fixed comments like checking for NULL pointers and following conventions in naming the instances recommended by Todd Poynor and Benoit Cousson. It looks like you missed at least two comments I did on the previous version whereas you did agree to fix them. You told me to move smartrefex__dev_attr above omap44xx_smartreflex_XXX_hwmod struct, Just before the struct which is not the case. Ok will do , just above that struct. which is already in that order and the other thing you suggested was to move .dev_attr before .slaves, that I have not done explaining that, to follow the standard as in all defined hwmod struct .dev_attr are placed after .slaves. Could you give some example in the OMAP4 data file? Benoit, I checked in OMAP3 data file, So it that in OMAP3 and OMAP4 data file the order should be different, what do you suggest? In the generic form, you should have opt_clk attribute then dev_attr then .slaves. Anyway, do not say you will fix something if you decide not to fix them after. Or in case of valid concern, please provide some explanation in the cover letter. Benoit, I did send a mail asking for this concern earlier too, Anyways we can decide order for OMAP3 and OMAP 4data files and I would change that in V5. Thanks. Regards, Benoit -- Thanks, Regards, Shweta -- 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] OMAP3+: SR Layer Cleanup
Benoit, On Fri, May 20, 2011 at 7:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Shweta, On 5/13/2011 8:27 AM, Gulati, Shweta wrote: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulatishweta.gul...@ti.com Acked by: Nishanth Menonn...@ti.com Cc: Benoit Coussonb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com --- V4: Fixed comments like checking for NULL pointers and following conventions in naming the instances recommended by Todd Poynor and Benoit Cousson. It looks like you missed at least two comments I did on the previous version whereas you did agree to fix them. You told me to move smartrefex__dev_attr above omap44xx_smartreflex_XXX_hwmod struct, which is already in that order and the other thing you suggested was to move .dev_attr before .slaves, that I have not done explaining that, to follow the standard as in all defined hwmod struct .dev_attr are placed after .slaves. Thanks, Benoit -- Thanks, Regards, Shweta -- 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] OMAP3+: SR Layer Cleanup
Hi, On Thu, May 19, 2011 at 2:29 PM, Kevin Hilman khil...@ti.com wrote: Shweta Gulati shweta.gul...@ti.com writes: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Acked by: Nishanth Menon n...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul p...@pwsan.com As this isn't a consolidation/cleanup, I'm not going to push for 2.6.40, but with an ack from Benoit, I'll queue for 2.6.40+. Also it has some minor conflicts with some other SR cleanups I have queued for 2.6.40+. Please rebase on to my for_2.6.40/pm-misc branch. Ok, I will rebase it to 2.6.40/pm-misc branch. Thanks, Kevin -- Thanks, Regards, Shweta -- 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] OMAP3+: SR Layer Cleanup
Kevin, On Thu, May 12, 2011 at 3:20 PM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Wed, May 11, 2011 at 04:12, Shweta Gulati shweta.gul...@ti.com wrote: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Cc: Nishanth Menon n...@ti.com --- V3: Changed the Subject and Rephrased Commit log as reviewed by Nishanth Menon. V2: Rebased on latest 'pm-wip/voltdm_a' branch. thanks.. actually it applies on voltdm_c branch as well :) Can this be taken as an Ack? if so, Shweta please add an Acked-by from Nishanth in your updated patch. Thanks. might be good if kevin where to roll it up Yes, I'll pick this one up (after Todd's comments are addressed.) I would address all the comments and post updated version soon, thanks. Kevin -- Thanks, Regards, Shweta -- 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] OMAP3+: SR Layer Cleanup
Hi,
On Thu, May 12, 2011 at 5:11 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Shweta,
On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: Nishanth Menonn...@ti.com
---
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
Since this patch is touching some hwmod files, it will be good to Cc Paul
and me. It is far from obvious from the subject that hwmod data are involved
in this patch.
Will do
arch/arm/mach-omap2/smartreflex.h | 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1
Re: [PATCH V3] OMAP3+: SR Layer Cleanup
Hi,
On Thu, May 12, 2011 at 6:19 PM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Thu, May 12, 2011 at 5:11 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Shweta,
On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: Nishanth Menonn...@ti.com
---
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
Since this patch is touching some hwmod files, it will be good to Cc Paul
and me. It is far from obvious from the subject that hwmod data are involved
in this patch.
Will do
arch/arm/mach-omap2/smartreflex.h | 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr
Re: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
Hi, On Tue, May 10, 2011 at 7:12 PM, Avinash.H.M. avinas...@ti.com wrote: On Tue, May 10, 2011 at 04:25:19PM +0530, Gulati, Shweta wrote: Hi, On Sat, May 7, 2011 at 3:19 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 21 Apr 2011, Gulati, Shweta wrote: Yes, but in current code clk_set_rate of dpll3_m2 - 'omap3_core_dpll_m2_set_rate' doesn't update clk.rate, I will submit patch fixing that bug and will make sure that set_rate of all clocks should update clk.rate Ping. Do you plan to post this soon? This should be a trivial patch. Sorry for the delay, I will post today. Hi Shweta , To avoid delay, yesterday posted a patch for the same with your signed off by : http://www.spinics.net/lists/linux-omap/msg50776.html Please verify the patch and if anything is missing, please submit a new patch. Thanks Avinash for posting the Patch on time. I have checked all clk's set_rate, other than 'omap3_dpll3_m2_set_rate' all set_rate APIs update clk rate, so the patch is complete. Acked. thanks , - Avinash - Paul -- Thanks, Regards, Shweta ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Thanks, Regards, Shweta -- 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] OMAP3+: SR Layer Cleanup
Hi,
On Wed, May 11, 2011 at 10:06 PM, Todd Poynor toddpoy...@google.com wrote:
On Wed, May 11, 2011 at 2:12 AM, Shweta Gulati shweta.gul...@ti.com wrote:
...
diff --git a/arch/arm/mach-omap2/sr_device.c
b/arch/arm/mach-omap2/sr_device.c
index 2782d3f..65b2aae 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -82,6 +82,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void
*user)
struct omap_sr_data *sr_data;
struct omap_device *od;
struct omap_volt_data *volt_data;
+ struct omap_sr_dev_attr *sr_dev_attr;
char *name = smartreflex;
static int i;
@@ -92,9 +93,11 @@ static int sr_dev_init(struct omap_hwmod *oh, void
*user)
return -ENOMEM;
}
- if (!oh-vdd_name) {
+ sr_dev_attr = (struct omap_sr_dev_attr *)oh-dev_attr;
+ if (!sr_dev_attr-voltdm_name) {
pr_err(%s: No voltage domain specified for %s.
Suggest if (!sr_dev_attr || !sr_dev_attr-voltdm_name) to catch this error.
Fair enough, Thanks for catching
NULL pointer shouldn't be deferenced.
- Cannot initialize\n, __func__, oh-name);
+ Cannot initialize\n, __func__,
+ sr_dev_attr-voltdm_name);
Should leave the hwmod's oh-name as the pr_err
param, sr_dev_attr-voltdm_name has just been verified bogus.
Fair, will do.
Todd
Thanks for reviewing.
--
Thanks,
Regards,
Shweta
--
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: Added recalculation of clock rate in 'clk_set_rate'
Hi, On Sat, May 7, 2011 at 3:19 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 21 Apr 2011, Gulati, Shweta wrote: Yes, but in current code clk_set_rate of dpll3_m2 - 'omap3_core_dpll_m2_set_rate' doesn't update clk.rate, I will submit patch fixing that bug and will make sure that set_rate of all clocks should update clk.rate Ping. Do you plan to post this soon? This should be a trivial patch. Sorry for the delay, I will post today. - Paul -- Thanks, Regards, Shweta -- 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] OMAP2+: SR Layer Cleanup.
Hi,
On Tue, May 10, 2011 at 5:52 AM, Menon, Nishanth n...@ti.com wrote:
might be a bit late, but seeing that Kevin has'nt picked this up yet,
a couple of cosmetic comments
I think it might be great if it could be folded into one of kevin's patches.
else,
$subject - OMAP3+ and could you drop the .?
Will correct the Subject line
On Fri, Apr 8, 2011 at 01:14, Shweta Gulati shweta.gul...@ti.com wrote:
As a part of Voltage Layer Cleanup Patches,
submitted by Kevin Hilman, Voltage domain
Information is removed from hwmod,
So the patch removes 'vdd_name' info from omap_hwmod
and adds that info into dev_attr as SR code uses vdd_name
to get voltagedomain sructure info.
word wrap cleanup a bit, also please indicate the issue you see if the
patch is not applied.
Would Rephrase the commit log.
Regards,
Nishanth Menon
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
arch/arm/mach-omap2/smartreflex.h | 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.omap_chip =
Re: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
Hi,
On Wed, Apr 20, 2011 at 7:05 PM, Janorkar, Mayuresh ma...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
Sent: Wednesday, April 20, 2011 2:55 PM
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; Gulati, Shweta; Nayak, Rajendra;
Paul Wamsley
Subject: [PATCH] OMAP: Added recalculation of clock rate in 'clk_set_rate'
From: Gulati, Shweta shweta.gul...@ti.com
Core Clk Tree shows incorrect Clk rates at OPP50, as
in commit e07f469d284ca3d1f5dcf5438c22982be98bc071
calling of 'recalc' in API clk_set_rate is unintentionally
removed, because of which clock's tree rates get goofed
up when DVFS happens. This Patch adds recalc API back.
I see that the patch is not adding API back.
It is adding a call to the API.
Will Modify Commit message.
Tested on OMAP3630 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Wamsley p...@pwsan.com
---
arch/arm/plat-omap/clock.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..5a0d06b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -130,8 +130,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
spin_lock_irqsave(clockfw_lock, flags);
ret = arch_clock-clk_set_rate(clk, rate);
- if (ret == 0)
+ if (ret == 0) {
checking if (!ret) is an intelligent way.
But it is an individual's choice.
It doesn't make much difference.
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
propagate_rate(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
--
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
--
Thanks,
Regards,
Shweta
--
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: Added recalculation of clock rate in 'clk_set_rate'
Hi, On Wed, Apr 20, 2011 at 9:12 PM, Sergei Shtylyov sshtyl...@mvista.com wrote: Hello. On 20-04-2011 13:25, Shweta Gulati wrote: From: Gulati, Shwetashweta.gul...@ti.com Core Clk Tree shows incorrect Clk rates at OPP50, as in commit e07f469d284ca3d1f5dcf5438c22982be98bc071 Please also specify that commit's summary -- for human readers. Will do. calling of 'recalc' in API clk_set_rate is unintentionally removed, because of which clock's tree rates get goofed up when DVFS happens. This Patch adds recalc API back. Tested on OMAP3630 SDP Board. Signed-off-by: Shweta Gulatishweta.gul...@ti.com Cc: Rajendra Nayakrna...@ti.com Cc: Paul Wamsleyp...@pwsan.com WBR, Sergei -- Thanks, Regards, Shweta -- 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: Added recalculation of clock rate in 'clk_set_rate'
Hi,
On Thu, Apr 21, 2011 at 1:25 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 20 Apr 2011, Shweta Gulati wrote:
From: Gulati, Shweta shweta.gul...@ti.com
Core Clk Tree shows incorrect Clk rates at OPP50, as
in commit e07f469d284ca3d1f5dcf5438c22982be98bc071
calling of 'recalc' in API clk_set_rate is unintentionally
removed,
That's intentional. struct clk.set_rate functions need to set the struct
clk.rate before returning. If they don't do that, it's a bug in the
struct clk's .set_rate function.
Yes, but in current code clk_set_rate of dpll3_m2 -
'omap3_core_dpll_m2_set_rate'
doesn't update clk.rate, I will submit patch fixing that bug and will
make sure that
set_rate of all clocks should update clk.rate
because of which clock's tree rates get goofed up when DVFS happens.
Clearly this isn't on the mainline kernel...
If you check for OPP50, the core clocks would show wrong rates.
Thanks for reviewing.
This Patch adds recalc API back.
Tested on OMAP3630 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Wamsley p...@pwsan.com
---
arch/arm/plat-omap/clock.c | 5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index c9122dd..5a0d06b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -130,8 +130,11 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
spin_lock_irqsave(clockfw_lock, flags);
ret = arch_clock-clk_set_rate(clk, rate);
- if (ret == 0)
+ if (ret == 0) {
+ if (clk-recalc)
+ clk-rate = clk-recalc(clk);
propagate_rate(clk);
+ }
spin_unlock_irqrestore(clockfw_lock, flags);
return ret;
--
1.7.0.4
- Paul
--
Thanks,
Regards,
Shweta
--
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] OMAP2+: SR Layer Cleanup.
Hi, On Wed, Apr 6, 2011 at 9:03 PM, Kevin Hilman khil...@ti.com wrote: Hi Shweta, Shweta Gulati shweta.gul...@ti.com writes: As a part of Voltage Layer Cleanup Patches, submitted by Kevin Hilman, Voltage domain Information is removed from hwmod, So the patch removes 'vdd_name' info from omap_hwmod and adds that info into dev_attr as SR code uses vdd_name to get voltagedomain sructure info. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Thanks for this. It looks good. --- It apllies over Voltage Layer Cleanup Patch by Kevin Hilman: https://patchwork.kernel.org/patch/657421/ Can you rebase on top of my pm-wip/voltdm_a branch? It currently doesn't apply there because the some of the voltage domain names were changed, e.g. mpu - mpu_iva, wkup - wakeup. Ok, I will do. Thanks. Thanks, Kevin -- Thanks, Regards, Shweta -- 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 v2] OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.
Hi,
On Tue, Apr 5, 2011 at 9:10 PM, Avinash.H.M avinas...@ti.com wrote:
GPIO module expects the debounce clocks to be enabled during reset. It doesn't
reset properly and timeouts are seen, if this clock isn't enabled during
reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
which the debounce clocks are enabled during reset.
Minor comment,
Rephrase as GPIO module doesn't reset properly and timeouts are seen
during bootup, if
debounce clock is not enabled
to make commit log more clear.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 4
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 5 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 6 ++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 82ff5f7..e0bda0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1640,6 +1640,7 @@ static struct omap_hwmod_ocp_if
*omap2420_gpio1_slaves[] = {
static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio1_irqs),
.main_clk = gpios_fck,
@@ -1670,6 +1671,7 @@ static struct omap_hwmod_ocp_if
*omap2420_gpio2_slaves[] = {
static struct omap_hwmod omap2420_gpio2_hwmod = {
.name = gpio2,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio2_irqs),
.main_clk = gpios_fck,
@@ -1700,6 +1702,7 @@ static struct omap_hwmod_ocp_if
*omap2420_gpio3_slaves[] = {
static struct omap_hwmod omap2420_gpio3_hwmod = {
.name = gpio3,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio3_irqs),
.main_clk = gpios_fck,
@@ -1730,6 +1733,7 @@ static struct omap_hwmod_ocp_if
*omap2420_gpio4_slaves[] = {
static struct omap_hwmod omap2420_gpio4_hwmod = {
.name = gpio4,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio4_irqs),
.main_clk = gpios_fck,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index ce292f0..99cd7bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1743,6 +1743,7 @@ static struct omap_hwmod_ocp_if
*omap2430_gpio1_slaves[] = {
static struct omap_hwmod omap2430_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio1_irqs),
.main_clk = gpios_fck,
@@ -1773,6 +1774,7 @@ static struct omap_hwmod_ocp_if
*omap2430_gpio2_slaves[] = {
static struct omap_hwmod omap2430_gpio2_hwmod = {
.name = gpio2,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio2_irqs),
.main_clk = gpios_fck,
@@ -1803,6 +1805,7 @@ static struct omap_hwmod_ocp_if
*omap2430_gpio3_slaves[] = {
static struct omap_hwmod omap2430_gpio3_hwmod = {
.name = gpio3,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio3_irqs),
.main_clk = gpios_fck,
@@ -1833,6 +1836,7 @@ static struct omap_hwmod_ocp_if
*omap2430_gpio4_slaves[] = {
static struct omap_hwmod omap2430_gpio4_hwmod = {
.name = gpio4,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio4_irqs),
.main_clk = gpios_fck,
@@ -1863,6 +1867,7 @@ static struct omap_hwmod_ocp_if
*omap2430_gpio5_slaves[] = {
static struct omap_hwmod omap2430_gpio5_hwmod = {
.name = gpio5,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio5_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio5_irqs),
.main_clk = gpio5_fck,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c74f972..7552b2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++
Re: Smartreflex on 'pm-wip/voltdm' Branch
Hi, On Mon, Mar 28, 2011 at 9:57 PM, Kevin Hilman khil...@ti.com wrote: Vishwa, Shweta, Vishwanath Sripathy vishwanath...@ti.com writes: [...] I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems an issue with reading VP registers. For OMAP3 and OMAP4 reading debugfs entries shows constant voltage. Thanks for testing. [...] I did a quick debug on this and found that the root cause of the issue is in usage of ffs (because of this, i2c slave address was configured wrongly in vc). Basically ffs returns the position of the first (least significant) bit set in the word and the least significant bit is position 1 where as our bit operation assumes that least significant position is 0. Vishwa, Thanks for findingg this. Indeed, I had assumed ffs() was zero based, but it is 1 based. I tested the attached patch on OMAP3 and it seems to work fine. Attached, is Patch which fixes the Issue, It works Fine for OMAP3 and OMAP4 SDP boards. Kevin, You may want to incorporate this change in your next version if this seems OK to you. Yes, I will fix this in forthcoming versions. Thanks, Kevin -- Thanks, Regards, Shweta 0001-OMAP2-PM-Ensure-Bitshifts-are-calculated-accurately.patch Description: Binary data
Smartreflex on 'pm-wip/voltdm' Branch
Kevin, I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems an issue with reading VP registers. For OMAP3 and OMAP4 reading debugfs entries shows constant voltage. Logs are: OMAP3: # cat /debug/voltage/vdd_mpu_iva/curr_nominal_volt 120 # cat /debug/voltage/vdd_core/curr_nominal_volt 120 # echo 1 /debug/voltage/vdd_mpu_iva/smartreflex/autocomp [ 311.680816] omap_device: smartreflex.0: new worst case activate latency 0: 91552 # echo 1 /debug/voltage/vdd_core/smartreflex/autocomp # cat /debug/voltage/vdd_core/vp/curr_volt 90 # cat /debug/voltage/vdd_mpu_iva/vp/curr_volt 90 OMAP4: # cat /debug/voltage/vdd_core/curr_nominal_volt 120 # cat /debug/voltage/vdd_mpu/curr_nominal_volt 1375000 # cat /debug/voltage/vdd_iva/curr_nominal_volt 1188000 # # echo 1 /debug/voltage/vdd_mpu/smartreflex/autocomp [ 61.514038] omap_device: smartreflex.2: new worst case activate latency 0: 30517 # echo 1 /debug/voltage/vdd_core/smartreflex/autocomp # echo 1 /debug/voltage/vdd_mpu/smartreflex/autocomp # # cat /debug/voltage/vdd_iva/curr_nominal_volt 1188000 # cat /debug/voltage/vdd_iva/vp/curr_volt 120 # # echo 1 /debug/voltage/vdd_iva/smartreflex/autocomp # cat /debug/voltage/vdd_iva/vp/curr_volt 812500 # # cat /debug/voltage/vdd_mpu/vp/curr_volt 812500 # cat /debug/voltage/vdd_core/vp/curr_volt 812500 # This Issue is not reproduced on 'pm-core' branch, seems in the voltage Layer Clean up Patches somewhere some thing is goofed up. Thanks, Regards, Shweta -- 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/7] OMAP2+: hwmod: remove unused voltagedomain pointer
Kevin,
On Mon, Mar 21, 2011 at 9:02 PM, Kevin Hilman khil...@ti.com wrote:
Cousson, Benoit b-cous...@ti.com writes:
Hi Kevin,
On 3/19/2011 1:18 AM, Hilman, Kevin wrote:
The voltage domain pointer currently in struct omap_hwmod is not used
and does not belong here. Instead, voltage domains will be associated
with powerdomains in forthcoming patches.
Technically speaking, an IP, and thus the hwmod does belong to a
voltage domain, a power domain and a clock domain.
What is maybe important to add is that since clkdm pwrdm voltdm,
we can potentially avoid providing the information for the each domain
type.
At some point the hwmod will have to contain a clkdm instead of
relying on the main_clk to get it... but that's another topic...
Signed-off-by: Kevin Hilmankhil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..a5fa7c1 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -520,7 +520,6 @@ struct omap_hwmod {
struct clk *_clk;
struct omap_hwmod_opt_clk *opt_clks;
char *vdd_name;
And what about vdd_name? It should probably be removed as well.
Yes, but it's currently used by the SR layer (currently the only user.)
Removing it required cleaning up the SR layer as well, so I decided to
leave the SR cleanups for someone else for the moment while I focus on
the voltage layer(s)
Even if we try to remove 'vdd_name', how should we get 'struct voltagedomain'
info corresponding to sr_mpu, sr_core in sr_dev_init API?
As functional clock of SR1 and SR2 are from
wake up domain, so even if we try to use current Clockdomain and
Powerdomain framework
APIs, to get 'clkdomain' pointer and then retrieve 'pwrdomain'
pointer, finally getting 'voltdomain'
pointer we would get 'WKUP' voltage domain ptr not the 'mpu' or 'core'
voltdomain pointer.
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
--
Thanks,
Regards,
Shweta
--
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/7] OMAP2+: hwmod: remove unused voltagedomain pointer
Hi, On Thu, Mar 24, 2011 at 8:44 PM, Cousson, Benoit b-cous...@ti.com wrote: On 3/24/2011 3:00 PM, Hilman, Kevin wrote: Hi Shweta, Gulati, Shwetashweta.gul...@ti.com writes: [...] And what about vdd_name? It should probably be removed as well. Yes, but it's currently used by the SR layer (currently the only user.) Removing it required cleaning up the SR layer as well, so I decided to leave the SR cleanups for someone else for the moment while I focus on the voltage layer(s) Even if we try to remove 'vdd_name', how should we get 'struct voltagedomain' info corresponding to sr_mpu, sr_core in sr_dev_init API? As functional clock of SR1 and SR2 are from wake up domain, so even if we try to use current Clockdomain and Powerdomain framework APIs, to get 'clkdomain' pointer and then retrieve 'pwrdomain' pointer, finally getting 'voltdomain' pointer we would get 'WKUP' voltage domain ptr not the 'mpu' or 'core' voltdomain pointer. Correct. I got this far and realized not only does the voltage layer need a cleanup, the SR layer needs a cleanup, but I need to focus on one thing at a time. As you noticed, what we need is the voltage domain of the SR sensor, not the voltage domain of the SR IP. Probably the best way to do this is ad the sensor voltage domain to the dev_attr of each SR module. Yep, I do agree. SR instances are all inside the CORE, but there is a dedicated sensor in each scalable voltage domain. dev_attr is the perfect place for that. In fact I do not understand why it was not added there initially??? Even the kerneldoc is confusing and not accurate: * @vdd_name: voltage domain name Whereas, SR is using that to provide the name of the voltage rail controlled by it. Let's provide a quick patch to get rid of that and replace it by a dev_attr. Shweta, are you volunteer? :-) Yes, I would submit Patch adding volt domain info in dev_attr of SR instances. Thanks, Benoit -- Thanks, Regards, Shweta -- 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: Add IVA OPP enteries with Updated Voltage Rail Values.
Hi, On Thu, Mar 3, 2011 at 8:11 PM, Nishanth Menon n...@ti.com wrote: Gulati, Shweta wrote, on 03/03/2011 07:37 PM: Hi, On Thu, Mar 3, 2011 at 3:53 PM, Menon, Nishanthn...@ti.com wrote: On Thu, Mar 3, 2011 at 15:39, Gulati, Shwetashweta.gul...@ti.com wrote: Hi, On Thu, Mar 3, 2011 at 3:04 PM, Menon, Nishanthn...@ti.com wrote: On Thu, Mar 3, 2011 at 14:57, Shweta Gulatishweta.gul...@ti.com wrote: This Patch adds OPP enteries for IVA in OMAP4 OPP Table and updates IVA voltage Rail values obtained from latest OMAP4430 Data Manual Operating Condition Addendum. Do you think we should add the version of the document in the commit message - it looks like every latest version we look at has some update, so we'd know what baseline the code currently maps to when we do a git blame at a later point of time Ok, Will do. Sorry, one more tiny point I missed - for the sake of ensuring the functional bisectability - could you do the following: a) update voltages (MPU,IVA) for doc 0.3 b) introduce IVA OPPs what do you think? I think its better to submit MPU and IVA domain Patches seperately The way I have done: 1. Patch Series that has MPU OPP Table and Voltage Rail Value changes. 2. Patch which adds IVA OPP Entries and updates Voltage Rail values. Thank you, but I had already understood what had been done. I was wondering if there is a reason why not we do: a) voltage updates on the code we already have - this categorizes as a fix b) introduce OPP entries for IVA - this in a way categorizes as a feature addition Ok, will do this way, rebasing all the patches to pm-core branch and including all comments received and putting features and fixes in different patches of a new series.Thanks. -- Regards, Nishanth Menon -- Thanks, Regards, Shweta -- 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 3/3] OMAP4: Enable Turbo and Nitro OPP for OMAP4
Hi,
On Wed, Mar 2, 2011 at 9:24 PM, Kevin Hilman khil...@ti.com wrote:
Menon, Nishanth n...@ti.com writes:
On Wed, Feb 16, 2011 at 11:48, Shweta Gulati shweta.gul...@ti.com wrote:
All OMAP4 boards support OPP-Turbo (800M) and OPP-Nitro (1G).
s/All OMAP4/Almost all/ - there are a minority of boards that use
OMAP4430-800 device instead of the OMAP4430-1000 device.
Also please use the full term 1GHz instead of 1G
Ok, Will do.
Enable them by default in OPPTable. For 800Mhz devices where
s/For 800Mhz/For the small minority of boards which use OMAP4430-800
(800MHz device),
OPP-Nitro is not supported, OPP-Nitro should be disabled
from board file.
Will do.
even though the TI documentation terminology is Turbo, Nitro etc.., I
suggest using frequencies to better map things historically.
I agree, IMO the Turbo Nitro names are useless.
Ok, Will Post V2.
Kevin
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/opp4xxx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 705fe9a..48d79e5 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -31,9 +31,9 @@ static struct omap_opp_def __initdata
omap44xx_opp_def_list[] = {
/* MPU OPP2 - OPP100 */
OPP_INITIALIZER(mpu, true, 6, OMAP4430_VDD_MPU_OPP100_UV),
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8,
OMAP4430_VDD_MPU_OPPTURBO_UV),
+ OPP_INITIALIZER(mpu, true, 8,
OMAP4430_VDD_MPU_OPPTURBO_UV),
/* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 100800,
OMAP4430_VDD_MPU_OPPNITRO_UV),
+ OPP_INITIALIZER(mpu, true, 100800,
OMAP4430_VDD_MPU_OPPNITRO_UV),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4430_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
1.7.0.4
I am ok with the overall patch - with the minor suggestions above.
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
--
Thanks,
Regards,
Shweta
--
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: Add IVA OPP enteries with Updated Voltage Rail Values.
Hi,
On Thu, Mar 3, 2011 at 3:04 PM, Menon, Nishanth n...@ti.com wrote:
On Thu, Mar 3, 2011 at 14:57, Shweta Gulati shweta.gul...@ti.com wrote:
This Patch adds OPP enteries for IVA in OMAP4 OPP Table
and updates IVA voltage Rail values obtained from latest
OMAP4430 Data Manual Operating Condition Addendum.
Do you think we should add the version of the document in the commit
message - it looks like every latest version we look at has some
update, so we'd know what baseline the code currently maps to when we
do a git blame at a later point of time
Ok, Will do.
Regards,
Nishanth Menon
Tested on OMAP4430 SDP Board.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/opp4xxx_data.c | 8 +++-
arch/arm/plat-omap/include/plat/voltage.h | 6 +++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 48d79e5..3e0fbdc 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -38,7 +38,13 @@ static struct omap_opp_def __initdata
omap44xx_opp_def_list[] = {
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4430_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
OPP_INITIALIZER(l3_main_1, true, 2,
OMAP4430_VDD_CORE_OPP100_UV),
- /* TODO: add IVA, DSP, aess, fdif, gpu */
+ /* IVA OPP1 - OPP50 */
+ OPP_INITIALIZER(iva, true, 13300, OMAP4430_VDD_IVA_OPP50_UV),
+ /* IVA OPP2 - OPP100 */
+ OPP_INITIALIZER(iva, true, 26610, OMAP4430_VDD_IVA_OPP100_UV),
+ /* IVA OPP3 - OPP-Turbo */
+ OPP_INITIALIZER(iva, false, 33200,
OMAP4430_VDD_IVA_OPPTURBO_UV),
+ /* TODO: add DSP, aess, fdif, gpu */
};
/**
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/plat-omap/include/plat/voltage.h
index 4d9bab1..27555ce 100644
--- a/arch/arm/plat-omap/include/plat/voltage.h
+++ b/arch/arm/plat-omap/include/plat/voltage.h
@@ -51,9 +51,9 @@
#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
-#define OMAP4430_VDD_IVA_OPP50_UV 93
-#define OMAP4430_VDD_IVA_OPP100_UV 110
-#define OMAP4430_VDD_IVA_OPPTURBO_UV 126
+#define OMAP4430_VDD_IVA_OPP50_UV 1013000
+#define OMAP4430_VDD_IVA_OPP100_UV 1188000
+#define OMAP4430_VDD_IVA_OPPTURBO_UV 130
#define OMAP4430_VDD_CORE_OPP50_UV 93
#define OMAP4430_VDD_CORE_OPP100_UV 110
--
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
--
Thanks,
Regards,
Shweta
--
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/3] OMAP4: Revise MPU Voltage rail values.
hi, On Wed, Mar 2, 2011 at 1:02 PM, Menon, Nishanth n...@ti.com wrote: On Wed, Feb 16, 2011 at 11:47, Shweta Gulati shweta.gul...@ti.com wrote: MPU voltage rail values are updated according to latest OMAP4430 Data Manual Operating Condition Addendum. looks like the latest is evolving :(. I just checked against 0.3 of the data manual operating conditions: Version I will add in V2. This patch does the following: MPU: #define OMAP4430_VDD_MPU_OPP50_UV 1025000 #define OMAP4430_VDD_MPU_OPP100_UV 120 #define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000 #define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000 Verified - ok IVA currently: #define OMAP4430_VDD_IVA_OPP50_UV 93 #define OMAP4430_VDD_IVA_OPP100_UV 110 #define OMAP4430_VDD_IVA_OPPTURBO_UV 126 Should be: #define OMAP4430_VDD_IVA_OPP50_UV 1013000 #define OMAP4430_VDD_IVA_OPP100_UV 1188000 #define OMAP4430_VDD_IVA_OPPTURBO_UV 130 Core currently - matches with the values in DM 0.3. #define OMAP4430_VDD_CORE_OPP50_UV 93 #define OMAP4430_VDD_CORE_OPP100_UV 110 Should we just have one patch to update both mpu and iva voltages? IVA OPP Table is not there, I have submitted Patch which adds IVA OPP Table and also updates Voltage Rail values. Regards, Nishanth Menon Signed-off-by: Shweta Gulati shweta.gul...@ti.com --- arch/arm/plat-omap/include/plat/voltage.h | 8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h index 5bd204e..4d9bab1 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -46,10 +46,10 @@ #define OMAP3630_VDD_CORE_OPP50_UV 100 #define OMAP3630_VDD_CORE_OPP100_UV 120 -#define OMAP4430_VDD_MPU_OPP50_UV 93 -#define OMAP4430_VDD_MPU_OPP100_UV 110 -#define OMAP4430_VDD_MPU_OPPTURBO_UV 126 -#define OMAP4430_VDD_MPU_OPPNITRO_UV 135 +#define OMAP4430_VDD_MPU_OPP50_UV 1025000 +#define OMAP4430_VDD_MPU_OPP100_UV 120 +#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000 +#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000 #define OMAP4430_VDD_IVA_OPP50_UV 93 #define OMAP4430_VDD_IVA_OPP100_UV 110 -- 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 -- Thanks, Regards, Shweta -- 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: Add IVA OPP enteries with Updated Voltage Rail Values.
Hi, On Thu, Mar 3, 2011 at 3:53 PM, Menon, Nishanth n...@ti.com wrote: On Thu, Mar 3, 2011 at 15:39, Gulati, Shweta shweta.gul...@ti.com wrote: Hi, On Thu, Mar 3, 2011 at 3:04 PM, Menon, Nishanth n...@ti.com wrote: On Thu, Mar 3, 2011 at 14:57, Shweta Gulati shweta.gul...@ti.com wrote: This Patch adds OPP enteries for IVA in OMAP4 OPP Table and updates IVA voltage Rail values obtained from latest OMAP4430 Data Manual Operating Condition Addendum. Do you think we should add the version of the document in the commit message - it looks like every latest version we look at has some update, so we'd know what baseline the code currently maps to when we do a git blame at a later point of time Ok, Will do. Sorry, one more tiny point I missed - for the sake of ensuring the functional bisectability - could you do the following: a) update voltages (MPU,IVA) for doc 0.3 b) introduce IVA OPPs what do you think? I think its better to submit MPU and IVA domain Patches seperately The way I have done: 1. Patch Series that has MPU OPP Table and Voltage Rail Value changes. 2. Patch which adds IVA OPP Entries and updates Voltage Rail values. Regards, Nishanth Menon -- Thanks, Regards, Shweta -- 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 4/4] OMAP: Voltage: Adaptive Body-Bias handlers
Hi,
On Tue, Mar 1, 2011 at 11:00 PM, Turquette, Mike mturque...@ti.com wrote:
On Mon, Feb 28, 2011 at 3:35 AM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Tue, Feb 22, 2011 at 1:17 AM, Turquette, Mike mturque...@ti.com wrote:
On Mon, Feb 21, 2011 at 4:31 AM, Gulati, Shweta shweta.gul...@ti.com
wrote:
Hi,
On Fri, Feb 18, 2011 at 2:50 PM, Mike Turquette mturque...@ti.com wrote:
Introduce voltage transition notification handlers for Adaptive Body-Bias
LDOs. There is an ABB LDO for VDD_MPU on OMAP3630 and an ABB_LDO on
VDD_MPU
and VDD_IVA on OMAP4430.
All of these LDOs are handled similary. Initial configuration is to
enable
the possibility of going into Forward Body-Bias (which boosts voltage at
high OPPs). This feature was designed for weak silicon, and eFuse values
exist to control whether or not this feature should be turned on. However
recommendations from hardware folks always say to leave it on regardless
of
eFuse values, so we don't bother checking them. For all other OPPs the
LDO
is in bypass and will follow the voltage of it's corresponding VDD_xxx.
Reverse Body-Bias exists but we never use this in practice (for saving
power
on strongly characterised silicon).
Would RBB be never enabled in future for any of the OPPs or any platforms
that way SLOW_OPP should also be added in OPP types
Will do this in next version. RBB is a possibility.
Upon a DVFS transition the notifiers handle the sequencing of voltage
scaling and ABB LDO transitions. When moving to a higher OPP that needs
FBB, raise voltage first and then enable FBB. When moving down to an OPP
that bypasses ABB, first bypass the LDO then lower voltage.
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/voltage.c | 379
-
arch/arm/plat-omap/include/plat/voltage.h | 6 +-
2 files changed, 370 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6ede092..644a45f 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -43,6 +43,16 @@
#define FAST_OPP 0x1
#define NOMINAL_OPP 0x0
+/* prototypes used by ABB function pointers */
+static int omap_abb_notify_voltage(struct notifier_block *nb,
+ unsigned long val, void *data);
+
+static int omap3_abb_configure(struct omap_abb_info *abb);
+static int omap3_abb_set_opp(struct omap_abb_info *abb, int opp_type);
+
+static int omap4_abb_configure(struct omap_abb_info *abb);
+static int omap4_abb_set_opp(struct omap_abb_info *abb, int opp_type);
+
static struct omap_vdd_info *vdd_info;
/*
* Number of scalable voltage domains.
@@ -70,9 +80,11 @@ static struct omap_vdd_info omap3_vdd_info[] = {
= OMAP3_PRM_IRQSTATUS_MPU_OFFSET,
.done_st_shift =
OMAP3630_ABB_LDO_TRANXDONE_ST_SHIFT,
.done_st_mask =
OMAP3630_ABB_LDO_TRANXDONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap3_abb_configure,
+ .set_opp = omap3_abb_set_opp,
},
},
{
@@ -113,9 +125,11 @@ static struct omap_vdd_info omap4_vdd_info[] = {
= OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
.done_st_shift = OMAP4430_ABB_MPU_DONE_ST_SHIFT,
.done_st_mask = OMAP4430_ABB_MPU_DONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap4_abb_configure,
+ .set_opp = omap4_abb_set_opp,
},
},
{
@@ -137,9 +151,11 @@ static struct omap_vdd_info omap4_vdd_info[] = {
= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.done_st_shift = OMAP4430_ABB_IVA_DONE_ST_SHIFT,
.done_st_mask = OMAP4430_ABB_IVA_DONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap4_abb_configure,
+ .set_opp = omap4_abb_set_opp
Re: [PATCH 18/19] omap3630+: sr: add support for class 1.5
Hi, On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote: Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are: * Class 0 - Product test calibration Silicon is calibration at production floor and fused with voltages for each OPP * Class 1 - Boot time calibration Silicon is calibrated once at boot time and voltages are stored for the lifetime of operation. * Class 2 - continuous s/w calibration SR module notifies s/w for any change in the system which is desired and the s/w makes runtime decisions in terms of setting the voltage, this mechanism could be used in the system which does not have PMIC capable of SR without using the voltage controller and voltage processor blocks. * Class 3 - continuous h/w calibration SR module is switch on after reaching a voltage level and SR continuously monitors the system and makes runtime adjustments without s/w involvement. OMAP3430 has used SmartReflex AVS and with a a PMIC which understands the SR protocol, Class 3 has been used. With OMAP3630 onwards, a new SmartReflex AVS class of operation Class 1.5 was introduced. * Class 1.5 - periodic s/w calibration This uses the h/w calibration loop and at the end of calibration stores the voltages to be used run time, periodic recalibration is performed as well. The operational mode is describes as the following: * SmartReflex AVS h/w calibration loop is essential to identify the optimal voltage for a given OPP. * Once this optimal voltage is detected, SmartReflex AVS loop is disabled in class 1.5 mode of operation. * Until there is a need for a recalibration, any further transition to an OPP voltage which is calibrated can use the calibrated voltage and does not require enabling the SR AVS h/w loop. * On a periodic basis (recommendation being once approximately every 24 hours), software is expected to perform a recalibration to find a new optimal voltage which is compensated for device aging. - For performing this recalibration, the start voltage does not need to be the nominal voltage anymore. instead, the system can start with a voltage which is 50mV higher than the previously calibrated voltage to identify the new optimal voltage as the aging factor within a period of 1 day is not going to be anywhere close to 50mV. - This new starting point for recalibration is called a dynamic nominal voltage for that voltage point. In short, with the introduction of SmartReflex class 1.5, there are three new voltages possible in a system's dvfs transition: * Nominal Voltage - The maximum voltage needed for a worst possible device in the worst possible conditions. This is the voltage we choose as the starting point for the h/w loop to optimize for the first time calibration on system bootup. * Dynamic Nominal Voltage - Worst case voltage for a specific device in considering the system aging on the worst process device. * Calibrated Voltage - Best voltage for the current device at a given point of time. In terms of the implementation, doing calibration involves waiting for the smartreflex h/w loop to settle down, and doing this as part of the dvfs flow itself is to increase the latency of dvfs transition when there is a need to calibrate that opp. instead, the calibration is performed out of path using a workqueue statemachine. The workqueue waits for the system stabilization, then enables VP interrupts to monitor for system instability interms of voltage oscillations that are reported back to the system as interrupts, in case of prolonged system oscillations, nominal voltage is chosen as a safe voltage and this event is logged in the system log for developer debug and fixing. For the recalibration, a common workqueue for all domains is started at the start of the class initialization and it resets the calibrated voltages on a periodic basis. For distros that may choose not to do the recommended periodic recalibration, instead choose to perform boot time calibration, kconfig configuration option is provided to do so. TODO: a) Cpuidle and suspend paths are not integrated with SmartReflex driver at this point. b) Since the SR registers are accessed and controlled in parallel to DVFS some sort of mechanism is necessary to be introduced along with OMAP dvfs layer to ensure mutual exclusivity c) Additional debug interfaces for vmin analysis for platform characterization and addition of system margin needs to be introduced from smartreflex perspective. This implementation also includes the following contributors: Tony Lindgren for suggestion on using interrupt based mechanism instead of polling to detect voltage oscillations. Peter 'p2' De Schrijver for debating alternatives on recalibration
Re: [PATCH 18/19] omap3630+: sr: add support for class 1.5
Hi, On Tue, Mar 1, 2011 at 3:47 PM, Menon, Nishanth n...@ti.com wrote: On Tue, Mar 1, 2011 at 15:23, Gulati, Shweta shweta.gul...@ti.com wrote: Hi, On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote: Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are: * Class 0 - Product test calibration Silicon is calibration at production floor and fused with voltages for each OPP * Class 1 - Boot time calibration Silicon is calibrated once at boot time and voltages are stored for the lifetime of operation. * Class 2 - continuous s/w calibration SR module notifies s/w for any change in the system which is desired and the s/w makes runtime decisions in terms of setting the voltage, this mechanism could be used in the system which does not have PMIC capable of SR without using the voltage controller and voltage processor blocks. * Class 3 - continuous h/w calibration SR module is switch on after reaching a voltage level and SR continuously monitors the system and makes runtime adjustments without s/w involvement. OMAP3430 has used SmartReflex AVS and with a a PMIC which understands the SR protocol, Class 3 has been used. With OMAP3630 onwards, a new SmartReflex AVS class of operation Class 1.5 was introduced. * Class 1.5 - periodic s/w calibration This uses the h/w calibration loop and at the end of calibration stores the voltages to be used run time, periodic recalibration is performed as well. The operational mode is describes as the following: * SmartReflex AVS h/w calibration loop is essential to identify the optimal voltage for a given OPP. * Once this optimal voltage is detected, SmartReflex AVS loop is disabled in class 1.5 mode of operation. * Until there is a need for a recalibration, any further transition to an OPP voltage which is calibrated can use the calibrated voltage and does not require enabling the SR AVS h/w loop. * On a periodic basis (recommendation being once approximately every 24 hours), software is expected to perform a recalibration to find a new optimal voltage which is compensated for device aging. - For performing this recalibration, the start voltage does not need to be the nominal voltage anymore. instead, the system can start with a voltage which is 50mV higher than the previously calibrated voltage to identify the new optimal voltage as the aging factor within a period of 1 day is not going to be anywhere close to 50mV. - This new starting point for recalibration is called a dynamic nominal voltage for that voltage point. In short, with the introduction of SmartReflex class 1.5, there are three new voltages possible in a system's dvfs transition: * Nominal Voltage - The maximum voltage needed for a worst possible device in the worst possible conditions. This is the voltage we choose as the starting point for the h/w loop to optimize for the first time calibration on system bootup. * Dynamic Nominal Voltage - Worst case voltage for a specific device in considering the system aging on the worst process device. * Calibrated Voltage - Best voltage for the current device at a given point of time. In terms of the implementation, doing calibration involves waiting for the smartreflex h/w loop to settle down, and doing this as part of the dvfs flow itself is to increase the latency of dvfs transition when there is a need to calibrate that opp. instead, the calibration is performed out of path using a workqueue statemachine. The workqueue waits for the system stabilization, then enables VP interrupts to monitor for system instability interms of voltage oscillations that are reported back to the system as interrupts, in case of prolonged system oscillations, nominal voltage is chosen as a safe voltage and this event is logged in the system log for developer debug and fixing. For the recalibration, a common workqueue for all domains is started at the start of the class initialization and it resets the calibrated voltages on a periodic basis. For distros that may choose not to do the recommended periodic recalibration, instead choose to perform boot time calibration, kconfig configuration option is provided to do so. TODO: a) Cpuidle and suspend paths are not integrated with SmartReflex driver at this point. b) Since the SR registers are accessed and controlled in parallel to DVFS some sort of mechanism is necessary to be introduced along with OMAP dvfs layer to ensure mutual exclusivity c) Additional debug interfaces for vmin analysis for platform characterization and addition of system margin needs to be introduced from
Re: [PATCH 4/4] OMAP: Voltage: Adaptive Body-Bias handlers
Hi,
On Tue, Feb 22, 2011 at 1:17 AM, Turquette, Mike mturque...@ti.com wrote:
On Mon, Feb 21, 2011 at 4:31 AM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Fri, Feb 18, 2011 at 2:50 PM, Mike Turquette mturque...@ti.com wrote:
Introduce voltage transition notification handlers for Adaptive Body-Bias
LDOs. There is an ABB LDO for VDD_MPU on OMAP3630 and an ABB_LDO on VDD_MPU
and VDD_IVA on OMAP4430.
All of these LDOs are handled similary. Initial configuration is to enable
the possibility of going into Forward Body-Bias (which boosts voltage at
high OPPs). This feature was designed for weak silicon, and eFuse values
exist to control whether or not this feature should be turned on. However
recommendations from hardware folks always say to leave it on regardless of
eFuse values, so we don't bother checking them. For all other OPPs the LDO
is in bypass and will follow the voltage of it's corresponding VDD_xxx.
Reverse Body-Bias exists but we never use this in practice (for saving power
on strongly characterised silicon).
Would RBB be never enabled in future for any of the OPPs or any platforms
that way SLOW_OPP should also be added in OPP types
Will do this in next version. RBB is a possibility.
Upon a DVFS transition the notifiers handle the sequencing of voltage
scaling and ABB LDO transitions. When moving to a higher OPP that needs
FBB, raise voltage first and then enable FBB. When moving down to an OPP
that bypasses ABB, first bypass the LDO then lower voltage.
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/voltage.c | 379
-
arch/arm/plat-omap/include/plat/voltage.h | 6 +-
2 files changed, 370 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6ede092..644a45f 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -43,6 +43,16 @@
#define FAST_OPP 0x1
#define NOMINAL_OPP 0x0
+/* prototypes used by ABB function pointers */
+static int omap_abb_notify_voltage(struct notifier_block *nb,
+ unsigned long val, void *data);
+
+static int omap3_abb_configure(struct omap_abb_info *abb);
+static int omap3_abb_set_opp(struct omap_abb_info *abb, int opp_type);
+
+static int omap4_abb_configure(struct omap_abb_info *abb);
+static int omap4_abb_set_opp(struct omap_abb_info *abb, int opp_type);
+
static struct omap_vdd_info *vdd_info;
/*
* Number of scalable voltage domains.
@@ -70,9 +80,11 @@ static struct omap_vdd_info omap3_vdd_info[] = {
= OMAP3_PRM_IRQSTATUS_MPU_OFFSET,
.done_st_shift =
OMAP3630_ABB_LDO_TRANXDONE_ST_SHIFT,
.done_st_mask = OMAP3630_ABB_LDO_TRANXDONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap3_abb_configure,
+ .set_opp = omap3_abb_set_opp,
},
},
{
@@ -113,9 +125,11 @@ static struct omap_vdd_info omap4_vdd_info[] = {
= OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
.done_st_shift = OMAP4430_ABB_MPU_DONE_ST_SHIFT,
.done_st_mask = OMAP4430_ABB_MPU_DONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap4_abb_configure,
+ .set_opp = omap4_abb_set_opp,
},
},
{
@@ -137,9 +151,11 @@ static struct omap_vdd_info omap4_vdd_info[] = {
= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.done_st_shift = OMAP4430_ABB_IVA_DONE_ST_SHIFT,
.done_st_mask = OMAP4430_ABB_IVA_DONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap4_abb_configure,
+ .set_opp = omap4_abb_set_opp,
},
},
{
@@ -194,7 +210,7 @@ static struct omap_volt_data
omap36xx_vddmpu_volt_data[] = {
NOMINAL_OPP),
VOLT_DATA_DEFINE
Re: [PATCH 0/3]: Update OPP Table and Voltage Rail Values
Hi, On Wed, Feb 16, 2011 at 11:46 AM, Shweta Gulati shweta.gul...@ti.com wrote: The series mainly does below: OMAP4 only - Update MPU VOltage rail values for all OPPs - Enable OPP-Nitro and OPP-Turbo for all boards OMAP2PLUS -Replace hardcoded Voltage values in OPP Table with Voltage Macros. Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Branch: pm Tested on OMAP4430 SDP, OMAP3630 SDP and OMAP3430 SDP. Shweta Gulati (2): OMAP4: Revise MPU Voltage rail values. OMAP4: Enable Turbo and Nitro OPP for OMAP4 Vishwanath BS (1): OMAP2+: Replace Voltage values with Macros. arch/arm/mach-omap2/opp3xxx_data.c | 47 +++-- arch/arm/mach-omap2/opp4xxx_data.c | 13 arch/arm/plat-omap/include/plat/voltage.h | 8 ++-- 3 files changed, 35 insertions(+), 33 deletions(-) Any Comments on this Patch Series. -- Thanks, Regards, Shweta -- 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 06/19] omap3+: voltage: use volt_data pointer instead values
Hi,
On Thu, Feb 24, 2011 at 10:58 AM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote:
Voltage values can get confusing in meaning with various Smartreflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. Hence pass the volt_data pointers through
the structure. Each voltage domain contains a set of volt_data structs.
Each of those volt_data struct represents a voltage point that is supported
for that domain. Hence, this is a more accurate representation of the
voltage point we are interested in going to, and the actual translation
of this voltage point to the voltage value is done inside the voltage layer
which allows the users of the voltage layer to be blissfully ignorant
of any complexity of the underneath layers.
Volt_data has efuse, Errgain and errminlimit other than nom_volt
How does this data differs in different SR Class implementation which
is why using volt_data is required?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm.c | 3 +-
arch/arm/mach-omap2/smartreflex-class3.c | 3 +-
arch/arm/mach-omap2/voltage.c | 72
+++--
arch/arm/plat-omap/include/plat/voltage.h | 13 -
4 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d5a102c..669998b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -209,7 +209,8 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
goto exit;
}
- omap_voltage_scale_vdd(voltdm, bootup_volt);
+ omap_voltage_scale_vdd(voltdm,
+ omap_voltage_get_voltdata(voltdm, bootup_volt));
return 0;
exit:
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 60e7055..2195668 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -15,7 +15,8 @@
static int sr_class3_enable(struct voltagedomain *voltdm)
{
- unsigned long volt = omap_voltage_get_nom_volt(voltdm);
+ unsigned long volt = omap_get_operation_voltage(
+ omap_voltage_get_nom_volt(voltdm));
if (!volt) {
pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3ee8a80..08f0abf 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -146,14 +146,14 @@ struct omap_vdd_info {
struct vc_reg_info vc_reg;
struct voltagedomain voltdm;
struct dentry *debug_dir;
- u32 curr_volt;
+ struct omap_volt_data *curr_volt;
u16 ocp_mod;
u8 prm_irqst_reg;
bool vp_enabled;
u32 (*read_reg) (u16 mod, u8 offset);
void (*write_reg) (u32 val, u16 mod, u8 offset);
int (*volt_scale) (struct omap_vdd_info *vdd,
- unsigned long target_volt);
+ struct omap_volt_data *target_volt);
};
static struct omap_vdd_info *vdd_info;
@@ -361,13 +361,15 @@ static int vp_volt_debug_get(void *data, u64 *val)
static int nom_volt_debug_get(void *data, u64 *val)
{
struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
+ struct omap_volt_data *volt_data;
if (!vdd) {
pr_warning(Wrong paramater passed\n);
return -EINVAL;
}
+ volt_data = omap_voltage_get_nom_volt(vdd-voltdm);
- *val = omap_voltage_get_nom_volt(vdd-voltdm);
+ *val = volt_data-volt_nominal;
return 0;
}
@@ -382,7 +384,8 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
unsigned long uvdc;
char vsel;
- uvdc = omap_voltage_get_nom_volt(vdd-voltdm);
+ uvdc = omap_get_operation_voltage(
+ omap_voltage_get_nom_volt(vdd-voltdm));
if (!uvdc) {
pr_warning(%s: unable to find current voltage for vdd_%s\n,
__func__, vdd-voltdm.name);
@@ -505,12 +508,18 @@ static void __init vdd_debugfs_init(struct
omap_vdd_info *vdd)
/* Voltage scale and accessory APIs */
static int _pre_volt_scale(struct omap_vdd_info *vdd,
- unsigned long target_volt, u8 *target_vsel, u8 *current_vsel)
+ struct omap_volt_data *target_volt, u8 *target_vsel,
+ u8 *current_vsel)
{
- struct omap_volt_data *volt_data;
u32 vc_cmdval, vp_errgain_val;
u16 vp_mod, vc_mod;
+ if (IS_ERR_OR_NULL(target_volt) || IS_ERR_OR_NULL(vdd) ||
+ !target_vsel || !current_vsel) {
+ pr_err(%s: invalid parms!\n, __func__);
+ return -EINVAL;
+ }
+
/* Check if suffiecient pmic info is available for this vdd
Re: [PATCH 06/19] omap3+: voltage: use volt_data pointer instead values
Hi,
On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote:
Voltage values can get confusing in meaning with various Smartreflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. Hence pass the volt_data pointers through
the structure. Each voltage domain contains a set of volt_data structs.
Each of those volt_data struct represents a voltage point that is supported
for that domain. Hence, this is a more accurate representation of the
voltage point we are interested in going to, and the actual translation
of this voltage point to the voltage value is done inside the voltage layer
which allows the users of the voltage layer to be blissfully ignorant
of any complexity of the underneath layers.
Volt_data has efuse, Errgain and errminlimit other than nom_volt
How does this data differs in different SR Class implementation which
is why using volt_data is required?
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm.c | 3 +-
arch/arm/mach-omap2/smartreflex-class3.c | 3 +-
arch/arm/mach-omap2/voltage.c | 72
+++--
arch/arm/plat-omap/include/plat/voltage.h | 13 -
4 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d5a102c..669998b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -209,7 +209,8 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
goto exit;
}
- omap_voltage_scale_vdd(voltdm, bootup_volt);
+ omap_voltage_scale_vdd(voltdm,
+ omap_voltage_get_voltdata(voltdm, bootup_volt));
return 0;
exit:
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 60e7055..2195668 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -15,7 +15,8 @@
static int sr_class3_enable(struct voltagedomain *voltdm)
{
- unsigned long volt = omap_voltage_get_nom_volt(voltdm);
+ unsigned long volt = omap_get_operation_voltage(
+ omap_voltage_get_nom_volt(voltdm));
if (!volt) {
pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 3ee8a80..08f0abf 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -146,14 +146,14 @@ struct omap_vdd_info {
struct vc_reg_info vc_reg;
struct voltagedomain voltdm;
struct dentry *debug_dir;
- u32 curr_volt;
+ struct omap_volt_data *curr_volt;
u16 ocp_mod;
u8 prm_irqst_reg;
bool vp_enabled;
u32 (*read_reg) (u16 mod, u8 offset);
void (*write_reg) (u32 val, u16 mod, u8 offset);
int (*volt_scale) (struct omap_vdd_info *vdd,
- unsigned long target_volt);
+ struct omap_volt_data *target_volt);
};
static struct omap_vdd_info *vdd_info;
@@ -361,13 +361,15 @@ static int vp_volt_debug_get(void *data, u64 *val)
static int nom_volt_debug_get(void *data, u64 *val)
{
struct omap_vdd_info *vdd = (struct omap_vdd_info *) data;
+ struct omap_volt_data *volt_data;
if (!vdd) {
pr_warning(Wrong paramater passed\n);
return -EINVAL;
}
+ volt_data = omap_voltage_get_nom_volt(vdd-voltdm);
- *val = omap_voltage_get_nom_volt(vdd-voltdm);
+ *val = volt_data-volt_nominal;
return 0;
}
@@ -382,7 +384,8 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
unsigned long uvdc;
char vsel;
- uvdc = omap_voltage_get_nom_volt(vdd-voltdm);
+ uvdc = omap_get_operation_voltage(
+ omap_voltage_get_nom_volt(vdd-voltdm));
if (!uvdc) {
pr_warning(%s: unable to find current voltage for vdd_%s\n,
__func__, vdd-voltdm.name);
@@ -505,12 +508,18 @@ static void __init vdd_debugfs_init(struct
omap_vdd_info *vdd)
/* Voltage scale and accessory APIs */
static int _pre_volt_scale(struct omap_vdd_info *vdd,
- unsigned long target_volt, u8 *target_vsel, u8 *current_vsel)
+ struct omap_volt_data *target_volt, u8 *target_vsel,
+ u8 *current_vsel)
{
- struct omap_volt_data *volt_data;
u32 vc_cmdval, vp_errgain_val;
u16 vp_mod, vc_mod;
+ if (IS_ERR_OR_NULL(target_volt) || IS_ERR_OR_NULL(vdd) ||
+ !target_vsel || !current_vsel) {
+ pr_err(%s: invalid parms!\n, __func__);
+ return -EINVAL;
+ }
+
/* Check if suffiecient pmic info is available for this vdd */
if (!vdd-pmic_info) {
pr_err(%s: Insufficient pmic info to scale the
Re: [PATCH 4/4] OMAP: Voltage: Adaptive Body-Bias handlers
Hi,
On Fri, Feb 18, 2011 at 2:50 PM, Mike Turquette mturque...@ti.com wrote:
Introduce voltage transition notification handlers for Adaptive Body-Bias
LDOs. There is an ABB LDO for VDD_MPU on OMAP3630 and an ABB_LDO on VDD_MPU
and VDD_IVA on OMAP4430.
All of these LDOs are handled similary. Initial configuration is to enable
the possibility of going into Forward Body-Bias (which boosts voltage at
high OPPs). This feature was designed for weak silicon, and eFuse values
exist to control whether or not this feature should be turned on. However
recommendations from hardware folks always say to leave it on regardless of
eFuse values, so we don't bother checking them. For all other OPPs the LDO
is in bypass and will follow the voltage of it's corresponding VDD_xxx.
Reverse Body-Bias exists but we never use this in practice (for saving power
on strongly characterised silicon).
Would RBB be never enabled in future for any of the OPPs or any platforms
that way SLOW_OPP should also be added in OPP types
Upon a DVFS transition the notifiers handle the sequencing of voltage
scaling and ABB LDO transitions. When moving to a higher OPP that needs
FBB, raise voltage first and then enable FBB. When moving down to an OPP
that bypasses ABB, first bypass the LDO then lower voltage.
Signed-off-by: Mike Turquette mturque...@ti.com
---
arch/arm/mach-omap2/voltage.c | 379
-
arch/arm/plat-omap/include/plat/voltage.h | 6 +-
2 files changed, 370 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6ede092..644a45f 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -43,6 +43,16 @@
#define FAST_OPP 0x1
#define NOMINAL_OPP 0x0
+/* prototypes used by ABB function pointers */
+static int omap_abb_notify_voltage(struct notifier_block *nb,
+ unsigned long val, void *data);
+
+static int omap3_abb_configure(struct omap_abb_info *abb);
+static int omap3_abb_set_opp(struct omap_abb_info *abb, int opp_type);
+
+static int omap4_abb_configure(struct omap_abb_info *abb);
+static int omap4_abb_set_opp(struct omap_abb_info *abb, int opp_type);
+
static struct omap_vdd_info *vdd_info;
/*
* Number of scalable voltage domains.
@@ -70,9 +80,11 @@ static struct omap_vdd_info omap3_vdd_info[] = {
= OMAP3_PRM_IRQSTATUS_MPU_OFFSET,
.done_st_shift = OMAP3630_ABB_LDO_TRANXDONE_ST_SHIFT,
.done_st_mask = OMAP3630_ABB_LDO_TRANXDONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap3_abb_configure,
+ .set_opp = omap3_abb_set_opp,
},
},
{
@@ -113,9 +125,11 @@ static struct omap_vdd_info omap4_vdd_info[] = {
= OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
.done_st_shift = OMAP4430_ABB_MPU_DONE_ST_SHIFT,
.done_st_mask = OMAP4430_ABB_MPU_DONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap4_abb_configure,
+ .set_opp = omap4_abb_set_opp,
},
},
{
@@ -137,9 +151,11 @@ static struct omap_vdd_info omap4_vdd_info[] = {
= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.done_st_shift = OMAP4430_ABB_IVA_DONE_ST_SHIFT,
.done_st_mask = OMAP4430_ABB_IVA_DONE_ST_MASK,
- .configure = NULL,
- .nb_handler = NULL,
- .set_opp = NULL,
+ .nb = {
+ .notifier_call = omap_abb_notify_voltage,
+ },
+ .configure = omap4_abb_configure,
+ .set_opp = omap4_abb_set_opp,
},
},
{
@@ -194,7 +210,7 @@ static struct omap_volt_data omap36xx_vddmpu_volt_data[]
= {
NOMINAL_OPP),
VOLT_DATA_DEFINE(OMAP3630_VDD_MPU_OPP100_UV,
OMAP3630_CONTROL_FUSE_OPP100_VDD1, 0xf9, 0x16,
- NOMINAL_OPP),
+ FAST_OPP),
VOLT_DATA_DEFINE(OMAP3630_VDD_MPU_OPP120_UV,
Re: [PATCH 2/3] OMAP: voltage: move plat/voltage.h to mach-omap2/voltage.h
Hi,
On Mon, Feb 21, 2011 at 7:38 AM, Paul Walmsley p...@pwsan.com wrote:
At this point in time, there's no reason for this header file to be in
plat-omap/include/plat/voltage.h. It should not be included by device
drivers, and the code that uses it is currently all under mach-omap2/.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_twl.c | 2 +-
arch/arm/mach-omap2/pm.c | 2 +-
arch/arm/mach-omap2/smartreflex.h | 3 ++-
arch/arm/mach-omap2/sr_device.c | 2 +-
arch/arm/mach-omap2/voltage.c | 3 ++-
arch/arm/mach-omap2/voltage.h | 0
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
7 files changed, 7 insertions(+), 6 deletions(-)
rename arch/arm/{plat-omap/include/plat/voltage.h = mach-omap2/voltage.h}
(100%)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 00e1d2b..ad8c18a 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -18,7 +18,7 @@
#include linux/kernel.h
#include linux/i2c/twl.h
-#include plat/voltage.h
+#include voltage.h
Extra Blank Line
#include pm.h
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d5a102c..4baa674 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -18,8 +18,8 @@
#include plat/omap-pm.h
#include plat/omap_device.h
#include plat/common.h
-#include plat/voltage.h
+#include voltage.h
#include powerdomain.h
#include clockdomain.h
#include pm.h
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 6568c88..5f35b9e 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -21,7 +21,8 @@
#define __ASM_ARM_OMAP_SMARTREFLEX_H
#include linux/platform_device.h
-#include plat/voltage.h
+
+#include voltage.h
/*
* Different Smartreflex IPs version. The v1 is the 65nm version used in
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index a636604..10d3c5e 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -23,9 +23,9 @@
#include linux/io.h
#include plat/omap_device.h
-#include plat/voltage.h
#include smartreflex.h
+#include voltage.h
#include control.h
#include pm.h
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 12be525..3c9bcdc 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -26,7 +26,6 @@
#include linux/slab.h
#include plat/common.h
-#include plat/voltage.h
#include prm-regbits-34xx.h
#include prm-regbits-44xx.h
@@ -35,6 +34,8 @@
#include prminst44xx.h
#include control.h
Extra Blank line
+#include voltage.h
+
#define VP_IDLE_TIMEOUT 200
#define VP_TRANXDONE_TIMEOUT 300
#define VOLTAGE_DIR_SIZE 16
diff --git a/arch/arm/plat-omap/include/plat/voltage.h
b/arch/arm/mach-omap2/voltage.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/voltage.h
rename to arch/arm/mach-omap2/voltage.h
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1eee85a..93beae2 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -34,7 +34,6 @@
#include linux/ioport.h
#include linux/spinlock.h
#include plat/cpu.h
-#include plat/voltage.h
voltage.h is not added.
struct omap_device;
--
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
--
Thanks,
Regards,
Shweta
--
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] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
Jarkko,
On Wed, Feb 16, 2011 at 5:15 PM, Jarkko Nikula jhnik...@gmail.com wrote:
On Wed, 16 Feb 2011 11:22:09 +0530
Gulati, Shweta shweta.gul...@ti.com wrote:
On Tue, Feb 15, 2011 at 8:59 PM, Jarkko Nikula jhnik...@gmail.com wrote:
Probably discussed earlier but would it make more sense to have flag in
struct twl4030_platform_data and to do registers writes in twl-core?
Looks suspicious to have i2c_writes under arch/arm/.
twl_i2c_read/write APIs are used from arch/arm in many board files,
so I think it should not cause any issue.
Not good either e.g. in modularization point of view. I was thinking
something like below. I played safe and let the SR to be enabled only if
the twl4030_power_data.sr_enable is set. I read that Kevin had problems
earlier with 2430SDP if SR was enabled.
Note proof of concept patch only. I omitted the comments and don't do
explicit SR disable and I'd clean up the error paths in twl4030_power_init
a bit before this (e.g. printing error codes). Not sure either is the
twl4030-power.c right place for this or core.
You missed commit log which says that T2 bit is required to enable I2C_SR
path of voltage control it is not at all enabling SR, voltage scale
APIs VPforceupdate/ VCbypass
needs this path to be enabled.
And calling APIs twl_i2c_read/write in driver codebase does n't ensure correct
ordering of flag changes and twl_read/write.
--
Jarkko
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 16422de0..e767b0f 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -92,6 +92,9 @@ static u8 twl4030_start_script_address = 0x2b;
#define OFF_STATE_SHIFT 4
#define OFF_STATE_MASK (0xf OFF_STATE_SHIFT)
+#define TWL4030_DCDC_GLOBAL_CFG PHY_TO_OFF_PM_RECEIVER(0x61)
+#define SMARTREFLEX_ENABLE BIT(3)
+
static u8 res_config_addrs[] = {
[RES_VAUX1] = 0x17,
[RES_VAUX2] = 0x1b,
@@ -510,6 +513,22 @@ int twl4030_remove_script(u8 flags)
return err;
}
+int __init twl4030_sr_enable(void)
+{
+ u8 temp;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ return ret;
+
+ temp |= SMARTREFLEX_ENABLE;
+
+ return twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+}
+
void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
{
int err = 0;
@@ -549,8 +568,15 @@ void __init twl4030_power_init(struct twl4030_power_data
*twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0,
TWL4030_PM_MASTER_PROTECT_KEY);
- if (err)
+ if (err) {
pr_err(TWL4030 Unable to relock registers\n);
+ return;
+ }
+
+ if (twl4030_scripts-sr_enable)
+ err = twl4030_sr_enable();
+ if (err)
+ pr_err(TWL4030 Unable to set smartreflex. %d\n, err);
return;
unlock:
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 61b9609..1f64e3e 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -630,6 +630,7 @@ struct twl4030_power_data {
struct twl4030_script **scripts;
unsigned num;
struct twl4030_resconfig *resource_config;
+ bool sr_enable; /* Smartreflex enable state */
#define TWL4030_RESCONFIG_UNDEF ((u8)-1)
};
--
Thanks,
Regards,
Shweta
--
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] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
Hi,
On Tue, Feb 15, 2011 at 10:00 PM, Vishwanath Sripathy
vishwanath...@ti.com wrote:
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Jarkko Nikula
Sent: Tuesday, February 15, 2011 8:47 PM
To: Shweta Gulati
Cc: Nishanth Menon; Thara Gopinath; linux-omap@vger.kernel.org;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH V4] OMAP3: PM: Set/clear T2 bit for Smartreflex on
TWL
On Tue, 15 Feb 2011 13:28:58 +0530
Shweta Gulati shweta.gul...@ti.com wrote:
This patch is based on LO PM Branch and Smartreflex has been
tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
OMAP2430 SDP.
I saw this was working on N900 (kind of special instrumentation
setup) after enabling /sys/kernel/debug/voltage/[vdd_core |
vdd_mpu]/smartreflex/autocomp. Few comments below.
@@ -269,6 +276,18 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax =
OMAP3630_VP2_VLIMITTO_VDDMAX;
}
...
+ if (!twl_sr_enable_autoinit)
+ omap3_twl_set_sr_bit(true);
...
+int __init omap3_twl_set_sr_bit(bool enable)
+{
+ u8 temp;
+ int ret;
+ if (twl_sr_enable_autoinit)
+ pr_warning(%s: unexpected multiple calls\n, __func__);
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (enable)
+ temp |= SMARTREFLEX_ENABLE;
+ else
+ temp = ~SMARTREFLEX_ENABLE;
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
Would it make more sense to set only the flag here and do the register
writes when omap3_twl_init is executing? Then it's not so strict when
the board code calls this function.
What if board code calls this function after twl_init is executed? Then
you will not clear the bit right?
Intention of this function is to make sure the bit is set/cleared when it
is called.
ompa3_twl_init is called from 'omap2_common_pm_late_init' which is
late_initcall.
So it would be called after board specific initializations are
completed in 'init' process.
vishwa
+ if (!ret) {
+ twl_sr_enable_autoinit = true;
+ return 0;
Should this be twl_sr_enable_autoinit = enable (if going to do
register write here)?
--
Jarkko
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Thanks,
Regards,
Shweta
--
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] OMAP3: PM: Set/clear T2 bit for Smartreflex on TWL
On Tue, Feb 15, 2011 at 8:59 PM, Jarkko Nikula jhnik...@gmail.com wrote: On Tue, 15 Feb 2011 17:16:52 +0200 Jarkko Nikula jhnik...@gmail.com wrote: Would it make more sense to set only the flag here and do the register writes when omap3_twl_init is executing? Then it's not so strict when the board code calls this function. Probably discussed earlier but would it make more sense to have flag in struct twl4030_platform_data and to do registers writes in twl-core? Looks suspicious to have i2c_writes under arch/arm/. twl_i2c_read/write APIs are used from arch/arm in many board files, so I think it should not cause any issue. -- Jarkko -- Thanks, Regards, Shweta -- 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: Fix Memory Leaks in Smartreflex driver.
Any comments on this Patch??
On Tue, Feb 8, 2011 at 5:22 PM, Shweta Gulati shweta.gul...@ti.com wrote:
This Patch frees all the dynamically allocated memory
which couldn't have been released in some error hitting cases.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d7deadf..a904625 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -282,6 +282,7 @@ error:
dev_err(sr_info-pdev-dev, %s: ERROR in registering
interrupt handler. Smartreflex will
not function as desired\n, __func__);
+ kfree(name);
kfree(sr_info);
return ret;
}
@@ -880,7 +881,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
ret = sr_late_init(sr_info);
if (ret) {
pr_warning(%s: Error in SR late init\n, __func__);
- return ret;
+ goto err_release_region;
}
}
@@ -891,14 +892,17 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
* not try to create rest of the debugfs entries.
*/
vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info-voltdm);
- if (!vdd_dbg_dir)
- return -EINVAL;
+ if (!vdd_dbg_dir) {
+ ret = -EINVAL;
+ goto err_release_region;
+ }
dbg_dir = debugfs_create_dir(smartreflex, vdd_dbg_dir);
if (IS_ERR(dbg_dir)) {
dev_err(pdev-dev, %s: Unable to create debugfs directory\n,
__func__);
- return PTR_ERR(dbg_dir);
+ ret = PTR_ERR(dbg_dir);
+ goto err_release_region;
}
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUGO, dbg_dir,
@@ -914,7 +918,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (IS_ERR(nvalue_dir)) {
dev_err(pdev-dev, %s: Unable to create debugfs directory
for n-values\n, __func__);
- return PTR_ERR(nvalue_dir);
+ ret = PTR_ERR(nvalue_dir);
+ goto err_release_region;
}
omap_voltage_get_volttable(sr_info-voltdm, volt_data);
@@ -923,7 +928,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
corresponding vdd vdd_%s. Cannot create debugfs
entries for n-values\n,
__func__, sr_info-voltdm-name);
- return -ENODATA;
+ ret = -ENODATA;
+ goto err_release_region;
}
for (i = 0; i sr_info-nvalue_count; i++) {
--
1.7.0.4
--
Thanks,
Regards,
Shweta
--
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: PM: implement devices wakeup latency constraints APIs
Jean,
On Fri, Feb 11, 2011 at 12:53 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
creating similar APIs at the omap_device and omap_hwmod levels. The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to set and
release the constraints.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.
Based on Vibhore's original patch , adapted to omap_device and
omap_hwmod frameworks.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vibhore Vardhan vvard...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 62 +-
arch/arm/mach-omap2/powerdomain.c | 176
-
arch/arm/mach-omap2/powerdomain.h | 31 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 60 +
arch/arm/plat-omap/include/plat/omap_device.h | 2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
arch/arm/plat-omap/omap-pm-constraints.c | 101 ++-
arch/arm/plat-omap/omap_device.c | 28
8 files changed, 399 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index e282e35..0dc096f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#include plat/clock.h
#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include plat/prcm.h
#include cm2xxx_3xxx.h
@@ -2198,10 +2199,69 @@ ohsps_unlock:
}
/**
+ * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up constraint
+ * @oh: struct omap_hwmod *
+ * @req_oh: struct omap_hwmod *
+ * @t: wakeup latency constraint (us). -1 removes the existing constraint
+ *
+ * Query the powerdomain of @oh to set/release the wake-up constraint
+ *
+ * Returns -EINVAL if @oh or @req_oh have no power domain, or the return
+ * code from the pwrdm function (pwrdm_wakeuplat_set/release_constraint)
+ * of the powerdomain assocated with @oh.
+ */
+int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod *req_oh,
+ struct omap_hwmod *oh, long t)
+{
+ struct device *req_dev;
+ struct platform_device *pdev;
+ struct powerdomain *pwrdm;
+ int ret = 0;
+
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+
+ /* Catch devices with undefined powerdomains */
+ if (!pwrdm) {
You can use IS_ERR macro.
+ pr_err(omap_hwmod: Error: could not find parent
+ powerdomain for %s\n, oh-name);
+ return -EINVAL;
+ }
+
+ pdev = (req_oh-od-pdev);
+ if (pdev == NULL) {
same
+ pr_err(omap_hwmod: Error: pdev not found for oh %s\n,
+ oh-name);
+ return -EINVAL;
+ }
+
+ req_dev = (pdev-dev);
+ if (req_dev == NULL) {
+ pr_err(omap_hwmod: Error: device not found for oh %s\n,
+ oh-name);
+ return -EINVAL;
+ }
+
+ /* Call set/release_constraint for the given pwrdm */
+ if (t == -1) {
+ pr_debug(omap_hwmod: remove max device latency constraint:
+ oh %s, pwrdm %s, req by oh %s\n,
+ oh-name, pwrdm-name, req_oh-name);
+ ret = pwrdm_wakeuplat_release_constraint(pwrdm, req_dev);
+ } else {
+ pr_debug(omap_hwmod: add max device latency constraint:
+ oh %s, t = %ld usec, pwrdm %s, req by oh %s\n,
+ oh-name, t, pwrdm-name, req_oh-name);
+ ret = pwrdm_wakeuplat_set_constraint(pwrdm, req_dev, t);
+ }
+
+ return 0;
What if 'pwrdm_wakeuplat_release_constraint' and '
pwrdm_wakeuplat_set_constraint' APIs fails in some error hitting
cases, then this API
should ideally return 'ret'.
+}
+
+/**
* omap_hwmod_get_context_loss_count - get lost context count
* @oh: struct omap_hwmod *
*
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
* count for this device.
*
* Returns the context loss count of the powerdomain assocated with @oh
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index eaed0df..3ed3bea 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -19,16 +19,19 @@
#include linux/list.h
#include linux/errno.h
#include linux/string.h
+#include linux/slab.h
+
+#include plat/cpu.h
+#include plat/prcm.h
+
#include cm2xxx_3xxx.h
#include prcm44xx.h
#include cm44xx.h
#include prm2xxx_3xxx.h
#include
Re: State of SDP4430 platform
Hi, On Sun, Jan 16, 2011 at 6:39 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: It's probably best if I just quote the boot log, and people see about fixing the masses of WARN_ON()s. Notice that it completely obliterates the early part of the boot log due to the number of WARN_ON()s triggered. Other stuff that shows in this boot log: - There's a couple of complaints about missing clock domains for some clocks - Bunch of regulators are returning errors (is this a problem?) - I2C timeouts which add quite a bit to the boot-time - missing vdd_mpu/vdd_iva? (with additional blank lines emitted) The warning coming as : unable to find boot up OPP for vdd_mpu and unable to find boot up OPP for vdd_iva is due to different OPP definition in voltage layer and OPP layer in current LO codebase. File arch/arm/mach-omap2/opp4xxx_data.c has mismatch in OPP50 and OPP100 voltage levels with those defined in voltage.c. We have discussion going with H/W folks to ensure what voltage level should be used for OPPs(Nominal voltage v/s Max voltage) Once we are finalized on that discussion, we would post patch to fix these warning. Uncompressing Linux... done, booting the kernel. 060768] (warn_slowpath_common+0x0/0x70) from [c006087c] (warn_slowpath_fmt+0x38/0x40) r8:c0359a10 r7: r6:0060 r5: r4: [c0060844] (warn_slowpath_fmt+0x0/0x40) from [c004c84c] (clkdm_clear_all_wkdeps+0x80/0x90) r3:2502 r2:c030688d [c004c7cc] (clkdm_clear_all_wkdeps+0x0/0x90) from [c004cf60] (clkdm_init+0x14c/0x17c) r5:c0359a10 r4:c0359b4c [c004ce14] (clkdm_init+0x0/0x17c) from [c0011758] (omap44xx_clockdomains_init+0x18/0x20) [c0011740] (omap44xx_clockdomains_init+0x0/0x20) from [c000f0b0] (omap2_init_common_infrastructure+0x28/0xa4) [c000f088] (omap2_init_common_infrastructure+0x0/0xa4) from [c0011d78] (omap_4430sdp_init_irq+0x2c/0x54) r4:0001 [c0011d4c] (omap_4430sdp_init_irq+0x0/0x54) from [c000b87c] (init_IRQ+0x1c/0x24) r4:bfff [c000b860] (init_IRQ+0x0/0x24) from [c0008a78] (start_kernel+0x194/0x314) [c00088e4] (start_kernel+0x0/0x314) from [80008040] (0x80008040) r8:8000 r7:c0357c84 r6:c0028678 r5:c0354b70 r4:10c53c7d ---[ end trace 1b75b31a2719ed2d ]--- [ cut here ] WARNING: at /home/rmk/git/linux-2.6-rmk/arch/arm/mach-omap2/prm2xxx_3xxx.h:264 clkdm_clear_all_wkdeps+0x80/0x90() prm: omap2xxx/omap3xxx specific function and not suppose to be used on omap4 Modules linked in: Backtrace: [c003ec64] (dump_backtrace+0x0/0x10c) from [c0288be0] (dump_stack+0x18/0x1c) r7:c0347f08 r6:c004c84c r5:c030684e r4:0108 [c0288bc8] (dump_stack+0x0/0x1c) from [c00607c0] (warn_slowpath_common+0x58/0x70) [c0060768] (warn_slowpath_common+0x0/0x70) from [c006087c] (warn_slowpath_fmt+0x38/0x40) r8:c0359a10 r7: r6:0060 r5: r4: [c0060844] (warn_slowpath_fmt+0x0/0x40) from [c004c84c] (clkdm_clear_all_wkdeps+0x80/0x90) r3:004cff02 r2:c030688d [c004c7cc] (clkdm_clear_all_wkdeps+0x0/0x90) from [c004cf60] (clkdm_init+0x14c/0x17c) r5:c0359a10 r4:c0359b20 [c004ce14] (clkdm_init+0x0/0x17c) from [c0011758] (omap44xx_clockdomains_init+0x18/0x20) [c0011740] (omap44xx_clockdomains_init+0x0/0x20) from [c000f0b0] (omap2_init_common_infrastructure+0x28/0xa4) [c000f088] (omap2_init_common_infrastructure+0x0/0xa4) from [c0011d78] (omap_4430sdp_init_irq+0x2c/0x54) r4:0001 [c0011d4c] (omap_4430sdp_init_irq+0x0/0x54) from [c000b87c] (init_IRQ+0x1c/0x24) r4:bfff [c000b860] (init_IRQ+0x0/0x24) from [c0008a78] (start_kernel+0x194/0x314) [c00088e4] (start_kernel+0x0/0x314) from [80008040] (0x80008040) r8:8000 r7:c0357c84 r6:c0028678 r5:c0354b70 r4:10c53c7d ---[ end trace 1b75b31a2719ed2e ]--- [ cut here ] WARNING: at /home/rmk/git/linux-2.6-rmk/arch/arm/mach-omap2/prm2xxx_3xxx.h:264 clkdm_clear_all_wkdeps+0x80/0x90() prm: omap2xxx/omap3xxx specific function and not suppose to be used on omap4 Modules linked in: Backtrace: [c003ec64] (dump_backtrace+0x0/0x10c) from [c0288be0] (dump_stack+0x18/0x1c) r7:c0347f08 r6:c004c84c r5:c030684e r4:0108 [c0288bc8] (dump_stack+0x0/0x1c) from [c00607c0] (warn_slowpath_common+0x58/0x70) [c0060768] (warn_slowpath_common+0x0/0x70) from [c006087c] (warn_slowpath_fmt+0x38/0x40) r8:c0359a10 r7: r6:0060 r5: r4: [c0060844] (warn_slowpath_fmt+0x0/0x40) from [c004c84c] (clkdm_clear_all_wkdeps+0x80/0x90) r3:0002 r2:c030688d [c004c7cc] (clkdm_clear_all_wkdeps+0x0/0x90) from [c004cf60] (clkdm_init+0x14c/0x17c) r5:c0359a10 r4:c0359af4 [c004ce14] (clkdm_init+0x0/0x17c) from [c0011758] (omap44xx_clockdomains_init+0x18/0x20) [c0011740] (omap44xx_clockdomains_init+0x0/0x20) from [c000f0b0] (omap2_init_common_infrastructure+0x28/0xa4) [c000f088] (omap2_init_common_infrastructure+0x0/0xa4) from [c0011d78] (omap_4430sdp_init_irq+0x2c/0x54) r4:0001 [c0011d4c]
Re: [query] smartreflex: No PMIC hook to init smartreflex
Sanjeev, On Mon, Jan 31, 2011 at 9:50 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] Sent: Thursday, January 27, 2011 7:56 PM To: Menon, Nishanth; Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: RE: [query] smartreflex: No PMIC hook to init smartreflex Nishant, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, January 27, 2011 3:06 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [query] smartreflex: No PMIC hook to init smartreflex Sanjeev, On Tue, Jan 25, 2011 at 20:55, Premi, Sanjeev pr...@ti.com wrote: While building the kernel at 2.6.37, i see this warning for omap3evm - with omap3630: Power Management for TI OMAP3. sr_init: No PMIC hook to init smartreflex -- THIS IS THE WARNING. smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized SmartReflex Class3 initialized In the code, i see this comment: /* * sr_init is a late init. If by then a pmic specific API is not * registered either there is no need for anything to be done on * the PMIC side or somebody has forgotten to register a PMIC * handler. Warn for the second condition. */ if (sr_pmic_data sr_pmic_data-sr_pmic_init) sr_pmic_data-sr_pmic_init(); else pr_warning(%s: No PMIC hook to init smartreflex\n, __func__); But, I couldn't find any place where PMIC is being registered. This is a harmless warning (ideally, we should remove the pr_warning). the intent here is to have hook for pmic_init which could be populated for custom PMICs which may need something additional for Smart reflex enablement. if you look at the sr_pmic_data - it just has a single api for pmic_init e.g. in the case of TWL4030/5030, we might need to set the bit to switch mode from I2C1 to I2C_SR - e.g. the patch from Shweta[1] if Smartreflex AVS was the *only* mechanism in the system, we could have hooked pmic_init to this bit setting. but since the system can do voltage scaling (VP forceupdate/vc bypass) independent of SR AVS block, the patch in [1] does initialization independent of sr_pmic_data-pmic_init which makes sense. in short, my 2cents: the warning is probably something we should remove from the code. As you mentioned, incase of TWL4030/5030, we do not need any hook. However if some other PMIC is used that genuinely needs this hook, then shouldn't SR throw up this warning? As SR module is independent of PMIC, it cannot I possibly see different arguments from your description: 1) This is hook is not needed for TWL4030/5030. But still, still hook is needed for another PMIC. True. struct 'sr_pmic_data' is generic way of handling all Pmic. The pmic needs to register to SR which it does by API 'sr_pmic_init'. Today this API just enables SR bit CFG_ENABLE_SRFLX in TWL PM module registers which is redundant in case of TWL chips as SR bit is already set in 'omap_twl_init' API in file omap_twl.c But in future if this API 'sr_pmic_init' has some other functionality or in case when Pmic is not TWL family chip then the initialization done by 'sr_pmic_init' is necessary. 2) It is okay to warn user for non-existent hook that is not really needed... in hope that there could be a different PMIC. 3) Despite saying that SR is independent of PMIC, we assume it as default and don't go thru the plugin route. Something seems to be missing in the argument. I haven't been able to spend more time on this since last mail (also reason for late response); but: 1) When user adds the hook - for different PMIC, this warning/info would go away. But not for current default systems. If some other PMIC is registered then ideally this warning shouldn't come and if it comes it hampers SR role but for TWL4030/TWL5030 this warning is harmless. 2) By keeping TWL4030 as default, we are possibly not telling the person keen on replacing the PMIC what should be done? If SR is really PMIC independent, then warning is right only if TWL4030 is also 'plugged-in' as any other PMIC is expected to be. distinguish them. So I feel this warning should be present probably reworded better like No PMIC hook registered to init smartreflex. Either this PM IC does not need SR init or PMIC hook is missing. This wording - as is - would again be misleading. ~sanjeev Vishwa [1] http://marc.info/?l=linux-omapm=129584746102725w=2 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
Re: [PATCH V2] OMAP3: PM: Set/reset T2 bit for Smartreflex on TWL.
Abhilash,
On Mon, Jan 31, 2011 at 7:19 PM, Koyamangalath, Abhilash
abhilash...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
Sent: Monday, January 24, 2011 11:07 AM
To: linux-omap@vger.kernel.org
Cc: Gopinath, Thara; Gulati, Shweta
Subject: [PATCH V2] OMAP3: PM: Set/reset T2 bit for Smartreflex on TWL.
From: Thara Gopinath th...@ti.com
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.API added
'omap3_twl_set_sr_bit' with parameter to set/clear SR bit. It is cleared
for platforms where voltage is not scaled using vpforceupdate
or vc_bypass Method. In those cases 'omap3_twl_set_sr_bit' is called
from board file, to make sure this bit is not overwritten in
'omap3_twl_init', a flag 'twl_sr_enable'
is added.
This patch is based on LO PM Branch and Smartreflex has been
tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
OMAP2430 SDP.
The function twl4030_vsel_to_uv (where you have added a call to
omap3_twl_set_sr_bit) method is getting invoked only from vp_volt_debug_get
(which is for debugfs) and omap_vp_get_curr_volt (which no one seems to be
calling). Due to this I was not able to get cpufreq to work.
(I finally got it working by calling omap3_twl_set_sr_bit from omap3_twl_init
instead).
It looks like I'm missing something, maybe an intermediate patch? (I'd
applied your patch manually on 2.6.37).
-Abhilash
The function 'omap3_twl_set_sr_bit' is called from omap3_twl_init
only, while manually applying the patch u saw the function defined
above omap3_twl_init in patch.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 62
arch/arm/mach-omap2/pm.h | 1 +
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 00e1d2b..871a349 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -59,8 +59,15 @@
static bool is_offset_valid;
static u8 smps_offset;
+/*
+ * Flag to ensure Smartreflex bit in TWL
+ * being cleared in board file is not overwritten.
+ */
+static bool twl_sr_enable = true;
+#define TWL4030_DCDC_GLOBAL_CFG 0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -269,6 +276,16 @@ 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.
+ */
+ if (twl_sr_enable)
+ omap3_twl_set_sr_bit(1);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
@@ -277,3 +294,48 @@ int __init omap3_twl_init(void)
return 0;
}
+
+/**
+ * omap3_twl_set_sr_bit() - API to Set/Clear SR bit on TWL
+ * @flag: Flag to Set/Clear SR bit
+ *
+ * If flag is non zero, enables Smartreflex bit on TWL 4030
+ * to make sure voltage scaling through Vp forceupdate works.
+ * Else, the smartreflex bit on twl4030 is
+ * cleared as there are platforms which use
+ * OMAP3 and T2 but use Synchronized Scaling Hardware
+ * Strategy (ENABLE_VMODE=1) and Direct Strategy Software
+ * Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
+ * in those scenarios this bit is to be cleared.
+ * API returns 0 on sucess, error is returned
+ * if I2C read/write fails.
+ */
+
+int omap3_twl_set_sr_bit(u8 flag)
+{
+ u8 temp;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (flag) {
+ temp |= SMARTREFLEX_ENABLE;
+ twl_sr_enable = true;
+ } else {
+ temp = ~SMARTREFLEX_ENABLE;
+ twl_sr_enable = false;
+ }
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret) {
+err:
+ pr_err(%s: Unable to Read/Write to TWL4030 through I2C bus
+ \n, __func__);
+ return -EINVAL;
+ }
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 704766b..c98be66 100644
--- a/arch/arm/mach-omap2/pm.h
Re: [PATCH] arm: Fix possible memory leak
Acked. Will make sure there is no Memory Leak issue in Smartreflex Driver.
On Mon, Jan 31, 2011 at 12:56 AM, Stefan Weil w...@mail.berlios.de wrote:
sr_info was allocated and needs a kfree before returning.
This error was reported by cppcheck:
arch/arm/mach-omap2/smartreflex.c:837: error: Memory leak: sr_info
To: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
arch/arm/mach-omap2/smartreflex.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index af39d17..07324607 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -832,7 +832,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_free_devinfo;
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.7.2.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
--
Thanks,
Regards,
Shweta
--
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: [query] smartreflex: No PMIC hook to init smartreflex
Sanjeev, On Thu, Jan 27, 2011 at 3:05 PM, Menon, Nishanth n...@ti.com wrote: Sanjeev, On Tue, Jan 25, 2011 at 20:55, Premi, Sanjeev pr...@ti.com wrote: While building the kernel at 2.6.37, i see this warning for omap3evm - with omap3630: Power Management for TI OMAP3. sr_init: No PMIC hook to init smartreflex -- THIS IS THE WARNING. smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized SmartReflex Class3 initialized In the code, i see this comment: /* * sr_init is a late init. If by then a pmic specific API is not * registered either there is no need for anything to be done on * the PMIC side or somebody has forgotten to register a PMIC * handler. Warn for the second condition. */ if (sr_pmic_data sr_pmic_data-sr_pmic_init) sr_pmic_data-sr_pmic_init(); else pr_warning(%s: No PMIC hook to init smartreflex\n, __func__); But, I couldn't find any place where PMIC is being registered. This is a harmless warning (ideally, we should remove the pr_warning). the intent here is to have hook for pmic_init which could be populated for custom PMICs which may need something additional for Smart reflex enablement. if you look at the sr_pmic_data - it just has a single api for pmic_init e.g. in the case of TWL4030/5030, we might need to set the bit to switch mode from I2C1 to I2C_SR - e.g. the patch from Shweta[1] if Smartreflex AVS was the *only* mechanism in the system, we could have hooked pmic_init to this bit setting. but since the system can do voltage scaling (VP forceupdate/vc bypass) independent of SR AVS block, the patch in [1] does initialization independent of sr_pmic_data-pmic_init which makes sense. in short, my 2cents: the warning is probably something we should remove from the code. [1] http://marc.info/?l=linux-omapm=129584746102725w=2 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 I have tested on OMAP4 board also, Smart reflex works fine. It brings down the nominal voltages to optimum levels, the registration done by generic Pmic framework to SR wouldn't hamper SR woking as the SR bit setting is done specifically in Triton specific file 'omap_twl.c' and thus, that warning is harmless. The patch you should take for SR to work is: https://patchwork.kernel.org/patch/510971/ -- Thanks, Regards, Shweta -- 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
On Wed, Jan 19, 2011 at 5:54 PM, Nishanth Menon n...@ti.com wrote: Gulati, Shweta wrote, on 01/19/2011 02:10 PM: I cant see how disable_sr is usable, further as discussed in http://marc.info/?l=linux-omapm=129424774929498w=2 http://marc.info/?l=linux-omapm=129424774929498w=2 we decided to introduce api *if needed*. does any one need it? There might be some OMAP3xxx chips where for DVFS VMODE or VSEL method is used, for those boards this disable API could be called from Board File, to make sure the sequence of execution of late_init_call of twl_init from omap2_common_pm_late_init does not hamper clearing of this bit I would add a global variable to keep track if Resetting is required or not, will submit V2 with changes. Apologies, but a Dumb question: late_initcall(omap2_common_pm_late_init) board files(arch/arm/include/asm/mach/arch.h machine_desc) tend to have the following hooks: void (*fixup)(struct machine_desc *, struct tag *, char **, struct meminfo *); void (*reserve)(void);/* reserve mem blocks */ void (*map_io)(void);/* IO mapping function */ void (*init_early)(void); void (*init_irq)(void); struct sys_timer *timer; /* system tick timer */ void (*init_machine (void); void (*handle_irq)(struct pt_regs *); So if i wanted to disable the SR setting, where should I do it? -- Regards, Nishanth Menon Nishanth, I think i could not make my point clear in my previous reply. There are two APIs added 'omap3_twl_disable_sr' and 'omap3_twl_enable_sr'. omap3_twl_enable_sr sets SR bit in TWL4030 registers to make sure VPforceupdate method of voltage scaling works properly but there could be some OMAP3xxx chips where VMODE or VSEL method of voltage scaling is used (though today these voltage scaling methods are not recommended by HW folks). For the boards where Vpforceupdate method is used this 'omap3_twl_disable_sr' would not be called. For possible case of platforms where VMODE or VSEL methods are used the API 'omap3_twl_disable_sr' will reset this bit. The API 'omap3_twl_disable_sr' can be called from board file, to make sure the resetting of this bit is not overwritten in late_init call of omap3_twl_init(where 'omap3_twl_enable_sr' is called) I suggested adding a global flag which will keep track whether this bit is cleared from board file or not. Would make these changes in V2. Regards, Shweta PS: could you please fix your mailer when replying on l-o for netetiquette reasons? -- Thanks, Regards, Shweta -- 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
FW: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on OMAP3430
Any comments would be taken in.
Thanks
Regards
Shweta
-Original Message-
From: Gulati, Shweta
Sent: Tuesday, October 13, 2009 3:56 PM
To: linux-omap@vger.kernel.org
Cc: Gulati, Shweta; Gopinath, Thara
Subject: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on OMAP3430
From: Shweta Gulati shweta.gul...@ti.com
(Resending the patch with the subject line and some minor fixes)
According to Silicon Bug on context restore it is found that the pad
configuration register for GPIO_28/GPIO_29(ETKD14/15) is corrupted after
returning from Core OFF mode. This happens if the MPU reads the
PADCONF_SAVEDONE bit very close to the end of context save sequence
for the pad conf registers, resulting in last context not being saved to the
scratchpad memory. This is a h/w bug. The workaround is to delay the
MPU access of SAVEDONE bit until the last context has been saved.
This patch adds a configuration option to allow 300 us delay in
save path as recommended by TI. The other option is to let the
bug occur but store the value of pad configuration register explicitly
and write it back in resume path. But this option should be chosen
only if the ETKD14/15 pads are not in use as this workaround can
lead to glitch in the pin.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 25 +
arch/arm/plat-omap/Kconfig | 17 +
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index cea3bca..4f9671a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/delay.h
#include mach/sram.h
#include mach/prcm.h
@@ -54,10 +55,19 @@
static int regset_save_on_suspend;
+/* A extra variable to store value of pad_config register if
+ * delay is not to be inserted and value is explicitly restored
+ * in resume path.
+ */
+#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
+static u32 store_pad_config;
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0x31
#define OMAP343X_TABLE_VALUE_OFFSET 0x30
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32
+#define CONTROL_PADCONF_ETK_D140x480025F8
u32 enable_off_mode;
u32 sleep_while_idle;
@@ -202,6 +212,17 @@ static void omap3_core_save_context(void)
omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
control_padconf_off |= START_PADCONF_SAVE;
omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
+#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
+ store_pad_config = omap_readl(CONTROL_PADCONF_ETK_D14);
+#else
+ /* Due to Silicon Bug on context restore it is found
+* that the CONTROL_PAD_CONF_ETK14 register is not saved into
+* scratch pad memory sometimes. To rectify it delay acess by Mpu
+* for 300us for scm to finish saving task
+*/
+ udelay(300);
+#endif
+
/* wait for the save to complete */
while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
PADCONF_SAVE_DONE)
@@ -217,6 +238,10 @@ static void omap3_core_save_context(void)
static void omap3_core_restore_context(void)
{
+ /* Restore the last padconf value if needed */
+#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
+ omap_writel(store_pad_config, CONTROL_PADCONF_ETK_D14);
+#endif
/* Restore the control module context, padconf restored by h/w */
omap3_control_restore_context();
/* Restore the GPMC context */
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 2143db5..737d0aa 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -242,6 +242,23 @@ config OMAP_PM_SRF
endchoice
+config DELAY_IN_PADCONF_SAVE
+ bool Insert 300 us delay after the start of padconf saving
+ depends on ARCH_OMAP3 PM
+ help
+If this option is selected a 300 us delay is inserted in the
+suspend path after writing into START_PADCONF_SAVE bit to ensure
+that pad configuration register is stored properly.If mpu tries to
+access SAVE_DOME bit before the entire save is over, there is a
+possibility that the last padconf register is not saved properly.
+The delay ensures that mpu does not acess SAVE_DONE bit before the
+save is complete.
+
+If this option is not selected the bug is let
+to happen and last pad configuration register
+is explicitly saved in SDRAM and written back
+in resume path.
+
endmenu
endif
--
1.5.4.7
--
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
