devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Figa <tfiga@chromium.org>
To: Bibby Hsieh <bibby.hsieh@mediatek.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	Nicolas Boichat <drinkcat@chromium.org>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v4] misc: eeprom: at24: support pm_runtime control
Date: Fri, 18 Oct 2019 18:24:55 +0900	[thread overview]
Message-ID: <CAAFQd5DuETr-N8efWYz7F-qrw1R-gL6fss2Ag1XezapojiakhQ@mail.gmail.com> (raw)
In-Reply-To: <20191018082557.3696-1-bibby.hsieh@mediatek.com>

Hi Bibby,

On Fri, Oct 18, 2019 at 5:26 PM Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>
> Although in the most platforms, the power of eeprom and i2c
> are alway on, some platforms disable the eeprom and i2c power
> in order to meet low power request.
> This patch add the pm_runtime ops to control power to support
> all platforms.
>
> Changes since v3:
>  - remove redundant calling function
>  - change SIMPLE_DEV_PM_OPS to SET_RUNTIME_PM_OPS
>  - change supply name
>
> Changes since v2:
>  - rebase onto v5.4-rc1
>  - pm_runtime_disable and regulator_bulk_disable at
>    err return in probe function
>
> Changes since v1:
>  - remove redundant code
>  - fixup coding style
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
>  drivers/misc/eeprom/at24.c | 64 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 2cccd82a3106..68ced4f25916 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -22,6 +22,7 @@
>  #include <linux/nvmem-provider.h>
>  #include <linux/regmap.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/regulator/consumer.h>
>  #include <linux/gpio/consumer.h>
>
>  /* Address pointer is 16 bit. */
> @@ -67,6 +68,12 @@
>   * which won't work on pure SMBus systems.
>   */
>
> +static const char * const at24_supply_names[] = {
> +       "vcc", "i2c",
> +};
> +
> +#define AT24_NUM_SUPPLIES ARRAY_SIZE(at24_supply_names)
> +
>  struct at24_client {
>         struct i2c_client *client;
>         struct regmap *regmap;
> @@ -91,6 +98,8 @@ struct at24_data {
>
>         struct gpio_desc *wp_gpio;
>
> +       bool has_supplies;
> +       struct regulator_bulk_data supplies[AT24_NUM_SUPPLIES];
>         /*
>          * Some chips tie up multiple I2C addresses; dummy devices reserve
>          * them for us, and we'll use them with SMBus calls.
> @@ -662,6 +671,17 @@ static int at24_probe(struct i2c_client *client)
>         at24->client[0].client = client;
>         at24->client[0].regmap = regmap;
>
> +       regulator_bulk_set_supply_names(at24->supplies,
> +                                       at24_supply_names, AT24_NUM_SUPPLIES);
> +       err =  devm_regulator_bulk_get(&at24->client[0].client->dev,
> +                                      AT24_NUM_SUPPLIES, at24->supplies);
> +       if (err == -ENODEV)
> +               at24->has_supplies = NULL;

has_supplies is a bool, so the right value would be false.

> +       else if (err == 0)

nit: One would typically use !err here as the condition.

> +               at24->has_supplies = !err;

In this branch, err is always 0, so !err is always true and we can
just directly assign true to the field.

> +       else
> +               return err;
> +
>         at24->wp_gpio = devm_gpiod_get_optional(dev, "wp", GPIOD_OUT_HIGH);
>         if (IS_ERR(at24->wp_gpio))
>                 return PTR_ERR(at24->wp_gpio);
> @@ -701,6 +721,14 @@ static int at24_probe(struct i2c_client *client)
>
>         i2c_set_clientdata(client, at24);
>
> +       if (at24->has_supplies) {
> +               err = regulator_bulk_enable(AT24_NUM_SUPPLIES, at24->supplies);
> +               if (err) {
> +                       dev_err(dev, "Failed to enable power regulators\n");
> +                       return err;
> +               }
> +       }
> +
>         /* enable runtime pm */
>         pm_runtime_set_active(dev);
>         pm_runtime_enable(dev);
> @@ -713,6 +741,9 @@ static int at24_probe(struct i2c_client *client)
>         pm_runtime_idle(dev);
>         if (err) {
>                 pm_runtime_disable(dev);
> +               if (at24->has_supplies)
> +                       regulator_bulk_disable(AT24_NUM_SUPPLIES,
> +                                              at24->supplies);
>                 return -ENODEV;
>         }
>
> @@ -725,15 +756,48 @@ static int at24_probe(struct i2c_client *client)
>
>  static int at24_remove(struct i2c_client *client)
>  {
> +       struct at24_data *at24 = i2c_get_clientdata(client);
> +
>         pm_runtime_disable(&client->dev);
>         pm_runtime_set_suspended(&client->dev);
> +       if (at24->has_supplies)
> +               regulator_bulk_disable(AT24_NUM_SUPPLIES, at24->supplies);

It's a weird behavior, but pm_runtime_disable() doesn't guarantee that
the device is actually resumed after the call returns. See [1].
We should move the regulator disable before we call
pm_runtime_set_suspended() and add !pm_runtime_status_suspended() as
an additional condition to the if.

By the way, that behavior is actually contradicting other parts of the
runtime PM core. For example pm_runtime_active() returns true if
dev->power.disable_depth is non-zero, but as per the above, the device
could as well be suspended. Rafael, is this expected?

[1] https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/base/power/runtime.c#L1316

> +
> +       return 0;
> +}
> +
> +static int __maybe_unused at24_suspend(struct device *dev)
> +{
> +       struct i2c_client *client = to_i2c_client(dev);
> +       struct at24_data *at24 = i2c_get_clientdata(client);
> +
> +       if (at24->has_supplies)
> +               return regulator_bulk_disable(AT24_NUM_SUPPLIES,
> +                                             at24->supplies);
> +
> +       return 0;
> +}
> +
> +static int __maybe_unused at24_resume(struct device *dev)
> +{
> +       struct i2c_client *client = to_i2c_client(dev);
> +       struct at24_data *at24 = i2c_get_clientdata(client);
> +
> +       if (at24->has_supplies)
> +               return regulator_bulk_enable(AT24_NUM_SUPPLIES,
> +                                            at24->supplies);
>
>         return 0;
>  }
>
> +static const struct dev_pm_ops at24_pm_ops = {
> +       SET_RUNTIME_PM_OPS(at24_suspend, at24_resume, NULL)

Do we also need pm_runtime_force_suspend() and
pm_runtime_force_resume() as system sleep PM ops or it isn't possible
for the device to be runtime active when entering the system suspend?

Best regards,
Tomasz

  parent reply	other threads:[~2019-10-18  9:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18  8:25 [PATCH v4] misc: eeprom: at24: support pm_runtime control Bibby Hsieh
2019-10-18  8:25 ` [PATCH v2] dt-binding: eeprom: at24: add supply properties Bibby Hsieh
2019-10-18 10:07   ` Bartosz Golaszewski
2019-10-24  6:22   ` Bartosz Golaszewski
2019-10-24  7:01     ` Tomasz Figa
2019-10-24  8:40       ` Bartosz Golaszewski
2019-10-24  9:32         ` Tomasz Figa
2019-10-25 21:10           ` Rob Herring
2019-10-26 12:05             ` Bartosz Golaszewski
2019-10-28  2:36               ` Bibby Hsieh
2019-11-07 14:32                 ` Tomasz Figa
2019-10-24  6:48   ` Peter Rosin
2019-10-18  9:24 ` Tomasz Figa [this message]
2019-10-18 10:11   ` [PATCH v4] misc: eeprom: at24: support pm_runtime control Bartosz Golaszewski
2019-10-22  2:25   ` Bibby Hsieh
2019-10-21 16:53 ` Bartosz Golaszewski
2019-10-22  2:23   ` Bibby Hsieh
2019-10-22  7:26   ` Tomasz Figa
2019-10-22  9:00     ` Bartosz Golaszewski
2019-10-22 10:33       ` Tomasz Figa
2019-10-22 11:19         ` Mark Brown
2019-10-22 12:13           ` Bartosz Golaszewski
2019-10-22 15:03             ` Mark Brown
2019-10-22 15:42               ` Bartosz Golaszewski
2019-10-22 16:33                 ` Mark Brown

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=CAAFQd5DuETr-N8efWYz7F-qrw1R-gL6fss2Ag1XezapojiakhQ@mail.gmail.com \
    --to=tfiga@chromium.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=bibby.hsieh@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    /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).