RE: [pandaboard] device tree does not work
Shifting thread to linux-omap mailing list. Regards, Nishanth Menon From: pandabo...@googlegroups.com [pandabo...@googlegroups.com] on behalf of Sukumar Ghorai [ghorai.suku...@gmail.com] Sent: Friday, December 21, 2012 10:33 To: pandabo...@googlegroups.com Subject: [pandaboard] device tree does not work Hi, Device Tree in Panda board does not boot. Device Tree with legacy u-boot : Appending dtb blob to kernel menuconfig → boot options select [*] Use appended device tree blob to zImage (EXPERIMENTAL) Used with legacy u-boot U-Boot 2011.09 (Nov 19 2011 - 04:44:45) CPU : OMAP4430 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # setenv bootargs 'console=ttyO2,115200n8 root=/dev/mmcblk0p3 rw rootwait rootfstype=ext4 init=/sbin/init ignore_loglevel debug printk.time=1 earlyprintk' Panda # setenv bootcmd 'mmc rescan; fatload mmc 0 8020 uImage-21dec; fatload mmc 0 8070 omap4-panda-es.dtb; bootm 8020 - 8070' Panda # boot reading uImage-21dec 4243816 bytes read reading omap4-panda-es.dtb 13602 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.7.0-11091-gf01af9f-dirty Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4243752 Bytes = 4 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8070 Booting using the fdt blob at 0x8070 Loading Kernel Image ... OK OK reserving fdt memory region: addr=9d00 size=300 Loading Device Tree to bfef1000, end bfef7521 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.7.0-11091-gf01af9f-dirty (sghorai@bgsxgitb03) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #15 SMP Fri Dec 21 15:50:23 IST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [0.00] debug: ignoring loglevel setting. [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] On node 0 totalpages: 261888 [0.00] free_area_init_node: node 0, pgdat c080eec0, node_mem_map c0d6d000 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 193040 pages, LIFO batch:31 [0.00] HighMem zone: 528 pages used for memmap [0.00] HighMem zone: 66800 pages, LIFO batch:15 [0.00] Unable to handle kernel paging request at virtual address ffef1000 [0.00] pgd = c0004000 [0.00] [ffef1000] *pgd=af7fe821, *pte=, *ppte= [0.00] Internal error: Oops: 17 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.7.0-11091-gf01af9f-dirty #15) [0.00] PC is at __unflatten_device_tree+0x1c/0x130 [0.00] LR is at unflatten_device_tree+0x1c/0x34 [0.00] pc : [c04558ec]lr : [c0755910]psr: a1d3 [0.00] sp : c0781f50 ip : 0001 fp : c0788954 [0.00] r10: c0666de0 r9 : c157c080 r8 : 8200 [0.00] r7 : c0730f64 r6 : c078d3d0 r5 : ffef1000 r4 : c0730f64 [0.00] r3 : d00dfeed r2 : c0730f64 r1 : c0d666e8 r0 : ffef1000 [0.00] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c53c7d Table: 8000404a DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc0780240) [0.00] Stack: (0xc0781f50 to 0xc0782000) [0.00] 1f40: 8200 c157c080 c0d666e8 [0.00] 1f60: c0730f64 c0d50c68 c078d3d0 c07e2c60 8200 c0755910 c075d548 c072fc94 [0.00] 1f80: 10c53c7d bfff c0781fdc 411fc092 c052f9b0 [0.00] 1fa0: c06655ac 0001 bfff 8000406a 411fc092 [0.00] 1fc0: c072c4ec c075f2b0 [0.00] 1fe0: 10c53c7d c078898c c075f2ac c078d1c4 80008078 [0.00] [c04558ec] (__unflatten_device_tree+0x1c/0x130) from [c0755910] (unflatten_device_tree+0x1c/0x34) [0.00] [c0755910] (unflatten_device_tree+0x1c/0x34) from [c072fc94] (setup_arch+0x5d4/0x7ac) [0.00] [c072fc94] (setup_arch+0x5d4/0x7ac) from [c072c4ec] (start_kernel+0x88/0x2fc) [0.00] [c072c4ec] (start_kernel+0x88/0x2fc) from [80008078] (0x80008078) [0.00] Code: e1a07002 0a35 e59f30fc e58d1008 (e5951000) [0.00] ---[ end trace
Re: [PATCH 2/3] PM / OPP: Initialize OPP table from device tree
On Thu, Jul 19, 2012 at 10:54 AM, Shawn Guo shawn@linaro.org wrote:
With a lot of devices booting from device tree nowadays, it requires
that OPP table can be initialized from device tree. The patch adds
a helper function of_init_opp_table together with a binding doc for
that purpose.
nice to see this happen, a quick feedback:
Signed-off-by: Shawn Guo shawn@linaro.org
---
Documentation/devicetree/bindings/power/opp.txt | 29 ++
drivers/base/power/opp.c| 66
+++
include/linux/opp.h |4 ++
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/opp.txt
diff --git a/Documentation/devicetree/bindings/power/opp.txt
b/Documentation/devicetree/bindings/power/opp.txt
new file mode 100644
index 000..1dd0db2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/opp.txt
@@ -0,0 +1,29 @@
+* Generic OPP Interface
+
+SoCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. These
+are called Operating Performance Points or OPPs.
+
+Properties:
+- operating-points: An array of 3-tuples items, and each item consists
+ of frequency, voltage and enabling like freq vol en.
+ freq: clock frequency in kHz
+ vol: voltage in microvolt
+ en: initially enabled (1) or not (0)
+
+Examples:
+
+cpu@0 {
+ compatible = arm,cortex-a9;
I am not sure how this works - would an example of OMAP4430, 60, 70
help? they have completely different OPP entries.
+ reg = 0;
+ next-level-cache = L2;
+ operating-points =
+ /* kHzuVen */
+ 120 1275000 0
+ 996000 1225000 1
+ 792000 110 1
+ 672000 110 0
+ 396000 95 1
+ 198000 85 1
Just my 2cents, If we change en to be a flag:
0 - add, but disable
1 - add (enabled)
we could extend this further if the definition is a flag, for example:
2 - add and disable IF any of notifier chain return failure
3- add but dont call notifier chain (e.g. OPPs that are present for All SoC)
in addition, SoC might have additional properties associated with each
OPP such a flag
could be split up to mean lower 16 bits as OPP library flag and higher
16 bit to mean SoC custom flag
Example - On certain SoC a specific type of power technique is
supposed to be used per OPP, such a flag
passed on via notifiers to SoC handler might be capable of
centralizing the OPP information into the DT.
+ ;
+};
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index ac993ea..2d750f9 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -22,6 +22,7 @@
#include linux/rculist.h
#include linux/rcupdate.h
#include linux/opp.h
+#include linux/of.h
/*
* Internal data structure organization with the OPP layer library is as
@@ -674,3 +675,68 @@ struct srcu_notifier_head *opp_get_notifier(struct
device *dev)
return dev_opp-head;
}
+
+#ifdef CONFIG_OF
+/**
+ * of_init_opp_table() - Initialize opp table from device tree
+ * @dev: device pointer used to lookup device OPPs.
+ *
+ * Register the initial OPP table with the OPP library for given device.
+ */
+int of_init_opp_table(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ const char *propname = operating-points;
+ const struct property *pp;
+ u32 *opp;
+ int ret, i, nr;
+
+ pp = of_find_property(np, propname, NULL);
+ if (!pp) {
+ dev_err(dev, %s: Unable to find property, __func__);
+ return -ENODEV;
+ }
+
+ opp = kzalloc(pp-length, GFP_KERNEL);
+ if (!opp) {
+ dev_err(dev, %s: Unable to allocate array\n, __func__);
+ return -ENOMEM;
+ }
+
+ nr = pp-length / sizeof(u32);
error warn if the pp-length is not multiple of u32? we also expect
later on to be a multiple of 3(f,v,disable
+ ret = of_property_read_u32_array(np, propname, opp, nr);
+ if (ret) {
+ dev_err(dev, %s: Unable to read OPPs\n, __func__);
+ goto out;
+ }
+
+ nr /= 3;
+ for (i = 0; i nr; i++) {
+ /*
+* Each OPP is a set of tuples consisting of frequency,
+* voltage and availability like freq-kHz vol-uV enable.
+*/
+ u32 *val = opp + i * 3;
+
+ val[0] *= 1000;
+ ret = opp_add(dev, val[0], val[1]);
+ if (ret) {
+ dev_warn(dev, %s: Failed to add OPP %d: %d\n,
+__func__, val[0], ret);
+ continue;
+ }
+
+ if (!val[2]) {
+ ret =
Re: [PATCH 2/3] PM / OPP: Initialize OPP table from device tree
On Fri, Jul 20, 2012 at 3:46 AM, Shawn Guo shawn@linaro.org wrote:
+ ret = of_property_read_u32_array(np, propname, opp, nr);
+ if (ret) {
+ dev_err(dev, %s: Unable to read OPPs\n, __func__);
+ goto out;
+ }
+
+ nr /= 3;
+ for (i = 0; i nr; i++) {
+ /*
+* Each OPP is a set of tuples consisting of frequency,
+* voltage and availability like freq-kHz vol-uV enable.
+*/
+ u32 *val = opp + i * 3;
+
+ val[0] *= 1000;
+ ret = opp_add(dev, val[0], val[1]);
+ if (ret) {
+ dev_warn(dev, %s: Failed to add OPP %d: %d\n,
+__func__, val[0], ret);
+ continue;
+ }
+
+ if (!val[2]) {
+ ret = opp_disable(dev, val[0]);
Since we are updating the table out of context of the SoC users,
consider what might happen if someone where to operate on the OPP
after opp_add, but before opp_disable?
I would take this as another comment reminding me to remove the
enabling/availability tuple from the binding. Will do it in the
next version.
I am not completely convinced that dropping the flag would be the best approach
on a long run, but might be a good starting point while we meet current reqs and
as a need arises, could increase the scope. Thanks once again for doing this.
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/8] ARM: OMAP2+: PM: introduce power domains achievable functional states
On Fri, Jun 15, 2012 at 6:28 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
1. The while loops need optimization. - This can definitely be
simplified and made non-risky; this also needs some more error
handling
If you are interested using something like the following
static int _match_pwrst(u32 pwrsts, u8 pwrst, u8 default_pwrst)
{
bool found = true;
int new_pwrst = pwrst;
/* Search down */
while (!(pwrsts (1 new_pwrst))) {
if (new_pwrst == PWRDM_POWER_OFF) {
found = false;
break;
}
new_pwrst--;
}
if (found)
goto done;
/* Search up */
new_pwrst = pwrst;
while (!(pwrsts (1 new_pwrst))) {
if (new_pwrst == default_pwrst)
break;
new_pwrst++;
}
done:
return new_pwrst;
}
new_pwrst = _match_pwrst(pwrdm-pwrsts, pwrst,
PWRDM_POWER_ON);
new_logic = _match_pwrst(pwrdm-pwrsts_logic_ret, logic,
PWRDM_POWER_RET);
to achieve the same code..
2. About the power domains state machine: you have only one power
state to move in and out of: it is called ON. If you do ON-CSWR-ON
etc. attempting to program ON-CSWR-OSWR is NOT supported in OMAP and
is an invitation for production team to sit and debug for a while
before finding the use of invalid power states
Point 2 is a good point. The solution would be to implement a state
machine in this function and/or omap_set_pwrdm_state, possibly using a
platform specific handling function.
Point 2 is not completely accurate - Lower pwr state transitions can
indeed and is indeed
supported on OMAP4+. CSWR-OSWR-OFF is possible and omap_setpwrdm_state does
indeed handle this. however going to OSWR-CSWR is possible only by
OSWR-ON-CSWR.
this is again supported in code, however, in practice, we have found
that certain IP blocks(in
personal experience, it was DSS) need IP specific additional work
which is not easily doable..
so when we come out of suspend state, if the IP block has achieved a
lower powerstate than
what was programmed, we just leave it as is.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
Minor nitpick:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
+/**
+ * _omap4_get_context_lost - get context loss counter for a hwmod
Documentation missing for oh
btw, you might be interested in using http://www.omappedia.org/wiki/Kmake
to provide list of kerneldoc errors in addition to other easily
catchable errors..
+ *
+ * Returns the in-memory context loss counter for a hwmod.
+ */
+static int _omap4_get_context_lost(struct omap_hwmod *oh)
+{
+ return oh-prcm.omap4.context_lost_counter;
+}
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints
On Thu, Jun 14, 2012 at 10:05 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
Minor comment follows:
[...]
+/**
+ * _pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
+ * @pwrdm: struct powerdomain * to which requesting device belongs to.
+ * @min_latency: the allowed wake-up latency for the given power domain. A
+ * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm.
+ *
+ * Finds the power domain next power state that fulfills the constraint.
+ * Programs a new target state if it is different from current power state.
+ * The power domains get the next power state programmed directly in the
+ * registers.
+ *
+ * Returns 0 in case of success, -EINVAL in case of invalid parameters,
+ * or the return value from omap_set_pwrdm_state.
+ */
+static int _pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+long min_latency)
+{
+ int ret = 0, state, new_state = PWRDM_FUNC_PWRST_ON;
+
+ if (!pwrdm) {
+ WARN(1, powerdomain: %s: invalid parameter(s), __func__);
+ return -EINVAL;
+ }
_pwrdm_wakeuplat_update_pwrst is an helper function, we check pwrdm to
be valid here,
however,
[...]
/* Public functions */
/**
+ * pwrdm_wakeuplat_update_constraint - Set or update a powerdomain wakeup
+ * latency constraint and apply it
+ * @pwrdm: struct powerdomain * which the constraint applies to
+ * @cookie: constraint identifier, used for tracking
+ * @min_latency: minimum wakeup latency constraint (in microseconds) for
+ * the given pwrdm
+ *
+ * Tracks the constraints by @cookie.
+ * Constraint set/update: Adds a new entry to powerdomain's wake-up latency
+ * constraint list. If the constraint identifier already exists in the list,
+ * the old value is overwritten.
+ *
+ * Applies the aggregated constraint value for the given pwrdm by calling
+ * _pwrdm_wakeuplat_update_pwrst.
+ *
+ * Returns 0 upon success, -ENOMEM in case of memory shortage, -EINVAL in
+ * case of invalid latency value, or the return value from
+ * _pwrdm_wakeuplat_update_pwrst.
+ *
+ * The caller must check the validity of the parameters.
+ */
+int pwrdm_wakeuplat_update_constraint(struct powerdomain *pwrdm, void
*cookie,
+ long min_latency)
+{
+ struct pwrdm_wkup_constraints_entry *tmp_user, *new_user, *user =
NULL;
+ long value = PM_QOS_DEV_LAT_DEFAULT_VALUE;
+ int free_new_user = 0;
+
+ pr_debug(powerdomain: %s: pwrdm %s, cookie=0x%p, min_latency=%ld\n,
+__func__, pwrdm-name, cookie, min_latency);
here,
+
+ if (min_latency = PM_QOS_DEV_LAT_DEFAULT_VALUE) {
+ pr_warn(%s: min_latency = PM_QOS_DEV_LAT_DEFAULT_VALUE\n,
+ __func__);
+ return -EINVAL;
+ }
+
+ /* Allocate a new entry for insertion in the list */
+ new_user = kzalloc(sizeof(struct pwrdm_wkup_constraints_entry),
+ GFP_KERNEL);
+ if (!new_user) {
+ pr_err(%s: FATAL ERROR: kzalloc failed\n, __func__);
+ return -ENOMEM;
+ }
+
+ mutex_lock(pwrdm-wkup_lat_plist_lock);
here,
+
+ /* Check if there already is a constraint for cookie */
+ plist_for_each_entry(tmp_user, pwrdm-wkup_lat_plist_head, node) {
+ if (tmp_user-cookie == cookie) {
+ user = tmp_user;
+ break;
+ }
+ }
here,
+
+ /* If nothing to update, job done */
+ if (user (user-node.prio == min_latency))
+ goto out;
+
+ if (!user) {
+ /* Add new entry to the list */
+ user = new_user;
+ user-cookie = cookie;
+ } else {
+ /* Update existing entry */
+ plist_del(user-node, pwrdm-wkup_lat_plist_head);
here
+ free_new_user = 1;
+ }
+
+ plist_node_init(user-node, min_latency);
+ plist_add(user-node, pwrdm-wkup_lat_plist_head);
here
+
+ /* Find the aggregated constraint value from the list */
+ if (!plist_head_empty(pwrdm-wkup_lat_plist_head))
...
+ value = plist_first(pwrdm-wkup_lat_plist_head)-prio;
...
+
+ mutex_unlock(pwrdm-wkup_lat_plist_lock);
...
+
+ /* Free the newly allocated entry if not in use */
+ if (free_new_user)
+ kfree(new_user);
+
+ /* Apply the constraint to the pwrdm */
+ pr_debug(powerdomain: %s: pwrdm %s, value=%ld\n,
+__func__, pwrdm-name, value);
...
+ return _pwrdm_wakeuplat_update_pwrst(pwrdm, value);
we have already crashed before we do a WARN in helper.
+
+out:
+ mutex_unlock(pwrdm-wkup_lat_plist_lock);
+ return 0;
+}
+
+/**
+ * pwrdm_wakeuplat_remove_constraint - Release a powerdomain wakeup latency
+ *
Re: [PATCH 04/10] ARM: OMAP: omap_device: register to the per-device PM QoS framework
On Wed, Jun 20, 2012 at 5:41 AM, Rajendra Nayak rna...@ti.com wrote:
+ /* Look for the platform device for the constraint target device
*/
+ pdev = to_platform_device(dev_pm_qos_req-dev);
+
+ /* Try to catch non platform devices */
+ if (pdev-name == NULL) {
Is this a safe way to catch non platform devices?
in addition, we should check !pdev before attempting to dereference
and check for pdev-name
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, Jul 19, 2012 at 4:49 AM, Tero Kristo t-kri...@ti.com wrote: Zero doesn't mean no context loss. If counter was previous MAX_INT, if it goes to zero it is still a context loss, as the counter value differs. Drivers do check against diff in the context loss counter, and if there is one, they do restore which is the right way to handle it. No need to unnecessarily make this more complicated than it is. so we flip the responsibility of overflow to drivers. considering a similar scenario of jiffies /* * These inlines deal with timer wrapping correctly. You are * strongly encouraged to use them * 1. Because people otherwise forget * 2. Because if the timer wrap changes in future you won't have to * alter your driver code. * * time_after(a,b) returns true if the time a is after time b. ... */ from past experience, it is highly possible that drivers never get this right. if the intent is just to let the drivers know context was lost, why not go back to the alternate possibility of a bool lost_context which tells the driver if it lost context since it last called the lost_context api. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints
On Thu, Jun 14, 2012 at 10:05 AM, Jean Pihet jean.pi...@newoldbits.com
wrote:
+static int _pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+long min_latency)
+{
+ int ret = 0, state, new_state = PWRDM_FUNC_PWRST_ON;
+
+ if (!pwrdm) {
+ WARN(1, powerdomain: %s: invalid parameter(s),
__func__);
+ return -EINVAL;
+ }
+
+ /*
+* Find the next supported power state with
+* wakeup latency = min_latency.
+* Pick the lower state if no constraint on the pwrdm
+* (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE).
+* Skip the states marked as unsupported (UNSUP_STATE).
+* If no power state found, fall back to PWRDM_FUNC_PWRST_ON.
+*/
+ for (state = 0x0; state PWRDM_MAX_FUNC_PWRSTS; state++) {
+ if ((min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE) ||
Since we search for default_value, we will endup matching OFF always,
even if it is supported
state(marked UNSUP_STATE) or not. That is not correct, even though
omap_setpwrdm_state
will check for achievable state before setting it.
+ ((pwrdm-wakeup_lat[state] != UNSUP_STATE)
+(pwrdm-wakeup_lat[state] = min_latency))) {
further instead of the ()s, can we make it simple as:
if (pwrdm-wakeup_lat[state] == UNSUP_STATE)
continue;
if (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE ||
pwrdm-wakeup_lat[state] = min_latency) {
new_state = state;
break;
}
+ new_state = state;
+ break;
+ }
+ }
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Wed, Jul 18, 2012 at 4:15 AM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-07-17 at 02:59 -0500, Menon, Nishanth wrote:
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter
if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead of
returning no context loss (count = 0)?
I guess you are right, this way we may have some extra context restores
for modules which don't have context offs defined, rather than not
restoring them at all. Only thing I can think might prevent this is if
there are modules that never lose context but don't have context
register? How about omap5+?
there has been an interesting debate ongoing with HWAUTO and context
loss count handling - since we update only on _enable, this might
actually be interesting to consider:
enable
idle
un_idle (lost context)
read counter - no update
Now to handle modules that never loose context - they have to be in
wakeup domain.. should we consider a flag for those? would'nt matter
o5 or not, context is still the same.. this issue could be resolved if
counter update is done even when a check is done.
+
+ r =
omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+
oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
need to be careful about counter overflow.
Well, this code can't do much for that even if it overflows... the type
for the context_lost_counter is unsigned though, maybe it should be
expanded if you are worried...?
it can hit 0 with overflow(no context loss). that will not be good, right?
How about something like:
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eac813a..5fb9572 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1606,6 +1606,18 @@ static void _reconfigure_io_chain(void)
spin_unlock_irqrestore(io_chain_lock, flags);
}
+static inline void _omap4_inc_context_loss(unsigned int *v)
+{
+
+ /*
+* Context loss count has to be a non-negative value.
+* Clear the sign bit to get a value range from 1 to
+* INT_MAX.
+*/
+ *v = (*v + 1) INT_MAX;
+ *v = *v ? *v : 1;
+}
+
/**
* _omap4_update_context_lost - increment hwmod context loss counter if
* hwmod context was lost, and clear hardware context loss reg
@@ -1629,7 +1641,7 @@ static void _omap4_update_context_lost(struct
omap_hwmod *oh)
if (!r)
return;
- oh-prcm.omap4.context_lost_counter++;
+ _omap4_inc_context_loss(oh-prcm.omap4.context_lost_counter);
omap4_prminst_write_inst_reg(r, oh-clkdm-pwrdm.ptr-prcm_partition,
oh-clkdm-pwrdm.ptr-prcm_offs,
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
Couple of minor comments:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ u32 r;
+
+ if (oh-prcm.omap4.context_offs == USHRT_MAX)
+ return;
would'nt it be better to return a dummy incremental counter instead of
returning no context loss (count = 0)?
+
+ r = omap4_prminst_read_inst_reg(oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs);
+
+ if (!r)
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
need to be careful about counter overflow.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will
need to know when it lost context to be able to reload it's firmware,
no?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM: OMAP2+: PM: introduce power domains functional states
On Fri, Jul 13, 2012 at 2:07 AM, Jean Pihet jean.pi...@newoldbits.com wrote: my Crib about the above apis are lack of logic power state handling :( which forces code like cpuidle to use different apis for logic power state and force them to use these apis just for pwrst. Please look at the rest of the series. Thanks for doing these, but with https://patchwork.kernel.org/patch/1160431/ in context, my comments on this patch is redundant and i think we should go with Rajendra's patch instead of this. I am currently dropping this patch in my internal tree. Will comment further as i get to next set of patches in this series. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM: OMAP2+: PM: introduce power domains functional states
On Fri, Jul 13, 2012 at 2:18 AM, Jean Pihet jean.pi...@newoldbits.com wrote: [..] Santosh pointed me to the thread offline. This is indeed a much better approach IMHO than having 3 conflicting options inside powerdomain framework. After looking at the code and having sent my comments, I like it ... mainly because it is really similar to my proposal ;-p Can you elaborate more on 'having 3 conflicting options inside powerdomain framework'? Current code has: a) PWRDM_POWER_XYZ - describe power state b) PWRSTS_XYZ -meant to describe supported states for each pwrdm this patch introduces: a) PWRDM_POWER_XYZ - describe power state (only for powerdomain*.[ch]) b) PWRSTS_XYZ -meant to describe supported states for each pwrdm c) PWRDM_FUNC_XYZ - for files other than powerdomain*.[ch] https://patchwork.kernel.org/patch/1160431/ maintains a) PWRDM_POWER_XYZ - describe power state b) PWRSTS_XYZ -meant to describe supported states for each pwrdm i) reduces code churn ii) supports logic pwr handling within existing framework iii) no conflicting usage beyond known definition and usage. (though personally, I;d like to see PWRSTS_XYZ dissappear into private header.. Here are the main differences in the implementation: - the RFC code provides a _private header file, which forces the external users (cpuidle, pm.c etc.), That is one of the reasons I like it. I need to have a code which will be maintained beyond the original code creators - reduced ability to mess up the code by not-well-informed developers is paramount importance for me. - the RFC code still uses the same function names while my code renames them to '*_func_*'. This makes the code look more complicated than it really is. True. But, it paves the way to move all functions that is not intended to be used beyond powerdomain files to a private power domain header - which achieves the same objective without code churn. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Simplification of Power Domain Control
On Thursday 05 July 2012, Rajendra Nayak wrote:
[..]
From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits
internally
Powerdomain framework exposes various apis for memory and logic
control for powerdomains, for its users to program OSWR: Open SWitch
Retention state. While in theory, there are various combinations of
memory and logic states possible which can be configured as OSWR,
in practice all OMAPs use just one combination. Logic lost, memory retained.
This can very easily be handled within the powerdomain framework itself,
without exposing all complex memory/logic control apis to upper layer
drivers like cpuidle and suspend.
To do this, introduce 2 new power domain states PWRDM_POWER_CSWR and
PWRDM_POWER_OSWR usable by the users of powerdomain framework and
make all memory/logic control apis internal to powerdomain framework.
Change all users of powerdomain framework to get rid of all usage
of memory/logic control apis and use the newly defined states for
CSWR and OSWR with the already used powerstate control apis.
Some functions (which are now made internal) are forward declared
to avoid moving functions around in the file (which can be done in a
later patch) to help keep the patch reviewable.
Signed-off-by: Rajendra Nayak rna...@ti.com
Ref: http://marc.info/?t=13396858684r=1w=2
Apologies, but i've had to copypaste the original message, so inline response
might be a bit messed up.
From an initial port to get cpuidle working on OMAP5, my experiences follow:
a) counter handling (pm-debug.c) - we can now do better than give our
arcane RET:5
LOGIC-POWER-OFF:4 , instead we can clearly indicate OSWR, CSWR in
counter
Part of the issue also now becomes that count and time arrays are in
the range of
PWRDM_POWER_ON. They break when CSWR/OSWR is in pwrdm-state
b) pwrst handling this becomes a hard one to handle (as usual) when
comparisons of
while (!(pwrdm-pwrsts (1 pwrst))) {
if (pwrst == PWRDM_POWER_OFF)
goto out;
pwrst--;
}
with value 4, 5 - pwrsts should either now use OSWR, CSWR definitions
OR we will need translate back before checks
c) in few critical places, these mentioned error checks do silent
error returns - example:
if (!(pwrdm-pwrsts_logic_ret (1 pwrst)))
return -EINVAL;
this bit me more than once while i tried to bring up the patch
we should be doing a patch which introduces a ratelimited WARN to kill the
bad callers.
d) we have been lazy in programming and have been using cur_pwrst
PWRDM_POWER_ON or INACTIVE etc.. and do a set of operations based off
that. this wont work as CSWR, OSWR POWER_INACTIVE. (e.g. pm3 code)
e) similar to what Jean did, omap_set_pwrdm_state will need to move
over from pm.c to powerdomain.c
f) We probably should also will need an updated patch for
http://marc.info/?l=linux-omapm=133968581105049w=2
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus
On Fri, Jul 13, 2012 at 3:38 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
Manufacturers can opt to use different codec than twl6040 and also can add
audio related IC to the bus (external amplifier for example on SDP4430).
Make it possible to add differnet set of additional devices to i2c1 bus on
OMAP4 boards.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Changes since v1:
Generated against l-o/master
Regards,
Peter
arch/arm/mach-omap2/board-4430sdp.c| 12 +-
arch/arm/mach-omap2/board-omap4panda.c | 12 +-
arch/arm/mach-omap2/twl-common.c | 35 +--
arch/arm/mach-omap2/twl-common.h |3 +-
4 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ad8a7d9..26466f2 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -547,6 +547,14 @@ static struct twl6040_platform_data twl6040_data = {
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
+static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(twl6040, 0x4b),
+ .irq = OMAP44XX_IRQ_SYS_2N,
+ .platform_data = twl6040_data,
+ },
+};
+
static struct twl4030_platform_data sdp4430_twldata = {
/* Regulators */
.vusim = sdp4430_vusim,
@@ -580,8 +588,8 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_CLK32KG |
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
- omap4_pmic_init(twl6030, sdp4430_twldata,
- twl6040_data, OMAP44XX_IRQ_SYS_2N);
+ omap4_pmic_init(twl6030, sdp4430_twldata, sdp4430_i2c_1_boardinfo,
+ ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
We still need a way to switch to I2C highspeed mode
omap4_pmic_init still does register in 400KHz mode, while setting a bit in 6040
should let us talk 3.3MHz on the bus.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM: OMAP2+: PM: introduce power domains functional states
On Fri, Jul 13, 2012 at 12:26 AM, Rajendra Nayak rna...@ti.com wrote: On Friday 13 July 2012 08:31 AM, Menon, Nishanth wrote: my Crib about the above apis are lack of logic power state handling:( which forces code like cpuidle to use different apis for logic power state and force them to use these apis just for pwrst. Have you looked at an alternate approach that was proposed here.. https://patchwork.kernel.org/patch/1160431/ Santosh pointed me to the thread offline. This is indeed a much better approach IMHO than having 3 conflicting options inside powerdomain framework. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
On Fri, Jun 1, 2012 at 2:03 AM, Igor Grinberg grinb...@compulab.co.il wrote:
On 06/01/12 02:15, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
Commit 9fa2df6b90786301b175e264f5fa9846aba81a65
(ARM: OMAP2+: OPP: allow OPP enumeration to continue if device is not
present)
makes the logic:
for (i = 0; i opp_def_size; i++) {
snip
if (!oh || !oh-od) {
snip
continue;
}
snip
opp_def++;
}
In short, the moment we hit a Bad OPP, we end up looping the list
comparing against the bad opp definition pointer for the rest of the
iteration count. Instead, increment opp_def in the for loop itself
and allow continue to be used in code without much thought so that
we check the next set of OPP definition pointers :)
Cc: Kevin Hilman khil...@ti.com
Cc: Steve Sakoman st...@sakoman.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
Good catch.
Queuing for my next set of PM fixes for v3.5-rc (branch: for_3.5/fixes/pm-2)
I think this should also apply for stable, right?
If it should, can you please add a
Cc: sta...@vger.kernel.org
I would like to think so, but punting over to Kevin on that decision.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v4] ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events
On Wed, Apr 25, 2012 at 2:17 AM, Govindraj.R govindraj.r...@ti.com wrote:
[...]
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,13 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
not suppose to be used on omap4\n);
return 0;
}
+static inline void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod,
+ u8 prm_reg_id, u8 prm_reg_shift, bool set_wake)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
^ minor comment - we should not return a value in a function returning void
[...]
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking
On Thu, May 31, 2012 at 8:28 AM, Tero Kristo t-kri...@ti.com wrote: minor comment: +void pwrdm_clkdm_enable(struct powerdomain *pwrdm) snip +void pwrdm_clkdm_disable(struct powerdomain *pwrdm) I know the understand that rest of the code lacks kernel-doc, but at least can we ensure that the new functions does? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 13/14] ARM: OMAP3: vc: auto_ret / auto_off support
On Thu, May 31, 2012 at 8:55 AM, Tero Kristo t-kri...@ti.com wrote: + case PWRDM_POWER_RET: Apologies on hijacking this thread, but I do think we need to revisit this series after rebase on top of Jean's series - it otherwise results a mess of different sets of macros. IMHO though, it might be a good time to discuss if we would like to switch from macros to enums to become as much as possible type safe in usage - it is just too easy for later developers who will maintain this code from mistakenly using wrong macros at the wrong place and causing others to spend weeks debugging? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 4/4] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
Regards,
Nishanth Menon
On Fri, Jun 1, 2012 at 4:03 PM, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
From: Wenbiao Wang ww...@ti.com
Voltage Processor state machine transition to disable need to
occur from IDLE state. When we transition OPP in a functioning
system, the call sequence for an OPP transition is as follows:
omap_sr_disable
- sr class 3 disable
- vp disable
- sr disable
forceupdate to voltage/frequency scale depending on which OPP
we are transitioning to.
If we hit a critical timing window where SR had commanded VP
for a voltage transition and VP is in the middle of operating
on that command, it needs to go through a few states before
going to update state(where it actually sends the command to
VC). Initial view of h/w owners is that the state disable of VP
is expected to be sampled for the next transition.
Instead, to be on a safer side, we ensure that the valid states
of the VP state machine is diligently followed by software. This
can be done by waiting for VP to be in idle prior to disabling
VP. Existing prints have been updated to ensure context is
available on error messages.
As part of this change, increase timeout for VP idle check to
improbable 500uSec to be certain that system is indeed unable
to continue before crashing out with error(worst case expectancy
remains the same 3-100uSec depending on when we caught VP).
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
[n...@ti.com: port from android]
and you also convert to use new _vp_wait_for_idle()
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Wenbiao Wang ww...@ti.com
---
arch/arm/mach-omap2/vp.c | 4
arch/arm/mach-omap2/vp.h | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 2a8a085..9a72deb 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -308,6 +308,10 @@ void omap_vp_disable(struct voltagedomain *voltdm)
return;
}
+ if (_vp_wait_for_idle(voltdm, vp)) {
+ pr_warn_ratelimited(%s: vdd_%s timedout!Ignore and try\n,
s/timedout/timed out/
no space after '!',
Kinda wanted to stay under 80 character and not split string out to
two lines and make sparse angry, yet did not want to loose information
which was being presented out.
also I don't get the Ignore and try part
if we fail, just try the disable anyways.. (at least till we have
voltage processor recovery mechanism(cold reset) introduced upstream -
the intent of the patch was not to introduce a recovery mechanism, but
to ensure proper checkpoint is in place)..
+ __func__, voltdm-name);
+ }
/* Disable VP */
vpconfig = voltdm-read(vp-vpconfig);
vpconfig = ~vp-common-vpconfig_vpenable;
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 4655b39..4b4eeb6 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -33,9 +33,10 @@ struct voltagedomain;
/*
* Time out for Voltage processor in micro seconds. Typical latency is
2uS,
* but worst case latencies could be around 3-200uS depending on where we
- * interrupted VP's operation.
+ * interrupted VP's operation. Use an improbable timeout value to be
+ * sure that timeout events are beyond doubt.
*/
-#define VP_IDLE_TIMEOUT 200
+#define VP_IDLE_TIMEOUT 500
#define VP_TRANXDONE_TIMEOUT 300
/**
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/19] ARM: OMAP4: PM: add errata support
On Wed, May 30, 2012 at 3:32 AM, Tero Kristo t-kri...@ti.com wrote: On Tue, 2012-05-29 at 15:10 -0500, Menon, Nishanth wrote: On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote: Added similar PM errata flag support as omap3 has. A few errata flags will be added in subsequent patches. Considering that we might have erratas for future SoCs as well, should'nt we just set up a common errata flag for all SoCs and since we have i123 numbers, would it help being able to reuse errata flags cross SoC generations (if we need to)? Not sure... how quickly do we run out of bits that way? :) Also, at least pm34xx / pm44xx erratas don't have anything in common. We can probably re-use pm44xx erratas for omap5 though. One annoyance is that, the OMAP4 erratas are going to have a number of ROM code erratas on them, which don't really have any public i123 numbers available. . Sounds good to me. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 17/19] ARM: OMAP4: put cpu1 back to sleep if no wake request
On Mon, May 21, 2012 at 5:40 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Not sure what you mean wakeup issue on GP device. IIUC, the issue is: Wakeup from device OFF, hardware releases the reset for both CPUs, This is special case and applicable only for device OFF. The reason CPU1 needs to be hold back, because the security SW is affined with CPU0 which needs to be up and running for any of the ROM code APIs to work. Like setting up SMP bit, AUX control etc. Without CPU0 booted, CPU1 won't be able to execute those ROM functions and hence won't be able to boot properly. I think the limitation is applicable to all OMAP4 devices as well as OMAP5 devices. yes, the stagger of CPU1 behind CPU0 has a few factors: HS devices with an older PPA release has a bug where caches can be messed up and GP devices need slightly different WA. with the older PPA, we put CPU1 back to OFF when we detect that CPU0 is not ready for action you can find the details and documentation in the link below: http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/sleep44xx.S;h=0c28def8f644e9803564bb66c8cfe8c580898978;hb=p-android-omap-3.0#l342 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 30, 2012 at 12:59 PM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Thu, May 17, 2012 at 3:52 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: [...] - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. This is again specific to device OFF only and not related to CPU cluster state as such. So I don't think notifiers should be used here. O.w even when we attempt just MPU OSWR C-state, all these functions will get called in notifier chain. Just a thought, we can have a separate notifier chain for device OFF. It can allow use to get rid of 'enable_off_mode kind of flags and can be used by many drivers too. Like the overall idea, but one minor dumb concern might be sequencing of notifiers - OFF entry and restore needs things to be executed in a specific sequence. How do we plan to ensure the sequence is maintained in a notifier call chain? one possible option might be a priority based scheme? Or just combine the events that need a specific sequence into single notifier callback function. There is other issues in case of failure cases - abort of OFF sequence due to pending interrupt detected as part of a notifier - error handling needs to be sane in proper sequence. I understand and appreciate the intent of replacing the single mega enter_sleep with a chain of notifiers but any such option will need to be scalable enough to handle weird erratum handling (HSI CAWAKE as an example) which potentially break the logic flow and be either be equal or better than what we have today interms of error handling. since these notifiers will be triggered for CPUIDLE(performance sensitive) and suspend, the intricacies might be better understood by seeing how this proposed notifiers look like. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 19/19] ARM: OMAP4: powerdomain: update mpu / core off counters during device off
On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote:
Currently device off does not have any counters / timers of its own
and it is impossible to track the time spent in this state. In device
off, MPU / CORE powerdomains enter OSWR, so normally the RETENTION
state times / counts are increased during device off.
This patch adds a new field to the powerdomain struct for context loss
register, which is checked during pwrdm_post_transition to see if
a device off type context loss has happened. If this is the case,
the counters + timers for OFF state are touched instead of RETENTION.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 1 -
arch/arm/mach-omap2/powerdomain.c | 9 +
arch/arm/mach-omap2/powerdomain.h | 2 ++
arch/arm/mach-omap2/powerdomains44xx_data.c | 2 ++
arch/arm/mach-omap2/prm44xx.c | 15 +++
arch/arm/mach-omap2/prm44xx.h | 2 ++
6 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 1f06f97..f187025 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -404,7 +404,6 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
omap4_cm_resume_off();
- omap4_device_clear_prev_off_state();
We should probably delete the function in it's entirety - not just the
call - the original implementation just clears L3 and this
implementation seems superior.
}
sar_save_failed:
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..f13bb2c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -156,6 +156,15 @@ static int _pwrdm_state_switch(struct powerdomain
*pwrdm, int flag)
break;
case PWRDM_STATE_PREV:
prev = pwrdm_read_prev_pwrst(pwrdm);
+
+ /*
+ * If powerdomain has context offset defined, check if
+ * the domain has lost context (i.e. entered off)
+ */
+ if (pwrdm-context_offs)
+ if (omap4_pwrdm_lost_context_rff(pwrdm-prcm_offs,
+ pwrdm-context_offs))
We should wrap this under pwrdm_lost_context(pwrdm)
pwrdm_lost_context should call the arch_pwrdm-lost_context_rff as
needed? the rest of the powerdomain.c does not use OMAP4 specific
APIs.
+ prev = PWRDM_POWER_OFF;
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
if (prev == PWRDM_POWER_RET)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..a427645 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -82,6 +82,7 @@ struct powerdomain;
* @name: Powerdomain name
* @voltdm: voltagedomain containing this powerdomain
* @prcm_offs: the address offset from CM_BASE/PRM_BASE
+ * @context_offs: the address offset for the CONTEXT register
* @prcm_partition: (OMAP4 only) the PRCM partition ID containing @prcm_offs
* @pwrsts: Possible powerdomain power states
* @pwrsts_logic_ret: Possible logic power states when pwrdm in RETENTION
@@ -106,6 +107,7 @@ struct powerdomain {
struct voltagedomain *ptr;
} voltdm;
const s16 prcm_offs;
+ const s16 context_offs;
const u8 pwrsts;
const u8 pwrsts_logic_ret;
const u8 flags;
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index d8701ce..c4de02f 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -36,6 +36,7 @@ static struct powerdomain core_44xx_pwrdm = {
.voltdm = { .name = core },
.prcm_offs = OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_L3_1_L3_1_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 5,
@@ -205,6 +206,7 @@ static struct powerdomain mpu_44xx_pwrdm = {
.voltdm = { .name = mpu },
.prcm_offs = OMAP4430_PRM_MPU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
+ .context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks = 3,
Why are we not populating the rest of the CONTEXT_OFFSET registers?
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
Re: [PATCHv5 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Mon, May 14, 2012 at 5:03 AM, Tero Kristo t-kri...@ti.com wrote:
[...]
+/**
* _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -1599,6 +1629,8 @@ static int _enable(struct omap_hwmod *oh)
_enable_clocks(oh);
_enable_module(oh);
+ _omap4_update_context_lost(oh);
+
r = _wait_target_ready(oh);
if (!r) {
/*
Dumb q: Since we monitor the count around _enable, how do we ensure
that context loss counter is accurate
around OFF and idle transitions for domains that could have been
hwauto? it might be good to have limitations
in the $commit_message if it is not targeted to do so.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 04/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Thu, May 17, 2012 at 3:52 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 12:34 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, May 17, 2012 at 4:12 AM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: [...] - Rather than hooking into omap4_enter_lowpower(), should use the cluster PM enter/exit notifier chain. This is again specific to device OFF only and not related to CPU cluster state as such. So I don't think notifiers should be used here. O.w even when we attempt just MPU OSWR C-state, all these functions will get called in notifier chain. Just a thought, we can have a separate notifier chain for device OFF. It can allow use to get rid of 'enable_off_mode kind of flags and can be used by many drivers too. Like the overall idea, but one minor dumb concern might be sequencing of notifiers - OFF entry and restore needs things to be executed in a specific sequence. How do we plan to ensure the sequence is maintained in a notifier call chain? one possible option might be a priority based scheme? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 09/19] ARM: OMAP4: PM: add errata support
On Mon, May 14, 2012 at 5:18 AM, Tero Kristo t-kri...@ti.com wrote:
Added similar PM errata flag support as omap3 has. A few errata flags
will be added in subsequent patches.
Considering that we might have erratas for future SoCs as well,
should'nt we just
set up a common errata flag for all SoCs and since we have i123 numbers, would
it help being able to reuse errata flags cross SoC generations (if we need to)?
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.h | 7 +++
arch/arm/mach-omap2/pm44xx.c | 1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ce1e27f..e53ee3c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -130,6 +130,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
+#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id) (pm44xx_errata (id))
+#else
+#define IS_PM44XX_ERRATUM(id) 0
+#endif
+
#ifdef CONFIG_OMAP_SMARTREFLEX
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8f0ec56..8238097 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -35,6 +35,7 @@ struct power_state {
};
static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
#ifdef CONFIG_SUSPEND
static int omap4_pm_suspend(void)
--
1.7.4.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 14/19] ARM: OMAP4: wakeupgen: enable clocks for save_secure_all
On Tue, May 29, 2012 at 3:15 PM, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: On Wed, 2012-05-16 at 17:06 -0700, Kevin Hilman wrote: +Benoit Tero Kristo t-kri...@ti.com writes: save_secure_all needs l3_main_3_ick and l4_secure_clkdm enabled, otherwise the secure ROM code will crash. Signed-off-by: Tero Kristo t-kri...@ti.com I think I mentioned this already (I'm already lost in what I've said for thisseries), but I don't think the secure RAM stuff belongs in the wakeupgen driver. As mentioned, save_secure_all saves: - secure RAM - GIC registers - some other mysterious stuff Attempting to do separate saves for secure RAM + GIC hang the device during wakeup, in addition to being really inefficient (secure API calls are expensive.) I guess my comment wasn't that this isn't needed, but that it doesn't seem to belong in the wakeupgen base (which should probably converted into a real driver.) Seems better to have this stuff in the secure code, maybe omap-secure.c? Perhaps OFF mode notifier might help best here. In addition - it might be safer to protect all calls with clkdm_wakeup around secure_dispatcher instead of just the save_secure_all.. ROM code is not smart enough around it. an completely safe version used by security driver can be found here: http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=security/smc/tf_comm_mshield.c;h=b5279fef0fa400438a57b3941af13d965e983bf0;hb=p-android-omap-3.0#l253 this is what the production kernels have used in the past. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
On Thu, May 24, 2012 at 2:49 AM, Paul Walmsley p...@pwsan.com wrote: Hi Nishanth On Fri, 18 May 2012, Nishanth Menon wrote: From: Vikram Pandita vikram.pand...@ti.com If the dpll is already locked, code can be optimized to return much earlier than doing redundent set of lock mode and wait on idlest. Cc: Tony Lindgren t...@atomide.com Cc: Jon Hunter jon-hun...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Vikram Pandita vikram.pand...@ti.com Did you intend to add your Signed-off-by: to this patch? Other than forwarding the patch over(since it seems to have slipped through the fingers of folks monitoring the product trees), I have had no other contributions to the patch. Also, just FYI, no need to add the Cc: lines for the mailing lists in the bottom of the patch description. Thanks. point taken. will take care of that in future patches. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3+: dpll: optimize noncore dpll locking logic
On Thu, May 24, 2012 at 9:57 AM, Paul Walmsley p...@pwsan.com wrote: Okay. As I understand it, the maintainers above me would like Signed-off-by:s from the entire submission patch, even if there are no contributions to the patch itself. So please let me know if it's okay for me to add your S-o-b. Thanks. ok with me :) Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman khil...@ti.com wrote: Woodruff, Richard r-woodru...@ti.com writes: From: Hilman, Kevin Sent: Tuesday, May 08, 2012 5:17 PM A basic OMAP AVS driver has been in mainline for a long time, yet we have not seen support submitted for all of these features. 1.5/3.5 is a feature. And I'm still waiting for it to be submitted upstream. ABB is requirement for a production useable driver. Higher speed rated OMAP4 and all OMAP5 added these to be useable. ditto Yes this is effort. Point of mentioning is to raise awareness of need. I'm well aware of the need. Yet to be added feature has different meaning than functional gap. And both need to be submitted upstream. SR 1.5: http://marc.info/?l=linux-omapm=129933897910785w=2 ABB: http://marc.info/?l=linux-omapm=130939399209099w=2 I am not sure what you mean need to be submitted upstream? Just tired of seeing things perpetually change without considering even how to handle features that are mandatory for SoC even with code posted upstream to show exactly what it takes.. I think you do mean merged upstream in this context. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: I guess it is time to properly document this increasing busy loop delay.. As it is getting closer to ms scale.. Does the following sound good? /* Maximum time for Voltage Processor to enter or exit idle */ Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
On Mon, May 21, 2012 at 9:51 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: On Mon, May 21, 2012 at 08:36:35AM -0500, ext Nishanth Menon wrote: Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: I guess it is time to properly document this increasing busy loop delay.. As it is getting closer to ms scale.. Does the following sound good? /* Maximum time for Voltage Processor to enter or exit idle */ Sounds way better :-). If you have an estimation of how long it takes in the average case, it might help. But I am OK already with the above, in case you don't have the estimation. /* * Maximum time for Voltage Processor to enter or exit idle * worst case is around 100uSec depending on when we intercepted VP * we use 5 times worst case value to be sure that the system flags * invalid condition */ better? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+ PM: Add support for TPS62361
On Mon, May 7, 2012 at 2:38 AM, Tero Kristo t-kri...@ti.com wrote: One more point to consider is that with this - we *should* disable VCORE3 and VMEM else we can have weird behavior such as those seen by pandaboard-ES early adopters. In what case are we seeing such? If the regulators should be disabled, maybe we should do it already in bootloader. We deal with tons of bootloaders - each platform tends to have their own custom bootloaders. kernel should always assume bootloader guys screw up and it is upto kernel to ensure that it keeps the platform stable at all points of time. TWL6030 does detect short if any LDO/SMPS is not connected but switched on. so it is necessary to ensure on 4460 that VCORE3 and VMEM are completely switched off in kernel no matter what the heck the bootloader decides to do. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Wed, May 2, 2012 at 6:40 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Wed, May 02, 2012 at 16:30:26, Shilimkar, Santosh wrote: [...] How ? SRAM is sower memory than DDR so I don't see how it will reduce latency. I am just guessing if that's indeed the case ;) Haven't done any measurements to really check if that's indeed the case though. You don't have to do any real measurements at least on OMAP. OCMC RAM is interfaced over L4 and MPU has to cross two interconnect bridges to reach to SRAM. DDR is more of direct path and much faster. Hmm, I was under the impression that OCMC RAM was on L3, at least for OMAP4. Maybe there's a extra low latency path for DDR that I am missing. have you folks considered the possibility that SRAM may be reprogrammed by Security code to almost nothing if PA/PPA size needs to be increased? it would be rather dumb not to support HS devices on which real products are made, no? rule of thumb has been to avoid usage of SRAM as it constraints security folks as well (yep, I know they should share code with all of us etc.. but they have a different sets of challenges that may deny them such luxury). Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [rtc-linux] [PATCH] RTC: twl6030: correct usage of static register while reading time
On Fri, Apr 6, 2012 at 14:19, Andrew Morton a...@linux-foundation.org wrote: I rewrote your acked-by to Signed-off-by, because you were on the delivery path of the patch. Documentation/SubmittingPatches has details. Is this OK? sure, thanks. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP
Kevin, [...] Nishanth, can you collect the acks/tested-bys and repost and official patch. I'll queue this up. Thanks. This is already done: http://marc.info/?l=linux-omapm=133191481703750w=2 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP
On Fri, Mar 16, 2012 at 10:47, Maximilian Schwerin maximilian.schwe...@tigris.de wrote: sorry my fault! This was not what I was thinking of as generic. Works as expected! Can i take it as an acked-by? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: OPP: Test for IVA subsystem before attempting to add IVA OPP
On Wed, Mar 14, 2012 at 16:15, Kevin Hilman khil...@ti.com wrote:
Maximilian Schwerin m...@tigris.de writes:
From: Steve Sakoman st...@sakoman.com
Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
subsystem, as this would make omap_init_opp_table fail.
Signed-off-by: Steve Sakoman st...@sakoman.com
Signed-off-by: Maximilian Schwerin m...@tigris.de
Minor: patch subjects for arch/arm/* core code need to have the ARM:
prefix also.
Also, please run scripts/checkpatch.pl on your patch and fix the
warnings.
---
arch/arm/mach-omap2/opp.c | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 9262a6b..414f2ec 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -62,6 +62,10 @@ int __init omap_init_opp_table(struct omap_opp_def
*opp_def,
__func__, i);
return -EINVAL;
}
+
+ if ((strcmp(opp_def-hwmod_name,iva) == 0)
!omap3_has_iva())
+ continue;
+
oh = omap_hwmod_lookup(opp_def-hwmod_name);
if (!oh || !oh-od) {
pr_warn(%s: no hwmod or odev for %s, [%d]
Wouldn't the one-liner below do the same thing?
Actually, your patch makes it less noisy at boot time, avoiding the
pr_warn(), so is probably better.
The only issue i have with current patch is that it focusses to solve
a specific device IVA.
we could have similar variances if we had SGX/AESS device etc
registered in the common
table. a generic solution might be preferable - could we reduce the
severity of pr_warn to pr_debug and do a continue instead?
Kevin
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 9262a6b..d3d4fa2 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -67,7 +67,7 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
pr_warn(%s: no hwmod or odev for %s, [%d]
cannot add OPPs.\n, __func__,
opp_def-hwmod_name, i);
- return -EINVAL;
+ continue;
}
dev = oh-od-pdev-dev;
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP3+: SmartReflex: introduce notifier_control
On Tue, Mar 13, 2012 at 05:26, jean.pi...@newoldbits.com wrote:
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7977018..dfe8075 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
...
+ 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);
can you move this to before we disable the interrupt? it took a while,
but we caught a bug recently when we disable IRQ and then attempt to
clear the status[1]
Regards,
Nishanth Menon
[1] http://review.omapzoom.org/#/c/20231/
--
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: [U-Boot] [PATCH V2 05/18] OMAP5: palmas: Configure nominal opp vdd values
On Wed, Mar 7, 2012 at 11:04, Tom Rini tr...@ti.com wrote: On Thu, Mar 01, 2012 at 08:08:30PM +0530, R Sricharan wrote: The nominal opp vdd values as recommended for ES1.0 silicon is set for mpu, core, mm domains using palmas. OK, this creates some trivial conflicts with http://patchwork.ozlabs.org/patch/144137/ but also raises a functional problem / question. Is this patch also changing the order to match what Nishanth did or does this patch also need that functional change done (and a v3) ? Thanks! Glancing at this patch, I see that scale sequence is still mpu, core, MM - which is what my sequence fixes. will be nice to have the sequence fixed followed by cleanup/update to retain the sequence appropriately. + /* Palmas settings */ + volt = VDD_MPU; + do_scale_vcore(SMPS_REG_ADDR_12_MPU, volt); - /* VCORE 1 - for vdd_core */ - volt = 1000; - do_scale_vcore(SMPS_REG_ADDR_VCORE1, volt); + volt = VDD_MM; + do_scale_vcore(SMPS_REG_ADDR_45_IVA, volt); - /* VCORE 2 - for vdd_MM */ - volt = 1125; - do_scale_vcore(SMPS_REG_ADDR_VCORE2, volt); + volt = VDD_CORE; + do_scale_vcore(SMPS_REG_ADDR_8_CORE, volt); Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] OMAP5: reset: Use cold reset in case of 5430ES1.0
On Wed, Mar 7, 2012 at 00:52, R Sricharan r.sricha...@ti.com wrote:
Warm reset is not functional in case of omap5430ES1.0.
So use cold reset instead.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
[v3]
Addressed Tom Rini's comments.tr...@ti.com
arch/arm/cpu/armv7/omap-common/reset.S | 3 +++
arch/arm/cpu/armv7/omap5/hwinit.c | 15 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/reset.S
b/arch/arm/cpu/armv7/omap-common/reset.S
index 838b122..f2a522a 100644
--- a/arch/arm/cpu/armv7/omap-common/reset.S
+++ b/arch/arm/cpu/armv7/omap-common/reset.S
@@ -23,6 +23,8 @@
#include config.h
+#ifndef CONFIG_OMAP54XX
+.type reset_cpu, %function
.global reset_cpu
reset_cpu:
ldr r1, rstctl @ get addr for global reset
@@ -36,3 +38,4 @@ rstctl:
.word PRM_RSTCTRL
rstbit:
.word PRM_RSTCTRL_RESET
+#endif
instead of doing the #ifdeffery, why not make this a C file with weak
and override it in omap5 as needed?
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 7da7075..d03e746 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -35,6 +35,7 @@
#include asm/sizes.h
#include asm/utils.h
#include asm/arch/gpio.h
+#include linux/compiler.h
DECLARE_GLOBAL_DATA_PTR;
@@ -160,3 +161,17 @@ void init_omap_revision(void)
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
}
}
+
+void __weak reset_cpu(ulong addr)
+{
+ u32 omap_rev = omap_revision();
+
+ /*
+ * WARM reset is not functional in case of OMAP5430 ES1.0 soc.
+ * So use cold reset in case instead.
+ */
+ if (omap_rev == OMAP5430_ES1_0)
+ writel(PRM_RSTCTRL_RESET 0x1, PRM_RSTCTRL);
+ else
+ writel(PRM_RSTCTRL_RESET, PRM_RSTCTRL);
+}
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 05/18] OMAP5: palmas: Configure nominal opp vdd values
On Wed, Mar 7, 2012 at 14:34, Tom Rini tr...@ti.com wrote: On Wed, Mar 7, 2012 at 11:19 AM, Menon, Nishanth n...@ti.com wrote: On Wed, Mar 7, 2012 at 11:04, Tom Rini tr...@ti.com wrote: On Thu, Mar 01, 2012 at 08:08:30PM +0530, R Sricharan wrote: The nominal opp vdd values as recommended for ES1.0 silicon is set for mpu, core, mm domains using palmas. OK, this creates some trivial conflicts with http://patchwork.ozlabs.org/patch/144137/ but also raises a functional problem / question. Is this patch also changing the order to match what Nishanth did or does this patch also need that functional change done (and a v3) ? Thanks! Glancing at this patch, I see that scale sequence is still mpu, core, MM - which is what my sequence fixes. will be nice to have the sequence fixed followed by cleanup/update to retain the sequence appropriately. + /* Palmas settings */ + volt = VDD_MPU; + do_scale_vcore(SMPS_REG_ADDR_12_MPU, volt); - /* VCORE 1 - for vdd_core */ - volt = 1000; - do_scale_vcore(SMPS_REG_ADDR_VCORE1, volt); + volt = VDD_MM; + do_scale_vcore(SMPS_REG_ADDR_45_IVA, volt); - /* VCORE 2 - for vdd_MM */ - volt = 1125; - do_scale_vcore(SMPS_REG_ADDR_VCORE2, volt); + volt = VDD_CORE; + do_scale_vcore(SMPS_REG_ADDR_8_CORE, volt); I think what might be easiest all around is to drop Nishanth's 4/4 and have patch 5 here correct the order as well, crediting Nishanth for the fix. Alternatively, respin the series, depending on Nishanth's series being applied. Thanks. ok with either. might be good to merge my patch 5 here so that #patches are reduced :) Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [PATCH] OMAP3+: PM: VP: fix integer truncation error
On Tue, Mar 6, 2012 at 12:36, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Change-Id: I0ee22e60555e1cfd6cc3dea7ee44d0584ce182b6 You don't need above gerrit change id in commit message. yow.. thanks for catching it, my bad.. thought i fixed it.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: powerdomain: unwrap and simplify logging strings
On Wed, Feb 29, 2012 at 22:23, Paul Walmsley p...@pwsan.com wrote: b/arch/arm/mach-omap2/powerdomain.c index 8a18d1b..89000d3 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -339,8 +339,8 @@ int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm) if (!pwrdm || !clkdm) return -EINVAL; - pr_debug(powerdomain: associating clockdomain %s with powerdomain - %s\n, clkdm-name, pwrdm-name); + pr_debug(powerdomain: %s: associating clockdomain %s\n, + clkdm-name, pwrdm-name); while at this, could i suggest having instead: pr_debug(%s: %s: associating clockdomain %s\n, __func__, clkdm-name, pwrdm-name); since the function name helps associate the message back in, wont it be a bit of a dual edged information as well? or even simplify it further with #define pr_fmt(fmt) %s:%s: fmt, powerdomain, __func__ ? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Thu, Feb 23, 2012 at 03:08, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-02-22 at 19:37 -0600, Menon, Nishanth wrote:
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 949938d..940a0d6 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
[...]
@@ -171,6 +169,18 @@ struct omap_voltdm_pmic {
u8 (*uv_to_vsel) (unsigned long uV);
};
+struct omap_vp_param {
+ u32 vddmax;
+ u32 vddmin;
+};
+
Thinking a little deeper about this(SoC level vdd min and max) on a
slightly different angle- core of the question that intend to answer
are:
- what is the least voltage we want to allow in active transtion? it
should not be lower than retention voltage.
I think this is a fair assumption, so we could init the vddmin to be the
same as the retention voltage for the domain (or even drop the
parameter.)
- what is the max voltage we want to allow in active transition? it
should be the max Nom voltage of all the OPPs for that domain.
Isn't it higher? I guess smartreflex can scale voltages even up from the
nominal level if we have a really old and/or bad silicon. Limiting this
to max opp would be bad, no? Maybe we could use max opp voltage + some
margin though... but what would be a safe margin here?
Vnom voltage definition tends to be a variant - yep. at least OMAP3,4 have
intended to have Vnom as the max voltage for the worst corner lot sample
at end of life - aka worst possible voltage for that OPP. But with newer process
technologies of the future SoCs, this definition might turn out to become the
start voltage.
OK, it is safer to have vnom max at max SoC supported voltage i guess to prevent
code churn in the future and maintain compatibility with current SoCs.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 03/14] arm: omap3+: voltage: parameter segregation
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 949938d..940a0d6 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
[...]
@@ -171,6 +169,18 @@ struct omap_voltdm_pmic {
u8 (*uv_to_vsel) (unsigned long uV);
};
+struct omap_vp_param {
+ u32 vddmax;
+ u32 vddmin;
+};
+
Thinking a little deeper about this(SoC level vdd min and max) on a
slightly different angle- core of the question that intend to answer
are:
- what is the least voltage we want to allow in active transtion? it
should not be lower than retention voltage.
- what is the max voltage we want to allow in active transition? it
should be the max Nom voltage of all the OPPs for that domain.
In effect, why do we even need to register
voltdm-vp_param-vdd[min|max]? We already have that info - right?
On the other hand it might be safer to do this way to handle quirks in
future SoCs.. but thought I'd spit it out anyways..
+struct omap_vc_param {
and elsewhere - please add kernel-doc struct documentation as well
when new structs are introduced?
+ u32 on;
+ u32 onlp;
+ u32 ret;
+ u32 off;
+};
+
[...]
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 02/14] arm: omap: voltage: renamed vp_vddmin and vp_vddmax fields
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
These are now called vddmin and vddmax, as these fields will be used
globally for selecting voltage ranges for a pmic channel, and not
only for voltage processor.
NAK. I think we need to setup voltage for SoC limits as well. the
programmed voltage to the VP register should be:
VP-vlimito-min = MAX(soc-vdd_min, pmic-vdd_min)
VP-vlimito-max = MIN(soc-vdd_max, pmic-vdd_max)
else you could be running the SoC beyond design voltage potentially
damaging the device.
Regards,
Nishanth Menon
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 27 ++-
arch/arm/mach-omap2/voltage.h | 4 ++--
arch/arm/mach-omap2/vp.c | 4 ++--
3 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index df4e7c3..5224fbd 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -149,8 +149,8 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
+ .vddmin = 60,
+ .vddmax = 145,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_MPU_SR_CONTROL_REG,
@@ -170,8 +170,8 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
+ .vddmin = 60,
+ .vddmax = 145,
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_CORE_SR_CONTROL_REG,
@@ -191,8 +191,8 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 150,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
@@ -213,8 +213,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 150,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
@@ -235,8 +235,8 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP4_VP_VSTEPMAX_VSTEPMAX,
- .vp_vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
- .vp_vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+ .vddmin = 0,
+ .vddmax = 150,
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_CORE_SR_VOLT_REG,
@@ -271,13 +271,6 @@ int __init omap3_twl_init(void)
if (!cpu_is_omap34xx())
return -ENODEV;
- if (cpu_is_omap3630()) {
- omap3_mpu_pmic.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
- omap3_mpu_pmic.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
- omap3_core_pmic.vp_vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
- omap3_core_pmic.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
- }
-
/*
* The smartreflex bit on twl4030 specifies if the setting of voltage
* is done over the I2C_SR path. Since this setting is independent of
diff --git a/arch/arm/mach-omap2/voltage.h
Re: [PATCHv5 06/14] arm: omap: add support for oscillator setup
On Tue, Feb 21, 2012 at 08:04, Tero Kristo t-kri...@ti.com wrote:
This contains startup and shutdown times for the oscillator. By default
use ULONG_MAX. Oscillator setup is used for calculating and setting up
latencies for sleep modes that disable oscillator.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm.c | 27 +++
arch/arm/mach-omap2/pm.h | 8
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..2402e8e 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -28,6 +28,33 @@
static struct omap_device_pm_latency *pm_lats;
+/**
+ * struct omap2_oscillator - Describe the board main oscillator latencies
+ * @startup_time: oscillator startup latency
+ * @shutdown_time: oscillator shutdown latency
+ */
+struct omap2_oscillator {
+ u32 startup_time;
+ u32 shutdown_time;
+};
+
+static struct omap2_oscillator oscillator = {
+ .startup_time = ULONG_MAX,
+ .shutdown_time = ULONG_MAX,
+};
+
+void omap_pm_setup_oscillator(u32 tstart, u32 tshut)
+{
+ oscillator.startup_time = tstart;
+ oscillator.shutdown_time = tshut;
+}
+
+void omap_pm_get_oscillator(u32 *tstart, u32 *tshut)
+{
Maybe a nitpick - variable check needed?
Regards,
Nishanth Menon
+ *tstart = oscillator.startup_time;
+ *tshut = oscillator.shutdown_time;
+}
+
static int _init_omap_device(char *name)
{
struct omap_hwmod *oh;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index ec8f874..797d2da 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -141,4 +141,12 @@ static inline int omap4_twl_init(void)
}
#endif
+#ifdef CONFIG_PM
+extern void omap_pm_setup_oscillator(u32 tstart, u32 tshut);
+extern void omap_pm_get_oscillator(u32 *tstart, u32 *tshut);
+#else
+static inline void omap_pm_setup_oscillator(u32 tstart, u32 tshut) { }
+static inline void omap_pm_get_oscillator(u32 *tstart, u32 *tshut) { }
+#endif
+
#endif
--
1.7.4.1
___
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: [PATCHv9 3/5] arm: omap3: add common twl configurations for vdd1 and vdd2
Regards, Nishanth Menon On Fri, Feb 17, 2012 at 05:06, Tero Kristo t-kri...@ti.com wrote: On Thu, 2012-02-16 at 12:23 -0600, Menon, Nishanth wrote: On Thu, Feb 16, 2012 at 04:27, Tero Kristo t-kri...@ti.com wrote: VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators are needed by DVFS. Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manual. Please provide documentation version referenced, else we will loose track of details at a later point of time. How should this be marked down? There are too many naming conventions for the TI docs, and I couldn't find any example from kernel commit logs for this. Personally I was using twl5030 es1.2 DM rev E / twl4030 es3.1 DM rev L. Or should the literature code be used? Or is there also some numerical version info available somewhere? Literature code is the best one. Adding, along with it, a human readable TWL4030 ES3.1 DM rev L is even better :) Also should we rename VDD1 with vdd_mpu_iva and VDD2 as vdd_core to be readable? This can be changed if needed, it is just a name. regulator/twl-regulator.c is using vdd1 / vdd2 though, and also pmic_data struct uses these. All the other regulators use Vxx type naming also. These are the names I see on my board through sys/class/regulator: dummy VDD1 VDD2 VMMC1 VDAC VDVI VSIM no strong opinions on this - thinking from OMAP perspective, I read vdd_mpu,core,iva. from TWL perspective, 4030/5030 - VDD1,2 6030: VCORE1,2,3 6032: SMPS1...5 so I guess it is fine as long as it is in context. -- 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 6/6] arm: omap: pm-debug: enhanced usecount debug support
On Wed, Feb 15, 2012 at 09:20, Kevin Hilman khil...@ti.com wrote: Tero Kristo t-kri...@ti.com writes: On Tue, 2012-02-14 at 15:52 -0800, Tony Lindgren wrote: * Kevin Hilman khil...@ti.com [120214 14:28]: Tony Lindgren t...@atomide.com writes: * Tero Kristo t-kri...@ti.com [120214 08:19]: Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to their own file, 'usecount'. This file shows the usecounts for every active domain and their children recursively. 'count' file now only shows power state counts for powerdomains. This patch also provices a way to do printk dumps from kernel code, by calling the pm_dbg_dump_X functions. The plan is to call these functions once an error condition is detected, e.g. failed suspend. Why don't you replace this all with a userspace tool that deciphers the registers for you? This patch isn't deciphering registers, it's just dumping usecounts, and I think that is extremely useful to have in debugfs. I've already removed all the register dumping from the kernel in the hopes that someone will write a userspace tool for that. OK good to hear you're already considering it. Yes, register dumps are gone, and I am actually one of the persons who is missing it. I think there should still be some capability to get register snapshots from certain points during kernel execution, this is useful for debugging purposes. I don't know if it would be possible to do a call_usermodehelper() or something from kernel space just before wfi to read all (or part of) the PRCM registers, store them somewhere, and then decipher this data later with another tool. Any comments to this? You should look into the omapconf tool (TI internal only currently) This tool already has the ability to use /dev/mem to read/decipher OMAP PM related registers. IMO, the one thing we're still missing is the ability to take register snapshots (like immediately before and after WFI) and somehow feed those to omapconf for deciphering. Something like this perhaps? https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95 Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] arm: omap: pm-debug: enhanced usecount debug support
On Thu, Feb 16, 2012 at 11:35, Kevin Hilman khil...@ti.com wrote: IMO, the one thing we're still missing is the ability to take register snapshots (like immediately before and after WFI) and somehow feed those to omapconf for deciphering. Something like this perhaps? https://github.com/nmenon/linux-omap-ti-pm/commit/3cd1994fc0df9a8e3e0be74ec3f3add3ff3aef95 Yes, although that is targetted pretty narrowly at suspend and only PRM registers. Do you then use omapconf to display the results? on the platform we worked on, not everyone had access to omapconf, it was just 'cat' to take the dump. omapconf support makes sense if this is a consistent interface cross OMAP variants, even better if a similar framework is available cross SoCs. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 3/5] arm: omap3: add common twl configurations for vdd1 and vdd2
On Thu, Feb 16, 2012 at 04:27, Tero Kristo t-kri...@ti.com wrote:
VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.
Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manual.
Please provide documentation version referenced, else we will loose
track of details at a later point of time.
Also should we rename VDD1 with vdd_mpu_iva and VDD2 as vdd_core to be readable?
Regards,
Nishanth Menon
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index 10b20c6..5f62e51 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -126,6 +126,38 @@ static struct regulator_init_data omap3_vpll2_idata = {
.consumer_supplies = omap3_vpll2_supplies,
};
+static struct regulator_consumer_supply omap3_vdd1_supply[] = {
+ REGULATOR_SUPPLY(vcc, mpu.0),
+};
+
+static struct regulator_consumer_supply omap3_vdd2_supply[] = {
+ REGULATOR_SUPPLY(vcc, l3_main.0),
+};
+
+static struct regulator_init_data omap3_vdd1 = {
+ .constraints = {
+ .name = VDD1,
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3_vdd1_supply),
+ .consumer_supplies = omap3_vdd1_supply,
+};
+
+static struct regulator_init_data omap3_vdd2 = {
+ .constraints = {
+ .name = VDD2,
+ .min_uV = 60,
+ .max_uV = 145,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(omap3_vdd2_supply),
+ .consumer_supplies = omap3_vdd2_supply,
+};
+
void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
u32 pdata_flags, u32 regulators_flags)
{
@@ -133,6 +165,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
pmic_data-irq_base = TWL4030_IRQ_BASE;
if (!pmic_data-irq_end)
pmic_data-irq_end = TWL4030_IRQ_END;
+ if (!pmic_data-vdd1)
+ pmic_data-vdd1 = omap3_vdd1;
+ if (!pmic_data-vdd2)
+ pmic_data-vdd2 = omap3_vdd2;
/* Common platform data configurations */
if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
--
1.7.4.1
___
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 RFC] OMAP: serial: Release the claimed memory region in remove
On Thu, Feb 9, 2012 at 23:58, Shubhrajyoti D shubhrajy...@ti.com wrote:
Currently the memory region is not released the folowing error is
observed.
/testsuites # insmod omap-serial.ko
[ 130.746917] omap_uart omap_uart.0: memory region already claimed
[ 130.753143] omap_uart: probe of omap_uart.0 failed with error -16
[ 130.759338] omap_uart omap_uart.1: memory region already claimed
[ 130.765380] omap_uart: probe of omap_uart.1 failed with error -16
[ 130.771606] omap_uart omap_uart.2: memory region already claimed
[ 130.777679] omap_uart: probe of omap_uart.2 failed with error -16
[ 130.783905] omap_uart omap_uart.3: memory region already claimed
[ 130.789947] omap_uart: probe of omap_uart.3 failed with error -16
Fix it by releasing the memory region.
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/tty/serial/omap-serial.c | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 130f7f8..4def6c3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1480,6 +1480,10 @@ do_release_region:
static int serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
+ struct resource *r;
+
+ r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ release_mem_region(r-start, resource_size(r));
if this is the same region which ioremapped to up-port.membase, then
please release mem region after the unmap.
Regards,
Nishanth Menon
if (up) {
iounmap(up-port.membase);
--
1.7.1
___
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 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
On Wed, Jan 25, 2012 at 12:49, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: On 1/25/2012 7:13 PM, Jean Pihet wrote: [...] I guess that path #3 and #5 should just be removed. I am ok with both options (keeping or removing the 2 commits), please let me know what you prefer. I guess that removing both is the only acceptable solution anyway. Yes, please remove them both. Also, please drop Change-IDs as well.. :) Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 04/15] omap4: add pmic startup / shutdown times
On Wed, Nov 30, 2011 at 03:45, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-11-29 at 12:30 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
Both startup and shutdown take 500us at maximum, value taken from
TWL6030 data manual.
Might be good to add reference version as well for traceability.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c
b/arch/arm/mach-omap2/omap_twl.c
index 62ed050..bd99328 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -207,6 +207,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12660,
+ .startup_time = 500,
549?
Where do you get 549? You looking at a different version of the DM? Or
are you adding something to the value?
woohoo.. welcome to TWL6030 doc hell ;)
Data Sheet: 0.05: T on =500Usec
*but* TRM 0.1 says T on = 500uSec for SMPS not freq locked, and upto
3ms with SMPS frequency locked).
*then* Functional spec rev 0.12 says Enable VCORE[1,2,3] = 549uSec.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 02/15] omap3+: voltage: parameter segregation
On Wed, Nov 30, 2011 at 04:07, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-11-29 at 12:26 -0600, Menon, Nishanth wrote:
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
more snip
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..1d44df5 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
/* 34xx */
+#define OMAP3_ON_VOLTAGE_UV 120
+#define OMAP3_ONLP_VOLTAGE_UV 100
+#define OMAP3_RET_VOLTAGE_UV 975000
+#define OMAP3_OFF_VOLTAGE_UV 60
this approach has a problem - ON, ONLP and RET voltage should consider:
Make that ON, ONLP, RET, OFF voltages! Sigh..
a) OMAP capabiltiy as above.
b) PMIC capability which is being removed in this patch
the framework should use the combination of both to make a decision.
So, I think we should limit these voltages based on the PMIC vddmin /
vddmax values, right? I don't think PMIC has any other limitations, and
Ideally speaking - this is what we want:
PMIC says - on this rail - I can give max x V and min y V. and when
you(kernel) gets control, expect Voltage = ON.
OMAP requirements - which ever wierd ones they might be - will be very
specific to OMAP variants.
some factors such as timing closures also come into play - ON, ONLP,
RET and OFF are OMAP reqs.
Now, we can have combinations like TPS+TWL+OMAP4430 (yep - those do
exist) or something like custom PMIC+OMAP4460
or many other combinations..
You could have additional complications as well - e.g. PMIC OFF path
is definitely our favourite.
writing 0x0 to TWL causes 0V and a 1 is 709..mV or 607..mV, 0x0 on TPS is 500mV!
we shouldn't define the voltage levels for all of these modes for PMIC.
PMIC limits should also probably be changed from current values (based
on OMAP defines) and changed to actual values, like vddmin = 600mV
(vsel=0), or whatever is the minimum voltage for the corresponding PMIC.
my point being: framework cannot expect any assumption about the PMIC
and the person writing the support for a new PMIC should be completely
ignorant for which OMAP he/she is writing for.
+};
+
#define OMAP4430_VDD_CORE_OPP50_UV 1025000
#define OMAP4430_VDD_CORE_OPP100_UV 120
@@ -64,6 +93,17 @@ struct omap_volt_data omap44xx_vdd_core_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+struct omap_vp_param omap44xx_core_vp_data = {
+ .vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
+ .vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+};
+
+struct omap_vc_param omap44xx_core_vc_data = {
+ .on = OMAP4_ON_VOLTAGE_UV,
+ .onlp = OMAP4_ONLP_VOLTAGE_UV,
+ .ret = OMAP4_RET_VOLTAGE_UV,
+ .off = OMAP4_OFF_VOLTAGE_UV,
+};
NOTE: we will be reaching all combinations ahead - in time to come
ahead we will have 4470 as well - linking this to opp data seems wrong
to me..
They are not really that much linked to opp data, they are just defined
in this file. The actual attach to voltdm is done in
voltagedomains_data.c file, where we can link data to whatever
voltagedomain we want to. See for example voltagedomains3xxx_data.c what
is done for omap34xx vs. omap36xx. Should we move this data over there
then...?
I think it belongs to VP/VC data and not in OPP file (which was meant
for OPPs in the first place).
we might want to think about replacing these with device tree data
someday - OPP data makes it
kinda hard to distinguish IMHO when we do that.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 02/15] omap3+: voltage: parameter segregation
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
Introduced two new voltage domain specific parameter structures,
omap_vp_param and omap_vc_param. These are used to describe the minimum
and maximum voltages for the voltagedomains, and also the sleep voltage
levels. Existing voltage levels are also moved into these new structures,
and the voltage domain code is changed to use these.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_opp_data.h | 15 ++
arch/arm/mach-omap2/omap_twl.c | 25
arch/arm/mach-omap2/opp3xxx_data.c | 52 +++
arch/arm/mach-omap2/opp4xxx_data.c | 40 ++
arch/arm/mach-omap2/vc.c | 178
+
arch/arm/mach-omap2/vc.h | 1 -
arch/arm/mach-omap2/voltage.h | 18 ++-
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 8 +
arch/arm/mach-omap2/voltagedomains44xx_data.c | 8 +
9 files changed, 289 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..b5fe711 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -86,11 +86,26 @@ extern int __init omap_init_opp_table(struct omap_opp_def
*opp_def,
extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
+extern struct omap_vp_param omap34xx_mpu_vp_data;
+extern struct omap_vp_param omap34xx_core_vp_data;
+extern struct omap_vc_param omap34xx_mpu_vc_data;
+extern struct omap_vc_param omap34xx_core_vc_data;
+
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
+extern struct omap_vp_param omap36xx_mpu_vp_data;
+extern struct omap_vp_param omap36xx_core_vp_data;
+extern struct omap_vc_param omap36xx_mpu_vc_data;
+extern struct omap_vc_param omap36xx_core_vc_data;
extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+extern struct omap_vp_param omap44xx_mpu_vp_data;
+extern struct omap_vp_param omap44xx_iva_vp_data;
+extern struct omap_vp_param omap44xx_core_vp_data;
+extern struct omap_vc_param omap44xx_mpu_vc_data;
+extern struct omap_vc_param omap44xx_iva_vc_data;
+extern struct omap_vc_param omap44xx_core_vc_data;
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index df4e7c3..62ed050 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -141,11 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt = 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
- .volt_setup_time = 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
@@ -162,11 +157,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt = 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
- .volt_setup_time = 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP3_VP_VSTEPMAX_VSTEPMAX,
@@ -183,11 +173,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt = 1375000,
- .onlp_volt = 1375000,
- .ret_volt = 83,
- .off_volt = 0,
- .volt_setup_time = 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP4_VP_VSTEPMAX_VSTEPMAX,
@@ -205,11 +190,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate = 4000,
.step_size = 12660,
- .on_volt = 1188000,
- .onlp_volt = 1188000,
- .ret_volt = 83,
- .off_volt = 0,
- .volt_setup_time
Re: [PATCHv4 04/15] omap4: add pmic startup / shutdown times
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote:
Both startup and shutdown take 500us at maximum, value taken from
TWL6030 data manual.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 62ed050..bd99328 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -207,6 +207,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12660,
+ .startup_time = 500,
549?
+ .shutdown_time = 500,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin = OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax = OMAP4_VP_VSTEPMAX_VSTEPMAX,
--
1.7.4.1
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 06/15] omap3+: vp: use new vp_params for calculating vddmin and vddmax
On Fri, Nov 25, 2011 at 09:49, Tero Kristo t-kri...@ti.com wrote: Now we select the vddmin and vddmax values based on both pmic and voltage processor data, this allows usage of different power ICs. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Nishanth Menon n...@ti.com Regards, Nishanth Menon --- arch/arm/mach-omap2/vp.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index 16cb6d4..ffb68d8 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -53,8 +53,10 @@ void __init omap_vp_init(struct voltagedomain *voltdm) sys_clk_rate = voltdm-sys_clk.rate / 1000; timeout = (sys_clk_rate * voltdm-pmic-vp_timeout_us) / 1000; - vddmin = voltdm-pmic-uv_to_vsel(voltdm-pmic-vp_vddmin); - vddmax = voltdm-pmic-uv_to_vsel(voltdm-pmic-vp_vddmax); + vddmin = max(voltdm-vp_param-vddmin, voltdm-pmic-vp_vddmin); + vddmax = min(voltdm-vp_param-vddmax, voltdm-pmic-vp_vddmax); + vddmin = voltdm-pmic-uv_to_vsel(vddmin); + vddmax = voltdm-pmic-uv_to_vsel(vddmax); waittime = ((voltdm-pmic-step_size / voltdm-pmic-slew_rate) * sys_clk_rate) / 1000; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RESEND #3 1/7] OMAP3+: PM: SR: add suspend/resume handlers
On Wed, Nov 16, 2011 at 18:02, Kevin Hilman khil...@ti.com wrote: Felipe Balbi ba...@ti.com writes: From: Nishanth Menon n...@ti.com SmartReflex should be disabled while entering low power mode due to the following reasons: [...] Nishanth, in the end, didn't you decide to drop this patch? Yes, I did eventually, once we implemented DVFS for GPU, Ducati, HSI, and other drivers, there was no real way to ensure sequence of suspend sequencing even after moving this to suspend_noirq. some of the other reasons: if I disabled Smartreflex and went to Nominal voltage on MPU, and say MPU was at performance mode of 1.5GHz or so, thermal scenarios got worse due on hot corner samples - these tend to have higher leakage and thermal characteristics tend to be more pronounced. The option of throttling frequency down while suspend was not really a good option in comparison to switching off smart reflex in the last possible moment - in pmxxx.c Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
On Thu, Sep 1, 2011 at 06:48, Cousson, Benoit b-cous...@ti.com wrote: Nishanth, Do you have any objection to replace that API with omap_hwmod_name_get_pdev? None. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 v4] mfd: omap: usb: Runtime PM support
On Fri, Aug 12, 2011 at 16:30, Todd Poynor toddpoy...@google.com wrote:
On Fri, Aug 12, 2011 at 12:20:21PM +0530, Munegowda, Keshava wrote:
On Wed, Aug 10, 2011 at 10:01 PM, Todd Poynor toddpoy...@google.com wrote:
@@ -913,12 +598,15 @@ static int usbhs_enable(struct device *dev)
(pdata-ehci_data-reset_gpio_port[1], 1);
}
-end_count:
- omap-count++;
+ pm_runtime_put_sync(dev);
spin_unlock_irqrestore(omap-lock, flags);
Is pm_runtime_irq_safe() needed (else I think runtime PM callbacks may
re-enable IRQs... or there's the new *_suspend runtime PM calls that
may avoid this)?
pm_runtime_irq_safe() is not required; usbhs does not have a parent
and it is the parent driver of
ehci and ohci drivers.
But the above expects IRQs to be disabled during the
pm_runtime_put_sync, and synchronous calls can turn IRQs back on in
rpm_idle:
if (callback) {
spin_unlock_irq(dev-power.lock);
callback(dev);
I see other folks who know this better than me are discussing USB run
time PM and might_sleep contexts, so I'll note this concern and let
others chime in if they think there's a real problem here.
It is rather easy with the following patch applied to pull this bug out!
https://patchwork.kernel.org/patch/1001572/
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/2] OMAP3+: voltage / oscillator parameter segregation
here is my quick feedback:
On Wed, Aug 3, 2011 at 10:29, Tero Kristo t-kri...@ti.com wrote:
This patch separates board specific voltage and oscillator ramp / setup
times from the core code. Things changed:
- on/sleep/ret/off voltage setup moved from common twl code to
VC / VP data (opp_data.c files)
- added board support for vdd ramp up / down times
- added board support for oscillator setup time declaration
Todo: split patch into more easily manageable parts.
Applies on top of pm/wip/voltdm branch, based on work done by Vishwanath
Sripathy.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
---
arch/arm/mach-omap2/omap_opp_data.h | 15 +++
arch/arm/mach-omap2/omap_twl.c | 59 --
arch/arm/mach-omap2/opp3xxx_data.c | 62 ++
arch/arm/mach-omap2/opp4xxx_data.c | 47
arch/arm/mach-omap2/prcm.c | 11 ++
arch/arm/mach-omap2/prm2xxx_3xxx.c | 6 +
arch/arm/mach-omap2/prm2xxx_3xxx.h | 1 +
arch/arm/mach-omap2/prm44xx.c | 7 +
arch/arm/mach-omap2/prm44xx.h | 1 +
arch/arm/mach-omap2/vc.c | 153
+
arch/arm/mach-omap2/vc.h | 1 -
arch/arm/mach-omap2/voltage.c | 22
arch/arm/mach-omap2/voltage.h | 55 -
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 8 ++
arch/arm/mach-omap2/voltagedomains44xx_data.c | 8 ++
arch/arm/mach-omap2/vp.c | 4 +-
arch/arm/plat-omap/include/plat/prcm.h | 7 +
17 files changed, 377 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..b5fe711 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -86,11 +86,26 @@ extern int __init omap_init_opp_table(struct omap_opp_def
*opp_def,
extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
+extern struct omap_vp_param omap34xx_mpu_vp_data;
+extern struct omap_vp_param omap34xx_core_vp_data;
+extern struct omap_vc_param omap34xx_mpu_vc_data;
+extern struct omap_vc_param omap34xx_core_vc_data;
+
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
+extern struct omap_vp_param omap36xx_mpu_vp_data;
+extern struct omap_vp_param omap36xx_core_vp_data;
+extern struct omap_vc_param omap36xx_mpu_vc_data;
+extern struct omap_vc_param omap36xx_core_vc_data;
extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+extern struct omap_vp_param omap44xx_mpu_vp_data;
+extern struct omap_vp_param omap44xx_iva_vp_data;
+extern struct omap_vp_param omap44xx_core_vp_data;
+extern struct omap_vc_param omap44xx_mpu_vc_data;
+extern struct omap_vc_param omap44xx_iva_vc_data;
+extern struct omap_vc_param omap44xx_core_vc_data;
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index f515a1a..d239792 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -30,16 +30,6 @@
#define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP3_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP3430_VP1_VLIMITTO_VDDMIN 0x14
-#define OMAP3430_VP1_VLIMITTO_VDDMAX 0x42
-#define OMAP3430_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3430_VP2_VLIMITTO_VDDMAX 0x2c
-
-#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3c
-#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18
-#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30
-
#define OMAP4_SRI2C_SLAVE_ADDR 0x12
#define OMAP4_VDD_MPU_SR_VOLT_REG 0x55
#define OMAP4_VDD_MPU_SR_CMD_REG 0x56
@@ -53,13 +43,6 @@
#define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
#define OMAP4_VP_VLIMITTO_TIMEOUT_US 200
-#define OMAP4_VP_MPU_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_MPU_VLIMITTO_VDDMAX 0x39
-#define OMAP4_VP_IVA_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_IVA_VLIMITTO_VDDMAX 0x2D
-#define OMAP4_VP_CORE_VLIMITTO_VDDMIN 0xA
-#define OMAP4_VP_CORE_VLIMITTO_VDDMAX 0x28
-
static bool is_offset_valid;
static u8 smps_offset;
/*
@@ -158,16 +141,9 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
- .on_volt = 120,
- .onlp_volt = 100,
- .ret_volt = 975000,
- .off_volt = 60,
- .volt_setup_time = 0xfff,
.vp_erroroffset =
Re: [PATCH v2 2/6] OMAP4: ID: add omap_has_feature for max freq supported
On Fri, Jul 1, 2011 at 21:30, Rajendra Nayak rna...@ti.com wrote:
[...]
+static void __init omap4_check_features(void)
+{
+ u32 si_type;
+
+ if (cpu_is_omap443x())
+ omap_features |= OMAP4_HAS_MPU_1GHZ;
+
+
+ if (cpu_is_omap446x()) {
+ si_type =
+
read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
+ switch ((si_type (3 16)) 16) {
+ case 2:
+ /* High performance device */
+ omap_features |= OMAP4_HAS_MPU_1_5GHZ;
+ break;
I have seen http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51988.html
and I disagree with this.
We are setting up a standard for all future silicon that omap_features
if it contains a higher frequency will always support all lower
frequencies in omap_feature. This may be convinent for the moment,
BUT, I disagree with the approach as we cannot guarantee that this
will be the approach for all silica in the future and approach taken
here could be considered short-sighted. if 1.2GHz will be supported
then a check for omap_has_1_2GHz should be true as well - which this
patch will fail to support. E.g. on 4460 has_1GHz should'nt return
true as it is 920MHz, but the check for 1_2GHz should be true - which
it wont as return omap_features OMAP3_HAS_ ##flag; will not have
BIT(9) set.
Regards,
Nishanth Menon
+ case 1:
+ default:
+ /* Standard device */
+ omap_features |= OMAP4_HAS_MPU_1_2GHZ;
+ break;
+ }
+ }
+}
[...]
--
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 2/7] OMAP3: beagle: don't touch omap_device internals
On Fri, Jul 29, 2011 at 09:05, Felipe Balbi ba...@ti.com wrote: +} +EXPORT_SYMBOL(omap_hwmod_name_get_odev); maybe EXPORT_SYMBOL_GPL() ?? Not sure we want non-GPL code to access this ;-) Sure.. but is this the way we want to go? if yes, I can post the series in a formal way to the list. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals
On Fri, Jul 29, 2011 at 09:05, Felipe Balbi ba...@ti.com wrote: +} +EXPORT_SYMBOL(omap_hwmod_name_get_odev); maybe EXPORT_SYMBOL_GPL() ?? Not sure we want non-GPL code to access this ;-) Sure.. but is this the way we want to go? if yes, I can post the series in a formal way to the list. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals
On Thu, Jul 28, 2011 at 07:57, Cousson, Benoit b-cous...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..77d01a2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#includeplat/clock.h
#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
I'd rather put that code inside the omap_device.c instead of here.
The omap_device layer is on top of the omap_hwmod.
In order to minimize the dependencies from the low HW description layer to
the omap_device layer, you should maybe define a omap_device_from_hwmod()
function or something similar.
Thanks for the review. will check on this.
That being said, do we really need to get the device from the hwmod name?
Cannot we use the device name instead?
I do not know all the usecases, that why I'm asking.
mpu.0 , are the device names - which probably lets me walk the kernel
data structrues instead of omap database to get to the right device,
Vs using the common names like mpu make things a little easier to
deal with from driver perspective.
as an example, some of the dev_driver_string(dev):dev_name(dev) (in
bracket hwmod name) I collected from OMAP4 are:
platform:mpu.0 (mpu)
platform:l3_main_1.0 ('l3_main_1)
pvrsrvkm:pvrsrvkm.0 (gpu)
rpres:fdif.0 (fdif)
omap_hsi:omap_hsi.0 (hsi)
platform:iss.0 (iss)
etc..
I mean I have'nt been keeping track of the device tree discussions so
dont know if this function could be better done - but I think I agree
with the overall idea that instead of spawning off get_xyz_device() we
need to have some uniform approach to get to the device scaling
silicon - I hoped we could consider the hwmod database/what ever
replacing it to do that.
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH 2/7] OMAP3: beagle: don't touch omap_device internals
On Thu, Jul 28, 2011 at 07:57, Cousson, Benoit b-cous...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 293fa6c..77d01a2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -142,6 +142,7 @@
#include powerdomain.h
#includeplat/clock.h
#includeplat/omap_hwmod.h
+#includeplat/omap_device.h
I'd rather put that code inside the omap_device.c instead of here.
The omap_device layer is on top of the omap_hwmod.
In order to minimize the dependencies from the low HW description layer to
the omap_device layer, you should maybe define a omap_device_from_hwmod()
function or something similar.
Thanks for the review. will check on this.
That being said, do we really need to get the device from the hwmod name?
Cannot we use the device name instead?
I do not know all the usecases, that why I'm asking.
mpu.0 , are the device names - which probably lets me walk the kernel
data structrues instead of omap database to get to the right device,
Vs using the common names like mpu make things a little easier to
deal with from driver perspective.
as an example, some of the dev_driver_string(dev):dev_name(dev) (in
bracket hwmod name) I collected from OMAP4 are:
platform:mpu.0 (mpu)
platform:l3_main_1.0 ('l3_main_1)
pvrsrvkm:pvrsrvkm.0 (gpu)
rpres:fdif.0 (fdif)
omap_hsi:omap_hsi.0 (hsi)
platform:iss.0 (iss)
etc..
I mean I have'nt been keeping track of the device tree discussions so
dont know if this function could be better done - but I think I agree
with the overall idea that instead of spawning off get_xyz_device() we
need to have some uniform approach to get to the device scaling
silicon - I hoped we could consider the hwmod database/what ever
replacing it to do that.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 V2] OMAP3+: PM: SR: add suspend/resume handlers
On Mon, Jul 25, 2011 at 03:42, Felipe Balbi ba...@ti.com wrote:
Hi,
On Sun, Jul 24, 2011 at 11:52:37AM -0500, Nishanth Menon wrote:
SmartReflex should be disabled while entering low power mode due to
the following reasons:
a) SmartReflex values are not defined for retention voltage.
b) With SmartReflex enabled, if the CPU enters low power state, FSM
will try to bump the voltage to current OPP's voltage for which
it has entered low power state, causing power loss and potential
unknown states for the SoC.
Since we are sure to attempt entering the lowest possible power state
during suspend operation, SmartReflex needs to be disabled for the
voltage domains in suspend path before achieving auto retention voltage
on the device.
Traditionally, this has been done with interrupts disabled as part of
the common code which handles the idle sequence. Instead, by using the
fact that we have to disable SmartReflex for sure during suspend
operations, we can opportunistically disable SmartReflex in device
standard pm ops, instead of disabling it as part of the code which
executes with interrupts disabled and slave CPU{s} shutdown. This
allows the system to do other parallel activities(such as suspending
other devices in the system using slave CPU{s}) and save the time
required to achieve suspend and resume from suspended state as a
sequential activity.
However, by being opportunistic as described above, we also increase
the likelihood of SmartReflex library access functions being invoked in
parallel contexts *after* SmartReflex driver's suspend handler (during
suspend operation) or *before* resume handler (during resume operation)
have been invoked (Example: DVFS for dependent devices, cpufreq for
MPU etc.). We prevent this by using a flag to reject the callers in
the duration where SmartReflex has been disabled.
while at that, SR's IRQ is never freed on exit path, could fix it while
you're already there ?
This is not really related to this patch is it? IMHO IRQ handling is
broken badly. Current support is for SmartReflex class3 - which does
not use the IRQ, Class2 and Class1.5 use it, but the current code
requires major fixes which I dont intend to support in this series.
@@ -998,10 +1020,75 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_sr_suspend(struct device *dev)
+{
+ struct omap_sr_data *pdata;
+ struct omap_sr *sr_info;
+
+ pdata = dev_get_platdata(dev);
I'm not sure you need to use platform data here...
see below
+ if (!pdata) {
+ dev_err(dev, %s: platform data missing\n, __func__);
+ return -EINVAL;
+ }
+
+ sr_info = _sr_lookup(pdata-voltdm);
this field is held on struct omap_sr. Can't you:
struct omap_sr *info = dev_get_drvdata(dev);
?? I see that a platform_set_drvdata() is missing from the driver, but
maybe you should add that instead of accessing platform_data.
omap_sr_data is added in arch/arm/mach-omap2/sr_device.c
With the current handling - it needs sr_data from which sr_info is
pulled out. in the current implementation, sr_data contains the voltdm
pointer from which sr_info is pulled out.
static struct platform_driver smartreflex_driver = {
.remove = omap_sr_remove,
.driver = {
.name = smartreflex,
+ .pm = omap_sr_dev_pm_ops,
this should not be valid in case CONFIG_PM isn't enabled.
a) arch/arm/plat-omap/Kconfig
CONFIG_OMAP_SMARTREFLEX depends on PM.
b) SmartReflex is PM feature
I dont see a need to add redundant code here.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 V2] OMAP3+: PM: SR: add suspend/resume handlers
On Mon, Jul 25, 2011 at 12:13, Felipe Balbi ba...@ti.com wrote:
[..]
while at that, SR's IRQ is never freed on exit path, could fix it while
you're already there ?
This is not really related to this patch is it? IMHO IRQ handling is
I didn't say to put it on the same patch ;-) I meant that while at that,
you could add that simple fix before this patch ;-)
Not really that simple - it is just one part of the equation, my point
being - if we are cleaning up, we better cleanup completely on that
thread at least.
broken badly. Current support is for SmartReflex class3 - which does
not use the IRQ, Class2 and Class1.5 use it, but the current code
requires major fixes which I dont intend to support in this series.
And that's exactly what I mean. IMHO it's far better to fix the mess
before adding more stuff, otherwise it just becomes an even bigger mess,
even more difficult to fix in the long run. We've seen that with GPIO
and sDMA drivers _at_least_ ;-(
I tried pushing the cleanups in my series
http://marc.info/?l=linux-omapm=129933897910785w=2
few of them did go through and I have since personally lost interest
and depending on my next free slot (not forthcoming for next few
months), I might want to retry it, but I guess there is more interest
in turning things into regulators than add new code.
I am ok if folks want to drop this patch - like previously, things
tend to get forgotten..
@@ -998,10 +1020,75 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_sr_suspend(struct device *dev)
+{
+ struct omap_sr_data *pdata;
+ struct omap_sr *sr_info;
+
+ pdata = dev_get_platdata(dev);
I'm not sure you need to use platform data here...
see below
+ if (!pdata) {
+ dev_err(dev, %s: platform data missing\n, __func__);
+ return -EINVAL;
+ }
+
+ sr_info = _sr_lookup(pdata-voltdm);
this field is held on struct omap_sr. Can't you:
struct omap_sr *info = dev_get_drvdata(dev);
?? I see that a platform_set_drvdata() is missing from the driver, but
maybe you should add that instead of accessing platform_data.
omap_sr_data is added in arch/arm/mach-omap2/sr_device.c
With the current handling - it needs sr_data from which sr_info is
pulled out. in the current implementation, sr_data contains the voltdm
pointer from which sr_info is pulled out.
but sr_info is allocated on probe() isn't it ? if you add
platform_set_drvdata(pdev, sr_info) on probe, you won't need sr_data to
fetch sr_info, all you need is to use dev_get_drvdata(dev). Am I missing
something ?
sr_info - I am not debating that this is not possible - I am just
explaining how it is being done now. I just dont have the bandwidth to
kill all evils in smartreflex driver. :(
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP2+: PM: SR: add suspend/resume handlers
On Fri, Jul 22, 2011 at 04:13, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 22, 2011 at 12:55:53AM -0500, Nishanth Menon wrote:
Suspend and Resume paths are safe enough to do it in
the standard LDM suspend/resume handlers where one can
sleep. Add suspend/resume handlers for SmartReflex.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 87
+
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 33a027f..fb90bd2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -39,6 +39,7 @@ struct omap_sr {
int ip_type;
int nvalue_count;
bool autocomp_active;
+ bool is_suspended;
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -684,6 +685,12 @@ void omap_sr_enable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
I wonder why you get these called if you're in suspend state. If this is
called by some other driver, then shouldn't you pm_runtime_get_sync();
do_whatever_you_need_to_do(); and pm_runtime_put(); rather then just
returning ?
because we have two state machines running in parallel - cpu idle and
dvfs(cpufreq, and other dependent domain voltage scaling) and SR
driver is just one - it does it's own get_sync and put_sync_suspend.
we cannot guarentee that the SR enable/disable calls can be properly
sequenced unless we use suspend lockouts. SmartReflex driver is an
independent entity of it's own - yeah we can do the same as we have
done historically in the omap[34]_idle paths(which is disable SR after
we have disabled interrupts), but in case of suspend(unlike in idle),
we do *know* that SR will have to be disabled - hence doing it earlier
as part of standard LDM suspend sequences is more opportunistic.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: I2C: Enable FIFO usage for OMAP4
On Tue, Jul 5, 2011 at 17:01, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Tested on omap4430 and 3430.
Reported-By: Nishanth Menon n...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Rebased on top of the series by Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Thanks.
This is v3.1 material, but would be nice to see a couple tested-by or
acked-by tags from folks that are more actively using the I2C driver
before merging
For what it is worth: tested on SDP4460/4430 with 255 multi-byte i2c
read operation on twl6030.
Tested-by: Nishanth Menon n...@ti.com
Regards,
Nishanth Menon
Kevin
drivers/i2c/busses/i2c-omap.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d53cd61..8f87a37 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1068,13 +1068,14 @@ omap_i2c_probe(struct platform_device *pdev)
* size. This is to ensure that we can handle the status on
int
* call back latencies.
*/
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430) {
- dev-fifo_size = 0;
+
+ dev-fifo_size = (dev-fifo_size / 2);
+
+ if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
dev-b_hw = 0; /* Disable hardware fixes */
- } else {
- dev-fifo_size = (dev-fifo_size / 2);
+ else
dev-b_hw = 1; /* Enable hardware fixes */
- }
+
/* calculate wakeup latency constraint for MPU */
if (dev-set_mpu_wkup_lat != NULL)
dev-latency = (100 * dev-fifo_size) /
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: I2C: Enable FIFO usage for OMAP4
On Tue, Jul 5, 2011 at 17:01, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently the fifo depth is set to zero for OMAP4 which disables
the FIFO usage. This patch enables the FIFO usage for I2C transactions
on OMAP4 also.
Tested on omap4430 and 3430.
Reported-By: Nishanth Menon n...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Rebased on top of the series by Andy Green
http://www.spinics.net/lists/linux-i2c/msg05632.html
Thanks.
This is v3.1 material, but would be nice to see a couple tested-by or
acked-by tags from folks that are more actively using the I2C driver
before merging
For what it is worth: tested on SDP4460/4430 with 255 multi-byte i2c
read operation on twl6030.
Tested-by: Nishanth Menon n...@ti.com
Regards,
Nishanth Menon
Kevin
drivers/i2c/busses/i2c-omap.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d53cd61..8f87a37 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1068,13 +1068,14 @@ omap_i2c_probe(struct platform_device *pdev)
* size. This is to ensure that we can handle the status on
int
* call back latencies.
*/
- if (dev-rev = OMAP_I2C_REV_ON_3530_4430) {
- dev-fifo_size = 0;
+
+ dev-fifo_size = (dev-fifo_size / 2);
+
+ if (dev-rev = OMAP_I2C_REV_ON_3530_4430)
dev-b_hw = 0; /* Disable hardware fixes */
- } else {
- dev-fifo_size = (dev-fifo_size / 2);
+ else
dev-b_hw = 1; /* Enable hardware fixes */
- }
+
/* calculate wakeup latency constraint for MPU */
if (dev-set_mpu_wkup_lat != NULL)
dev-latency = (100 * dev-fifo_size) /
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: OPP: add OMAP4460 definitions
On Sat, Jul 2, 2011 at 07:20, Vishwanath BS vishwanath...@ti.com wrote:
Add OMAP4460 OPP definitions for voltage and frequencies based on
OMAP4460 ES1.0 DM Operating Condition Addendum Version 0.1
The following exceptions are present:
* Smartreflex support is still on experimental mode: the gains and min
limits are currently pending characterization data. Currently OMAP4430 values
are used.
* Efuse offset for core OPP100-OV setting is not clear in documentation.
* IVA OPPs beyond OPP100 are disabled due to the delta between max OMAP4460
current requirements and Phoenix Max supply on VCORE2 in the default
configuration - boards which have supply which can support this should
explicitly call opp_enable and enable the same.
* MPU OPPs OPPTURBO can easily be detected using a efuse burnt - currently
disabled pending clock changes to support DCC feature.
Pathch is generated against Patch series [PATCH v2 0/6] OMAP4: Add 4460 base
support from Rajendra.
Spell check and this line does not belong to the commit message
Regards,
Nishanth Menon
[n...@ti.com: cleanups and updates from Datamanual]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/control.h | 1 +
arch/arm/mach-omap2/omap_opp_data.h | 9 ++-
arch/arm/mach-omap2/opp4xxx_data.c | 96
++---
arch/arm/mach-omap2/voltagedomains44xx_data.c | 14 +++-
4 files changed, 105 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a016c8b..a41b9a7 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -195,6 +195,7 @@
#define OMAP44XX_CONTROL_FUSE_MPU_OPPNITRO 0x249
#define OMAP44XX_CONTROL_FUSE_CORE_OPP50 0x254
#define OMAP44XX_CONTROL_FUSE_CORE_OPP100 0x257
+#define OMAP44XX_CONTROL_FUSE_CORE_OPP100OV 0x25A
/* AM35XX only CONTROL_GENERAL register offsets */
#define AM35XX_CONTROL_MSUSPENDMUX_6 (OMAP2_CONTROL_GENERAL + 0x0038)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h
b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..18a750e 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -89,8 +89,11 @@ extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
extern struct omap_volt_data omap36xx_vddcore_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
-extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+extern struct omap_volt_data omap443x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap443x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap443x_vdd_core_volt_data[];
+extern struct omap_volt_data omap446x_vdd_mpu_volt_data[];
+extern struct omap_volt_data omap446x_vdd_iva_volt_data[];
+extern struct omap_volt_data omap446x_vdd_core_volt_data[];
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 2293ba2..8c285e4 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -1,7 +1,7 @@
/*
* OMAP4 OPP table definitions.
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated -
http://www.ti.com/
* Nishanth Menon
* Kevin Hilman
* Thara Gopinath
@@ -36,7 +36,7 @@
#define OMAP4430_VDD_MPU_OPPTURBO_UV 1313000
#define OMAP4430_VDD_MPU_OPPNITRO_UV 1375000
-struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
+struct omap_volt_data omap443x_vdd_mpu_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP50_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPP100_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_MPU_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_MPU_OPPTURBO, 0xfa, 0x23),
@@ -48,7 +48,7 @@ struct omap_volt_data omap44xx_vdd_mpu_volt_data[] = {
#define OMAP4430_VDD_IVA_OPP100_UV 1188000
#define OMAP4430_VDD_IVA_OPPTURBO_UV 130
-struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
+struct omap_volt_data omap443x_vdd_iva_volt_data[] = {
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP50_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP50, 0xf4, 0x0c),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPP100_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPP100, 0xf9, 0x16),
VOLT_DATA_DEFINE(OMAP4430_VDD_IVA_OPPTURBO_UV,
OMAP44XX_CONTROL_FUSE_IVA_OPPTURBO, 0xfa, 0x23),
@@ -58,14 +58,14 @@ struct omap_volt_data omap44xx_vdd_iva_volt_data[] = {
#define OMAP4430_VDD_CORE_OPP50_UV 1025000
#define OMAP4430_VDD_CORE_OPP100_UV 120
-struct omap_volt_data
Re: [pm-wip/voltdm_nm][PATCH 07/10] OMAP3+: PM: VP: use uV for max and min voltage limits
On Thu, Jun 16, 2011 at 15:45, Kevin Hilman khil...@ti.com wrote: Nice! A reference to where these voltages values came from would be good to have in the code as well. these are just conversions of the existing values - :( I think we need a seperate patch updating from each of OMAP DMs.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/voltdm_nm][PATCH 09/10] OMAP2+: PM: secure OPP access using rcu locks
On Thu, Jun 16, 2011 at 15:47, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
OPP functions as described in Documentation/power/opp.txt
should be accessed under rcu_locks.
Signed-off-by: Nishanth Menon n...@ti.com
This looks like a fix needed in mainline.
Please send as a standalone patch against mainline and Cc
linux-arm-kernel.
ok will do.
Regards,
Nishanth Menon
Thanks,
Kevin
---
arch/arm/mach-omap2/pm.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d085f29..7355347 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -198,14 +198,17 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
freq = clk-rate;
clk_put(clk);
+ rcu_read_lock();
opp = opp_find_freq_ceil(dev, freq);
if (IS_ERR(opp)) {
+ rcu_read_unlock();
printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
bootup_volt = opp_get_voltage(opp);
+ rcu_read_unlock();
if (!bootup_volt) {
printk(KERN_ERR %s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
--
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] power: opp: Fix rcu_dereference_check() without protection!
On Tue, Jun 14, 2011 at 08:03, Santosh Shilimkar santosh.shilim...@ti.com wrote: With RCU debug options enabled, below warning is observed. === [ INFO: suspicious rcu_dereference_check() usage. ] --- drivers/base/power/opp.c:151 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1. ... --- Fix the same by protecting it with rcu_read lock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rafael J. Wysocki r...@sisk.pl Cc: Nishanth Menon n...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com --- drivers/base/power/opp.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index 56a6899..cbed5e1 100644 --- a/drivers/base/power/opp.c +++ b/drivers/base/power/opp.c @@ -148,7 +148,9 @@ unsigned long opp_get_voltage(struct opp *opp) struct opp *tmp_opp; unsigned long v = 0; + rcu_read_lock(); tmp_opp = rcu_dereference(opp); + rcu_read_unlock(); if (unlikely(IS_ERR_OR_NULL(tmp_opp)) || !tmp_opp-available) pr_err(%s: Invalid parameters\n, __func__); else NAK. please read the Documentation/power/opp.txt the usage is as follows: rcu_read_lock(); opp = opp_find_freq_ceil(); voltage = opp_get_voltage(opp); rcu_read_unlock(); the reason for this is that the opp pointer is not safe if we lock just the dereferencing. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Duration of mdelay and udelay depends on MPU frequency in SMP
On Mon, Jun 13, 2011 at 22:24, Stephen Boyd sb...@codeaurora.org wrote: On 06/10/2011 03:19 PM, Menon, Nishanth wrote: On Thu, May 12, 2011 at 01:42, Santosh Shilimkar santosh.shilim...@ti.com wrote: It's a well known problem if the udelay() is based of global lpj. You can read more here [1] Regards Santosh [1] http://eeek.borgchat.net/lists/arm-kernel/msg120702.html I am curious about this topic now. Searching Russel's patchworks for this: http://www.arm.linux.org.uk/developer/patches/search.php?summary=udelay I see nothing queued. What is the recommendation for udelay? The patches are sitting in Russell's patch tracker, waiting for him to accept/reject them. http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6874/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6875/1 http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6873/1 thanks for the same and hope these do get through :) Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3+: Kconfig: has EHCI only if USB present
On Fri, Jun 10, 2011 at 11:08, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Friday, June 10, 2011 8:45 PM To: linux-omap Cc: Tony; linux-arm; Balbi, Felipe; Menon, Nishanth Subject: [PATCH] OMAP3+: Kconfig: has EHCI only if USB present Attempting to disable USB generates the following warning at the moment: warning: (ARCH_OMAP3 ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) Signed-off-by: Nishanth Menon n...@ti.com --- based on 3.0-rc2 arch/arm/mach-omap2/Kconfig | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index ef7e12f..d5cf1a8 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -33,7 +33,7 @@ config ARCH_OMAP3 depends on ARCH_OMAP2PLUS default y select CPU_V7 - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4 select ARCH_HAS_OPP select PM_OPP if PM @@ -50,7 +50,7 @@ config ARCH_OMAP4 select ARM_ERRATA_720789 select ARCH_HAS_OPP select PM_OPP if PM - select USB_ARCH_HAS_EHCI + select USB_ARCH_HAS_EHCI if USB_SUPPORT comment OMAP Core Type depends on ARCH_OMAP2 Here is earlier discussion on the same subject: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42064.html Exactly same patch was proposed. You may want to do that for the full Kconfig file(not just for OMAP3) and post out.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Duration of mdelay and udelay depends on MPU frequency in SMP
On Thu, May 12, 2011 at 01:42, Santosh Shilimkar santosh.shilim...@ti.com wrote: On 5/5/2011 12:23 PM, Saquib wrote: Can anyone please help me to understand and fix this issue? When CPU frequency is 1008MHz, duration of delay was close to theoretical value, however, when 300MHz, it was close to about 4 times the theoretical value. I tested it on OMAP4(SMP) blaze board. It's a well known problem if the udelay() is based of global lpj. You can read more here [1] Regards Santosh [1] http://eeek.borgchat.net/lists/arm-kernel/msg120702.html I am curious about this topic now. Searching Russel's patchworks for this: http://www.arm.linux.org.uk/developer/patches/search.php?summary=udelay I see nothing queued. What is the recommendation for udelay? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit
On Wed, Jun 8, 2011 at 13:51, Kevin Hilman khil...@ti.com wrote:
[..]
the issue is as follows:
currently we dont do voltage transitions. when we do that
eventually(and my current code has an forked implementation of dvfs,
the following steps happen):
late_initcall(omap2_common_pm_late_init);
does pmic inits, omap_voltage_late_init, init_voltages and SR dev
initialization
without these, there is no way to transition MPU to proper voltage,
frequency combination. The requirement will have to be that
omap2-cpufreq.c allows for cpufreq transitions only after voltage and
clk layers are ready for transitions - if we ever want to do dvfs -
which we will eventually need to.
Yes, I understand.
But $SUBJECT patch is fixing this as an _init_ time ordering problem,
What you're describing is a runtime requirement that doesn't exist until
a DVFS transition is done. IOW, the requirement is that the voltage
etc. layers have to be init'd before the first transition.
So, rather than fix this with initcall ordering (which will have to be
redone as things git moved and converted to modules), just create a type
of late init function in this driver, which gets called on the first
transition.
The tricky part ofcourse is for the registration - if we do the
registration, omap_cpu_init will get called once the registration
happens - no reason to stop it, which in turn triggers omap_target the
moment the governors are ready to do their thing. Is the following
what you are talking about? I am not completely sure how this helps..
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 77efcb0..8586df8 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -253,6 +253,11 @@ static struct cpufreq_driver omap_driver = {
.attr = omap_cpufreq_attr,
};
+static int __init omap_cpufreq_lateinit(void)
+{
+ return cpufreq_register_driver(omap_driver);
+}
+
static int __init omap_cpufreq_init(void)
{
if (cpu_is_omap24xx()) {
@@ -277,8 +282,7 @@ static int __init omap_cpufreq_init(void)
pr_warning(%s: unable to get the mpu device\n, __func__);
return -EINVAL;
}
-
- return cpufreq_register_driver(omap_driver);
+ return 0;
}
static void __exit omap_cpufreq_exit(void)
@@ -288,5 +292,6 @@ static void __exit omap_cpufreq_exit(void)
MODULE_DESCRIPTION(cpufreq driver for OMAP2PLUS SOCs);
MODULE_LICENSE(GPL);
+late_initcall(omap_cpufreq_lateinit);
module_init(omap_cpufreq_init);
module_exit(omap_cpufreq_exit);
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit
On Tue, Jun 7, 2011 at 03:15, Santosh Shilimkar santosh.shilim...@ti.com wrote: On 6/7/2011 7:35 AM, Nishanth Menon wrote: Since we do module_init, cpufreq initializes before power late_init where many of the required data structures are registered. Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on which the build depends is bool and does'nt support modules yet. You might want to fix sequence instead of this change considering we want to make OMAP CPUFReq as a loadable module. Unless I add a is_omap_pm_ready() in omap_target() - it is not really safe. but smartreflex.c has a similar issue as well - I am open to suggestions on how we should fix this in a clean manner. Current omap2-cpufreq.c does not do dvfs - so it has dependency only on clocks - but the moment it depends on anything PM code does,we'd be dead as, for instance, dvfs requires a lot of those pieces to fall in place before we can execute omap_target. Regards, Nishanth Menon Signed-off-by: Nishanth Menonn...@ti.com --- arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index 2177381..07c2ab9 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) MODULE_DESCRIPTION(cpufreq driver for OMAP2PLUS SOCs); MODULE_LICENSE(GPL); -module_init(omap_cpufreq_init); +late_initcall(omap_cpufreq_init); module_exit(omap_cpufreq_exit); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/cpufreq][PATCH 3/3] OMAP2+: cpufreq: do lateinit
On Tue, Jun 7, 2011 at 16:49, Kevin Hilman khil...@ti.com wrote: Nishanth Menon n...@ti.com writes: Since we do module_init, cpufreq initializes before power late_init where many of the required data structures are registered. What exactly are the dependencies here? The only thing I see is the dependency on omap2_get_mpuss_device(), and those devices should be created as a postcore_initcall. If there are other dependencies, they're probably created a side effect of your earlier patches where you moved stuff from the -init hook (which happens much later) into the initcall function. Maybe that needs a rethink? Move cpufreq init to late_initcall instead. Further CONFIG_CPU_FREQ on which the build depends is bool and does'nt support modules yet. Signed-off-by: Nishanth Menon n...@ti.com If this works, it's only because of the link order defined by the Makefile ordering since both are the same level of initcall. When I move this driver to drivers/cpufreq, then the link order is less obvious. the issue is as follows: currently we dont do voltage transitions. when we do that eventually(and my current code has an forked implementation of dvfs, the following steps happen): late_initcall(omap2_common_pm_late_init); does pmic inits, omap_voltage_late_init, init_voltages and SR dev initialization without these, there is no way to transition MPU to proper voltage, frequency combination. The requirement will have to be that omap2-cpufreq.c allows for cpufreq transitions only after voltage and clk layers are ready for transitions - if we ever want to do dvfs - which we will eventually need to. Regards, Nishanth Menon Kevin --- arch/arm/mach-omap2/omap2plus-cpufreq.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index 2177381..07c2ab9 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -273,5 +273,5 @@ static void __exit omap_cpufreq_exit(void) MODULE_DESCRIPTION(cpufreq driver for OMAP2PLUS SOCs); MODULE_LICENSE(GPL); -module_init(omap_cpufreq_init); +late_initcall(omap_cpufreq_init); module_exit(omap_cpufreq_exit); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm-wip/voltdm_nm][PATCH 10/10] OMAP2+: PM: init_voltages: handle non compliant bootloaders
On Tue, Jun 7, 2011 at 20:12, Colin Cross ccr...@google.com wrote:
Bootloaders should in theory setup a frequency which is enabled in
OPP table. However, there can be mismatches, and we should try
both going lower in addition to the going higher to find
a match if bootloader boots up at a OPP than the kernel thinks it
should be allowed. We also sequence the frequency and voltage settings
properly.
Reported-by: Colin Cross ccr...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
---
PS: Apologies on the spam.. for some reason 10/10 never appeared in
http://marc.info/?l=linux-omapr=2b=201106w=2 - grumble grumble :(
arch/arm/mach-omap2/pm.c | 55
-
1 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 7355347..ce7554b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -174,7 +174,9 @@ static int __init omap2_set_init_voltage(char *vdd_name,
ch ar *clk_name,
struct voltagedomain *voltdm;
struct clk *clk;
struct opp *opp;
- unsigned long freq, bootup_volt;
+ unsigned long freq_cur, freq_valid, bootup_volt;
+ int raise_freq_idx, i;
+ int ret = -EINVAL;
if (!vdd_name || !clk_name || !dev) {
printk(KERN_ERR %s: Invalid parameters!\n, __func__);
@@ -195,16 +197,20 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
goto exit;
}
- freq = clk-rate;
- clk_put(clk);
+ freq_cur = clk-rate;
+ freq_valid = freq_cur;
rcu_read_lock();
- opp = opp_find_freq_ceil(dev, freq);
+ opp = opp_find_freq_ceil(dev, freq_valid);
if (IS_ERR(opp)) {
- rcu_read_unlock();
- printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
- __func__, vdd_name);
- goto exit;
+ opp = opp_find_freq_floor(dev, freq_valid);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ pr_err(%s: no boot OPP match for %ld on vdd_%s\n,
+ __func__, freq_cur, vdd_name);
+ ret = -ENOENT;
+ goto exit_ck;
+ }
}
bootup_volt = opp_get_voltage(opp);
@@ -212,11 +218,38 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
if (!bootup_volt) {
printk(KERN_ERR %s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
- goto exit;
+ ret = -ENOENT;
+ goto exit_ck;
}
- voltdm_scale(voltdm, bootup_volt);
- return 0;
+ /*
+ * Frequency and Voltage have to be sequenced: if we move from
+ * a lower frequency to higher frequency, raise voltage, followed by
+ * frequency, and vice versa. we assume that the voltage at boot
+ * is the required voltage for the frequency it was set for.
+ */
+ raise_freq_idx = freq_cur freq_valid;
+ for (i = 0; i 2; i++) {
+ if (i == raise_freq_idx)
+ ret = clk_set_rate(clk, freq_valid);
+ else
+ ret = voltdm_scale(voltdm, bootup_volt);
+ if (ret 0) {
+ pr_err(%s: unable to set %s-%s(f=%ld v=%ld)on
vdd%s\n,
+ __func__,
+ (i == raise_freq_idx) ? clk : voltage,
+ (i == raise_freq_idx) ? clk_name : vdd_name,
+ freq_valid, bootup_volt, vdd_name);
+ goto exit_ck;
+ }
+ }
This is way too complicated. Writing out what you mean is much more
readable, and not many more LOC:
hmm.. fine with me..
if (freq_cur freq_valid) {
ret = voltdm_scale(voltdm, bootup_volt);
if (ret) {
pr_err(%s: unable to set voltage-%s(f=%ld v=%ld)on vdd%s\n,
vdd_name, freq_valid, bootup_volt, vdd_name);
goto exit_ck;
}
}
optionally -
if (freq_cur == freq_valid) {
ret = clk_set_rate(clk, freq_valid);
if (ret) {
pr_err(%s: unable to set clk-%s(f=%ld v=%ld)on vdd%s\n,
clk_name, freq_valid, bootup_volt, vdd_name);
goto exit_ck;
}
}
if (freq_cur freq_valid) {
since we dont really know how the bootloader might have set the
voltage, (twl4030 allows i2c1 programming, others plugged on I2C_SR
can either use forcedupdate/vc bypass, we should do a force setting of
voltage..
if (freq_cur = freq_valid) ?
ret = voltdm_scale(voltdm, bootup_volt);
if (ret) {
pr_err(%s: unable to set voltage-%s(f=%ld v=%ld)on vdd%s\n,
vdd_name, freq_valid, bootup_volt, vdd_name);
goto exit_ck;
}
}
+
+
Re: [pm-wip/voltdm_nm][PATCH 10/10] OMAP2+: PM: init_voltages: handle non compliant bootloaders
On Tue, Jun 7, 2011 at 20:41, Menon, Nishanth n...@ti.com wrote:
On Tue, Jun 7, 2011 at 20:12, Colin Cross ccr...@google.com wrote:
Bootloaders should in theory setup a frequency which is enabled in
OPP table. However, there can be mismatches, and we should try
both going lower in addition to the going higher to find
a match if bootloader boots up at a OPP than the kernel thinks it
should be allowed. We also sequence the frequency and voltage settings
properly.
Reported-by: Colin Cross ccr...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
---
PS: Apologies on the spam.. for some reason 10/10 never appeared in
http://marc.info/?l=linux-omapr=2b=201106w=2 - grumble grumble :(
arch/arm/mach-omap2/pm.c | 55
-
1 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 7355347..ce7554b 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -174,7 +174,9 @@ static int __init omap2_set_init_voltage(char
*vdd_name, ch ar *clk_name,
struct voltagedomain *voltdm;
struct clk *clk;
struct opp *opp;
- unsigned long freq, bootup_volt;
+ unsigned long freq_cur, freq_valid, bootup_volt;
+ int raise_freq_idx, i;
+ int ret = -EINVAL;
if (!vdd_name || !clk_name || !dev) {
printk(KERN_ERR %s: Invalid parameters!\n, __func__);
@@ -195,16 +197,20 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
goto exit;
}
- freq = clk-rate;
- clk_put(clk);
+ freq_cur = clk-rate;
+ freq_valid = freq_cur;
rcu_read_lock();
- opp = opp_find_freq_ceil(dev, freq);
+ opp = opp_find_freq_ceil(dev, freq_valid);
if (IS_ERR(opp)) {
- rcu_read_unlock();
- printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
- __func__, vdd_name);
- goto exit;
+ opp = opp_find_freq_floor(dev, freq_valid);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ pr_err(%s: no boot OPP match for %ld on vdd_%s\n,
+ __func__, freq_cur, vdd_name);
+ ret = -ENOENT;
+ goto exit_ck;
+ }
}
bootup_volt = opp_get_voltage(opp);
@@ -212,11 +218,38 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
if (!bootup_volt) {
printk(KERN_ERR %s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
- goto exit;
+ ret = -ENOENT;
+ goto exit_ck;
}
- voltdm_scale(voltdm, bootup_volt);
- return 0;
+ /*
+ * Frequency and Voltage have to be sequenced: if we move from
+ * a lower frequency to higher frequency, raise voltage, followed by
+ * frequency, and vice versa. we assume that the voltage at boot
+ * is the required voltage for the frequency it was set for.
+ */
+ raise_freq_idx = freq_cur freq_valid;
+ for (i = 0; i 2; i++) {
+ if (i == raise_freq_idx)
+ ret = clk_set_rate(clk, freq_valid);
+ else
+ ret = voltdm_scale(voltdm, bootup_volt);
+ if (ret 0) {
+ pr_err(%s: unable to set %s-%s(f=%ld v=%ld)on
vdd%s\n,
+ __func__,
+ (i == raise_freq_idx) ? clk : voltage,
+ (i == raise_freq_idx) ? clk_name : vdd_name,
+ freq_valid, bootup_volt, vdd_name);
+ goto exit_ck;
+ }
+ }
This is way too complicated. Writing out what you mean is much more
readable, and not many more LOC:
hmm.. fine with me..
if (freq_cur freq_valid) {
ret = voltdm_scale(voltdm, bootup_volt);
if (ret) {
pr_err(%s: unable to set voltage-%s(f=%ld v=%ld)on vdd%s\n,
vdd_name, freq_valid, bootup_volt, vdd_name);
goto exit_ck;
}
}
optionally -
if (freq_cur == freq_valid) {
oops.. typo - intended:
if (freq_cur != freq_valid) {
Since the get_rate already says that we are in proper freq, why do
set_rate again?
ret = clk_set_rate(clk, freq_valid);
if (ret) {
pr_err(%s: unable to set clk-%s(f=%ld v=%ld)on vdd%s\n,
clk_name, freq_valid, bootup_volt, vdd_name);
goto exit_ck;
}
}
if (freq_cur freq_valid) {
since we dont really know how the bootloader might have set the
voltage, (twl4030 allows i2c1 programming, others plugged on I2C_SR
can either use forcedupdate/vc bypass, we should do a force setting of
voltage..
if (freq_cur = freq_valid) ?
ret = voltdm_scale(voltdm, bootup_volt
Re: [PATCH][pm-wip/cpufreq] OMAP2+: CPUfreq: Remove superfluous check in target() for online CPU's.
On Fri, Jun 3, 2011 at 07:16, Santosh Shilimkar santosh.shilim...@ti.com wrote: Current OMAP2PLUS CPUfreq tagret() functions returns when all the CPU's are not online. This breaks CPUfreq when secondary CPUs are offlined on SMP system. The intention of that check was just avoid CPU frequency change during the window when CPU becomes online but it's cpufreq_init is not done yet. Otherwise it can lead to notifiers being sent on a CPU which is not yet registered to the governor. But this race conditions is already managed by the CPUfreq core driver by updating the available cpumask accordingly. OMAP CPUFReq driver make use same cpumask for the notifiers so the above problem doesn't exist. In my initial implementation of the OMAP4 CPUFreq driver, I was using 'for_each_online_cpu()' for notifiers which lead me to add that check. Later I fixed the notifies but didn't realise that the check has become redundant then. Fix it by removing the superfluous check in target(). Thanks for Nishant Menon n...@ti.com for reporting issue with hot-plug and Kevin Hilman khil...@ti.com for his comment on excessive check in target(). Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Reported-by: Nishanth Menon n...@ti.com Tested-by: Vishwanath BS vishwanath...@ti.com Cc: Kevin Hilman khil...@ti.com Tested-by: Nishanth Menon n...@ti.com Regards, Nishanth Menon --- This change is an outcome of discussion on another patch to fix the hot-plug issue. For details refer below thread: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg50348.html arch/arm/mach-omap2/omap2plus-cpufreq.c | 4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index 33a91ec..3bf1704 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -81,10 +81,6 @@ static int omap_target(struct cpufreq_policy *policy, int i, ret = 0; struct cpufreq_freqs freqs; - /* Changes not allowed until all CPUs are online */ - if (is_smp() (num_online_cpus() NR_CPUS)) - return ret; - /* Ensure desired rate is within allowed range. Some govenors * (ondemand) will just pass target_freq=0 to get the minimum. */ if (target_freq policy-min) -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH v4 2/4] OMAP2+: cpufreq: use OPP library
On Thu, Jun 2, 2011 at 17:45, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code has does not use clk_init_cpufreq_table. As a result,
it is unusuable for OMAP2 and only usable only on platforms using OPP
library.
So move the compilation for cpufreq only if OPP is available for the
architecture and deny OMAP2 in multi-OMAP builds until OMAP2 is fixed.
Signed-off-by: Nishanth Menon n...@ti.com
I updated this patch slightly, preferring a more generic failure mode,
namely just failing with a warning on init when no OPPs are present.
I tested this on 3430/n900 by simply commenting out the
omap_init_opp_table() for OMAP3. CPUfreq init fails predictably with
platform mpu.0: opp_init_cpufreq_table: Device OPP not found (-19)
platform mpu.0: omap_cpu_init: cpu0: failed creating freq table[-19]
So CPUfreq driver never gets registered.
Updated patch below. If you're OK with this change, I'll apply it to
pm-wip/cpufreq.
Kevin
From 22f1704e2ec30816e34b3d46a4c61513441fce8d Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Thu, 26 May 2011 19:39:18 -0700
Subject: [PATCH 2/4] OMAP2+: cpufreq: only supports OPP library
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code does not currently use clk_init_cpufreq_table. As a
result, it is unusuable for OMAP2 and only usable only on platforms
using OPP library.
Remove the unbalanced clk_exit_cpufreq_table(). Any platforms where
OPPs are not availble will fail on init because a freq table will not
be properly initialized.
Signed-off-by: Nishanth Menon n...@ti.com
[khil...@ti.com: changelog edits, and graceful failure mode changes]
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index acf18e8..3af7cda 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -1,7 +1,7 @@
/*
* OMAP2PLUS cpufreq driver
*
- * CPU frequency scaling for OMAP
+ * CPU frequency scaling for OMAP using OPP information
*
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren t...@atomide.com
@@ -203,7 +203,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
- clk_exit_cpufreq_table(freq_table);
clk_put(mpu_clk);
return 0;
}
--
1.7.4
Fine with me. thanks for it. it achieves what I needed as well :)
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [pm_wip/voltdm_nm][PATCH v2 2/3] OMAP4: PM: VC: introduce concept of default channel
On Thu, Jun 2, 2011 at 18:45, Kevin Hilman khil...@ti.com wrote:
Nishanth Menon n...@ti.com writes:
Due to a TRM bug, the current code assumes that channel0(core) is the default
channel. With the additional explanation provided by the hardware team, it is
clear that PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. For example, the I2C slave address on
TWL6030
when using 4430 configuration could potentially use the same slave address
for
all domains, while in 4460 configuration, we drive MPU using TPS; Core and
IVA
using TWL6030. To allow this flexibility, we state in existing parameters
using
a flag to indicate usage of default channel.
In addition, the TRM update clears up the confusion on the fact that MPU is
infact the default channel on OMAP4.
We update the same here.
Signed-off-by: Nishanth Menon n...@ti.com
There's too much going on in this patch not described in the changelog
(extra error checking, volt cmd reg checking etc.)
Also, I don't like the USE_DEFAULT_CHANNEL_I2C_PARAM, mainly because it
adds clutter without any obvious value. To me, zero is a perfectly good
value to signify use default channel value, especially since that's
the value used by the hardware.
The reason is that 0 is a valid i2c register address. 8 bits is used
in VC and I wanted one bit which was further away, hence the 16 bit.
The usage could be that in .volt_reg_addr or in .cmd_reg_addr I could
set this up with the macro. and bingo, we use the default domain's
configuration.
This is esp useful if we had a single pmic reg for all domains.. I
mean the VC design allows for it, even though we dont use it
currently.
Incidentally, adding this doesn't actually change current behavior.
Currently, I use zero (an unconfigured value in the VC settings) to
signify it should use default settings. In your patch, you defined
USE_DEFAULT_CHANNEL_I2C_PARAM as 0x1 (17 bits) but assign it to 16
bit fields, which means they are just set to zero. :)
So rather than take this patch, I'm just going to fold the following
diff into OMAP3+: VC: abstract out channel configuration in voltdm_b.
I'll also update the changelog noting that the TRM is wrong here in that
it describes CORE as the default channel when it's in fact MPU.
I intend to post a new series including my PMIC changes as well early
next week(mondayish hopefully). Can we hold off review of any further
of my voltage fixes patches till then?
Kevin
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index fba352d..fa48944 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -33,21 +33,20 @@
* - command configuration address (RAC) and enable bit (RACEN)
* - command values for ON, ONLP, RET and OFF (CMD)
*
- * This function currently only allows flexible configuration of
- * the non-default channel (e.g. non-zero channels.) Starting with
- * OMAP4, only the non-zero channels can be configured. Channel zero
- * always uses the channel zero register values. Therefore, the
- * same limitation is imposed on OMAP3 for consistency.
+ * This function currently only allows flexible configuration of the
+ * non-default channel. Starting with OMAP4, there are more than 2
+ * channels, with one defined as the default (on OMAP4, it's MPU.)
+ * Only the non-default channel can be configured.
*/
static int omap_vc_config_channel(struct voltagedomain *voltdm)
{
struct omap_vc_channel *vc = voltdm-vc;
/*
- * For channel zero, the only configurable bit is RACEN.
+ * For default channel, the only configurable bit is RACEN.
* All others must stay at zero (see function comment above.)
*/
- if (!vc-cfg_channel_sa_shift)
+ if (vc-is_default_channel)
vc-cfg_channel = CFG_CHANNEL_RACEN;
voltdm-rmw(CFG_CHANNEL_MASK vc-cfg_channel_sa_shift,
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index f0fb61f..c216b57 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -84,6 +84,8 @@ struct omap_vc_channel {
u32 smps_cmdra_mask;
u8 cmdval_reg;
u8 cfg_channel_sa_shift;
+
+ bool is_default_channel;
};
extern struct omap_vc_channel omap3_vc_mpu;
diff --git a/arch/arm/mach-omap2/vc44xx_data.c
b/arch/arm/mach-omap2/vc44xx_data.c
index fe4f4e5..5844b20 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -58,6 +58,7 @@ struct omap_vc_channel omap4_vc_mpu = {
.smps_volra_mask = OMAP4430_VOLRA_VDD_MPU_L_MASK,
.smps_cmdra_mask = OMAP4430_CMDRA_VDD_MPU_L_MASK,
.cfg_channel_sa_shift = OMAP4430_SA_VDD_MPU_L_SHIFT,
+ .is_default_channel = true,
};
struct omap_vc_channel omap4_vc_iva = {
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [pm_wip/voltdm_nm][PATCH v2 2/3] OMAP4: PM: VC: introduce concept of default channel
On Thu, Jun 2, 2011 at 19:10, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Thu, Jun 2, 2011 at 18:45, Kevin Hilman khil...@ti.com wrote: Nishanth Menon n...@ti.com writes: Due to a TRM bug, the current code assumes that channel0(core) is the default channel. With the additional explanation provided by the hardware team, it is clear that PRM_VC_CFG_CHANNEL register allows for flexibility of configuring for various PMIC configurations. For example, the I2C slave address on TWL6030 when using 4430 configuration could potentially use the same slave address for all domains, while in 4460 configuration, we drive MPU using TPS; Core and IVA using TWL6030. To allow this flexibility, we state in existing parameters using a flag to indicate usage of default channel. In addition, the TRM update clears up the confusion on the fact that MPU is infact the default channel on OMAP4. We update the same here. Signed-off-by: Nishanth Menon n...@ti.com There's too much going on in this patch not described in the changelog (extra error checking, volt cmd reg checking etc.) Also, I don't like the USE_DEFAULT_CHANNEL_I2C_PARAM, mainly because it adds clutter without any obvious value. To me, zero is a perfectly good value to signify use default channel value, especially since that's the value used by the hardware. The reason is that 0 is a valid i2c register address. 8 bits is used in VC and I wanted one bit which was further away, hence the 16 bit. The usage could be that in .volt_reg_addr or in .cmd_reg_addr I could set this up with the macro. and bingo, we use the default domain's configuration. This is esp useful if we had a single pmic reg for all domains.. I mean the VC design allows for it, even though we dont use it currently. OK. See, it's easy to convince me that something is needed/useful. Of course, I prefer to be conviced by the changelog. :) Please make this feature into a dedicated patch with an appropriately descriptive changelog. Thanks. Yes, I agree. it probably is a better idea to break this thing up - I guess I was a bit lazyish considering these were targetted to be squashed.. not in the next series :) Incidentally, adding this doesn't actually change current behavior. Currently, I use zero (an unconfigured value in the VC settings) to signify it should use default settings. In your patch, you defined USE_DEFAULT_CHANNEL_I2C_PARAM as 0x1 (17 bits) but assign it to 16 bit fields, which means they are just set to zero. :) So rather than take this patch, I'm just going to fold the following diff into OMAP3+: VC: abstract out channel configuration in voltdm_b. I'll also update the changelog noting that the TRM is wrong here in that it describes CORE as the default channel when it's in fact MPU. I intend to post a new series including my PMIC changes as well early next week(mondayish hopefully). Can we hold off review of any further of my voltage fixes patches till then? Sure. It's the first time anyone as asked me not to review patches. :) I'll gladly comply. I've already folded the minimal change I proposed into the original patch locally, and will push updated voltdm_* branches by the end of today. :) Thanks. I will rework the patches and line up a series from cpufreq and voltage domain perspective in the upcoming days.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2+: CPUfreq: Allow the CPU scaling when secondary CPUs are offline.
On Thu, Jun 2, 2011 at 09:51, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Current OMAP2PLUS CPUfreq tagret() functions returns when all
the CPU's are not online. This will break DVFS when secondary
CPUs are offlined.
The intention of that check was just avoid CPU frequency change
during the window when CPU becomes online but it's cpufreq_init is
not done yet.
is it this requirement a boot requirement or a necessity for
cpufreq_driver.init being called for online cpus? Since we maintain
just a single freq_table... why do we care about multiple cpu_inits?
Anyways, tried testing this and .config with CONFIG_SMP_ON_UP and
USERSPACE. it works with one cpu and does not scale 2 cpus :(
After applying this patch on kevin's cpufreq branch, I added some
prints for logging:
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 909bfcb..89856d5 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -83,8 +83,13 @@ static int omap_target(struct cpufreq_policy *policy,
struct cpufreq_freqs freqs;
/* Changes not allowed until all CPUs are online */
- if (is_smp() (cpus_initialized num_online_cpus()))
+ if (is_smp() (cpus_initialized num_online_cpus())) {
+ pr_err(%s: cpu %d not ready to go to %d (inits=%d vs
online=%d)\n, __func__,
+ policy-cpu, target_freq,
cpus_initialized, num_online_cpus());
return ret;
+ }
+ pr_err(%s: cpu %d ready to go to %d (inits=%d vs online=%d)\n,
__func__,
+ policy-cpu, target_freq, cpus_initialized, num_online_cpus());
/* Ensure desired rate is within allowed range. Some govenors
* (ondemand) will just pass target_freq=0 to get the minimum. */
@@ -197,6 +202,9 @@ static int __cpuinit omap_cpu_init(struct
cpufreq_policy *policy)
cpumask_copy(policy-cpus, cpumask);
cpus_initialized++;
smp_wmb();
+ pr_err(%s: cpu %d cpus_initialized = %d online=%d\n, __func__,
+ policy-cpu, cpus_initialized, num_online_cpus());
+
}
/* FIXME: what's the actual transition time? */
@@ -212,6 +220,8 @@ static int omap_cpu_exit(struct cpufreq_policy *policy)
if (is_smp()) {
cpus_initialized--;
smp_wmb();
+ pr_err(%s: cpu %d cpus_initialized = %d online=%d\n, __func__,
+ policy-cpu, cpus_initialized, num_online_cpus());
}
return 0;
}
on boot, this is what I see:
[0.421020] omap_cpu_init: cpu 0 cpus_initialized = 1 online=2
[0.421264] omap_target: cpu 0 not ready to go to 1008000 (inits=1
vs online=2)
[0.421630] omap_cpu_init: cpu 1 cpus_initialized = 2 online=2
[0.421691] omap_cpu_exit: cpu 1 cpus_initialized = 1 online=2
...
snip
...
[2.044128] omap_target: cpu 0 not ready to go to 1008000 (inits=1
vs online=2)
[2.051849] omap_target: cpu 0 not ready to go to 1008000 (inits=1
vs online=2)
... snip..
...boots up to busybox shell..
/ # head /sys/devices/system/cpu/cpu1/online /sys/devices/system/cpu/cpu0/online
== /sys/devices/system/cpu/cpu1/online ==
1
== /sys/devices/system/cpu/cpu0/online ==
1
/ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
30 60 80 1008000
/ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1008000
/ # echo -n 30/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 130.257385] omap_target: cpu 0 not ready to go to 30 (inits=1
vs online=2)
/ # echo -n 0 /sys/devices/system/cpu/cpu1/online
[ 144.749877] CPU1: shutdown
/ # head /sys/devices/system/cpu/cpu1/online /sys/devices/system/cpu/cpu0/online
== /sys/devices/system/cpu/cpu1/online ==
0
== /sys/devices/system/cpu/cpu0/online ==
1
/ # echo -n 35 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 165.881927] omap_target: cpu 0 ready to go to 35 (inits=1 vs online=1)
[ 165.889526] cpufreq-omap: transition: 1008000 -- 0
/ #
/ # echo -n 1 /sys/devices/system/cpu/cpu1/online
[ 176.469360] CPU1: Booted secondary processor
[ 176.469421] CPU1: Unknown IPI message 0x1
[ 176.475280] Switched to NOHz mode on CPU #1
[ 176.600891] omap_cpu_init: cpu 1 cpus_initialized = 2 online=2
[ 176.620178] omap_cpu_exit: cpu 1 cpus_initialized = 1 online=2
[ 176.626373] omap_target: cpu 0 not ready to go to 35 (inits=1
vs online=2)
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/4: PM: Boot message is not an error/info, and not helpful, remove it
On Mon, May 30, 2011 at 08:44, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 5/30/2011 7:06 PM, Sergei Shtylyov wrote:
Hello.
Santosh Shilimkar wrote:
The commit '99aa18278e' removed the boot messege for OMAP3. Do the same
Please specify that commit's summary in parens -- for the human readers.
Oh, and you don't need quotes around commit ID too.
Yes I missed that. Updated patch below.
Regards
Santosh
From 53e986a2a43dc204146af99c2d7a906dba781ea0 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 30 May 2011 15:52:01 +0530
Subject: [PATCH] OMAP2/4: PM: Boot message is not an error/info, and not
helpful, remove it
The commit 99aa18278e (OMAP3: PM: Boot message is not an error,
and not helpful, remove it), removed the boot message for OMAP3.
Do the same for OMAP2 and OMAP4 since it's really just noise in the
boot log and PM init is always called.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
Acked-by: Nishanth Menon n...@ti.com
Regards,
Nishanth Menon
---
arch/arm/mach-omap2/pm24xx.c | 1 -
arch/arm/mach-omap2/pm44xx.c | 2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index df3ded6..5970759 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -442,7 +442,6 @@ static int __init omap2_pm_init(void)
if (!cpu_is_omap24xx())
return -ENODEV;
- printk(KERN_INFO Power Management for OMAP2 initializing\n);
l = omap2_prm_read_mod_reg(OCP_MOD, OMAP2_PRCM_REVISION_OFFSET);
printk(KERN_INFO PRCM revision %d.%d\n, (l 4) 0x0f, l 0x0f);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 59a870b..a6259d6 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -103,8 +103,6 @@ static int __init omap4_pm_init(void)
if (!cpu_is_omap44xx())
return -ENODEV;
- pr_err(Power Management for TI OMAP4.\n);
-
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
pr_err(Failed to setup powerdomains\n);
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On Fri, May 27, 2011 at 14:38, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: [...] In general we do not want to reset nor idle an IP that was potentially already properly configured by bootloader or early Linux boot code. Actually, the opposite is true. The kernel should not make any assumptions about what the bootloader has or has not done. We need to have a kernel that can boot from any bootloader (or none, like using kexec) and be able to start from a known hardware state. Any use of HWMOD_INIT_NO_IDLE, HWMOD_INIT_NO_RESET should be a rare exception and well documented. Looking deeper to find the rootcause, I see this: a) TI provides a reference schematics design that is usually copied on to most of the platforms - e.g. blaze and panda etc.. this may not be the norm, but tends to be same except for intrepid board designers who like to go into unexplored areas. b) in this case, I tracked the issue down. Here is what is happening (given NDA restrictions as the datasheet of the PMIC is not pubic yet, I am being vague here. Apologies on the same :(): This PMIC has one voltage output which drives MPU - just like the 1vsel per rail as we had in TWL series, here we have an option of storing n values in n vsel registers and selecting one of them. the selection is based on x pins that may be driven by the MPU. In this particular case, one of the pins is connected to OMAP GPIO1 block allowing PMIC to set the voltage from one of two options inside the PMIC - This could have been used like we'd have done in OMAP2 days with VMODE pin. However, in our TI's x-loader case it sets it to 1, and since hwmod reset happens here, it gets set to 0, selecting a much lower voltage than what is needed for functioning causing system to hangup. Now, with this reference design, many things are possible - folks following TI x-loader might pull the pin high, could pull the pin low or even go and ground the pin and free up the GPIO itself. now we have two cases: a) folks who follow TI's recommendations verbatim b) intrepid folks who like doing their own things. What should the default kernel look like here? I think I agree - it should be board files that is usually tied to a particular bootloader (exception being devel boards like Beagle, Panda, Blaze etc where people do develop bootloaders as well..). I agree with kevin here - this should be done by board file. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On Thu, May 26, 2011 at 22:06, Santosh Shilimkar santosh.shilim...@ti.com wrote: On 5/26/2011 11:40 PM, Kevin Hilman wrote: So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. We are running only one instance and for the exact same reason as above. You are completely right and that's the whole intention of those CPUMASK two lines in the initialization code. What am I missing? Not at all. So not have cpufreq driver registered at all for CPU1? Life would be a lot simpler in omap2-cpufreq.c as a result. but that said, two views: a) future silicon somewhere ahead might need the current infrastructure to scale into different tables.. b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but* cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but .../cpu1/online is present). Keep in mind that userspace is usually written chip independent. IMHO registering drivers for both devices do make sense they reflect what the reality of the system is. 2 cpus scaling together - why do we want to OMAP specific stuff here? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 6/8] OMAP2+: cpufreq: fix freq_table leak
On Thu, May 26, 2011 at 10:11, Kevin Hilman khil...@ti.com wrote: When you're talking about potentially concurrent modification of data, that make sense. Here you're implementing a plugin for an existing framework, and you can (and have to) make assumptions about when the callbacks are used. ok, that is the one i was looking for. thanks. will use atomic ops and drop the mutex. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
On Thu, May 26, 2011 at 10:38, Kevin Hilman khil...@ti.com wrote: I'd prefer to see this even cleaner by dropping the clk_* versions all together. Then, for those who want OMAP2 support (currently not working or validated anyways), all that's needed is to add a function simlilar to clk_init_cpufreq_table() which registers OPPs. yeah - that is better as well.. will do Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On Thu, May 26, 2011 at 11:10, Kevin Hilman khil...@ti.com wrote: So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. What am I missing? my understanding from the code is that we have one instance of cpufreq controllable from either cpu0 or 1. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
On Thu, May 26, 2011 at 11:35, Menon, Nishanth n...@ti.com wrote: On Thu, May 26, 2011 at 10:38, Kevin Hilman khil...@ti.com wrote: I'd prefer to see this even cleaner by dropping the clk_* versions all together. Then, for those who want OMAP2 support (currently not working or validated anyways), all that's needed is to add a function simlilar to clk_init_cpufreq_table() which registers OPPs. yeah - that is better as well.. will do oops - missed asking - are you ok with just returning a warning and not registering the cpufreq driver for OMAP2? Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
