linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-i2c@vger.kernel.org, Wolfram Sang <wsa@the-dreams.de>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Lv Zheng <lv.zheng@intel.com>, Aaron Lu <aaron.lu@intel.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RESEND 1/2] i2c: prepare runtime PM support for I2C client devices
Date: Tue, 10 Sep 2013 10:51:00 +0300	[thread overview]
Message-ID: <20130910075100.GK7393@intel.com> (raw)
In-Reply-To: <20130909154028.GP29403@sirena.org.uk>

On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
> On Mon, Sep 09, 2013 at 04:34:38PM +0300, Mika Westerberg wrote:
> 
> > +	/*
> > +	 * Enable runtime PM for the client device. If the client wants to
> > +	 * participate on runtime PM it should call pm_runtime_put() in its
> > +	 * probe() callback.
> > +	 *
> > +	 * User still needs to allow the PM runtime before it can actually
> > +	 * happen.
> > +	 */
> > +	pm_runtime_forbid(&client->dev);
> > +	pm_runtime_get_noresume(&client->dev);
> > +	pm_runtime_set_active(&client->dev);
> > +	pm_runtime_enable(&client->dev);
> 
> How is this going to interact with client devices which are already
> enabling runtime PM for themselves, and what are the advantages of doing
> this over having the client device enable runtime PM for itself (given
> that the client still needs an explicit put() adding)?

My understanding is that you can call pm_runtime_enable() several times
(provided that pm_runtime_disable() is called as many times). So that
should have no effect on the current drivers that already take advantage of
runtime PM.

There is one difference though -- runtime PM is now blocked by default and
it needs to be unblocked from the userspace per each device.

For the advantages compared to each driver handling it completely
themselves:

	- Few lines less as you only need to call _put().
	- It follows what is already been done for other buses, like PCI
	  and AMBA .
	- The I2C core makes sure that the device is available (from bus
	  point of view) when the driver ->probe() is called.

> Given that it's relatively common for devices to have both I2C and SPI
> control it seems like it'd be sensible to keep the policy common between
> the two buses to simplify driver implementation.

Yes and IMHO if I2C and SPI follows what has already been done for other
buses it should make the driver writer's job easier as the usage is similar
from one bus to another.

  reply	other threads:[~2013-09-10  7:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09 13:34 [PATCH RESEND 0/2] runtime PM support for I2C clients Mika Westerberg
2013-09-09 13:34 ` [PATCH RESEND 1/2] i2c: prepare runtime PM support for I2C client devices Mika Westerberg
2013-09-09 15:40   ` Mark Brown
2013-09-10  7:51     ` Mika Westerberg [this message]
     [not found]       ` <20130910075100.GK7393-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-09-10 11:38         ` Rafael J. Wysocki
2013-09-10 12:27       ` Mark Brown
     [not found]         ` <20130910122754.GK29403-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-09-10 14:26           ` Mika Westerberg
2013-09-10 16:13             ` Mark Brown
     [not found]               ` <20130910161321.GM29403-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-09-10 20:04                 ` Rafael J. Wysocki
     [not found]                   ` <3397524.g9aUWuArnm-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2013-09-10 21:35                     ` Mark Brown
     [not found]                       ` <20130910213522.GG29403-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-09-10 22:32                         ` Rafael J. Wysocki
2013-09-11  1:01                           ` Aaron Lu
2013-09-11  9:55                             ` Mark Brown
     [not found]                               ` <20130911095552.GI29403-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-09-11 11:05                                 ` Mika Westerberg
2013-09-11 11:14                                   ` Mark Brown
2013-09-11 11:24                                     ` Mika Westerberg
     [not found]                             ` <522FC0DC.9030708-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-09-12 21:07                               ` Kevin Hilman
     [not found]                                 ` <87eh8trbob.fsf-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-09-12 22:01                                   ` Mark Brown
2013-09-09 13:34 ` [PATCH RESEND 2/2] i2c: attach/detach I2C client device to the ACPI power domain Mika Westerberg

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=20130910075100.GK7393@intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=aaron.lu@intel.com \
    --cc=broonie@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=wsa@the-dreams.de \
    /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;
as well as URLs for NNTP newsgroup(s).