2021-03-08 08:42:15

by Hsin-Yi Wang

[permalink] [raw]
Subject: [PATCH v16 0/2] add power control in i2c

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 v15:
- Squash the fix[1] for v15.
[1] https://patchwork.ozlabs.org/project/linux-i2c/patch/[email protected]/

Changes since v14:
- change the return value in normal condition
- access the variable after NULL pointer checking
- add ack tag

Changes since v13:
- fixup some logic error

Changes since v12:
- rebase onto v5.7-rc1
- change the property description in binding

Changes since v11:
- use suspend_late/resume_early instead of suspend/resume
- rebase onto v5.6-rc1

Changes since v10:
- fixup some worng codes

Changes since v9:
- fixup build error
- remove redundant code

Changes since v8:
- fixup some wrong code
- remove redundant message

[... snip ...]

Bibby Hsieh (2):
dt-binding: i2c: add bus-supply property
i2c: core: support bus regulator controlling in adapter

Documentation/devicetree/bindings/i2c/i2c.txt | 3 +
drivers/i2c/i2c-core-base.c | 93 +++++++++++++++++++
include/linux/i2c.h | 2 +
3 files changed, 98 insertions(+)

--
2.30.1.766.gb4fecdf3b7-goog


2021-03-08 08:43:35

by Hsin-Yi Wang

[permalink] [raw]
Subject: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter

From: Bibby Hsieh <[email protected]>

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 <[email protected]>
Signed-off-by: Marek Szyprowski <[email protected]>
Signed-off-by: Hsin-Yi Wang <[email protected]>
---
drivers/i2c/i2c-core-base.c | 93 +++++++++++++++++++++++++++++++++++++
include/linux/i2c.h | 2 +
2 files changed, 95 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 63ebf722a424..667f4a4de7cc 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -439,12 +439,14 @@ 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;
struct i2c_driver *driver;
int status;

if (!client)
return 0;

+ adap = client->adapter;
client->irq = client->init_irq;

if (!client->irq) {
@@ -510,6 +512,12 @@ static int i2c_device_probe(struct device *dev)

dev_dbg(dev, "probe\n");

+ status = regulator_enable(adap->bus_regulator);
+ 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;
@@ -550,8 +558,10 @@ static int i2c_device_probe(struct device *dev)
static int i2c_device_remove(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_adapter *adap;
struct i2c_driver *driver;

+ adap = client->adapter;
driver = to_i2c_driver(dev->driver);
if (driver->remove) {
int status;
@@ -564,6 +574,8 @@ static int i2c_device_remove(struct device *dev)
}

dev_pm_domain_detach(&client->dev, true);
+ if (!pm_runtime_status_suspended(&client->dev))
+ regulator_disable(adap->bus_regulator);

dev_pm_clear_wake_irq(&client->dev);
device_init_wakeup(&client->dev, false);
@@ -576,6 +588,80 @@ static int i2c_device_remove(struct device *dev)
return 0;
}

+#ifdef CONFIG_PM_SLEEP
+static int i2c_resume_early(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ int err;
+
+ if (!client)
+ return 0;
+
+ if (!pm_runtime_status_suspended(&client->dev)) {
+ err = regulator_enable(client->adapter->bus_regulator);
+ if (err)
+ return err;
+ }
+
+ return pm_generic_resume_early(&client->dev);
+}
+
+static int i2c_suspend_late(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ int err;
+
+ if (!client)
+ return 0;
+
+ err = pm_generic_suspend_late(&client->dev);
+ if (err)
+ return err;
+
+ if (!pm_runtime_status_suspended(&client->dev))
+ return regulator_disable(client->adapter->bus_regulator);
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_PM
+static int i2c_runtime_resume(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ int err;
+
+ if (!client)
+ return 0;
+
+ err = regulator_enable(client->adapter->bus_regulator);
+ if (err)
+ return err;
+
+ return pm_generic_runtime_resume(&client->dev);
+}
+
+static int i2c_runtime_suspend(struct device *dev)
+{
+ struct i2c_client *client = i2c_verify_client(dev);
+ int err;
+
+ if (!client)
+ return 0;
+
+ err = pm_generic_runtime_suspend(&client->dev);
+ if (err)
+ return err;
+
+ return regulator_disable(client->adapter->bus_regulator);
+}
+#endif
+
+static const struct dev_pm_ops i2c_device_pm = {
+ SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late, i2c_resume_early)
+ 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);
@@ -633,6 +719,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);

@@ -1446,6 +1533,12 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
if (res)
goto out_reg;

+ adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
+ if (IS_ERR(adap->bus_regulator)) {
+ res = PTR_ERR(adap->bus_regulator);
+ goto out_reg;
+ }
+
pm_runtime_no_callbacks(&adap->dev);
pm_suspend_ignore_children(&adap->dev, true);
pm_runtime_enable(&adap->dev);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 56622658b215..ec87758d9f40 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 */
@@ -721,6 +722,7 @@ struct i2c_adapter {
const struct i2c_adapter_quirks *quirks;

struct irq_domain *host_notify_domain;
+ struct regulator *bus_regulator;
};
#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)

--
2.30.1.766.gb4fecdf3b7-goog

2021-03-08 17:19:40

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter

On Mon, Mar 08, 2021 at 12:36:07PM +0800, Hsin-Yi Wang wrote:

> + adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
> + if (IS_ERR(adap->bus_regulator)) {
> + res = PTR_ERR(adap->bus_regulator);
> + goto out_reg;
> + }

Idiomatically supplies should be named as they are by the chip datasheet
rather than just a generic name like this, and I'm guessing that systems
that have supplies like this will often already have something
requesting the supply (eg, it's quite common for consumer drivers to do
this) under that name. I can see this being a useful thing to factor
out into the core but it seems like it'd be better to have it enabled by
having the controllers (or devices) pass a supply name (or possibly
requested regulator) to the core rather than by just hard coding a name
in the core so bindings look as expected.

I do also wonder if it's better to put the feature on the clients rather
than the controller, I don't think it makes much difference though.


Attachments:
(No filename) (0.98 kB)
signature.asc (499.00 B)
Download all attachments

2021-03-09 13:36:56

by Hsin-Yi Wang

[permalink] [raw]
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter

On Tue, Mar 9, 2021 at 1:17 AM Mark Brown <[email protected]> wrote:
>
> On Mon, Mar 08, 2021 at 12:36:07PM +0800, Hsin-Yi Wang wrote:
>
> > + adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
> > + if (IS_ERR(adap->bus_regulator)) {
> > + res = PTR_ERR(adap->bus_regulator);
> > + goto out_reg;
> > + }
>
> Idiomatically supplies should be named as they are by the chip datasheet
> rather than just a generic name like this, and I'm guessing that systems
> that have supplies like this will often already have something
> requesting the supply (eg, it's quite common for consumer drivers to do
> this) under that name. I can see this being a useful thing to factor
> out into the core but it seems like it'd be better to have it enabled by
> having the controllers (or devices) pass a supply name (or possibly
> requested regulator) to the core rather than by just hard coding a name
> in the core so bindings look as expected.
>

I'll move the regulator request into device instead of core in the
next version. Thanks.

> I do also wonder if it's better to put the feature on the clients rather
> than the controller, I don't think it makes much difference though.

2021-04-07 22:32:27

by Hsin-Yi Wang

[permalink] [raw]
Subject: Re: [PATCH v16 2/2] i2c: core: support bus regulator controlling in adapter

On Tue, Mar 9, 2021 at 9:34 PM Hsin-Yi Wang <[email protected]> wrote:
>
> On Tue, Mar 9, 2021 at 1:17 AM Mark Brown <[email protected]> wrote:
> >
> > On Mon, Mar 08, 2021 at 12:36:07PM +0800, Hsin-Yi Wang wrote:
> >
> > > + adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
> > > + if (IS_ERR(adap->bus_regulator)) {
> > > + res = PTR_ERR(adap->bus_regulator);
> > > + goto out_reg;
> > > + }
> >
> > Idiomatically supplies should be named as they are by the chip datasheet
> > rather than just a generic name like this, and I'm guessing that systems
> > that have supplies like this will often already have something
> > requesting the supply (eg, it's quite common for consumer drivers to do
> > this) under that name. I can see this being a useful thing to factor
> > out into the core but it seems like it'd be better to have it enabled by
> > having the controllers (or devices) pass a supply name (or possibly
> > requested regulator) to the core rather than by just hard coding a name
> > in the core so bindings look as expected.
> >
>
> I'll move the regulator request into device instead of core in the
> next version. Thanks.
>
Hi Mark,

v17 is sent here:
https://patchwork.kernel.org/project/linux-mediatek/cover/[email protected]/

Thanks.

> > I do also wonder if it's better to put the feature on the clients rather
> > than the controller, I don't think it makes much difference though.