On Thu, Jul 28, 2011 at 10:30:15AM +0200, jean.pi...@newoldbits.com wrote:
...
+int pwrdm_set_wkup_lat_constraint(struct powerdomain *pwrdm, void *cookie,
+ long min_latency)
+{
+ struct pwrdm_wkup_constraints_entry *user = NULL;
+ struct
On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the PM QoS devices constraint can be requested
early in the boot sequence, the power domains
Mark,
On Thu, Jul 28, 2011 at 3:14 PM, mark gross markgr...@thegnar.org wrote:
On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
High level implementation:
...
7. Misc
Todd,
On Fri, Jul 29, 2011 at 9:59 AM, Todd Poynor toddpoy...@google.com wrote:
On Thu, Jul 28, 2011 at 10:30:15AM +0200, jean.pi...@newoldbits.com wrote:
...
+int pwrdm_set_wkup_lat_constraint(struct powerdomain *pwrdm, void *cookie,
+ long min_latency)
+{
+
On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor toddpoy...@google.com wrote:
On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the PM QoS devices
Hi,
On Thu, Jul 14, 2011 at 01:34:54PM +0200, Enric Balletbò i Serra wrote:
Playing with USB ethernet gadget on IGEP boards with mainline kernel
(Linux 3.0.0-rc7) I observed one strange behavior. The ethernet gadget
works with one board with OMAP3530 but it doesn't with another one
with
On Thu, Jul 28, 2011 at 02:48:57PM +0300, Tero Kristo wrote:
OMAP SMPS regulator driver provides access to OMAP voltage processor
controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
layer for the actual
Hi,
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Proposal:
1. For the UART, follow the current approach of locking the console in
Idle/Suspend path before cutting the clock but using
pm_runtime_putsync.
That is, continue using the
2011/7/29 Tapani Utriainen tap...@technexion.com:
On Thu, 28 Jul 2011 16:18:51 +0200
Arno Steffen arno.stef...@googlemail.com wrote:
That has been good points. I've tried both, but with no result so far.
Try appending earlyprintk=${console} to your bootargs (where ${console}
is your
Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the platform.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c | 18 ++
include/linux/i2c-omap.h |1 +
2 files changed, 19 insertions(+), 0
The SYSC register should not accessed in the driver removing the
define from the driver.
Also clean up the syscstate from the omap_i2c_dev struct.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 -
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
device_reset were added in those places to effect the
The series attempts to do the following
- The reset should not be done in the driver
have support for the same.
- Remove the sysc register access in the driver.
version 2
- Fix the indentation.
- Restore in the error path is not needed as we are
doing a init.
version 3
- Combine the
[...]
Looking at omap_gpio_mod_init() it seems like much of its processing
could probably be done once at probe time (or at pm_runtime_get_sync
time) as well, namely setting the IRQ enable masks.
This must be called at the beginning of bank access to get reset state.
Otherwise, it
[...]
To be clear, it seems like resetting irqenable settings should be a
one-time action at probe time. The power management actions such as
Looking at it again, well we could probably avoid *_mod_init() in request.
I will test and confirm. Thanks.
--
Tarun
[...]
Anyhow, mainly wanted to
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
Thanks for replying.
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Proposal:
1. For the UART, follow the current approach of locking the console in
Idle/Suspend path before cutting
On Thursday 21 July 2011 04:57 PM, Santosh Shilimkar wrote:
Thanks for your review.
On 7/21/2011 4:39 PM, Shubhrajyoti D wrote:
snip
+/*
+ * Enabling all wakup sources to stop I2C freezing on
+ * WFI instruction.
+ * REVISIT: Some wkup sources might not be
Hi,
On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
Thanks for replying.
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Proposal:
1. For the UART, follow the current
Currently for OMAP4 the I2C_WE is not programmed.
This patch enables the programming for OMAP4.
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
TODO:
Currently all the wakeup sources are enabled.
There is scope of optimising the same.
On Fri, Jul 29, 2011 at 5:07 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 29, 2011 at 04:54:44PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 3:25 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
Thanks for replying.
On Thu, Jul 28, 2011 at 02:59:55PM +0530, Govindraj.R wrote:
Hi,
On Fri, Jul 29, 2011 at 05:18:42PM +0530, Shubhrajyoti D wrote:
Currently for OMAP4 the I2C_WE is not programmed.
This patch enables the programming for OMAP4.
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
TODO:
Hi,
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios even before first runtime_suspend happens,
ex: uart_port_configure - get_sync - pm_generic_runtime_resume
(omap_device_enable in this case) debug printk - console_write - get_sync.
there are
Hi,
On Fri, Jul 29, 2011 at 01:28:12PM +0100, Andy Green (林安廸) wrote:
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
dev-westate);
+ if (dev-rev OMAP_I2C_REV_ON_3530_4430)
+
This patch adds the NAND support on OMAP3EVM board and also allocates
five partitions on NAND.
Referred to file: arch/arm/mach-omap2/board-omap3beagle.c
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Hrishikesh Bhandiwad
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ if (dev-rev OMAP_I2C_REV_ON_3530_4430)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
+
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios even before first runtime_suspend happens,
ex: uart_port_configure - get_sync - pm_generic_runtime_resume
(omap_device_enable in
Hi!
Actually, it just occurred to me that if we're waiting for a system
timer and can hand that off to a suitable timer in the PMIC then we can
do a suspend to RAM for the deep idle state from the hardware point of
view.
Yep. At LinuxCon Cambridge two years ago, we had a
On Friday 29 July 2011 06:07 PM, Felipe Balbi wrote:
Hi,
On Fri, Jul 29, 2011 at 01:28:12PM +0100, Andy Green (林安廸) wrote:
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+
On 08:31-20110728, Menon, Nishanth wrote:
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
+++
Hi,
On Fri, Jul 29, 2011 at 06:28:32PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios even before first runtime_suspend
happens,
ex:
Hi,
On Fri, Jul 29, 2011 at 07:11:34PM +0530, Shubhrajyoti wrote:
On Friday 29 July 2011 06:07 PM, Felipe Balbi wrote:
Hi,
On Fri, Jul 29, 2011 at 01:28:12PM +0100, Andy Green (林安廸) wrote:
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
-
hi,
On Fri, Jul 29, 2011 at 08:49:34AM -0500, Nishanth Menon wrote:
From f03490456e24f72ca5272303c95a6f0b212494d5 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Wed, 27 Jul 2011 15:02:32 -0500
Subject: [PATCH 1/2] OMAP: PM: omap_device: add omap_hwmod_name_get_odev
An API
Hi,
On Fri, Jul 29, 2011 at 07:33:39PM +0530, Datta, Shubhrajyoti wrote:
On Fri, Jul 29, 2011 at 7:11 PM, Shubhrajyoti [1]shubhrajy...@ti.com
wrote:
On Friday 29 July 2011 06:07 PM, Felipe Balbi wrote:
Hi,
On Fri, Jul 29, 2011 at 01:28:12PM +0100, Andy Green
On Fri, Jul 29, 2011 at 10:37:52AM +0200, Jean Pihet wrote:
Mark,
On Thu, Jul 28, 2011 at 3:14 PM, mark gross markgr...@thegnar.org wrote:
On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for
On Fri, Jul 29, 2011 at 7:32 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jul 29, 2011 at 06:28:32PM +0530, Govindraj wrote:
On Fri, Jul 29, 2011 at 5:49 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Jul 29, 2011 at 05:29:12PM +0530, Govindraj wrote:
Yes fine, But there are scenarios
Currently for OMAP4 the I2C_WE is not programmed.
This patch enables the programming for OMAP4.
This patch fixes a bad conflict resolution.
This effectively restores the following commit
Commit 120bdaa47[i2c-omap: Program I2C_WE on OMAP4 to enable i2c wakeup]
which got changed by
Commit
On Fri, Jul 29, 2011 at 10:47:43AM +0200, Jean Pihet wrote:
On Fri, Jul 29, 2011 at 9:59 AM, Todd Poynor toddpoy...@google.com wrote:
...
All min_latency != PM_QOS_DEV_LAT_DEFAULT_VALUE paths need
free_new_user = 1.
free_new_user = 1 is only needed if no existing constraint has been
found,
On Friday, July 29, 2011, Pavel Machek wrote:
Hi!
Actually, it just occurred to me that if we're waiting for a system
timer and can hand that off to a suitable timer in the PMIC then we can
do a suspend to RAM for the deep idle state from the hardware point of
view.
Yep.
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
High level implementation:
1. Add a new PM QoS class for device wake-up constraints (PM_QOS_DEV_LATENCY).
. Define a
On Friday, July 29, 2011, mark gross wrote:
On Fri, Jul 29, 2011 at 10:37:52AM +0200, Jean Pihet wrote:
Mark,
On Thu, Jul 28, 2011 at 3:14 PM, mark gross markgr...@thegnar.org wrote:
On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Add the field latency_constraints in the struct dev_pm_info
and the initialization of the plist in device_pm_init.
This enables the implementation of per-device constraints in
PM QoS.
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The PM QoS implementation files are better named
kernel/pm_qos.c and include/linux/pm_qos.h.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-msm/clock.c |2 +-
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Extend the PM QoS kernel API:
- add a new PM QoS class PM_QOS_DEV_LATENCY for device wake-up latency
constraints
- make the pm_qos_add_request API more generic by using a parameter of
type struct
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.
G, Manjunath Kondaiah manj...@ti.com writes:
On Wed, Jul 27, 2011 at 02:45:33PM -0700, Hilman, Kevin wrote:
Hi Manjunath,
On Wed, Jul 27, 2011 at 7:04 AM, G, Manjunath Kondaiah manj...@ti.com
wrote:
Kevin,
On Thu, Jul 21, 2011 at 04:52:10PM -0700, Kevin Hilman wrote:
Here's a first
45 matches
Mail list logo
