On Thu, Jun 30, 2011 at 12:50 AM, Kevin Hilman khil...@ti.com wrote:
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and
On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs
On Wed, 29 Jun 2011, Munegowda, Keshava wrote:
for usb host case , I am seeing that the pm_runtime_get_sync
static int rpm_resume(struct device *dev, int rpmflags)
{
..
if (dev-pwr_domain) {
callback = dev-pwr_domain-ops.runtime_resume;
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Wednesday, June 29, 2011 11:03 PM
To: Munegowda, Keshava
Cc: Kevin Hilman; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; ba...@ti.com; gadi...@ti.com;
sa...@linux.intel.com;
On Wed, 29 Jun 2011, Partha Basak wrote:
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Wednesday, June 29, 2011 11:03 PM
To: Munegowda, Keshava
Cc: Kevin Hilman; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org;
Munegowda, Keshava keshava_mgo...@ti.com writes:
On Wed, Jun 29, 2011 at 8:52 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Thu, Jun 2, 2011 at 5:36 AM, Kevin Hilman khil...@ti.com wrote:
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
On Sun, Jun 05, 2011 at 03:30:55PM -0400, Alan Stern wrote:
On Sun, 5 Jun 2011, Felipe Balbi wrote:
that would mean changes to all linker scripts, though and a utility call
that only does anything ifndef CONFIG_PM to free the .pm.ops section.
In my opinion this would make programming
On Sun, 5 Jun 2011, Felipe Balbi wrote:
Hi,
On Sun, Jun 05, 2011 at 03:30:55PM -0400, Alan Stern wrote:
good point. BTW, do we need this #ifdef CONFIG_PM stuff which has been
popping on most drivers recently ? To me it looks like driver.pm field
is always available even if PM
Hi,
On Mon, Jun 06, 2011 at 12:06:44PM -0400, Alan Stern wrote:
So, something like:
#define __pm_ops__section(.pm.ops)
static const struct dev_pm_ops my_driver_pm_ops __pm_ops = {
.suspend= my_driver_suspend,
.resume =
On Mon, 6 Jun 2011, Felipe Balbi wrote:
But what is the right thing? Suppose you want to have conditional
support for dev_pm_ops whenever CONFIG_PM is enabled and you _also_
want to have conditional support for runtime PM whenever
CONFIG_PM_RUNTIME is enabled?
we don't have this
On Wednesday, June 01, 2011, Felipe Balbi wrote:
Hi,
On Wed, Jun 01, 2011 at 03:54:38PM +0200, Rafael J. Wysocki wrote:
+static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
+ .suspend= usbhs_suspend,
+ .resume = usbhs_resume,
+};
Please add
Hi,
On Sun, Jun 05, 2011 at 07:19:38PM +0200, Rafael J. Wysocki wrote:
On Wed, Jun 01, 2011 at 03:54:38PM +0200, Rafael J. Wysocki wrote:
+static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
+ .suspend= usbhs_suspend,
+ .resume = usbhs_resume,
+};
On Sun, 5 Jun 2011, Felipe Balbi wrote:
good point. BTW, do we need this #ifdef CONFIG_PM stuff which has been
popping on most drivers recently ? To me it looks like driver.pm field
is always available even if PM is disabled, so what's the point ? Saving
a few bytes ?
Basically,
Hi,
On Sun, Jun 05, 2011 at 03:30:55PM -0400, Alan Stern wrote:
good point. BTW, do we need this #ifdef CONFIG_PM stuff which has been
popping on most drivers recently ? To me it looks like driver.pm field
is always available even if PM is disabled, so what's the point ? Saving
a
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus suspend and resume of ehci and ohci drivers are called
from
Hi,
On Wed, Jun 01, 2011 at 06:57:27PM +0530, Keshava Munegowda wrote:
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 43de12a..32d19e2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -146,6 +146,10 @@
#define is_ehci_hsic_mode(x)
On Wed, Jun 1, 2011 at 7:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Jun 01, 2011 at 06:57:27PM +0530, Keshava Munegowda wrote:
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 43de12a..32d19e2 100644
--- a/drivers/mfd/omap-usb-host.c
+++
On Wednesday, June 01, 2011, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus
Hi,
On Wed, Jun 01, 2011 at 03:54:38PM +0200, Rafael J. Wysocki wrote:
+static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
+ .suspend= usbhs_suspend,
+ .resume = usbhs_resume,
+};
Please add .freeze()/.thaw() and .poweroff()/.restore() callbacks too.
They may
Keshava Munegowda keshava_mgo...@ti.com writes:
From: Keshava Munegowda keshava_mgo...@ti.com
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus suspend and
21 matches
Mail list logo