public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFC][PATCH] Power domains for platform bus type
Date: Mon, 31 Jan 2011 15:16:15 -0800	[thread overview]
Message-ID: <87tygo3br4.fsf@ti.com> (raw)
In-Reply-To: <201101300107.19389.rjw@sisk.pl> (Rafael J. Wysocki's message of "Sun, 30 Jan 2011 01:07:19 +0100")

Hi Rafael,

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> Hi,
>
> This is something we discussed during the last Linux Plumbers Conference.
>
> The problem appears to be that the same device may be used in different
> systems in different configurations such that actions necessary for the
> device's power management can vary from one system to another.  In those
> cases the drivers' power management callbacks are generally not sufficient,
> because they can't take the configuration of the whole system into account.
>
> I think this issue may be addressed by adding objects that will represent
> power domains and will provide power management callbacks to be executed
> in addition to the device driver's PM callbacks, which is done by the patch
> below.
>
> Please have a look at it and tell me what you think.

Very nice.  I like the approach and the fact that it allows grouping of
only devices we care about customizing, instead of every device on the
platform_bus (I know Grant will like that part too.  :)

I experimented with something similar before I took the easy way out
with platform_bus_set_pm_ops() :/

This approach might also solve the problem(s) we've been discussing
around the conflicts between runtime PM callbacks and system PM
callbacks (that RTC vs. i2c issue.)  With this approach, I shouldn't
have to to add the callbacks like I did for the i2c driver, but rather
handle them in common code.  I'll experiment with this...

The primary question for me is whether this should rather be at the
'struct device' level instead of at the platform_device level.  While
we're currently only using this customization on platform_devices, I
don't think we should limit it to that.  Part of these discussions at
LPC was also about whether or not to move to using custom SoC-specific
devices and busses.  If/when we go that route, we'd want these power
domains part of struct device, not platform_device.

It would be a rather minor change to your patch, but would be more
flexible for the future.

Some other minor comments below...

> ---
> The platform bus type is often used to represent Systems-on-a-Chip
> (SoC) where all devices are represented by objects of type struct
> platform_device.  In those cases the same "platform" device driver
> may be used in multiple different system configurations, but the
> actions needed to put the devices it handles into a low-power state
> and back into the full-power state may depend on the design of the
> SoC.  The driver, however, cannot possibly include all the
> information necessary for the power management of its device on all
> the systems it's used with.  Moreover, the device hierarchy also
> isn't suitable for holding this kind of information.
>
> The patch below attempts to address this problem by introducing
> objects of type struct power_domain that can be used for representing
> power domains inside of the SoC.  Every struct power_domain object
> consists of two sets of device power management callbacks that
> can be used to perform what's needed for device power management
> in addition to the operations carried out by the device's driver.
> Namely, if a struct power_domain object is pointed to by the domain
> field in a struct platform_device, the callbacks provided by its
> pre_ops member will be executed for the dev member of that
> struct platform_device before executing the corresponding callbacks
> provided by the device's driver.  Analogously, the power domain's
> post_ops callbacks will be executed after the corresponding callbacks
> provided by the device's driver.

You should probably add here that the power_domain callbacks will be
called even if a driver is not present for the device, which may or may
not be expected.

> ---
>  drivers/base/platform.c         |  266 ++++++++++++++++++++++++++++------------
>  include/linux/platform_device.h |    6 
>  2 files changed, 198 insertions(+), 74 deletions(-)
>
> Index: linux-2.6/include/linux/platform_device.h
> ===================================================================
> --- linux-2.6.orig/include/linux/platform_device.h
> +++ linux-2.6/include/linux/platform_device.h
> @@ -14,6 +14,11 @@
>  #include <linux/device.h>
>  #include <linux/mod_devicetable.h>
>  
> +struct power_domain {
> +	struct dev_pm_ops *pre_ops;
> +	struct dev_pm_ops *post_ops;
> +};

Since most SoC code is also going to have something called 'struct
power_domain', I'd suggest naming this 'struct dev_power_domain' or
something to indicate it's part of the driver model, so it wouldn't get
confused with other SoC specific power_domain structs.

Thanks,

Kevin

  parent reply	other threads:[~2011-01-31 23:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201101300107.19389.rjw@sisk.pl>
2011-01-30 16:03 ` [RFC][PATCH] Power domains for platform bus type Alan Stern
2011-01-31 12:05 ` Mark Brown
2011-01-31 22:59 ` Grant Likely
     [not found] ` <20110131225902.GD27856@angua.secretlab.ca>
2011-01-31 23:10   ` Rafael J. Wysocki
     [not found]   ` <201102010010.46096.rjw@sisk.pl>
2011-01-31 23:43     ` Kevin Hilman
     [not found]     ` <871v3s3ahe.fsf@ti.com>
2011-02-01  3:18       ` Grant Likely
2011-02-01  3:40       ` Alan Stern
     [not found]       ` <AANLkTinEsUOZQURXOfAVoTU5=k0mi8PC0_Gte6gACDFj@mail.gmail.com>
2011-02-01 10:58         ` Rafael J. Wysocki
     [not found]         ` <201102011158.46312.rjw@sisk.pl>
2011-02-01 16:48           ` Kevin Hilman
     [not found]           ` <87sjw7wvjl.fsf@ti.com>
2011-02-01 18:39             ` Rafael J. Wysocki
     [not found]             ` <201102011939.49793.rjw@sisk.pl>
2011-02-12 22:12               ` [RFC][PATCH 0/2] PM: Core power management modifications Rafael J. Wysocki
     [not found]               ` <201102122312.26545.rjw@sisk.pl>
2011-02-12 22:13                 ` [RFC][PATCH 1/2] PM: Add support for device power domains Rafael J. Wysocki
2011-02-12 22:14                 ` [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle subsystems consistently Rafael J. Wysocki
     [not found]                 ` <201102122314.41407.rjw@sisk.pl>
2011-02-14 16:25                   ` Alan Stern
2011-02-15 18:10                   ` Kevin Hilman
     [not found]                   ` <87pqqtrwxt.fsf@ti.com>
2011-02-15 19:48                     ` Grant Likely
     [not found]                 ` <201102122313.23398.rjw@sisk.pl>
2011-02-14 16:12                   ` [RFC][PATCH 1/2] PM: Add support for device power domains Alan Stern
2011-02-15 18:23                   ` Kevin Hilman
2011-01-31 23:16 ` Kevin Hilman [this message]
2011-01-31 23:23   ` [RFC][PATCH] Power domains for platform bus type Grant Likely
2011-02-01  0:17 ` Kevin Hilman
     [not found] ` <878vy01udd.fsf@ti.com>
2011-02-01 10:52   ` Rafael J. Wysocki
     [not found] <Pine.LNX.4.44L0.1101311442100.1931-100000@iolanthe.rowland.org>
2011-01-31 22:16 ` Rafael J. Wysocki
     [not found] ` <201101312316.52116.rjw@sisk.pl>
2011-01-31 22:26   ` Grant Likely
     [not found]   ` <20110131222609.GC27856@angua.secretlab.ca>
2011-01-31 22:44     ` Kevin Hilman
     [not found]     ` <87vd1466d8.fsf@ti.com>
2011-01-31 23:01       ` Rafael J. Wysocki
     [not found] <201101311909.07333.rjw@sisk.pl>
2011-01-31 19:45 ` Alan Stern
     [not found] <Pine.LNX.4.44L0.1101310957350.1931-100000@iolanthe.rowland.org>
2011-01-31 18:09 ` Rafael J. Wysocki
     [not found] <201101302339.02993.rjw@sisk.pl>
2011-01-31 15:01 ` Alan Stern
     [not found] <Pine.LNX.4.44L0.1101301100090.6500-100000@netrider.rowland.org>
2011-01-30 22:39 ` Rafael J. Wysocki
2011-01-30  0:07 Rafael J. Wysocki

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=87tygo3br4.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox