RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Jan 24, 2012 at 23:17:56, Hilman, Kevin wrote: Hiremath, Vaibhav hvaib...@ti.com writes: On Tue, Jan 24, 2012 at 05:08:50, Hilman, Kevin wrote: Vaibhav Hiremath hvaib...@ti.com writes: OMAP device has 32k-sync timer which is currently used as a clocksource in the kernel (omap2plus_defconfig). The current implementation uses compile time selection between gp-timer and 32k-sync timer, which breaks multi-omap build for the devices like AM33xx, where 32k-sync timer is not available. So use hwmod database lookup mechanism, through which at run-time we can identify availability of 32k-sync timer on the device, else fall back to gp-timer. With the runtime detection fallback, I suggest also removing the Kconfig choice between the two as well. Kevin, Actually I thought of cleaning whole 32KTIMER related code, but then realized that, it would be major cleanup, since it is being used in lot of places. So let's not block this patch-series for this further cleanup. I will work on cleaning up the complete 32KTIMER macro and submit the patches. OK, Tony can make the call. Tony, Can this also get merged? Thanks, Vaibhav Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: enable watchdog by default
On Wed, Feb 1, 2012 at 5:22 AM, Justin P. Mattock justinmatt...@gmail.com wrote: not sure if I see this warning or not on my machine, but is there a fix for the warning? I would rather see that, than hide it with setting: default y (if that's what its doing!) No, there's no fix. IIRC Omar said it would not be easy. -- Felipe Contreras -- 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] ARM: OMAP3+: PM debug: fix the use of debugfs_create_* API
Kevin, On Tue, Jan 31, 2012 at 6:44 PM, Kevin Hilman khil...@ti.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: The debugfs_create_* API returns a NULL ptr in case of problem. Fix the PM debug code to take this into account. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/pm-debug.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 4411163..e5bf367 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -264,8 +264,8 @@ static int __init pm_dbg_init(void) return 0; d = debugfs_create_dir(pm_debug, NULL); - if (IS_ERR(d)) - return PTR_ERR(d); + if (!d) I think this should be IS_ERR_OR_NULL() because this function can also return ERR_PTR(-ENODEV). (Yes, only when debugfs is not enabled, but it's still more correct.) That makes sense, even if the PM debug code is enclosed by #ifdef CONFIG_DEBUG_FS. I have a new version of the patch, it also fixes another potential problem with debugfs. Thanks, Jean 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
[PATCH] ARM: OMAP2+: PM debug: fix the use of debugfs_create_* API
Check the return code pointer value from debugfs_create_dir for error or NULL. Also added an additional check to prevent the creation of a 'suspend' entry at the debugfs root in case a power domain directory cannot be created. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/pm-debug.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c index 4411163..814bcd9 100644 --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -220,8 +220,8 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir) return 0; d = debugfs_create_dir(pwrdm-name, (struct dentry *)dir); - - (void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d, + if (!(IS_ERR_OR_NULL(d))) + (void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d, (void *)pwrdm, pwrdm_suspend_fops); return 0; @@ -264,7 +264,7 @@ static int __init pm_dbg_init(void) return 0; d = debugfs_create_dir(pm_debug, NULL); - if (IS_ERR(d)) + if (IS_ERR_OR_NULL(d)) return PTR_ERR(d); (void) debugfs_create_file(count, S_IRUGO, -- 1.7.5.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
[PATCH v3 00/20] ARM: OMAP3+: SmartReflex: bugfixes
Integrate the latest SmartReflex bufixes from Felipe Balbi [1] and Nishant Menon [2], plus misc bugfixes. Based on latest master branch of the mainline git tree (3.3.0-rc1) [3], commit 27ba234c8dfe86c96675d4ef275d1d3c1f5f7053. [1] http://marc.info/?l=linux-omapm=132134699423547w=2 [2] https://github.com/nmenon/linux-omap-ti-pm/commits/linux-omap-3.0 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=shortlog Revision history: . v3: fixed the error handling code . v2: fixed the use of debugfs_create_* API minor fixes after comments on l-o ML: commits title, removed unneeded fields in descriptions removed the unneeded patches about the suspend/resume handlers . v1: initial commits Felipe Balbi (4): ARM: OMAP3+: SmartReflex: add missing platform_set_drvdata() ARM: OMAP3+: SmartReflex: move late_initcall() closer to its argument ARM: OMAP3+: SmartReflex: misc cleanups ARM: OMAP3+: SmartReflex: micro-optimization for sanity check Jean Pihet (2): ARM: OMAP3+: SmartReflex: fix the use of debugfs_create_* API ARM: OMAP3+: SmartReflex: fix error handling Julia Lawall (1): ARM: OMAP3+: SmartReflex: add missing error-handling code Nishanth Menon (12): ARM: OMAP3+: SmartReflex: fix err interrupt disable sequence ARM: OMAP3+: SmartReflex Class3: disable errorgen before disable VP ARM: OMAP3+: SmartReflex: Add a shutdown hook ARM: OMAP3+: SmartReflex: Fix status masking in ERRCONFIG register ARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need ARM: OMAP3+: hwmod: add SmartReflex IRQs ARM: OMAP3+: SmartReflex: introduce class init, deinit and priv data ARM: OMAP3+: SmartReflex: introduce notifiers flags ARM: OMAP3+: SmartReflex: introduce notifier_control ARM: OMAP3+: SmartReflex: disable spamming interrupts ARM: OMAP3+: SmartReflex: introduce class private data per voltage domain ARM: OMAP3+: SmartReflex Class3: restrict CPU to run on Shweta Gulati (1): ARM: OMAP3+: SmartReflex: Layer Cleanup [V4] arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 31 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 +- arch/arm/mach-omap2/smartreflex-class3.c | 16 +- arch/arm/mach-omap2/smartreflex.c| 424 + arch/arm/mach-omap2/smartreflex.h| 42 +++- arch/arm/mach-omap2/sr_device.c | 11 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 - 7 files changed, 457 insertions(+), 88 deletions(-) -- 1.7.5.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
[PATCH 01/20] ARM: OMAP3+: SmartReflex: Layer Cleanup [V4]
From: Shweta Gulati shweta.gul...@ti.com
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
[n...@ti.com: minor modifications in sequence and GPU support]
Signed-off-by: Nishanth Menon n...@ti.com
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 Walmsley p...@pwsan.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
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|9 +
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 --
5 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5324e8d..a201ff5 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
@@ -2642,6 +2643,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_smartreflex_dev_attr sr1_dev_attr = {
+ .sensor_voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2650,7 +2655,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,
@@ -2662,6 +2666,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2669,7 +2674,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,
@@ -2681,9 +2685,14 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
};
/* SR2 */
+static struct omap_smartreflex_dev_attr sr2_dev_attr = {
+ .sensor_voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2692,7 +2701,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,
@@ -2704,6 +2712,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2711,7 +2720,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,
@@ -2723,6 +2731,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f9f1510..9f8ee1f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -34,6 +34,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include cm1_44xx.h
#include cm2_44xx.h
#include prm44xx.h
@@ -3961,6 +3962,10 @@ static struct omap_hwmod_class
omap44xx_smartreflex_hwmod_class = {
};
/* smartreflex_core */
+static struct omap_smartreflex_dev_attr smartreflex_core_dev_attr = {
+ .sensor_voltdm_name = core,
+};
+
static struct omap_hwmod
[PATCH 02/20] ARM: OMAP3+: SmartReflex: add missing error-handling code
From: Julia Lawall ju...@diku.dk
At this point, the ioremap has taken place, so the error handling code at
the label err_iounmap should be used rather than returning directly.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
identifier x;
@@
kfree(x)
@@
identifier r.x;
expression E1!=0,E2,E3,E4;
statement S;
@@
(
if (+...x...+) S
|
if (...) { ... when != kfree(x)
when != if (...) { ... kfree(x); ... }
when != x = E3
* return E1;
}
... when != x = E2
if (...) { ... when != x = E4
kfree(x); ... return ...; }
)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Acked-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9dd9345..7e755bb 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -897,7 +897,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_iounmap;
}
}
--
1.7.5.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
[PATCH 03/20] ARM: OMAP3+: SmartReflex: fix err interrupt disable sequence
From: Nishanth Menon n...@ti.com sr_modify_mask takes mask, value as parameters, the usage currently is value, mask which is wrong, as a result vpboundint_st which was supposed to have been disabled, does not get disabled. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/smartreflex.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 7e755bb..ee224df 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -447,8 +447,8 @@ int sr_configure_errgen(struct voltagedomain *voltdm) sr_errconfig); /* Enabling the interrupts if the ERROR module is used */ - sr_modify_reg(sr, errconfig_offs, - vpboundint_en, (vpboundint_en | vpboundint_st)); + sr_modify_reg(sr, errconfig_offs, (vpboundint_en | vpboundint_st), + vpboundint_en); return 0; } -- 1.7.5.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
[PATCH 04/20] ARM: OMAP3+: SmartReflex Class3: disable errorgen before disable VP
From: Nishanth Menon n...@ti.com
SmartReflex AVS Errorgen module supplies signals to Voltage
Processor. It is suggested that by disabling Errorgen module
before we disable VP, we might be able to ensure lesser
chances of race condition to occur in the system.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |1 +
arch/arm/mach-omap2/smartreflex.c| 44 ++
arch/arm/mach-omap2/smartreflex.h|1 +
3 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 53d9d0a..955566e 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -29,6 +29,7 @@ static int sr_class3_enable(struct voltagedomain *voltdm)
static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
{
+ sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
sr_disable(voltdm);
if (is_volt_reset)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index ee224df..d7294c6 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -454,6 +454,50 @@ int sr_configure_errgen(struct voltagedomain *voltdm)
}
/**
+ * sr_disable_errgen() - Disables SmartReflex AVS module's errgen component
+ * @voltdm: voltagedomain pointer to which the SR module to be configured
belongs to.
+ *
+ * This API is to be called from the smartreflex class driver to
+ * disable the error generator module inside the smartreflex module.
+ *
+ * Returns 0 on success and error value in case of failure.
+ */
+int sr_disable_errgen(struct voltagedomain *voltdm)
+{
+ u32 errconfig_offs, vpboundint_en;
+ u32 vpboundint_st;
+ struct omap_sr *sr = _sr_lookup(voltdm);
+
+ if (IS_ERR(sr)) {
+ pr_warning(%s: omap_sr struct for sr_%s not found\n,
+ __func__, voltdm-name);
+ return -EINVAL;
+ }
+
+ if (sr-ip_type == SR_TYPE_V1) {
+ errconfig_offs = ERRCONFIG_V1;
+ vpboundint_en = ERRCONFIG_VPBOUNDINTEN_V1;
+ vpboundint_st = ERRCONFIG_VPBOUNDINTST_V1;
+ } else if (sr-ip_type == SR_TYPE_V2) {
+ errconfig_offs = ERRCONFIG_V2;
+ vpboundint_en = ERRCONFIG_VPBOUNDINTEN_V2;
+ vpboundint_st = ERRCONFIG_VPBOUNDINTST_V2;
+ } else {
+ dev_err(sr-pdev-dev, %s: Trying to Configure smartreflex
+ module without specifying the ip\n, __func__);
+ return -EINVAL;
+ }
+
+ /* Disable the interrupts of ERROR module */
+ sr_modify_reg(sr, errconfig_offs, vpboundint_en | vpboundint_st, 0);
+
+ /* Disable the Sensor and errorgen */
+ sr_modify_reg(sr, SRCONFIG, SRCONFIG_SENENABLE | SRCONFIG_ERRGEN_EN, 0);
+
+ return 0;
+}
+
+/**
* sr_configure_minmax() - Configures the smrtreflex to perform AVS using the
* minmaxavg module.
* @voltdm:VDD pointer to which the SR module to be configured belongs to.
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index fd61498..5809141 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -240,6 +240,7 @@ void omap_sr_register_pmic(struct omap_sr_pmic_data
*pmic_data);
int sr_enable(struct voltagedomain *voltdm, unsigned long volt);
void sr_disable(struct voltagedomain *voltdm);
int sr_configure_errgen(struct voltagedomain *voltdm);
+int sr_disable_errgen(struct voltagedomain *voltdm);
int sr_configure_minmax(struct voltagedomain *voltdm);
/* API to register the smartreflex class driver with the smartreflex driver */
--
1.7.5.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
[PATCH 05/20] ARM: OMAP3+: SmartReflex: Add a shutdown hook
From: Nishanth Menon n...@ti.com
Since OMAP's VP and PRM modules do not get reset by warm reset,
we should ensure that proper shutdown procedure is followed prior
to allowing the kernel to reboot back up.
Without this patch, Smartreflex module might be left active or
system might be caught in an indeterminate sequence when reboot
is triggered, leaving the next reboot behavior to be unpredictable.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d7294c6..f384c19 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1055,8 +1055,32 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static void __devexit omap_sr_shutdown(struct platform_device *pdev)
+{
+ struct omap_sr_data *pdata = pdev-dev.platform_data;
+ struct omap_sr *sr_info;
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: platform data missing\n, __func__);
+ return;
+ }
+
+ sr_info = _sr_lookup(pdata-voltdm);
+ if (IS_ERR(sr_info)) {
+ dev_warn(pdev-dev, %s: omap_sr struct not found\n,
+ __func__);
+ return;
+ }
+
+ if (sr_info-autocomp_active)
+ sr_stop_vddautocomp(sr_info);
+
+ return;
+}
+
static struct platform_driver smartreflex_driver = {
.remove = omap_sr_remove,
+ .shutdown = omap_sr_shutdown,
.driver = {
.name = smartreflex,
},
--
1.7.5.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
[PATCH 07/20] ARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need
From: Nishanth Menon n...@ti.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
ERRCONFIG register's VPBOUNDINTST has an additional functional meaning
It force clears Sr_interruptz internal signal. This can result in
scenarios where VP- SR protocol is violated where voltage processor's
As interruptz is already high, VP will never clear the signal vpirqclr.
Therefore during the next force update to reset to nominal voltage,
VP can’t pulsed vpirqclr = PRCM HW can’t generate the tranxdone IRQ
and the situation is not recoverable untill a cold reset is invoked.
To prevent this situation, check if status is set before clearing the
status as this needs to be done only on a need basis.
Reported-by: Vincent Bour v-b...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index ba6ad09..6dea30d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,6 +289,8 @@ error:
static void sr_v1_disable(struct omap_sr *sr)
{
int timeout = 0;
+ int errconf_val = ERRCONFIG_MCUACCUMINTST | ERRCONFIG_MCUVALIDINTST |
+ ERRCONFIG_MCUBOUNDINTST;
/* Enable MCUDisableAcknowledge interrupt */
sr_modify_reg(sr, ERRCONFIG_V1,
@@ -297,13 +299,13 @@ static void sr_v1_disable(struct omap_sr *sr)
/* SRCONFIG - disable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, 0x0);
- /* Disable all other SR interrupts and clear the status */
+ /* Disable all other SR interrupts and clear the status as needed */
+ if (sr_read_reg(sr, ERRCONFIG_V1) ERRCONFIG_VPBOUNDINTST_V1)
+ errconf_val |= ERRCONFIG_VPBOUNDINTST_V1;
sr_modify_reg(sr, ERRCONFIG_V1,
(ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUVALIDINTEN |
ERRCONFIG_MCUBOUNDINTEN | ERRCONFIG_VPBOUNDINTEN_V1),
- (ERRCONFIG_MCUACCUMINTST | ERRCONFIG_MCUVALIDINTST |
- ERRCONFIG_MCUBOUNDINTST |
- ERRCONFIG_VPBOUNDINTST_V1));
+ errconf_val);
/*
* Wait for SR to be disabled.
@@ -332,9 +334,17 @@ static void sr_v2_disable(struct omap_sr *sr)
/* SRCONFIG - disable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, 0x0);
- /* Disable all other SR interrupts and clear the status */
- sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2,
+ /*
+* Disable all other SR interrupts and clear the status
+* write to status register ONLY on need basis - only if status
+* is set.
+*/
+ if (sr_read_reg(sr, ERRCONFIG_V2) ERRCONFIG_VPBOUNDINTST_V2)
+ sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2,
ERRCONFIG_VPBOUNDINTST_V2);
+ else
+ sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2,
+ 0x0);
sr_write_reg(sr, IRQENABLE_CLR, (IRQENABLE_MCUACCUMINT |
IRQENABLE_MCUVALIDINT |
IRQENABLE_MCUBOUNDSINT));
--
1.7.5.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
[PATCH 06/20] ARM: OMAP3+: SmartReflex: Fix status masking in ERRCONFIG register
From: Nishanth Menon n...@ti.com
ERRCONFIG register has status bits that were intended not to
be destroyed by bad modification. We cleanup and simplify the
handling the status in the modify path.
Reported-by: Vincent Bour v-b...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index f384c19..ba6ad09 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -74,10 +74,6 @@ static inline void sr_modify_reg(struct omap_sr *sr,
unsigned offset, u32 mask,
u32 value)
{
u32 reg_val;
- u32 errconfig_offs = 0, errconfig_mask = 0;
-
- reg_val = __raw_readl(sr-base + offset);
- reg_val = ~mask;
/*
* Smartreflex error config register is special as it contains
@@ -88,16 +84,15 @@ static inline void sr_modify_reg(struct omap_sr *sr,
unsigned offset, u32 mask,
* if they are currently set, but does allow the caller to write
* those bits.
*/
- if (sr-ip_type == SR_TYPE_V1) {
- errconfig_offs = ERRCONFIG_V1;
- errconfig_mask = ERRCONFIG_STATUS_V1_MASK;
- } else if (sr-ip_type == SR_TYPE_V2) {
- errconfig_offs = ERRCONFIG_V2;
- errconfig_mask = ERRCONFIG_VPBOUNDINTST_V2;
- }
+ if (sr-ip_type == SR_TYPE_V1 offset == ERRCONFIG_V1)
+ mask |= ERRCONFIG_STATUS_V1_MASK;
+ else if (sr-ip_type == SR_TYPE_V2 offset == ERRCONFIG_V2)
+ mask |= ERRCONFIG_VPBOUNDINTST_V2;
+
+ reg_val = __raw_readl(sr-base + offset);
+ reg_val = ~mask;
- if (offset == errconfig_offs)
- reg_val = ~errconfig_mask;
+ value = mask;
reg_val |= value;
--
1.7.5.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
[PATCH 08/20] ARM: OMAP3+: hwmod: add SmartReflex IRQs
From: Nishanth Menon n...@ti.com
OMAP3 SmartReflex IRQs in hwmod structures with the same naming as
present in OMAP4. Without these IRQs being registered, SmartReflex
driver will be unable to get the IRQ numbers to handle notifications
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index a201ff5..b224ea2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -377,6 +377,16 @@ static struct omap_hwmod_ocp_if omap3_l4_core__i2c3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
+ { .name = sr1_irq, .irq = 18},
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
+ { .name = sr2_irq, .irq = 19},
+ { .irq = -1 }
+};
+
/* L4 CORE - SR1 interface */
static struct omap_hwmod_addr_space omap3_sr1_addr_space[] = {
{
@@ -2667,6 +2677,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
.dev_attr = sr1_dev_attr,
+ .mpu_irqs = omap3_smartreflex_mpu_irqs,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2686,6 +2697,7 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
.dev_attr = sr1_dev_attr,
+ .mpu_irqs = omap3_smartreflex_mpu_irqs,
};
/* SR2 */
@@ -2713,6 +2725,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
.dev_attr = sr2_dev_attr,
+ .mpu_irqs = omap3_smartreflex_core_irqs,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2732,6 +2745,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
.dev_attr = sr2_dev_attr,
+ .mpu_irqs = omap3_smartreflex_core_irqs,
};
/*
--
1.7.5.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
[PATCH 09/20] ARM: OMAP3+: SmartReflex: introduce class init, deinit and priv data
From: Nishanth Menon n...@ti.com
Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be inited up or deinited independent
of smart reflex operation. They also may need private data to be
used for operations of their own, provide the same.
This allows the class driver to initialize it's internal data structures
on a need basis in preparation for the specific domain's autocomp usage.
The resultant operation is as follows:
when autocomp is set to 1 - class drivers' init is called
The existing enable/disable is still used as before by the SmartReflex
core driver to enable disable the class operation.
When autocomp is set to 0 - class drivers' deinit is called, signaling
the end of usage for that domain.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 15 +++
arch/arm/mach-omap2/smartreflex.h |6 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 6dea30d..5fd9cb1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -218,6 +218,13 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
return;
}
+ if (sr_class-init
+ sr_class-init(sr-voltdm, sr_class-class_priv_data)) {
+ dev_err(sr-pdev-dev,
+ %s: SRClass initialization failed\n, __func__);
+ return;
+ }
+
if (!sr_class-enable(sr-voltdm))
sr-autocomp_active = true;
}
@@ -233,6 +240,14 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
if (sr-autocomp_active) {
sr_class-disable(sr-voltdm, 1);
+ if (sr_class-deinit
+ sr_class-deinit(sr-voltdm,
+ sr_class-class_priv_data)) {
+ dev_err(sr-pdev-dev,
+ %s: SR[%d]Class deinitialization failed\n,
+ __func__, sr-srid);
+ }
+
sr-autocomp_active = false;
}
}
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 5809141..dd5b21e 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -177,6 +177,8 @@ struct omap_smartreflex_dev_attr {
*
* @enable:API to enable a particular class smaartreflex.
* @disable: API to disable a particular class smartreflex.
+ * @init: API to do class specific initialization (optional)
+ * @deinit:API to do class specific deinitialization (optional)
* @configure: API to configure a particular class smartreflex.
* @notify:API to notify the class driver about an event in SR.
* Not needed for class3.
@@ -184,14 +186,18 @@ struct omap_smartreflex_dev_attr {
* @class_type:specify which smartreflex class.
* Can be used by the SR driver to take any class
* based decisions.
+ * @class_priv_data: Class specific private data (optional)
*/
struct omap_sr_class_data {
int (*enable)(struct voltagedomain *voltdm);
int (*disable)(struct voltagedomain *voltdm, int is_volt_reset);
+ int (*init)(struct voltagedomain *voltdm, void *class_priv_data);
+ int (*deinit)(struct voltagedomain *voltdm, void *class_priv_data);
int (*configure)(struct voltagedomain *voltdm);
int (*notify)(struct voltagedomain *voltdm, u32 status);
u8 notify_flags;
u8 class_type;
+ void *class_priv_data;
};
/**
--
1.7.5.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
[PATCH 10/20] ARM: OMAP3+: SmartReflex: introduce notifiers flags
From: Nishanth Menon n...@ti.com
SmartReflex IP V1 and V2 have different registers and offsets.
Currently, we pass the status as is to the class driver. However,
since we don't pass the version of the underlying SR hardware
to the Class driver, it will not be unable to make consistent
sense of the status bits coming over to it.
A class driver should be able to function without dependency
on the exact IP version it is actually running on. We hence
introduce our own translation in software level for a generic
notification flag.
As part of this change, we will now call the notifier if we get
a match with the notifier flags that the class driver requested.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 78 -
arch/arm/mach-omap2/smartreflex.h |6 +++
2 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 5fd9cb1..8380201 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -121,27 +121,101 @@ static struct omap_sr *_sr_lookup(struct voltagedomain
*voltdm)
return ERR_PTR(-ENODATA);
}
+static inline u32 notifier_to_irqen_v1(u8 notify_flags)
+{
+ u32 val;
+
+ val = (notify_flags SR_NOTIFY_MCUACCUM) ?
+ ERRCONFIG_MCUACCUMINTEN : 0;
+ val |= (notify_flags SR_NOTIFY_MCUVALID) ?
+ ERRCONFIG_MCUVALIDINTEN : 0;
+ val |= (notify_flags SR_NOTIFY_MCUBOUND) ?
+ ERRCONFIG_MCUBOUNDINTEN : 0;
+ val |= (notify_flags SR_NOTIFY_MCUDISACK) ?
+ ERRCONFIG_MCUDISACKINTEN : 0;
+
+ return val;
+}
+
+static inline u32 notifier_to_irqen_v2(u8 notify_flags)
+{
+ u32 val;
+
+ val = (notify_flags SR_NOTIFY_MCUACCUM) ?
+ IRQENABLE_MCUACCUMINT : 0;
+ val |= (notify_flags SR_NOTIFY_MCUVALID) ?
+ IRQENABLE_MCUVALIDINT : 0;
+ val |= (notify_flags SR_NOTIFY_MCUBOUND) ?
+ IRQENABLE_MCUBOUNDSINT : 0;
+ val |= (notify_flags SR_NOTIFY_MCUDISACK) ?
+ IRQENABLE_MCUDISABLEACKINT : 0;
+
+ return val;
+}
+
+static inline u8 irqstat_to_notifier_v1(u32 status)
+{
+ u8 val;
+
+ val = (status ERRCONFIG_MCUACCUMINTST) ?
+ SR_NOTIFY_MCUACCUM : 0;
+ val |= (status ERRCONFIG_MCUVALIDINTEN) ?
+ SR_NOTIFY_MCUVALID : 0;
+ val |= (status ERRCONFIG_MCUBOUNDINTEN) ?
+ SR_NOTIFY_MCUBOUND : 0;
+ val |= (status ERRCONFIG_MCUDISACKINTEN) ?
+ SR_NOTIFY_MCUDISACK : 0;
+
+ return val;
+}
+
+static inline u8 irqstat_to_notifier_v2(u32 status)
+{
+ u8 val;
+
+ val = (status IRQENABLE_MCUACCUMINT) ?
+ SR_NOTIFY_MCUACCUM : 0;
+ val |= (status IRQENABLE_MCUVALIDINT) ?
+ SR_NOTIFY_MCUVALID : 0;
+ val |= (status IRQENABLE_MCUBOUNDSINT) ?
+ SR_NOTIFY_MCUBOUND : 0;
+ val |= (status IRQENABLE_MCUDISABLEACKINT) ?
+ SR_NOTIFY_MCUDISACK : 0;
+
+ return val;
+}
+
static irqreturn_t sr_interrupt(int irq, void *data)
{
struct omap_sr *sr_info = (struct omap_sr *)data;
u32 status = 0;
+ u32 value = 0;
if (sr_info-ip_type == SR_TYPE_V1) {
+ /* Status bits are one bit before enable bits in v1 */
+ value = notifier_to_irqen_v1(sr_class-notify_flags) 1;
+
/* Read the status bits */
status = sr_read_reg(sr_info, ERRCONFIG_V1);
+ status = value;
/* Clear them by writing back */
- sr_write_reg(sr_info, ERRCONFIG_V1, status);
+ sr_modify_reg(sr_info, ERRCONFIG_V1, value, status);
+
+ value = irqstat_to_notifier_v1(status);
} else if (sr_info-ip_type == SR_TYPE_V2) {
+ value = notifier_to_irqen_v2(sr_class-notify_flags);
/* Read the status bits */
status = sr_read_reg(sr_info, IRQSTATUS);
+ status = value;
/* Clear them by writing back */
sr_write_reg(sr_info, IRQSTATUS, status);
+ value = irqstat_to_notifier_v2(status);
}
if (sr_class-notify)
- sr_class-notify(sr_info-voltdm, status);
+ sr_class-notify(sr_info-voltdm, value);
return IRQ_HANDLED;
}
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index dd5b21e..da00f8c 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -142,6 +142,12 @@
#define OMAP3430_SR_ERRWEIGHT 0x04
#define OMAP3430_SR_ERRMAXLIMIT0x02
+/* Smart reflex notifiers for class drivers to use */
+#define SR_NOTIFY_MCUDISACKBIT(3)
+#define SR_NOTIFY_MCUBOUND BIT(2)
+#define SR_NOTIFY_MCUVALID
[PATCH 11/20] ARM: OMAP3+: SmartReflex: introduce notifier_control
From: Nishanth Menon n...@ti.com
We need some mechanism from class drivers to control when notifiers
should be triggered and when not, currently we have none, which makes
Class driver usage of the interrupt events almost impossible.
We also ensure that disable/enable or irq is always guarenteed to be
paired. The need to do this is because of the mixture of interrupt based
and polling based operations that is implemented as the most optimal
strategy for various SmartReflex AVS class
Introduce an SmartReflex driver API for doing the same. This is useful
for SmartReflex AVS class 1.5 or 2 drivers.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 65 +
arch/arm/mach-omap2/smartreflex.h |8
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 8380201..a24a228 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -50,6 +50,7 @@ struct omap_sr {
u32 senp_mod;
u32 senn_mod;
unsigned intirq;
+ boolirq_enabled;
void __iomem*base;
struct platform_device *pdev;
struct list_headnode;
@@ -765,6 +766,70 @@ void sr_disable(struct voltagedomain *voltdm)
}
/**
+ * sr_notifier_control() - control the notifier mechanism
+ * @voltdm:VDD pointer to which the SR module to be configured belongs to.
+ * @enable:true to enable notifiers and false to disable the same
+ *
+ * SR modules allow an MCU interrupt mechanism that vary based on the IP
+ * revision, we allow the system to generate interrupt if the class driver
+ * has capability to handle the same. it is upto the class driver to ensure
+ * the proper sequencing and handling for a clean implementation. returns
+ * 0 if all goes fine, else returns failure results
+ */
+int sr_notifier_control(struct voltagedomain *voltdm, bool enable)
+{
+ struct omap_sr *sr = _sr_lookup(voltdm);
+ u32 value = 0;
+
+ if (!sr) {
+ pr_warning(%s: sr corresponding to domain not found\n,
+ __func__);
+ return -EINVAL;
+ }
+ if (!sr-autocomp_active)
+ return -EINVAL;
+
+ /* If I could never register an ISR, why bother?? */
+ if (!(sr_class sr_class-notify sr_class-notify_flags
+ sr-irq)) {
+ dev_warn(sr-pdev-dev,
+ %s: unable to setup IRQ without handling mechanism\n,
+ __func__);
+ return -EINVAL;
+ }
+
+ switch (sr-ip_type) {
+ case SR_TYPE_V1:
+ value = notifier_to_irqen_v1(sr_class-notify_flags);
+ sr_modify_reg(sr, ERRCONFIG_V1, value,
+ (enable) ? value : 0);
+ break;
+ case SR_TYPE_V2:
+ value = notifier_to_irqen_v2(sr_class-notify_flags);
+ sr_write_reg(sr, (enable) ? IRQENABLE_SET : IRQENABLE_CLR,
+ value);
+ break;
+ default:
+dev_warn(sr-pdev-dev, %s: unknown type of sr??\n,
+__func__);
+ return -EINVAL;
+ }
+
+ if (!enable)
+ sr_write_reg(sr, IRQSTATUS, value);
+
+ if (enable != sr-irq_enabled) {
+ if (enable)
+ enable_irq(sr-irq);
+ else
+ disable_irq(sr-irq);
+ sr-irq_enabled = enable;
+ }
+
+ return 0;
+}
+
+/**
* sr_register_class() - API to register a smartreflex class parameters.
* @class_data:The structure containing various sr class specific data.
*
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index da00f8c..8660049 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -251,6 +251,7 @@ void omap_sr_register_pmic(struct omap_sr_pmic_data
*pmic_data);
/* Smartreflex driver hooks to be called from Smartreflex class driver */
int sr_enable(struct voltagedomain *voltdm, unsigned long volt);
void sr_disable(struct voltagedomain *voltdm);
+int sr_notifier_control(struct voltagedomain *voltdm, bool enable);
int sr_configure_errgen(struct voltagedomain *voltdm);
int sr_disable_errgen(struct voltagedomain *voltdm);
int sr_configure_minmax(struct voltagedomain *voltdm);
@@ -260,6 +261,13 @@ int sr_register_class(struct omap_sr_class_data
*class_data);
#else
static inline void omap_sr_enable(struct voltagedomain *voltdm) {}
static inline void omap_sr_disable(struct voltagedomain *voltdm) {}
+
+static inline int sr_notifier_control(struct voltagedomain *voltdm,
+
[PATCH 12/20] ARM: OMAP3+: SmartReflex: disable spamming interrupts
From: Nishanth Menon n...@ti.com
At times with bad SR configurations, especially during silicon bring-ups,
we could get continuous spurious interrupts which end up hanging the
platform in the form of an ISR call for status bits that are
automatically enabled by the hardware without any software clearing
option.
If we detect scenarios where ISR was called without the corresponding
notification bit being set, instead of hanging up the system,
we will disable interrupt after noting the event in the system log
to try and keep system sanity and allow developer to debug and fix
the condition.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index a24a228..6971b94 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -215,8 +215,25 @@ static irqreturn_t sr_interrupt(int irq, void *data)
value = irqstat_to_notifier_v2(status);
}
- if (sr_class-notify)
- sr_class-notify(sr_info-voltdm, value);
+ /* Attempt some resemblance of recovery! */
+ if (!value) {
+ dev_err(sr_info-pdev-dev, %s: Spurious interrupt!
+ status = 0x%08x. Disabling to prevent spamming!!\n,
+ __func__, status);
+ disable_irq_nosync(sr_info-irq);
+ sr_info-irq_enabled = false;
+ } else {
+ /* If the caller reports inability to handle, disable as well */
+ if (sr_class-notify
+ sr_class-notify(sr_info-voltdm, value)) {
+ dev_err(sr_info-pdev-dev, %s: Callback cant handle!
+ status=0x%08x. Disabling to prevent spam!!\n,
+ __func__, status);
+ disable_irq_nosync(sr_info-irq);
+ sr_info-irq_enabled = false;
+ }
+
+ }
return IRQ_HANDLED;
}
--
1.7.5.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
[PATCH 13/20] ARM: OMAP3+: SmartReflex: introduce class private data per voltage domain
From: Nishanth Menon n...@ti.com
Introduce private data for class drivers to operate on per
voltage domain. This removes the necessity for drivers such
as SmartReflex AVS Class 1.5 drivers from maintaining
a special lookup table which does not scale when number of
voltage domains change depending on silicon. It also makes
the life of such class drivers to be faster without having
to do a double lookup to get to their voltage domain specific
private data
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c | 10 +++---
arch/arm/mach-omap2/smartreflex.c| 23 +--
arch/arm/mach-omap2/smartreflex.h| 16 ++--
3 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 955566e..9dcda93 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -13,7 +13,8 @@
#include smartreflex.h
-static int sr_class3_enable(struct voltagedomain *voltdm)
+static int sr_class3_enable(struct voltagedomain *voltdm,
+ void *voltdm_cdata)
{
unsigned long volt = voltdm_get_voltage(voltdm);
@@ -27,7 +28,9 @@ static int sr_class3_enable(struct voltagedomain *voltdm)
return sr_enable(voltdm, volt);
}
-static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
+static int sr_class3_disable(struct voltagedomain *voltdm,
+void *voltdm_cdata,
+int is_volt_reset)
{
sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
@@ -38,7 +41,8 @@ static int sr_class3_disable(struct voltagedomain *voltdm,
int is_volt_reset)
return 0;
}
-static int sr_class3_configure(struct voltagedomain *voltdm)
+static int sr_class3_configure(struct voltagedomain *voltdm,
+ void *voltdm_cdata)
{
return sr_configure_errgen(voltdm);
}
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 6971b94..65e1a7c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -56,6 +56,8 @@ struct omap_sr {
struct list_headnode;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain*voltdm;
+ /* Managed by class driver as needed */
+ void*voltdm_cdata;
struct dentry *dbg_dir;
};
@@ -224,8 +226,8 @@ static irqreturn_t sr_interrupt(int irq, void *data)
sr_info-irq_enabled = false;
} else {
/* If the caller reports inability to handle, disable as well */
- if (sr_class-notify
- sr_class-notify(sr_info-voltdm, value)) {
+ if (sr_class-notify sr_class-notify(sr_info-voltdm,
+ sr_info-voltdm_cdata, value)) {
dev_err(sr_info-pdev-dev, %s: Callback cant handle!
status=0x%08x. Disabling to prevent spam!!\n,
__func__, status);
@@ -311,13 +313,14 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
}
if (sr_class-init
- sr_class-init(sr-voltdm, sr_class-class_priv_data)) {
+ sr_class-init(sr-voltdm, sr-voltdm_cdata,
+ sr_class-class_priv_data)) {
dev_err(sr-pdev-dev,
%s: SRClass initialization failed\n, __func__);
return;
}
- if (!sr_class-enable(sr-voltdm))
+ if (!sr_class-enable(sr-voltdm, sr-voltdm_cdata))
sr-autocomp_active = true;
}
@@ -331,9 +334,9 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
}
if (sr-autocomp_active) {
- sr_class-disable(sr-voltdm, 1);
+ sr_class-disable(sr-voltdm, sr-voltdm_cdata, 1);
if (sr_class-deinit
- sr_class-deinit(sr-voltdm,
+ sr_class-deinit(sr-voltdm, sr-voltdm_cdata,
sr_class-class_priv_data)) {
dev_err(sr-pdev-dev,
%s: SR[%d]Class deinitialization failed\n,
@@ -736,7 +739,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
return 0;
/* Configure SR */
- ret = sr_class-configure(voltdm);
+ ret = sr_class-configure(voltdm, sr-voltdm_cdata);
if (ret)
return ret;
@@ -911,7 +914,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
return;
}
- sr_class-enable(voltdm);
+ sr_class-enable(voltdm, sr-voltdm_cdata);
}
/**
@@ -944,7 +947,7 @@ void omap_sr_disable(struct voltagedomain *voltdm)
return;
[PATCH 14/20] ARM: OMAP3+: SmartReflex Class3: restrict CPU to run on
From: Nishanth Menon n...@ti.com
Use SmartReflex AVS Class3 initialization only for OMAP343x family of
processors.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 9dcda93..735937a 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -11,6 +11,7 @@
* published by the Free Software Foundation.
*/
+#include plat/cpu.h
#include smartreflex.h
static int sr_class3_enable(struct voltagedomain *voltdm,
@@ -58,6 +59,10 @@ static struct omap_sr_class_data class3_data = {
/* Smartreflex Class3 init API to be called from board file */
static int __init sr_class3_init(void)
{
+ /* Enable this class only for OMAP343x */
+ if (!cpu_is_omap343x())
+ return -EINVAL;
+
pr_info(SmartReflex Class3 initialized\n);
return sr_register_class(class3_data);
}
--
1.7.5.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
[PATCH 15/20] ARM: OMAP3+: SmartReflex: add missing platform_set_drvdata()
From: Felipe Balbi ba...@ti.com
That's very useful to fetch the correct struct sr_info
from the PM handlers.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 65e1a7c..eacf4b3 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1062,6 +1062,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
return -ENOMEM;
}
+ platform_set_drvdata(pdev, sr_info);
+
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
ret = -EINVAL;
--
1.7.5.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
[PATCH 16/20] ARM: OMAP3+: SmartReflex: move late_initcall() closer to its argument
From: Felipe Balbi ba...@ti.com
no functional changes, trivial patch.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index eacf4b3..c86880d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1291,12 +1291,12 @@ static int __init sr_init(void)
return 0;
}
+late_initcall(sr_init);
static void __exit sr_exit(void)
{
platform_driver_unregister(smartreflex_driver);
}
-late_initcall(sr_init);
module_exit(sr_exit);
MODULE_DESCRIPTION(OMAP Smartreflex Driver);
--
1.7.5.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
[PATCH 17/20] ARM: OMAP3+: SmartReflex: misc cleanups
From: Felipe Balbi ba...@ti.com
There are no functional changes here, only misc cleanups in general:
- re-organize variable declarations,
- converting if {} else if {} else {} into switch statements,
- correct comments typos,
- add/remove white lines to improve readability,
- etc.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 103 +---
1 files changed, 71 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c86880d..c2e3d6b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -36,10 +36,18 @@
#define SR_DISABLE_TIMEOUT 200
struct omap_sr {
+ struct list_headnode;
+ struct platform_device *pdev;
+ struct omap_sr_nvalue_table *nvalue_table;
+ struct voltagedomain*voltdm;
+ struct dentry *dbg_dir;
+
+ unsigned intirq;
+
int srid;
int ip_type;
int nvalue_count;
- boolautocomp_active;
+
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -49,16 +57,13 @@ struct omap_sr {
u32 senp_avgweight;
u32 senp_mod;
u32 senn_mod;
- unsigned intirq;
+
boolirq_enabled;
+ boolautocomp_active;
+
void __iomem*base;
- struct platform_device *pdev;
- struct list_headnode;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain*voltdm;
/* Managed by class driver as needed */
void*voltdm_cdata;
- struct dentry *dbg_dir;
};
/* sr_list contains all the instances of smartreflex module */
@@ -190,11 +195,12 @@ static inline u8 irqstat_to_notifier_v2(u32 status)
static irqreturn_t sr_interrupt(int irq, void *data)
{
- struct omap_sr *sr_info = (struct omap_sr *)data;
+ struct omap_sr *sr_info = data;
u32 status = 0;
u32 value = 0;
- if (sr_info-ip_type == SR_TYPE_V1) {
+ switch (sr_info-ip_type) {
+ case SR_TYPE_V1:
/* Status bits are one bit before enable bits in v1 */
value = notifier_to_irqen_v1(sr_class-notify_flags) 1;
@@ -206,7 +212,8 @@ static irqreturn_t sr_interrupt(int irq, void *data)
sr_modify_reg(sr_info, ERRCONFIG_V1, value, status);
value = irqstat_to_notifier_v1(status);
- } else if (sr_info-ip_type == SR_TYPE_V2) {
+ break;
+ case SR_TYPE_V2:
value = notifier_to_irqen_v2(sr_class-notify_flags);
/* Read the status bits */
status = sr_read_reg(sr_info, IRQSTATUS);
@@ -215,6 +222,11 @@ static irqreturn_t sr_interrupt(int irq, void *data)
/* Clear them by writing back */
sr_write_reg(sr_info, IRQSTATUS, status);
value = irqstat_to_notifier_v2(status);
+ break;
+ default:
+ dev_err(sr_info-pdev-dev, UNKNOWN IP type %d\n,
+ sr_info-ip_type);
+ return IRQ_NONE;
}
/* Attempt some resemblance of recovery! */
@@ -255,6 +267,7 @@ static void sr_set_clk_length(struct omap_sr *sr)
__func__);
return;
}
+
sys_clk_speed = clk_get_rate(sys_ck);
clk_put(sys_ck);
@@ -372,7 +385,7 @@ static int sr_late_init(struct omap_sr *sr_info)
goto error;
}
ret = request_irq(sr_info-irq, sr_interrupt,
- 0, name, (void *)sr_info);
+ 0, name, sr_info);
if (ret)
goto error;
disable_irq(sr_info-irq);
@@ -393,6 +406,7 @@ error:
not function as desired\n, __func__);
kfree(name);
kfree(sr_info);
+
return ret;
}
@@ -513,8 +527,9 @@ static u32 sr_retrieve_nvalue(struct omap_sr *sr, u32
efuse_offs)
*/
int sr_configure_errgen(struct voltagedomain *voltdm)
{
- u32 sr_config, sr_errconfig, errconfig_offs, vpboundint_en;
- u32 vpboundint_st, senp_en = 0, senn_en = 0;
+ u32 sr_config, sr_errconfig, errconfig_offs;
+ u32 vpboundint_en, vpboundint_st;
+ u32 senp_en = 0, senn_en = 0;
u8 senp_shift, senn_shift;
struct omap_sr *sr = _sr_lookup(voltdm);
@@ -533,20
[PATCH 18/20] ARM: OMAP3+: SmartReflex: micro-optimization for sanity check
From: Felipe Balbi ba...@ti.com
val (val != 1) == val 1
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c2e3d6b..2fe882f 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1065,7 +1065,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
/* Sanity check */
- if (val (val != 1)) {
+ if (val 1) {
pr_warning(%s: Invalid argument %lld\n, __func__, val);
return -EINVAL;
}
--
1.7.5.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
[PATCH 19/20] ARM: OMAP3+: SmartReflex: fix the use of debugfs_create_* API
The debugfs_create_* API returns a return code or NULL
in the return ptr in case of problem.
Fix the smartreflex code to take this into account.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2fe882f..96a97c1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1168,7 +1168,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
dev_info(pdev-dev, %s: SmartReflex driver initialized\n, __func__);
if (!sr_dbg_dir) {
sr_dbg_dir = debugfs_create_dir(smartreflex, NULL);
- if (!sr_dbg_dir) {
+ if (IS_ERR_OR_NULL(sr_dbg_dir)) {
ret = PTR_ERR(sr_dbg_dir);
pr_err(%s:sr debugfs dir creation failed(%d)\n,
__func__, ret);
@@ -1185,7 +1185,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
}
sr_info-dbg_dir = debugfs_create_dir(name, sr_dbg_dir);
kfree(name);
- if (IS_ERR(sr_info-dbg_dir)) {
+ if (IS_ERR_OR_NULL(sr_info-dbg_dir)) {
dev_err(pdev-dev, %s: Unable to create debugfs directory\n,
__func__);
ret = PTR_ERR(sr_info-dbg_dir);
@@ -1202,7 +1202,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-err_minlimit);
nvalue_dir = debugfs_create_dir(nvalue, sr_info-dbg_dir);
- if (IS_ERR(nvalue_dir)) {
+ if (IS_ERR_OR_NULL(nvalue_dir)) {
dev_err(pdev-dev, %s: Unable to create debugfs directory
for n-values\n, __func__);
ret = PTR_ERR(nvalue_dir);
--
1.7.5.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
[PATCH 20/20] ARM: OMAP3+: SmartReflex: fix error handling
Fix the code to correctly use IS_ERR and PTR_ERR on the return
values pointers
Reported-by: Sergei Shtylyov sshtyl...@ru.mvista.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 96a97c1..205531b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -536,7 +536,7 @@ int sr_configure_errgen(struct voltagedomain *voltdm)
if (IS_ERR(sr)) {
pr_warning(%s: omap_sr struct for sr_%s not found\n,
__func__, voltdm-name);
- return -EINVAL;
+ return PTR_ERR(sr);
}
if (!sr-clk_length)
@@ -604,7 +604,7 @@ int sr_disable_errgen(struct voltagedomain *voltdm)
if (IS_ERR(sr)) {
pr_warning(%s: omap_sr struct for sr_%s not found\n,
__func__, voltdm-name);
- return -EINVAL;
+ return PTR_ERR(sr);
}
switch (sr-ip_type) {
@@ -655,7 +655,7 @@ int sr_configure_minmax(struct voltagedomain *voltdm)
if (IS_ERR(sr)) {
pr_warning(%s: omap_sr struct for sr_%s not found\n,
__func__, voltdm-name);
- return -EINVAL;
+ return PTR_ERR(sr);
}
if (!sr-clk_length)
@@ -741,7 +741,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
if (IS_ERR(sr)) {
pr_warning(%s: omap_sr struct for sr_%s not found\n,
__func__, voltdm-name);
- return -EINVAL;
+ return PTR_ERR(sr);
}
volt_data = omap_voltage_get_voltdata(sr-voltdm, volt);
@@ -749,7 +749,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
if (IS_ERR(volt_data)) {
dev_warn(sr-pdev-dev, %s: Unable to get voltage table
for nominal voltage %ld\n, __func__, volt);
- return -ENODATA;
+ return PTR_ERR(volt_data);
}
nvalue_reciprocal = sr_retrieve_nvalue(sr, volt_data-sr_efuse_offs);
@@ -839,10 +839,10 @@ int sr_notifier_control(struct voltagedomain *voltdm,
bool enable)
struct omap_sr *sr = _sr_lookup(voltdm);
u32 value = 0;
- if (!sr) {
+ if (IS_ERR(sr)) {
pr_warning(%s: sr corresponding to domain not found\n,
__func__);
- return -EINVAL;
+ return PTR_ERR(sr);
}
if (!sr-autocomp_active)
return -EINVAL;
@@ -1258,7 +1258,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
if (IS_ERR(sr_info)) {
dev_warn(pdev-dev, %s: omap_sr struct not found\n,
__func__);
- return -EINVAL;
+ return PTR_ERR(sr_info);
}
if (sr_info-autocomp_active)
--
1.7.5.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
Re: [PATCH v2 00/19] ARM: OMAP3+: SmartReflex: bugfixes
On Wed, Feb 1, 2012 at 12:58 AM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@ti.com [120131 13:28]: ... OK, let's plan on putting all the smartreflex stuff into a separate branch then. If some changes are needed to the PM code, those should probably be applied first into Kevin's PM branch. Tony, I'll queue up this series (after I get to reviewing them) as well as the changes needed to the PM core code. After that we'll be ready to move. OK thanks. Tony I just submitted v3 of the patch set. Thanks! Jean -- 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: Reg pinmux driver for OMAP based SoC- AM335X
On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote: Hi, * Mohammed, Afzal af...@ti.com [120131 06:04]: Hi Tony, I am working on implementing pincontrol driver for AM335X SoC (OMAP34XX family). Is there any specific plan you have in mind w.r.t incorporating pincontrol driver for OMAP family of SoC's. There was an initial patch for OMAP4 pin control driver, but it seems you were in favour of a DT based approach. As per my understanding after going through few threads (lot more remaining) is that pincontrol driver can be either a DT based or non-DT based (either way we are going out of platform folders), and it seems you prefer a DT based approach (have seen mentioning about pinmux-simple.c). With at least omaps, there are few good reasons to go for a common DT only driver: 1. We already have about 6k lines of mux data and seem to be adding several thousands of lines of mux data each year. 2. The driver does not need this data, it just needs to know how to operate certain kind of mux registers. The data is mostly handy for developers for debugging, and that can be done via debugfs and userspace tools. Tegra pincontrol driver posted recently, seems to use DT to distinguish only the SoC type, with all the pincontrol information for SoC present in Kernel. I would be thankful if you can give me some pointers on how to proceed for AM335X pincontrol driver and/or any work in progress for OMAP pincontrol driver. The plan is to deprecate the existing arch/arm/*omap*/*mux* code, and cut it down to minimum. And then add DT only mux support that should work for at least omap2+. That should work for am335x too. There's currently some discussion going on regarding the pinmux device tree binding and how dynamic mux states should be handled. But I'd assume we'll have basic support available very soon. The driver I'm working leaves all the data out of kernel, and the driver just knows how to handle a pinmux register instances. Tony, Is this hosted or accessible somewhere? Just for reference... Thanks, Vaibhav Then debugging tools can be done in userspace via debugfs to display more detailed SoC specific information. So it might be worth waiting just a little bit longer. If you have resources to spend on the pinmuxing, then creating some userspace tool to display SoC specific information would be nice :) For the userspace tool, we can use the data in arch/arm/mach-omap2/mux*2*.[ch]. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
Hi Russell, On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. Fully agree, and this is exactly the idea of this DMA binding: First argument is always a DMA controller phandle and then you can add 0, 1 or more cells to define extra specifiers dependent of the DMA controller driver expectation. The one cell Grant was referring was just the extra specifier that is needed for a simple DMA engine like the SDMA we have inside OMAP. But the whole idea is to have a flexible enough mechanism to allow any kind of specifier. No more global linear number space like for IRQ! Regards, Benoit -- 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: In many cases softlockup can not be reported after disabling IRQ for long time
(Please don't top-reply.)
On 02/01/2012 10:18 AM, TAO HU wrote:
Hi, Don
Thanks for your feedback!
Unfortunately, the hardlockup depends on NMI which is not available on
ARM (Cortex-A9) per my understanding.
Our system uses OMAP4430. Any more suggestions?
When there is no NMI, touch_nmi_watchdog() actually touches softlockup
watchdog:
#if defined(ARCH_HAS_NMI_WATCHDOG) || defined(CONFIG_HARDLOCKUP_DETECTOR)
#include asm/nmi.h
extern void touch_nmi_watchdog(void);
#else
static inline void touch_nmi_watchdog(void)
{
touch_softlockup_watchdog();
}
#endif
so you need to check if other places calling touch_nmi_watchdog()
especially on ARM.
--
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] mt_ventoux: support for TeeJet Mt.Ventoux board
On 28/12/2011 00:09, Ilya Yanok wrote: This patch adds support for TeeJet Mt.Ventoux board based on TAM3517 SOM. Supported devices: - Serial - Ethernet - NAND - USB host - LCD - Touchscreen - CAN controller - ADC128S converter Signed-off-by: Ilya Yanok ya...@emcraft.com --- Changes from V1: - Fixed indentation (use tabs not spaces) - Fixed over 80 characters lines - Added #if defined(CONFIG_SENSORS_ADCXX_MODULE) to allow adcxx to be a module. - Fixes for compilation with CONFIG_TOUCHSCREEN_ADS7846!=y - Added defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE) - Moved call to omap_ads7846_init to separate small function - Register fixed regulator used for touchscreen only if the driver is enabled - Changed board name (MT_VENTOUX - Mt.Ventoux) Hi Tony, can I ask you about the status of these patches ? I have not seen open comments, do you think they can be merged in your tree ? Thanks, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = -- 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: Reg pinmux driver for OMAP based SoC- AM335X
Hi Tony, On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote: The plan is to deprecate the existing arch/arm/*omap*/*mux* code, and cut it down to minimum. And then add DT only mux support that should work for at least omap2+. That should work for am335x too. There's currently some discussion going on regarding the pinmux device tree binding and how dynamic mux states should be handled. But I'd assume we'll have basic support available very soon. The driver I'm working leaves all the data out of kernel, and the driver just knows how to handle a pinmux register instances. Then debugging tools can be done in userspace via debugfs to display more detailed SoC specific information. So it might be worth waiting just a little bit longer. If you have resources to spend on the pinmuxing, then creating some userspace tool to display SoC specific information would be nice :) For the userspace tool, we can use the data in arch/arm/mach-omap2/mux*2*.[ch]. Thank you for the detailed reply. I will wait for it and willing to help you in its testing. I have been tasked on getting AM335X supported well in mainline, and will move to other aspects of it while waiting. Regards Afzal -- 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: GPIO debounce problems on 3.2
On Wed, Feb 1, 2012 at 8:06 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 31 Jan 2012, Paul Walmsley wrote: Well, whether it's in or out of idle, I'll bet the DEBOUNCENABLE bits are still set to 1 while the debounce clock is off :-( Along these lines, you might try patching omap2_gpio_prepare_for_idle() to turn off the DEBOUNCENABLE bits? Yes that helps. I guess I'll carry this in pandora tree, at least we'll have debounce while more demanding programs/games are running. Don't know how it's all working for Kevin though.. -- Gražvydas -- 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: [linux-pm] [PATCH 0/3] coupled cpuidle state support
Hi Colin, Sorry for this late reply On 27 January 2012 18:32, Colin Cross ccr...@android.com wrote: On Fri, Jan 27, 2012 at 12:54 AM, Vincent Guittot vincent.guit...@linaro.org wrote: On 20 January 2012 21:40, Colin Cross ccr...@android.com wrote: On Fri, Jan 20, 2012 at 12:46 AM, Daniel Lezcano daniel.lezc...@linaro.org wrote: Hi Colin, this patchset could be interesting to resolve in a generic way the cpu dependencies. What is the status of this patchset ? I can't do much with it right now, because I don't have any devices that can do SMP idle with a v3.2 kernel. I've started working on an updated version that avoids the spinlock, but it might be a while before I can test and post it. I'm mostly looking for feedback on the approach taken in this patch, and whether it will be useful for other SoCs besides Tegra and OMAP4. Hi Colin, In your patch, you put in safe state (WFI for most of platform) the cpus that become idle and these cpus are woken up each time a new cpu of the cluster becomes idle. Then, the cluster state is chosen and the cpus enter the selected C-state. On ux500, we are using another behavior for synchronizing the cpus. The cpus are prepared to enter the c-state that has been chosen by the governor and the last cpu, that enters idle, chooses the final cluster state (according to cpus' C-state). The main advantage of this solution is that you don't need to wake other cpus to enter the C-state of a cluster. This can be quite worth full when tasks mainly run on one cpu. Have you also think about such behavior when developing the coupled cpuidle driver ? It could be interesting to add such behavior. Waking up the cpus that are in the safe state is not done just to choose the target state, it's done to allow the cpus to take themselves to the target low power state. On ux500, are you saying you take the cpus directly from the safe state to a lower power state without ever going back to the active state? I once implemented Tegra yes it is that way, and it required lots of nasty synchronization to prevent resetting the cpu at the same time that it was booting due to an interrupt, and I was later told that Tegra can't handle that sequence at all, although I haven't verified it yet. you have to 2 main things to check : - this cpu is the last one to enter an idle state - other cpus are prepared to enter a cluster power state - other cpus are in WFI Vincent On platforms that can't turn the cpus off in a random order, or that can't take a cpu directly from the safe state to the target state, something like these coupled cpuidle patches are required. On platforms that can, the low power modes can be implemented without these patches, although it is very hard to do without race conditions. -- 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 0/2] ARM: OMAP2+: PM: miscellaneous powerdomain-related improvements
On Mon, 2012-01-30 at 13:27 -0800, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: This series optimizes some of the powerdomain-related code in arch/arm/mach-omap2/pm*, and fixes a bug or two. These were noticed while working on the functional powerstate code. Rajendra and Santosh, if you have a spare moment, could you please peek at the OMAP4 LOWPOWERSTATECHANGE part of the second patch? It makes sense to me in theory, but you both would probably know better than I :-) Kevin, want to take this series (assuming folks are happy with it) ? Yes, I'll take this and add the Ack from Santosh. Thanks for the nice cleanup. Will submit after seeing a Tested-by from someone who can test with CORE retention/off on OMAP4 (hint, hint, Tero :) The patches appear to behave nicely on omap4, there are still a couple of quirks in the basic omap4 support though. l3init pd state is not updated properly once we wake-up from device-off (it remains active for a short while during wake-up before switching to idle with hwauto), and cpu1 pwrdm state is not updated properly during hotplug, but these are minor issues and should be fixed elsewhere. You can add: Tested-by: Tero Kristo t-kri...@ti.com Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: In many cases softlockup can not be reported after disabling IRQ for long time
On Wed, Feb 01, 2012 at 10:18:09AM +0800, TAO HU wrote: Hi, Don Thanks for your feedback! Unfortunately, the hardlockup depends on NMI which is not available on ARM (Cortex-A9) per my understanding. Our system uses OMAP4430. Any more suggestions? Ah. I wrongly assumed this is x86. Sorry about that. Ok, so this is what is going on. The softlockup check is just a high priority thread that periodically runs. If preemption is disabled that thread can't run (or any threads for that matter) and a softlockup condition will exist. However, in order to determine that, a periodic hrtimer has to come along and do the actual check. If that check fails, then the warning is printed out. However that accuracy is based on the resolution of that hrtimer which I set to about 1/5 the watchdog threshold or 1 second in this case. Unfortunately, if you disable the irqs, then that timer can't fire and now we don't have a way to trigger the softlockup check until interrupts are re-enabled. On x86, we have a backup plan for disabled interrupts and that is the hardlockup check which rely on NMIs (something that still fires even when interrupts are disabled). If on ARM you don't have NMIs, then it will be difficult to check for softlockups when interrupts are disabled. Though I do recall sparc doing something clever like using IRQ0 as a special purpose IRQ to emulate an NMI (IOW, software purposely avoided masking IRQ0). So when an interrupt came in on that irq, it was never blocked and always ran based on the irq nesting rules. I don't know ARM well enough to give any solution for your problem, but my reason above is why it isn't working the way you intended. Cheers, Don On Tue, Jan 31, 2012 at 11:47 PM, Don Zickus dzic...@redhat.com wrote: On Tue, Jan 31, 2012 at 03:28:09PM +0800, TAO HU wrote: Resend with a new subject On Wed, Jan 25, 2012 at 4:24 PM, TAO HU tgh...@motorola.com wrote: Hi, All While playing kernel 3.0.8 with below test code, it does NOT report any softlockup with 60%~70% chances. NOTE: the softlockup timeout is set to 10 seconds (i.e. watchdog_thresh=5) in my test. ... ... preempt_disable(); local_irq_disable(); for (i = 0; i 20; i++) mdelay(1000); local_irq_enable(); preempt_enable(); ... ... However, if I remove local_irq_disable()/local_irq_enable() it will report softlockup with no problem. I believe it is due to that after local_irq_enable() touch_softlockup_watchdog() is called prior softlockup timer. Hi Hu, Honestly, you should be getting hardlockup warnings if you are disabling interrupts. Do you see anything in the console output? Cheers, Don -- Best Regards Hu Tao -- 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: [linux-pm] [PATCH 0/3] coupled cpuidle state support
On Wed, Feb 01, 2012 at 12:13:26PM +, Vincent Guittot wrote: [...] In your patch, you put in safe state (WFI for most of platform) the cpus that become idle and these cpus are woken up each time a new cpu of the cluster becomes idle. Then, the cluster state is chosen and the cpus enter the selected C-state. On ux500, we are using another behavior for synchronizing the cpus. The cpus are prepared to enter the c-state that has been chosen by the governor and the last cpu, that enters idle, chooses the final cluster state (according to cpus' C-state). The main advantage of this solution is that you don't need to wake other cpus to enter the C-state of a cluster. This can be quite worth full when tasks mainly run on one cpu. Have you also think about such behavior when developing the coupled cpuidle driver ? It could be interesting to add such behavior. Waking up the cpus that are in the safe state is not done just to choose the target state, it's done to allow the cpus to take themselves to the target low power state. On ux500, are you saying you take the cpus directly from the safe state to a lower power state without ever going back to the active state? I once implemented Tegra yes it is But if there is a single power rail for the entire cluster, when a CPU is prepared for shutdown this means that you have to save the context and clean L1, maybe for nothing since if other CPUs are up and running the CPU going idle can just enter a simple standby wfi (clock-gated but power on). With Colin's approach, context is saved and L1 cleaned only when it is almost certain the cluster is powered off (so the CPUs). It is a trade-off, I am not saying one approach is better than the other; we just have to make sure that preparing the CPU for possible shutdown is better than sending IPIs to take CPUs out of wfi and synchronize them (this happens if and only if CPUs enter coupled C-states). As usual this will depend on use cases (and silicon implementations :) ) It is definitely worth benchmarking them. Lorenzo -- 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: GPIO debounce problems on 3.2
Grazvydas Ignotas nota...@gmail.com writes: On Wed, Feb 1, 2012 at 8:06 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 31 Jan 2012, Paul Walmsley wrote: Well, whether it's in or out of idle, I'll bet the DEBOUNCENABLE bits are still set to 1 while the debounce clock is off :-( Along these lines, you might try patching omap2_gpio_prepare_for_idle() to turn off the DEBOUNCENABLE bits? Yes that helps. I guess I'll carry this in pandora tree, at least we'll have debounce while more demanding programs/games are running. Care to share the patch? It might be worth merging until we have a full solution. Don't know how it's all working for Kevin though.. Now I'm not so sure either... At first I thought it was because I was getting IO ring wakeups, but using vanilla 3.2, MPU, CORE PER are staying on due to the (broken) UART constraint, so I'm getting module-level wakeups, but haven't dug into why. 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
[PATCH] OMAP3: Add Corscience Tricorder board
Tricorder is a board which is very similar to the Devkit8000.
It is designed as a base platform for further medical devices.
www.corscience.de/en/medical-engineering/products/multiparameter/mp10-board.html
Signed-off-by: Thomas Weber we...@corscience.de
---
arch/arm/mach-omap2/Kconfig |6 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-tricorder.c| 379 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
sound/soc/omap/Kconfig |2 +-
sound/soc/omap/omap3beagle.c |6 +-
6 files changed, 392 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-tricorder.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41e6612..980c11c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -159,6 +159,12 @@ config MACH_DEVKIT8000
default y
select OMAP_PACKAGE_CUS
+config MACH_TRICORDER
+ bool Tricorder board
+ depends on ARCH_OMAP3
+ default y
+ select OMAP_PACKAGE_CUS
+
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fc9b238..83e8156 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -204,6 +204,7 @@ obj-$(CONFIG_MACH_OVERO)+= board-overo.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
+obj-$(CONFIG_MACH_TRICORDER) += board-tricorder.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-tricorder.c
b/arch/arm/mach-omap2/board-tricorder.c
new file mode 100644
index 000..bafe6a7
--- /dev/null
+++ b/arch/arm/mach-omap2/board-tricorder.c
@@ -0,0 +1,379 @@
+/*
+ * board-tricorder.c - Corscience Tricorder board
+ *
+ * Copyright (C) 2012
+ * Corscience GmbH Co. KG, www.corscience.de
+ * Thomas Weber we...@corscience.de
+ *
+ * Modified from mach-omap2/board-omap3beagle.c
+ *
+ * Initial code: Syed Mohammed Khasim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/leds.h
+#include linux/gpio.h
+#include linux/input.h
+#include linux/gpio_keys.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mmc/host.h
+
+#include linux/regulator/machine.h
+#include linux/i2c/twl.h
+
+#include mach/hardware.h
+#include mach/id.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/flash.h
+
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/usb.h
+
+#include linux/input/matrix_keypad.h
+#include linux/interrupt.h
+
+#include linux/i2c/at24.h
+
+#include sdram-micron-mt46h32m32lf-6.h
+
+#include common.h
+#include mux.h
+#include hsmmc.h
+#include common-board-devices.h
+
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition tricorder_nand_partitions[] = {
+ /* All the partitionsizes are listed in terms of NAND block size */
+ {
+ .name = U-Boot SPL,
+ .offset = 0,
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 15 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot Env,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x26 */
+ .size = 1 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = Kernel,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = File System,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap2_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= 126,
+ },
+ {} /*
Re: Adding remoteproc/rpmsg to linux-next
On Wednesday 01 February 2012, Ohad Ben-Cohen wrote: On Thu, Dec 22, 2011 at 5:22 PM, Arnd Bergmann a...@arndb.de wrote: If you think you need more Acks or if there are other reasons to have it go through arm-soc, please tell me and I'll try harder to find the time for a proper review. Any chance you could carve out some time for reviewing remoteproc and rpmsg [1] ? I will. I hope we could either get your Acks on the patches or even have it go through arm-soc for 3.4. Yes, I think it's best to have it merged through arm-soc, in case Linus is more likely to take it from there than pull from your tree. Arnd -- 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: Adding remoteproc/rpmsg to linux-next
On Wed, Feb 1, 2012 at 6:57 PM, Arnd Bergmann a...@arndb.de wrote: I will. Thanks. Yes, I think it's best to have it merged through arm-soc, in case Linus is more likely to take it from there than pull from your tree. Great, thanks. Ohad. -- 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: [linux-pm] [PATCH 0/3] coupled cpuidle state support
On Wed, Feb 1, 2012 at 6:59 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: On Wed, Feb 01, 2012 at 12:13:26PM +, Vincent Guittot wrote: [...] In your patch, you put in safe state (WFI for most of platform) the cpus that become idle and these cpus are woken up each time a new cpu of the cluster becomes idle. Then, the cluster state is chosen and the cpus enter the selected C-state. On ux500, we are using another behavior for synchronizing the cpus. The cpus are prepared to enter the c-state that has been chosen by the governor and the last cpu, that enters idle, chooses the final cluster state (according to cpus' C-state). The main advantage of this solution is that you don't need to wake other cpus to enter the C-state of a cluster. This can be quite worth full when tasks mainly run on one cpu. Have you also think about such behavior when developing the coupled cpuidle driver ? It could be interesting to add such behavior. Waking up the cpus that are in the safe state is not done just to choose the target state, it's done to allow the cpus to take themselves to the target low power state. On ux500, are you saying you take the cpus directly from the safe state to a lower power state without ever going back to the active state? I once implemented Tegra yes it is But if there is a single power rail for the entire cluster, when a CPU is prepared for shutdown this means that you have to save the context and clean L1, maybe for nothing since if other CPUs are up and running the CPU going idle can just enter a simple standby wfi (clock-gated but power on). With Colin's approach, context is saved and L1 cleaned only when it is almost certain the cluster is powered off (so the CPUs). It is a trade-off, I am not saying one approach is better than the other; we just have to make sure that preparing the CPU for possible shutdown is better than sending IPIs to take CPUs out of wfi and synchronize them (this happens if and only if CPUs enter coupled C-states). As usual this will depend on use cases (and silicon implementations :) ) It is definitely worth benchmarking them. I'm less worried about performance, and more worried about race conditions. How do you deal with the following situation: CPU0 goes to WFI, and saves its state CPU1 goes idle, and selects a deep idle state that powers down CPU0 CPU1 saves is state, and is about to trigger the power down CPU0 gets an interrupt, restores its state, and modifies state (maybe takes a spinlock during boot) CPU1 cuts the power to CPU0 On OMAP4, the race is handled in hardware. When CPU1 tries to cut the power to the blocks shared by CPU0 the hardware will ignore the request if CPU0 is not in WFI. On Tegra2, there is no hardware support and I had to handle it with a spinlock implemented in scratch registers because CPU0 is out of coherency when it starts booting and ldrex/strex don't work. I'm not convinced my implementation is correct, and I'd be curious to see any other implementations. -- 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 3/3] arm:omap:omap4: Hook-up am33xx support to existing prm code
Hiremath, Vaibhav hvaib...@ti.com writes:
On Tue, Jan 24, 2012 at 04:05:32, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
On Wed, Jan 11, 2012 at 21:48:25, Hiremath, Vaibhav wrote:
On Tue, Jan 10, 2012 at 23:39:22, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
AM33XX PRM module (L4_WK domain) will be treated as another seperate
partition in _prm_bases[] table.
Also, since cpu_is_omap34xx check is true for am33xx family of
devices, we must check cpu_is_am33xx fisrt, in order to follow
omap4 execution path.
Can you remind me why cpu_is_omap34xx() is true for AM33xx family?
Yeah sure...
Kevin,
As mentioned before, the main idea behind bringing am33xx under omap34xx
was mainly due to cortex-A8 family of devices.
It has been discussed and aligned long time back, so
please refer to the thread -
http://www.spinics.net/lists/linux-omap/msg41046.html
Multiple versions of -
http://www.spinics.net/lists/linux-omap/msg45505.html
Thanks,
Vaibhav
These AM3xxx devices make my brain hurt.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/prminst44xx.c
b/arch/arm/mach-omap2/prminst44xx.c
index 3d9894f..fcc4123 100644
--- a/arch/arm/mach-omap2/prminst44xx.c
+++ b/arch/arm/mach-omap2/prminst44xx.c
@@ -19,6 +19,7 @@
#include common.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include prm-regbits-44xx.h
#include prcm44xx.h
@@ -31,6 +32,7 @@ static u32 _prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
[OMAP4430_CM2_PARTITION]= 0,
[OMAP4430_SCRM_PARTITION] = 0,
[OMAP4430_PRCM_MPU_PARTITION] =
OMAP2_L4_IO_ADDRESS(OMAP4430_PRCM_MPU_BASE),
+ [AM33XX_PRM_PARTITION] =
AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRM_BASE),
};
I'm not crazy about just extending the normal OMAP4 table.
If it is required then yes (with proper comment).
That would
imply that with each OMAP4 derivatve we keep extending this table.
I would say anyway we will end up adding
Cpu_is_xxx everywhere as we add new table for derivatives.
Instead, how about rename this to one to omap44xx_prm_bases[], then
create a new one called am33xx_prm_bases[]. Then, at init time, assing
_prm_bases to the right one based on cpu_is_.
Just wanted to avoid cpu_is_ check here. Will specific comment
wouldn't
help here (I have clearly mentioned in patch description), may be in c
file
it is required?
OR
you want to be clearly separate table for code readability.
Kevin,
Any comments on this? Should I stick to what is implemented now?
cpu_is_* checks are acceptable at init time, and we use them often to
initialize SoC-dependent tables/arrays etc.
Kevin,
Sorry for delayed response,
Here is the ugly part, which I was referring to -
1) _prm_bases variable is static variable to the prminst44xx.c
2) prminst44xx.c file doesn't contain any boot time __init function,
So I have to either add exported __init function OR extern __prm_bases
variable and initialize somewhere outside this file.
3) Even if I create 2 separate variables, for example,
static u32 omap44xx_prm_bases[OMAP4_MAX_PRCM_PARTITIONS] = {
...
};
static u32 omap33xx_prm_bases[AM33XX_MAX_PRCM_PARTITIONS] = {
...
};
Makes it difficult and messy to handle inside below code,
BUG_ON doesn't make sense from AM335x perspective.
Then you can change the BUG_ON.
static u32 omap44xx_max_partitions = ARRAY_SIZE(omap44xx_prm_bases)
static u32 am33xx_max_partitions = ARRAY_SIZE(am33xx_prm_bases)
static u32 max_partitions.
At init time, assign max_partitions when you assign prm_bases, then
change the BUG_ON() to be something like:
BUG_ON(part = max_partitions || part == INVALID_PARTITION)
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: PM debug: fix the use of debugfs_create_* API
Jean Pihet jean.pi...@newoldbits.com writes: Check the return code pointer value from debugfs_create_dir for error or NULL. Also added an additional check to prevent the creation of a 'suspend' entry at the debugfs root in case a power domain directory cannot be created. Signed-off-by: Jean Pihet j-pi...@ti.com Thanks, queing for v3.4. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/3] coupled cpuidle state support
On Wed, Feb 01, 2012 at 05:30:15PM +, Colin Cross wrote: On Wed, Feb 1, 2012 at 6:59 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: On Wed, Feb 01, 2012 at 12:13:26PM +, Vincent Guittot wrote: [...] In your patch, you put in safe state (WFI for most of platform) the cpus that become idle and these cpus are woken up each time a new cpu of the cluster becomes idle. Then, the cluster state is chosen and the cpus enter the selected C-state. On ux500, we are using another behavior for synchronizing the cpus. The cpus are prepared to enter the c-state that has been chosen by the governor and the last cpu, that enters idle, chooses the final cluster state (according to cpus' C-state). The main advantage of this solution is that you don't need to wake other cpus to enter the C-state of a cluster. This can be quite worth full when tasks mainly run on one cpu. Have you also think about such behavior when developing the coupled cpuidle driver ? It could be interesting to add such behavior. Waking up the cpus that are in the safe state is not done just to choose the target state, it's done to allow the cpus to take themselves to the target low power state. On ux500, are you saying you take the cpus directly from the safe state to a lower power state without ever going back to the active state? I once implemented Tegra yes it is But if there is a single power rail for the entire cluster, when a CPU is prepared for shutdown this means that you have to save the context and clean L1, maybe for nothing since if other CPUs are up and running the CPU going idle can just enter a simple standby wfi (clock-gated but power on). With Colin's approach, context is saved and L1 cleaned only when it is almost certain the cluster is powered off (so the CPUs). It is a trade-off, I am not saying one approach is better than the other; we just have to make sure that preparing the CPU for possible shutdown is better than sending IPIs to take CPUs out of wfi and synchronize them (this happens if and only if CPUs enter coupled C-states). As usual this will depend on use cases (and silicon implementations :) ) It is definitely worth benchmarking them. I'm less worried about performance, and more worried about race conditions. How do you deal with the following situation: CPU0 goes to WFI, and saves its state CPU1 goes idle, and selects a deep idle state that powers down CPU0 CPU1 saves is state, and is about to trigger the power down CPU0 gets an interrupt, restores its state, and modifies state (maybe takes a spinlock during boot) CPU1 cuts the power to CPU0 On OMAP4, the race is handled in hardware. When CPU1 tries to cut the power to the blocks shared by CPU0 the hardware will ignore the request if CPU0 is not in WFI. On Tegra2, there is no hardware support and I had to handle it with a spinlock implemented in scratch registers because CPU0 is out of coherency when it starts booting and ldrex/strex don't work. I'm not convinced my implementation is correct, and I'd be curious to see any other implementations. That's a problem you solved with coupled C-states (ie your example in the cover letter), where the primary waits for other CPUs to be reset before issuing the power down command, right ? At that point in time secondaries cannot wake up (?) and if wfi (ie power down) aborts you just take the secondaries out of reset and restart executing simultaneously, correct ? It mirrors the suspend behaviour, which is easier to deal with than completely random idle paths. It is true that this should be managed by the PM HW; if HW is not capable of managing these situations things get nasty as you highlighted. And it is also true ldrex/strex on cacheable memory might not be available in those early warm-boot stages. I came up with a locking algorithm on strongly ordered memory to deal with that, but I am still not sure it is something we really really need. I will test coupled C-state code ASAP, and come back with feedback. Thanks, Lorenzo -- 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: Reg pinmux driver for OMAP based SoC- AM335X
* Hiremath, Vaibhav hvaib...@ti.com [120201 01:34]: On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote: The driver I'm working leaves all the data out of kernel, and the driver just knows how to handle a pinmux register instances. Tony, Is this hosted or accessible somewhere? Just for reference... Still few more things to fix before I can post it.. Tony -- 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: OMAP HDQ: was Re: DSS2/PM on 3.2 broken?
On Wed, 1 Feb 2012, NeilBrown wrote: On Fri, 27 Jan 2012 23:02:51 -0700 (MST) Paul Walmsley p...@pwsan.com wrote: Since the HDQ module doesn't support the idle protocol, the target clock FSM in the CM is what should determine whether the module is considered idle or not. And as long as the bit in the CM_FCLKEN register corresponding to HDQ_FCLK is set, the FSM should consider the module as active, and the clockdomain should not be allowed to go inactive. I write should. Given that big caution at the bottom of section 20.4.5 System Power Management and Wakeup, this appears to have not been correctly implemented. Can you help me understand why you say should there. You seem to be implying that a down-stream clock gate should cause an upstream clock to stay active, but that doesn't make sense to me given the presence of the much richer SIDLE framework. Also I cannot find it in the TRM (though there a lots of words in there and I might have missed some). Functional clocks are almost never auto-idled by the hardware[*]. So when the kernel sets a CM_FCLKEN* bit in a register for a clockdomain, that clockdomain should never go inactive. As I understand it, main functional clocks on I/O IP blocks aren't automatically idled for a few basic reasons. One is that the main functional clock has to be running in order for register accesses to succeed, so initiators have to have some way of preventing it from going off while they are interacting with it. The PRCM doesn't snoop the interconnect :-) Another is that some of the I/O IP blocks can continue to operate after they've idle-acked. They idle-ack, which could allow clocks to be gated to interconnects, but the module can still continue to fill or drain FIFOs, which obviously requires a clock. This was what is not working correctly with the UARTs... some events that generate interrupts can't generate SWAKEUPs :-( And there are a few other lesser reasons that I am aware of that are not worth going into at this point. Even interface clock auto-idle works in a different way than what one might expect. Even if a module idle-acks, the interface clock will stay on until the interface clockdomain can go idle. So suppose that you have an interface clockdomain with 20 modules and 19 of them idle-ack. The interface clock stays supplied to those 19 modules until the 20th idle-acks. This ensures that an initiator access to a target module will succeed. (This is true for OMAP2/3; OMAP4 does something more clever.) In general, setting ICLKEN/FCLKEN bits to zero doesn't shut down clocks directly; it simply indicates that the clocks may be shut down once other users of that clock also indicate that they don't need the clocks. Most modules use SIDLE to keep the upstream clock active. It's the other way around. The device driver uses the FCLKEN bits to keep the upstream clock active :-) Disabling AUTO_HDQ is probably a reasonable workaround. It would prevent the CORE_L4 clockdomain from going inactive, and that happens to be where the functional clock originates from, also. We have a partial facility to handle this type of bug in the existing code. Could you please try the patch enclosed at the bottom of this E-mail and see if it helps? Yes, that patch fixes my problem too - the HDQ keeps working. Great; thanks for the test. We'll implement a variant of that for mainline. Please also let me know if you wind up having wakeup problems with HDQ, especially with MPU off-mode. If you don't, obviously that's good; but I suspect you might want it at some point. (it's a bit smoke-and-mirrors though .. I want fclk to stay on, so let's make sure iclk doesn't autoidle, because we *know* they have the same source :-) A theoretically clearer workaround would be to place the main functional clock's clockdomain into software-supervised wakeup as long as the hwmod code thinks that the HDQ IP block is active. But that is not so easy to implement with our current codebase. We'd need to implement usecounting for our clockdomain control operations, and the other PM code assumes that it can force clockdomain states directly. So I'm not too eager to do that rewrite at the moment given all the other stuff that's going on... Meanwhile, this fix targets the target clock FSM, and that's where the bug is, albeit on a slightly different path. It's also functionally equivalent, given that the HDQ apparently can't send wakeups. - Paul *. Main functional clocks can be autoidled if they are interface+functional clocks. This is the case for some purely computational, non-I/O IP blocks such as MAILBOXES. Those combined interface+functional clocks are controlled via ICLKEN registers, not FCLKEN registers. -- 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
Re: GPIO debounce problems on 3.2
On Wed, 1 Feb 2012, Grazvydas Ignotas wrote: On Wed, Feb 1, 2012 at 8:06 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 31 Jan 2012, Paul Walmsley wrote: Well, whether it's in or out of idle, I'll bet the DEBOUNCENABLE bits are still set to 1 while the debounce clock is off :-( Along these lines, you might try patching omap2_gpio_prepare_for_idle() to turn off the DEBOUNCENABLE bits? Yes that helps. I guess I'll carry this in pandora tree, at least we'll have debounce while more demanding programs/games are running. Yep definitely. When only I/O wakeups can occur on those GPIO lines (when CORE/PER is in a low-power state), they are intrinsically debounced :-) So it should be fine. You are re-enabling the DEBOUNCENABLE bits in omap2_gpio_resume_after_idle() I assume? If so, that should be a good workaround for mainline too. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/5] OMAP4: hwmod: Add names for DMIC memory address space
Hi Péter, On Wed, 1 Feb 2012, Peter Ujfalusi wrote: On 01/25/2012 11:23 PM, Paul Walmsley wrote: Okay, thanks, queued for 3.3-rc. It seams this patch did not made it to 3.3-rc2. We still have broken audio out of box on SDP4430/Blaze. Can you make sure that this will be queued for rc3? No sadly I can't. There are at least three levels of maintainers above me in my mainline submission path. As you may have seen, I've sent the patch to Tony and he has pulled the series: http://www.spinics.net/lists/linux-omap/msg63525.html so I've done what I can. - Paul
Re: [PATCH 1/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
On Tue, 31 Jan 2012, Kevin Hilman wrote: Kevin Hilman khil...@ti.com writes: Paul Walmsley p...@pwsan.com writes: Remove some superfluous calls to pwrdm_clear_all_prev_pwrst(). pwrdm_pre_transition(), which appears a few lines after these calls, invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no need to do it twice. It looks like these two for OMAP4 are surpurfluous since the immediately follow a call to pwrdm_pre_transition() as well. Santosh/Rajendra, please confirm/ack. So after the discussion, do you want to fold this into the original patch, or do you want a separate patch? Your changes make sense to me. I am fine with you adding them into the original patch and adding some credit for you into the commit message. Or you can create a separate patch. N.B., I haven't looked at this file before. There are a few other things that don't look right that hopefully someone can take the initiative to fix. For example, those calls to mpuss_clear_prev_logic_pwrst() and cpu_clear_prev_logic_pwrst() should be removed as well. That should be done by pwrdm_clear_all_prev_pwrst() in mach-omap2/powerdomain44xx.c. Currently it's not, so that needs to be patched. Also all of the open-coded powerdomain register accesses in omap-mpuss-lowpower.c should be removed - those should all go through pwrdm_*() functions... - Paul -- 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] staging: tidspbridge: enable watchdog by default
On Wed, Feb 1, 2012 at 2:11 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Feb 1, 2012 at 5:22 AM, Justin P. Mattock justinmatt...@gmail.com wrote: not sure if I see this warning or not on my machine, but is there a fix for the warning? I would rather see that, than hide it with setting: default y (if that's what its doing!) No, there's no fix. IIRC Omar said it would not be easy. Indeed, the ideal would be the ability to turn off the config option but on the dsp side (when compiling the baseimage), however the release package only contains binaries given that the source is not open. I have been exploring introducing a flag in the shared memory area which would require a new baseimage release. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE
On Fri, 27 Jan 2012, Sakari Ailus wrote: MPU and CORE should stay awake if there is CAM domain ACTIVE. I guess this should read that MPU and CORE should stay awake if the ISP IP block is active? This is because that module doesn't have wake-up capability. The original patch was written by Jouni Högander in 2008 and this is the last part left of it which is not in upstream yet. I wonder if the approach taken in the patch is valid these days; nevertheless it seems to do the job... Unfortunately we do not yet have a Linux generic framework for this sort of thing yet, and Tony doesn't want to add more platform_data function pointers. So in the interim, would suggest following an approach similar to the patch at the bottom of this message: http://www.spinics.net/lists/linux-omap/msg63495.html using PM QoS constraints to get what you want. Make sure you keep the big nasty comment in there. That way, when someone manages to get some generic support in for it, we can convert it over easily. We should probably be marking all of these IP blocks with broken wakeup with a hwmod flag also, for warning purposes if nothing else. Warning, missing IP block wakeup line; energy consumption will be higher than necessary; please annoy your silicon vendor - Paul
Re: GPIO debounce problems on 3.2
On Wed, Feb 1, 2012 at 5:30 PM, Kevin Hilman khil...@ti.com wrote:
Grazvydas Ignotas nota...@gmail.com writes:
On Wed, Feb 1, 2012 at 8:06 AM, Paul Walmsley p...@pwsan.com wrote:
Along these lines, you might try patching omap2_gpio_prepare_for_idle() to
turn off the DEBOUNCENABLE bits?
Yes that helps. I guess I'll carry this in pandora tree, at least
we'll have debounce while more demanding programs/games are running.
Care to share the patch? It might be worth merging until we have a full
solution.
Attached.
Don't know how it's all working for Kevin though..
Now I'm not so sure either...
At first I thought it was because I was getting IO ring wakeups, but
using vanilla 3.2, MPU, CORE PER are staying on due to the (broken)
UART constraint, so I'm getting module-level wakeups, but haven't dug
into why.
Maybe the CPU is sometimes busy and debounce clock is enabled long
enough for it to work.
--
Gražvydas
From f384b2b48970db36a751f454d1ef10910775b5d2 Mon Sep 17 00:00:00 2001
From: Grazvydas Ignotas nota...@gmail.com
Date: Wed, 1 Feb 2012 15:10:52 +0200
Subject: [PATCH] gpio/omap: disable debounce on idle
After omap2_gpio_prepare_for_idle call it's not guaranteed that given
GPIO module will hit idle, so it might end up in active state but with
debounce clock disabled, which will break input functionality.
Disable debounce feature on idle to avoid this problem.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/gpio/gpio-omap.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0b05629..4f8e8ba 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1347,9 +1347,19 @@ void omap2_gpio_prepare_for_idle(int off_mode)
for (i = min; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
+ void __iomem *reg;
u32 l1 = 0, l2 = 0;
int j;
+ /*
+ * Disable debounce since clock disable below will cause
+ * problems if GPIO module doesn't go idle for some reason.
+ */
+ if (bank-dbck_enable_mask != 0) {
+ reg = bank-base + bank-regs-debounce_en;
+ __raw_writel(0, reg);
+ }
+
for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
clk_disable(bank-dbck);
@@ -1415,12 +1425,18 @@ void omap2_gpio_resume_after_idle(void)
min = 1;
for (i = min; i gpio_bank_count; i++) {
struct gpio_bank *bank = gpio_bank[i];
+ void __iomem *reg;
u32 l = 0, gen, gen0, gen1;
int j;
for (j = 0; j hweight_long(bank-dbck_enable_mask); j++)
clk_enable(bank-dbck);
+ if (bank-dbck_enable_mask != 0) {
+ reg = bank-base + bank-regs-debounce_en;
+ __raw_writel(bank-dbck_enable_mask, reg);
+ }
+
if (!workaround_enabled)
continue;
--
1.7.0.4
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On Tue, Jan 31, 2012 at 10:26:19PM +0100, Cousson, Benoit wrote: Hi Grant, On 1/28/2012 7:06 PM, Grant Likely wrote: On Fri, Jan 27, 2012 at 06:29:22PM +0100, Cousson, Benoit wrote: +EXPORT_SYMBOL_GPL(of_dma_to_resource); How do you see this function being used? I ask because I don't want to add it to the DT device registration code (of_platform_populate()). Yep, that was the plan :-) I actually want to reduce the amount of work being done at device registration time and push resolving irqs out to the device drivers. The reason for this is so that drivers can resolve irqs supplied by other device drivers once I've got deferred probe merged. That make senses, but that will break all the drivers that are expecting IRQ and DMA resources to be already there at probe time. These drivers are still relying on the good old platform_get_resource() API. That will add some extra effort to the drivers migration to DT:-( They will be broken anyway because there isn't any way for the core code to decode DMA properties. There isn't a consistent way that drivers use DMA resources or any complete data about what dma engine those resources refer to. Unlike irqs, there is no global DMA channel number space available to driver, which makes it really hard to generically populate DMA channels into the resource table. It really is much better to resolve it at .probe() time where the driver can get unambiguous information. Plus, as I mentioned, it plays better with deferred probe. This isn't currently possible because a lot of drivers parse the resources table directly. Those users first need to be migrated to use the platform_get_irq*() APIs. But even in that case, the device should still have the resources populated before probe. I'm not sure I fully understand what you mean here. Ah, but once it is in an API, hooks can be implemented in the platform_get_*() APIs to resolve relevant things at call time instead of at device registration time. DMAs have the same issue, so it is important that device drivers resolve the dma specifier at .probe() time so that it can use dma channels supplied by a dma device driver. I suspect having a common of_parse_named_phandle_with_args() will useful when needing to resolve named dma resources from device drivers. So it looks like you really have a plan to deprecate all the platform_get_resource APIs usage from driver? At least for DMA and IRQ? I definitely would like to be rid of (or refactor) the DMA get APIs from drivers because I don't think they provide enough information about how DMA channels are hooked up (as described above). However, I actually prefer the platform_get_ API for irqs over accessing the resource table directly. I can hook into it if/when I change irqs to be resolved at .probe time. g. -- 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] arm/dts: OMAP3: Add omap3evm and am335xevm support
On Wed, Feb 01, 2012 at 11:57:00AM +0530, Vaibhav Hiremath wrote: TI's OMAP3EVM and AM335xEVM are software development boards available for OMAP35x(AM/DM37x) and AM335x devices respectively; and these devices are considered under omap3 family. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Tony Lindgren t...@atomide.com Applied, thanks. g. --- .../devicetree/bindings/arm/omap/omap.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..ce78498 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -41,3 +41,9 @@ Boards: - OMAP4 PandaBoard : Low cost community board compatible = ti,omap4-panda, ti,omap4430 + +- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x + compatible = ti,omap3-evm, ti,omap3 + +- AM335X EVM : Software Developement Board for AM335x + compatible = ti,am335x-evm, ti,am33xx, ti,omap3 -- 1.7.0.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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/2] ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
On Thu, Feb 2, 2012 at 12:57 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 31 Jan 2012, Kevin Hilman wrote: Kevin Hilman khil...@ti.com writes: Paul Walmsley p...@pwsan.com writes: Remove some superfluous calls to pwrdm_clear_all_prev_pwrst(). pwrdm_pre_transition(), which appears a few lines after these calls, invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no need to do it twice. It looks like these two for OMAP4 are surpurfluous since the immediately follow a call to pwrdm_pre_transition() as well. Santosh/Rajendra, please confirm/ack. So after the discussion, do you want to fold this into the original patch, or do you want a separate patch? Your changes make sense to me. I am fine with you adding them into the original patch and adding some credit for you into the commit message. Or you can create a separate patch. N.B., I haven't looked at this file before. There are a few other things that don't look right that hopefully someone can take the initiative to fix. For example, those calls to mpuss_clear_prev_logic_pwrst() and cpu_clear_prev_logic_pwrst() should be removed as well. That should be done by pwrdm_clear_all_prev_pwrst() in mach-omap2/powerdomain44xx.c. Currently it's not, so that needs to be patched. We(rajendra and myself) discussed this some time back with Benoit and we agreed that for CPU and MPU power domains which are needed very early in the PM power up sequence, we can do direct APIs.. These calls were in critical path and the PD API's proposed for context clear and logic clear were use to iterate over all power domains. It is only recently we got clear context etc some reasonable form even though it still iterates over all hwmod etc which is really overhead. Also you need to create 'pdev' etc for context-loss kind of APIs and we all thought that that makes things un-ncessary complicated and lengthy. Also all of the open-coded powerdomain register accesses in omap-mpuss-lowpower.c should be removed - those should all go through pwrdm_*() functions... I will have another look at the code with your recent power domain clean-ups and see what all can be moved to generic APIs. Regards Santosh -- 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
