[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Sep 2013 16:40:28 +0100
From: Mark Brown <broonie@...nel.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: linux-i2c@...r.kernel.org, Wolfram Sang <wsa@...-dreams.de>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
Lv Zheng <lv.zheng@...el.com>, Aaron Lu <aaron.lu@...el.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RESEND 1/2] i2c: prepare runtime PM support for I2C
client devices
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)?
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.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists