All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@suse.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
Date: Thu, 07 Apr 2011 22:31:23 +0000	[thread overview]
Message-ID: <201104080031.23452.rjw@suse.com> (raw)
In-Reply-To: <87hbaa7zhs.fsf@ti.com>

On Thursday, April 07, 2011, Kevin Hilman wrote:
> Kevin Hilman <khilman@ti.com> writes:
> 
> [...]
> 
> > Replacing the PM ops for all devices was done on OMAP and SH-mobile
> > because that was the only approach we had.  Now that we have device
> > power domains (thanks Rafael!), we can be more selective about which
> > devices to apply them to.
> >
> > Note that my RFC patch/series did not do the selective part of deciding
> > which devices to override and which ones not to, that part will be
> > platform specific.  
> 
> Actually, thinking about this a little more, my patch actually does
> select only relevant devices, and not *all* platform devices.
> 
> In my patch, the device power domain pointers are only added for devices
> where a clk_get() actually succeeds.  In the original version, the
> runtime PM hooks are overridden for *all* platform devices, but ones
> that have no clock (or where clk_get() failed) have the additional
> overhead of still calling the custom PM ops, but the custom ops have
> nothing to do.

As I wrote in another message to Grant, the problem basically is that
the platform bus type behavior is not the desirable one.  Namely, I don't
generally want device driver callbacks to be invoked until we know that
power will be removed from the devices.  However, the platform bus type
executes driver callbacks automatically if they exist.  This currently is
unavoidable, because power domain callbacks are executed in addition to and
not instead the bus type callbacks.

We've discussed that a bit at the LF Collab Summit with Grant and Paul and
the conclusion is that to address this particular problem we'll need to change
the core so that if there is a power domain for the given device, the
power domain callbacks will be executed first and if they return a specific
error code, the core will execute the bus type callbacks.  For devices that
don't belong to any power domain, the bus type callbacks will be executed
(which is the current behavior).

I'm going to post a patch along these lines early next week.  Then, we
can simply move the management of device clocks, the execution of device
driver callbacks and the power removal into power domain callbacks.

At that point it may be possible to share some code between shmobile and
OMAP, but I'm not sure yet how much of the code may be shared and it what
way exactly.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@suse.com>
To: Kevin Hilman <khilman@ti.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	"Greg Kroah-Hartman" <gregkh@suse.de>,
	"Linux-pm mailing list" <linux-pm@lists.linux-foundation.org>,
	Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
Date: Fri, 8 Apr 2011 00:31:23 +0200	[thread overview]
Message-ID: <201104080031.23452.rjw@suse.com> (raw)
In-Reply-To: <87hbaa7zhs.fsf@ti.com>

On Thursday, April 07, 2011, Kevin Hilman wrote:
> Kevin Hilman <khilman@ti.com> writes:
> 
> [...]
> 
> > Replacing the PM ops for all devices was done on OMAP and SH-mobile
> > because that was the only approach we had.  Now that we have device
> > power domains (thanks Rafael!), we can be more selective about which
> > devices to apply them to.
> >
> > Note that my RFC patch/series did not do the selective part of deciding
> > which devices to override and which ones not to, that part will be
> > platform specific.  
> 
> Actually, thinking about this a little more, my patch actually does
> select only relevant devices, and not *all* platform devices.
> 
> In my patch, the device power domain pointers are only added for devices
> where a clk_get() actually succeeds.  In the original version, the
> runtime PM hooks are overridden for *all* platform devices, but ones
> that have no clock (or where clk_get() failed) have the additional
> overhead of still calling the custom PM ops, but the custom ops have
> nothing to do.

As I wrote in another message to Grant, the problem basically is that
the platform bus type behavior is not the desirable one.  Namely, I don't
generally want device driver callbacks to be invoked until we know that
power will be removed from the devices.  However, the platform bus type
executes driver callbacks automatically if they exist.  This currently is
unavoidable, because power domain callbacks are executed in addition to and
not instead the bus type callbacks.

We've discussed that a bit at the LF Collab Summit with Grant and Paul and
the conclusion is that to address this particular problem we'll need to change
the core so that if there is a power domain for the given device, the
power domain callbacks will be executed first and if they return a specific
error code, the core will execute the bus type callbacks.  For devices that
don't belong to any power domain, the bus type callbacks will be executed
(which is the current behavior).

I'm going to post a patch along these lines early next week.  Then, we
can simply move the management of device clocks, the execution of device
driver callbacks and the power removal into power domain callbacks.

At that point it may be possible to share some code between shmobile and
OMAP, but I'm not sure yet how much of the code may be shared and it what
way exactly.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: rjw@suse.com (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
Date: Fri, 8 Apr 2011 00:31:23 +0200	[thread overview]
Message-ID: <201104080031.23452.rjw@suse.com> (raw)
In-Reply-To: <87hbaa7zhs.fsf@ti.com>

On Thursday, April 07, 2011, Kevin Hilman wrote:
> Kevin Hilman <khilman@ti.com> writes:
> 
> [...]
> 
> > Replacing the PM ops for all devices was done on OMAP and SH-mobile
> > because that was the only approach we had.  Now that we have device
> > power domains (thanks Rafael!), we can be more selective about which
> > devices to apply them to.
> >
> > Note that my RFC patch/series did not do the selective part of deciding
> > which devices to override and which ones not to, that part will be
> > platform specific.  
> 
> Actually, thinking about this a little more, my patch actually does
> select only relevant devices, and not *all* platform devices.
> 
> In my patch, the device power domain pointers are only added for devices
> where a clk_get() actually succeeds.  In the original version, the
> runtime PM hooks are overridden for *all* platform devices, but ones
> that have no clock (or where clk_get() failed) have the additional
> overhead of still calling the custom PM ops, but the custom ops have
> nothing to do.

As I wrote in another message to Grant, the problem basically is that
the platform bus type behavior is not the desirable one.  Namely, I don't
generally want device driver callbacks to be invoked until we know that
power will be removed from the devices.  However, the platform bus type
executes driver callbacks automatically if they exist.  This currently is
unavoidable, because power domain callbacks are executed in addition to and
not instead the bus type callbacks.

We've discussed that a bit at the LF Collab Summit with Grant and Paul and
the conclusion is that to address this particular problem we'll need to change
the core so that if there is a power domain for the given device, the
power domain callbacks will be executed first and if they return a specific
error code, the core will execute the bus type callbacks.  For devices that
don't belong to any power domain, the bus type callbacks will be executed
(which is the current behavior).

I'm going to post a patch along these lines early next week.  Then, we
can simply move the management of device clocks, the execution of device
driver callbacks and the power removal into power domain callbacks.

At that point it may be possible to share some code between shmobile and
OMAP, but I'm not sure yet how much of the code may be shared and it what
way exactly.

Thanks,
Rafael

  parent reply	other threads:[~2011-04-07 22:31 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  0:02 [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations Kevin Hilman
2011-04-07  0:02 ` Kevin Hilman
2011-04-07  0:02 ` Kevin Hilman
2011-04-07  0:02 ` [PATCH/RFC 1/6] ARM: sh-mobile: runtime PM: convert to device powerdomains Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02 ` [PATCH/RFC 2/6] OMAP2+: PM: move runtime PM implementation to use device power domains Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  5:49   ` [PATCH/RFC 2/6] OMAP2+: PM: move runtime PM implementation to Grant Likely
2011-04-07  5:49     ` [PATCH/RFC 2/6] OMAP2+: PM: move runtime PM implementation to use device power domains Grant Likely
2011-04-07  5:49     ` Grant Likely
2011-06-09 14:30   ` Sakari Ailus
2011-06-09 16:37     ` Kevin Hilman
2011-06-10  6:57       ` N900 USB fix (Was: Re: [PATCH/RFC 2/6] OMAP2+: PM: move runtime PM implementation to use device power domains) Sakari Ailus
2011-06-13  8:28         ` Jarkko Nikula
2011-06-13  8:46           ` Felipe Balbi
2011-06-13  8:47             ` Felipe Balbi
2011-04-07  0:02 ` [PATCH/RFC 3/6] OMAP1: runtime PM: drop platform bus implementation Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02 ` [PATCH/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07 16:56   ` Paul Mundt
2011-04-07 16:56     ` Paul Mundt
2011-04-07 16:56     ` Paul Mundt
2011-04-07 17:08     ` Kevin Hilman
2011-04-07 17:08       ` Kevin Hilman
2011-04-07 17:08       ` Kevin Hilman
2011-04-07 22:35       ` Rafael J. Wysocki
2011-04-07 22:35         ` Rafael J. Wysocki
2011-04-07 22:35         ` Rafael J. Wysocki
2011-04-08  0:38         ` Kevin Hilman
2011-04-08  0:38           ` Kevin Hilman
2011-04-08  0:38           ` Kevin Hilman
2011-04-08  5:01           ` Paul Mundt
2011-04-08  5:01             ` Paul Mundt
2011-04-08  5:01             ` Paul Mundt
2011-04-07  0:02 ` [PATCH/RFC 5/6] ARM: use common clock-based runtime PM implementation on SH-mobile & OMAP1 Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02 ` [PATCH/RFC 6/6] Revert "driver core: platform_bus: allow runtime override of dev_pm_ops" Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  0:02   ` Kevin Hilman
2011-04-07  5:38 ` [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations Rafael J. Wysocki
2011-04-07  5:38   ` Rafael J. Wysocki
2011-04-07  5:38   ` Rafael J. Wysocki
2011-04-07 14:58   ` Kevin Hilman
2011-04-07 14:58     ` Kevin Hilman
2011-04-07 14:58     ` Kevin Hilman
2011-04-07 17:17     ` Kevin Hilman
2011-04-07 17:17       ` Kevin Hilman
2011-04-07 17:17       ` Kevin Hilman
2011-04-07 22:31       ` Rafael J. Wysocki
2011-04-07 22:31       ` Rafael J. Wysocki [this message]
2011-04-07 22:31         ` Rafael J. Wysocki
2011-04-07 22:31         ` Rafael J. Wysocki
2011-04-08  0:32         ` Kevin Hilman
2011-04-08  0:32         ` Kevin Hilman
2011-04-08  0:32           ` Kevin Hilman
2011-04-08  0:32           ` Kevin Hilman
2011-04-07 17:17     ` Kevin Hilman
2011-04-07 14:58   ` Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201104080031.23452.rjw@suse.com \
    --to=rjw@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.