One correction here:
On Wed, 23 Jun 2010, Paul Walmsley wrote:
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Just to clarify. The functions I'm overriding here is the bus
functions (bus-pm-[suspend|resume]_noirq(), not any driver functions
OK, I see that now - this code was confusing in
Paul Walmsley p...@pwsan.com writes:
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
I guess the intent of your patch is to avoid having to patch in
omap_device_{idle,enable}() into a bunch of driver DPM suspend/resume
callbacks?
Partially.
On Thu, 24 Jun 2010, Paul Walmsley wrote:
Sorry, misread this also. Indeed, something like this is necessary in
your platform bus override code - so please ignore this part of the
comments.
By the way, I owe you a more general apology, Kevin, that some of these
comments have been
Hi Kevin,
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
I guess the intent of your patch is to avoid having to patch in
omap_device_{idle,enable}() into a bunch of driver DPM suspend/resume
callbacks?
Partially. Actually, I think many (most?)
On Tue, 1 Jun 2010, Kevin Hilman wrote:
Nayak, Rajendra rna...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/pm_bus.c
b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@
Paul Walmsley p...@pwsan.com writes:
On Tue, 1 Jun 2010, Kevin Hilman wrote:
Nayak, Rajendra rna...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/pm_bus.c
b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
As far as I can tell, it's not safe for upper-layer code to idle a device
like this. The driver itself needs to be aware of the device's idle
state.
The driver is made aware using the standard
Paul Walmsley p...@pwsan.com writes:
On Mon, 21 Jun 2010, Kevin Hilman wrote:
Paul Walmsley p...@pwsan.com writes:
As far as I can tell, it's not safe for upper-layer code to idle a device
like this. The driver itself needs to be aware of the device's idle
state.
The driver is
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Friday, May 28, 2010 2:43 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
Hook
Nayak, Rajendra rna...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/pm_bus.c
b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
};
Hook into the platform bus methods for suspend and resume and
use the omap_device API to automatically idle and enable the
device on suspend and resume.
This allows device drivers to get rid of direct management of their
clocks in their suspend/resume paths, and let omap_device do it for
them.
11 matches
Mail list logo
