From: Tomasz Figa <tfiga@chromium.org>
To: Bibby Hsieh <bibby.hsieh@mediatek.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
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>,
linux-devicetree <devicetree@vger.kernel.org>
Subject: Re: [PATCH v9 4/4] i2c: core: support bus regulator controlling in adapter
Date: Mon, 16 Dec 2019 20:58:49 +0900 [thread overview]
Message-ID: <CAAFQd5CU79CnRkpo8bpijMCvtzKAkQXj6nadt3YyQSCcq5roXQ@mail.gmail.com> (raw)
In-Reply-To: <20191216080445.8747-5-bibby.hsieh@mediatek.com>
Hi Bibby,
On Mon, Dec 16, 2019 at 5:04 PM Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>
> Although in the most platforms, the bus power of i2c
> are alway on, some platforms disable the i2c bus power
> in order to meet low power request.
>
> We get and enable bulk regulator in i2c adapter device.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/i2c/i2c-core-base.c | 65 +++++++++++++++++++++++++++++++++++++
> include/linux/i2c.h | 3 ++
> 2 files changed, 68 insertions(+)
>
Thanks for the patch! Please see my comments below.
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 9333c865d4a9..e95ebd0af200 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -306,6 +306,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
> static int i2c_device_probe(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
> struct i2c_driver *driver;
> int status;
>
> @@ -371,6 +372,12 @@ static int i2c_device_probe(struct device *dev)
>
> dev_dbg(dev, "probe\n");
>
> + status = regulator_enable(adap->bus_reg);
> + if (status != 0) {
> + dev_err(&adap->dev, "Failed to enable power regulator\n");
> + goto err_clear_wakeup_irq;
> + }
> +
> status = of_clk_set_defaults(dev->of_node, false);
> if (status < 0)
> goto err_clear_wakeup_irq;
> @@ -407,6 +414,7 @@ static int i2c_device_probe(struct device *dev)
> static int i2c_device_remove(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
> struct i2c_driver *driver;
> int status = 0;
>
> @@ -420,6 +428,8 @@ static int i2c_device_remove(struct device *dev)
> }
>
> dev_pm_domain_detach(&client->dev, true);
> + if (!pm_runtime_status_suspended(&adap->dev))
> + regulator_disable(adap->bus_reg);
>
> dev_pm_clear_wake_irq(&client->dev);
> device_init_wakeup(&client->dev, false);
> @@ -431,6 +441,54 @@ static int i2c_device_remove(struct device *dev)
> return status;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int i2c_resume(struct device *dev)
> +{
> + struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
We need to ensure here that if the slave device was not runtime
suspended before the system suspend, the regulator is enabled before
the slave's resume callback is called.
> +
> + return pm_generic_resume(&adap->dev);
> +}
> +
> +static int i2c_suspend(struct device *dev)
> +{
> + struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
> +
> + return pm_generic_suspend(&adap->dev);
We need to ensure that the regulator is disabled when the system suspends.
> +}
> +#endif
> +
> +#ifdef CONFIG_PM
> +static int i2c_runtime_resume(struct device *dev)
> +{
> + struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
> +
> + pm_generic_runtime_resume(&adap->dev);
Why adap->dev? This callback is expected to execute a PM operation on
the I2C slave device.
Also, don't we need some error handling here?
> +
> + return regulator_enable(adap->bus_reg);
> +}
> +
> +static int i2c_runtime_suspend(struct device *dev)
> +{
> + struct i2c_client *client = i2c_verify_client(dev);
> + struct i2c_adapter *adap = client->adapter;
> +
> + pm_generic_runtime_suspend(&adap->dev);
Ditto.
> +
> + if (!pm_runtime_status_suspended(&adap->dev))
Since we just executed a suspend operation on the device, how is it
possible that it isn't suspended?
> + return regulator_disable(client->adapter->bus_reg);
> +
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops i2c_device_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(i2c_suspend, i2c_resume)
> + SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume, NULL)
> +};
> +
> static void i2c_device_shutdown(struct device *dev)
> {
> struct i2c_client *client = i2c_verify_client(dev);
> @@ -488,6 +546,7 @@ struct bus_type i2c_bus_type = {
> .probe = i2c_device_probe,
> .remove = i2c_device_remove,
> .shutdown = i2c_device_shutdown,
> + .pm = &i2c_device_pm,
> };
> EXPORT_SYMBOL_GPL(i2c_bus_type);
>
> @@ -1351,6 +1410,11 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
> goto out_reg;
>
> dev_dbg(&adap->dev, "adapter [%s] registered\n", adap->name);
> + adap->bus_reg = devm_regulator_get(&adap->dev, "bus");
> + if (IS_ERR(adap->bus_reg)) {
> + res = PTR_ERR(adap->bus_reg);
> + goto out_reg;
> + }
>
> pm_runtime_no_callbacks(&adap->dev);
> pm_suspend_ignore_children(&adap->dev, true);
> @@ -1580,6 +1644,7 @@ void i2c_del_adapter(struct i2c_adapter *adap)
> dev_dbg(&adap->dev, "adapter [%s] unregistered\n", adap->name);
>
> pm_runtime_disable(&adap->dev);
> + devm_regulator_put(adap->bus_reg);
>
> i2c_host_notify_irq_teardown(adap);
>
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index d2f786706657..833b81a680da 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -15,6 +15,7 @@
> #include <linux/device.h> /* for struct device */
> #include <linux/sched.h> /* for completion */
> #include <linux/mutex.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/rtmutex.h>
> #include <linux/irqdomain.h> /* for Host Notify IRQ */
> #include <linux/of.h> /* for struct device_node */
> @@ -330,6 +331,7 @@ struct i2c_client {
> int init_irq; /* irq set at initialization */
> int irq; /* irq issued by device */
> struct list_head detected;
> +
Unnecessary change.
Best regards,
Tomasz
prev parent reply other threads:[~2019-12-16 11:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 8:04 [PATCH v9 0/4] add power control in i2c and at24 Bibby Hsieh
2019-12-16 8:04 ` [PATCH v9 1/4] dt-binding: eeprom: at24: add vcc-supply property Bibby Hsieh
2019-12-16 8:04 ` [PATCH v9 2/4] dt-binding: i2c: add bus-supply property Bibby Hsieh
2019-12-18 14:47 ` Rob Herring
2019-12-16 8:04 ` [PATCH v9 3/4] misc: eeprom: at24: support pm_runtime control Bibby Hsieh
2019-12-19 10:50 ` Bartosz Golaszewski
2020-01-06 7:09 ` Bibby Hsieh
2019-12-16 8:04 ` [PATCH v9 4/4] i2c: core: support bus regulator controlling in adapter Bibby Hsieh
2019-12-16 11:58 ` Tomasz Figa [this message]
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=CAAFQd5CU79CnRkpo8bpijMCvtzKAkQXj6nadt3YyQSCcq5roXQ@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=robh+dt@kernel.org \
--cc=srv_heupstream@mediatek.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).