Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751795AbdITIp3 (ORCPT ); Wed, 20 Sep 2017 04:45:29 -0400 Received: from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:44444 "EHLO hillosipuli.retiisi.org.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751655AbdITIpX (ORCPT ); Wed, 20 Sep 2017 04:45:23 -0400 Date: Wed, 20 Sep 2017 11:45:20 +0300 From: "sakari.ailus@iki.fi" To: Tomasz Figa Cc: "Mani, Rajmohan" , "Mohandass, Divagar" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "wsa@the-dreams.de" , "devicetree@vger.kernel.org" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" , mika.westerberg@linux.intel.com Subject: Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support Message-ID: <20170920084519.asyfjxo6upt36woz@valkosipuli.retiisi.org.uk> References: <1504520928-5191-1-git-send-email-divagar.mohandass@intel.com> <1504520928-5191-4-git-send-email-divagar.mohandass@intel.com> <6F87890CF0F5204F892DEA1EF0D77A5972FC1278@FMSMSX114.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5741 Lines: 163 Hi Tomasz, On Wed, Sep 20, 2017 at 12:56:09PM +0900, Tomasz Figa wrote: > Thanks Raj. > > Let me post my comments inline. > > On Wed, Sep 20, 2017 at 12:52 PM, Mani, Rajmohan > wrote: > > Adding Tomasz... > > > >> -----Original Message----- > >> From: Mohandass, Divagar > >> Sent: Monday, September 04, 2017 3:29 AM > >> To: robh+dt@kernel.org; mark.rutland@arm.com; wsa@the-dreams.de; > >> sakari.ailus@iki.fi > >> Cc: devicetree@vger.kernel.org; linux-i2c@vger.kernel.org; linux- > >> kernel@vger.kernel.org; Mani, Rajmohan ; > >> Mohandass, Divagar > >> Subject: [PATCH v6 3/3] eeprom: at24: enable runtime pm support > >> > >> Currently the device is kept in D0, there is an opportunity to save power by > >> enabling runtime pm. > >> > >> Device can be daisy chained from PMIC and we can't rely on I2C core for auto > >> resume/suspend. Driver will decide when to resume/suspend. > >> > >> Signed-off-by: Divagar Mohandass > >> --- > >> drivers/misc/eeprom/at24.c | 38 > >> ++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 38 insertions(+) > >> > >> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index > >> 2199c42..d718a7a 100644 > >> --- a/drivers/misc/eeprom/at24.c > >> +++ b/drivers/misc/eeprom/at24.c > >> @@ -24,6 +24,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> /* > >> * I2C EEPROMs from most vendors are inexpensive and mostly > >> interchangeable. > >> @@ -501,11 +502,21 @@ static ssize_t at24_eeprom_write_i2c(struct > >> at24_data *at24, const char *buf, static int at24_read(void *priv, unsigned int > >> off, void *val, size_t count) { > >> struct at24_data *at24 = priv; > >> + struct i2c_client *client; > >> char *buf = val; > >> + int ret; > >> > >> if (unlikely(!count)) > >> return count; > >> > >> + client = at24_translate_offset(at24, &off); > >> + > >> + ret = pm_runtime_get_sync(&client->dev); > >> + if (ret < 0) { > >> + pm_runtime_put_noidle(&client->dev); > >> + return ret; > >> + } > >> + > >> /* > >> * Read data from chip, protecting against concurrent updates > >> * from this host, but not from other I2C masters. > >> @@ -518,6 +529,7 @@ static int at24_read(void *priv, unsigned int off, void > >> *val, size_t count) > >> status = at24->read_func(at24, buf, off, count); > >> if (status < 0) { > >> mutex_unlock(&at24->lock); > >> + pm_runtime_put(&client->dev); > >> return status; > >> } > >> buf += status; > >> @@ -527,17 +539,29 @@ static int at24_read(void *priv, unsigned int off, void > >> *val, size_t count) > >> > >> mutex_unlock(&at24->lock); > >> > >> + pm_runtime_put(&client->dev); > >> + > >> return 0; > >> } > >> > >> static int at24_write(void *priv, unsigned int off, void *val, size_t count) { > >> struct at24_data *at24 = priv; > >> + struct i2c_client *client; > >> char *buf = val; > >> + int ret; > >> > >> if (unlikely(!count)) > >> return -EINVAL; > >> > >> + client = at24_translate_offset(at24, &off); > >> + > >> + ret = pm_runtime_get_sync(&client->dev); > >> + if (ret < 0) { > >> + pm_runtime_put_noidle(&client->dev); > >> + return ret; > >> + } > >> + > >> /* > >> * Write data to chip, protecting against concurrent updates > >> * from this host, but not from other I2C masters. > >> @@ -550,6 +574,7 @@ static int at24_write(void *priv, unsigned int off, void > >> *val, size_t count) > >> status = at24->write_func(at24, buf, off, count); > >> if (status < 0) { > >> mutex_unlock(&at24->lock); > >> + pm_runtime_put(&client->dev); > >> return status; > >> } > >> buf += status; > >> @@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned int off, void > >> *val, size_t count) > >> > >> mutex_unlock(&at24->lock); > >> > >> + pm_runtime_put(&client->dev); > >> + > >> return 0; > >> } > >> > >> @@ -743,11 +770,17 @@ static int at24_probe(struct i2c_client *client, const > >> struct i2c_device_id *id) > >> > >> i2c_set_clientdata(client, at24); > >> > >> + /* enable runtime pm */ > >> + pm_runtime_get_noresume(&client->dev); > >> + pm_runtime_set_active(&client->dev); > >> + pm_runtime_enable(&client->dev); > > Do we need this get_noresume/set_active dance? I remember it was for > some reason needed for PCI devices, but I don't see why for I2C > anything else than just pm_runtime_enable() would be necessary. You specifically do not need (all) this for PCI devices, but AFAIU for I?C devices you do. The runtime PM status of a device is disabled by default and the use count is zero, but on ACPI based systems the device is still powered on. > > Also, we enable runtime PM, but we don't provide any callbacks. If > there is no callback in any level of the hierarchy, NULL would be > returned in [3], making [2] return -ENOSYS and [1] fail. The behavior > depends on subsystem and whether the device is attached to a > pm_domain. In our particular case I'd guess the device would be in an > ACPI pm_domain and that would work, but the driver is generic and must > work in any cases. Agreed. Cc Mika, too. -- Regards, Sakari Ailus e-mail: sakari.ailus@iki.fi