diff mbox series

[09/15] gpio: support ROHM BD71815 GPOs

Message ID e7c5919cc0d95aca09807a828fe3c0018af8828b.1610110144.git.matti.vaittinen@fi.rohmeurope.com
State Superseded
Headers show
Series Support ROHM BD71815 PMIC | expand

Commit Message

Vaittinen, Matti Jan. 8, 2021, 1:39 p.m. UTC 
Support GPO(s) found from ROHM BD71815 power management IC. The IC has two
GPO pins but only one is properly documented in data-sheet. The driver
exposes by default only the documented GPO. The second GPO is connected to
E5 pin and is marked as GND in data-sheet. Control for this undocumented
pin can be enabled using a special DT property.

This driver is derived from work by Peter Yang <yanglsh@embest-tech.com>
although not so much of original is left.

Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
 drivers/gpio/Kconfig        |  10 +++
 drivers/gpio/Makefile       |   1 +
 drivers/gpio/gpio-bd71815.c | 160 ++++++++++++++++++++++++++++++++++++
 3 files changed, 171 insertions(+)
 create mode 100644 drivers/gpio/gpio-bd71815.c

Comments

Vaittinen, Matti Jan. 11, 2021, 6:15 a.m. UTC | #1 
Hi Linus,

Thanks a lot for review!

On Sat, 2021-01-09 at 01:45 +0100, Linus Walleij wrote:
> On Fri, Jan 8, 2021 at 2:39 PM Matti Vaittinen

> <matti.vaittinen@fi.rohmeurope.com> wrote:

> 

> > Support GPO(s) found from ROHM BD71815 power management IC. The IC

> > has two

> > GPO pins but only one is properly documented in data-sheet. The

> > driver

> > exposes by default only the documented GPO. The second GPO is

> > connected to

> > E5 pin and is marked as GND in data-sheet. Control for this

> > undocumented

> > pin can be enabled using a special DT property.

> > 

> > This driver is derived from work by Peter Yang <

> > yanglsh@embest-tech.com>

> > although not so much of original is left.

> > 

> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

> 

> Overall this looks good!

> 

> > +       depends on MFD_ROHM_BD71828

> 

> I suppose this makes i possible to merge out-of-order with the

> core patches actually.


Actually not. MFD_ROHM_BD71828 is existing config as this BD71815 uses
same MFD driver with BD71828. So MFD headers should be in before
merging the depending sub-device drivers.

> 

> > +#define DEBUG

> 

> Why? Development artifact?


Ouch. Thanks for spotting it :) I'll get rid of that.

> > +#include <linux/kthread.h>

> 

> You certainly do not need this.

> 

> > +#include <linux/mfd/rohm-bd71815.h>

> > +#include <linux/mfd/rohm-generic.h>

> 

> I guess registers come from these? Do you need both?

> Add a comment about what they provide.


Ok. Can do. (registers, I will recheck if I can get rid of including
the rohm-generic)

> 

> > +       g->chip.ngpio = 1;

> > +       if (g->e5_pin_is_gpo)

> > +               g->chip.ngpio = 2;

> 

> Overwriting value, how not elegant.

> 

> if (g->e5_pin_is_gpo)

>   g->chip.ngpio = 2;

> else

>   g->chip.ngpio = 1;


matter of taste I'd say :) As I would say about functions named like
_foo() ;) Not a poin I would fight over though - I can change this :]


> > +       g->chip.parent = pdev->dev.parent;

> > +       g->chip.of_node = pdev->dev.parent->of_node;

> > +       g->regmap = dev_get_regmap(pdev->dev.parent, NULL);

> > +       g->dev = &pdev->dev;

> > +

> > +       ret = devm_gpiochip_add_data(&pdev->dev, &g->chip, g);

> > +       if (ret < 0) {

> > +               dev_err(&pdev->dev, "could not register gpiochip,

> > %d\n", ret);

> > +               return ret;

> > +       }

> 

> It's a bit confusing how you use pdev->dev.parent for some stuff

> and &pdev->dev for some.

> 

> What about assinging

> 

> struct device *dev = pdev->dev.parent;

> 

> and use dev for all the calls, it looks like it'd work fine.


I wouldn't bind the lifetime of devm functions to the parent device. I
am not sure if it would work - what happens we bind lifetime of XX to
parent device - and next call at probe fails (for example with
DEFERRED?) I _assume_ the XX bound to parent is not released? (Please,
do correct me if I am wrong!)

Br,
    Matti Vaittinen
Vaittinen, Matti Jan. 11, 2021, 7:26 a.m. UTC | #2 
On Mon, 2021-01-11 at 08:15 +0200, Matti Vaittinen wrote:
> On Sat, 2021-01-09 at 01:45 +0100, Linus Walleij wrote:

> > On Fri, Jan 8, 2021 at 2:39 PM Matti Vaittinen

> > <matti.vaittinen@fi.rohmeurope.com> wrote:

> > 

> > > Support GPO(s) found from ROHM BD71815 power management IC. The

> > > IC

> > > has two

> > > GPO pins but only one is properly documented in data-sheet. The

> > > driver

> > > exposes by default only the documented GPO. The second GPO is

> > > connected to

> > > E5 pin and is marked as GND in data-sheet. Control for this

> > > undocumented

> > > pin can be enabled using a special DT property.

> > > 

> > > This driver is derived from work by Peter Yang <

> > > yanglsh@embest-tech.com>

> > > although not so much of original is left.

> > > 

> > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com

> > > >


// Snip

> > > +       g->chip.parent = pdev->dev.parent;

> > > +       g->chip.of_node = pdev->dev.parent->of_node;

> > > +       g->regmap = dev_get_regmap(pdev->dev.parent, NULL);

> > > +       g->dev = &pdev->dev;

> > > +

> > > +       ret = devm_gpiochip_add_data(&pdev->dev, &g->chip, g);

> > > +       if (ret < 0) {

> > > +               dev_err(&pdev->dev, "could not register gpiochip,

> > > %d\n", ret);

> > > +               return ret;

> > > +       }

> > 

> > It's a bit confusing how you use pdev->dev.parent for some stuff

> > and &pdev->dev for some.

> > 

> > What about assinging

> > 

> > struct device *dev = pdev->dev.parent;

> > 

> > and use dev for all the calls, it looks like it'd work fine.

> 

> I wouldn't bind the lifetime of devm functions to the parent device.

> I

> am not sure if it would work - what happens we bind lifetime of XX to

> parent device - and next call at probe fails (for example with

> DEFERRED?) I _assume_ the XX bound to parent is not released?

> (Please,

> do correct me if I am wrong!)


/*
 * Bind devm lifetime to this platform device => use dev for devm.
 * also the prints should originate from this device.
 */
dev = &pdev->dev;
/* The device-tree and regmap come from MFD => use parent for that */
parent = dev->parent;

Maybe adding dev and parent variables + comments would clear it up?


Br,
	Matti Vaittinen
diff mbox series

Patch

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 5d4de5cd6759..14a169c3232e 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1072,6 +1072,16 @@  config GPIO_BD70528
 	  This driver can also be built as a module. If so, the module
 	  will be called gpio-bd70528.
 
+config GPIO_BD71815
+	tristate "ROHM BD71815 PMIC GPIO support"
+	depends on MFD_ROHM_BD71828
+	help
+	  Support for GPO(s) on ROHM BD71815 PMIC. There are two GPOs
+	  available on the ROHM PMIC.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called gpio-bd71815.
+
 config GPIO_BD71828
 	tristate "ROHM BD71828 GPIO support"
 	depends on MFD_ROHM_BD71828
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 09dada80ac34..87ae0762eafa 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -39,6 +39,7 @@  obj-$(CONFIG_GPIO_ATH79)		+= gpio-ath79.o
 obj-$(CONFIG_GPIO_BCM_KONA)		+= gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BCM_XGS_IPROC)	+= gpio-xgs-iproc.o
 obj-$(CONFIG_GPIO_BD70528)		+= gpio-bd70528.o
+obj-$(CONFIG_GPIO_BD71815)		+= gpio-bd71815.o
 obj-$(CONFIG_GPIO_BD71828)		+= gpio-bd71828.o
 obj-$(CONFIG_GPIO_BD9571MWV)		+= gpio-bd9571mwv.o
 obj-$(CONFIG_GPIO_BRCMSTB)		+= gpio-brcmstb.o
diff --git a/drivers/gpio/gpio-bd71815.c b/drivers/gpio/gpio-bd71815.c
new file mode 100644
index 000000000000..5beac32fd07b
--- /dev/null
+++ b/drivers/gpio/gpio-bd71815.c
@@ -0,0 +1,160 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support to GPOs on ROHM BD71815
+ */
+#define DEBUG
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kthread.h>
+#include <linux/irq.h>
+#include <linux/gpio/driver.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/mfd/rohm-bd71815.h>
+#include <linux/mfd/rohm-generic.h>
+
+struct bd71815_gpio {
+	struct gpio_chip chip;
+	struct device *dev;
+	struct regmap *regmap;
+	/*
+	 * Sigh. The BD71815 and BD71817 were originally designed to support two
+	 * GPO pins. At some point it was noticed the second GPO pin which is
+	 * the E5 pin located at the center of IC is hard to use on PCB (due to
+	 * the location). It was decided to not promote this second GPO and pin
+	 * is marked as GND on the data-sheet. The functionality is still there
+	 * though! I guess driving GPO connected to ground is a bad idea. Thus
+	 * we do not support it by default. OTOH - the original driver written
+	 * by colleagues at Embest did support controlling this second GPO. It
+	 * is thus possible this is used in some of the products.
+	 *
+	 * This driver does not by default support configuring this second GPO
+	 * but allows using it by providing the DT property
+	 * "rohm,enable-hidden-gpo".
+	 */
+	bool e5_pin_is_gpo;
+};
+
+static int bd71815gpo_get(struct gpio_chip *chip, unsigned int offset)
+{
+	struct bd71815_gpio *bd71815 = gpiochip_get_data(chip);
+	int ret = 0;
+	int val;
+
+	ret = regmap_read(bd71815->regmap, BD71815_REG_GPO, &val);
+	if (ret)
+		return ret;
+
+	return (val >> offset) & 1;
+}
+
+static void bd71815gpo_set(struct gpio_chip *chip, unsigned int offset,
+			   int value)
+{
+	struct bd71815_gpio *bd71815 = gpiochip_get_data(chip);
+	int ret, val, mask;
+
+	if (!bd71815->e5_pin_is_gpo && offset)
+		return;
+
+	mask = BIT(offset);
+	val = value ? mask : 0;
+	ret = regmap_update_bits(bd71815->regmap, BD71815_REG_GPO, mask, val);
+	if (ret)
+		dev_warn(bd71815->dev, "failed to toggle GPO\n");
+}
+
+static int bd71815_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+				   unsigned long config)
+{
+	struct bd71815_gpio *bdgpio = gpiochip_get_data(chip);
+
+	if (!bdgpio->e5_pin_is_gpo && offset)
+		return -EOPNOTSUPP;
+
+	switch (pinconf_to_config_param(config)) {
+	case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+		return regmap_update_bits(bdgpio->regmap,
+					  BD71815_REG_GPO,
+					  BD71815_GPIO_DRIVE_MASK << offset,
+					  BD71815_GPIO_OPEN_DRAIN << offset);
+	case PIN_CONFIG_DRIVE_PUSH_PULL:
+		return regmap_update_bits(bdgpio->regmap,
+					  BD71815_REG_GPO,
+					  BD71815_GPIO_DRIVE_MASK << offset,
+					  BD71815_GPIO_CMOS << offset);
+	default:
+		break;
+	}
+	return -EOPNOTSUPP;
+}
+
+/* BD71815 GPIO is actually GPO */
+static int bd71815gpo_direction_get(struct gpio_chip *gc, unsigned int offset)
+{
+	return GPIO_LINE_DIRECTION_OUT;
+}
+
+/* Template for GPIO chip */
+static struct gpio_chip bd71815gpo_chip = {
+	.label			= "bd71815",
+	.owner			= THIS_MODULE,
+	.get			= bd71815gpo_get,
+	.get_direction		= bd71815gpo_direction_get,
+	.set			= bd71815gpo_set,
+	.set_config		= bd71815_gpio_set_config,
+	.can_sleep		= 1,
+};
+
+static int gpo_bd71815_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct bd71815_gpio *g;
+
+	g = devm_kzalloc(&pdev->dev, sizeof(*g), GFP_KERNEL);
+	if (!g)
+		return -ENOMEM;
+
+	g->e5_pin_is_gpo = of_property_read_bool(pdev->dev.parent->of_node,
+						 "rohm,enable-hidden-gpo");
+	g->chip = bd71815gpo_chip;
+	g->chip.base = -1;
+	g->chip.ngpio = 1;
+	if (g->e5_pin_is_gpo)
+		g->chip.ngpio = 2;
+	g->chip.parent = pdev->dev.parent;
+	g->chip.of_node = pdev->dev.parent->of_node;
+	g->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	g->dev = &pdev->dev;
+
+	ret = devm_gpiochip_add_data(&pdev->dev, &g->chip, g);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "could not register gpiochip, %d\n", ret);
+		return ret;
+	}
+
+	return ret;
+}
+static const struct platform_device_id bd7181x_gpo_id[] = {
+	{ "bd71815-gpo", ROHM_CHIP_TYPE_BD71815 },
+	{ },
+};
+MODULE_DEVICE_TABLE(platform, bd7181x_gpo_id);
+
+static struct platform_driver gpo_bd71815_driver = {
+	.driver = {
+		.name	= "bd71815-gpo",
+		.owner	= THIS_MODULE,
+	},
+	.probe		= gpo_bd71815_probe,
+	.id_table	= bd7181x_gpo_id,
+};
+
+module_platform_driver(gpo_bd71815_driver);
+
+/* Note:  this hardware lives inside an I2C-based multi-function device. */
+MODULE_ALIAS("platform:bd71815-gpo");
+
+MODULE_AUTHOR("Peter Yang <yanglsh@embest-tech.com>");
+MODULE_DESCRIPTION("GPO interface for BD71815");
+MODULE_LICENSE("GPL");