mbox series

[v7,0/6] Support ROHM BD9576MUF and BD9573MUF PMICs

Message ID cover.1611324968.git.matti.vaittinen@fi.rohmeurope.com
Headers show
Series Support ROHM BD9576MUF and BD9573MUF PMICs | expand

Message

Matti Vaittinen Jan. 22, 2021, 2:30 p.m. UTC
Initial support for ROHM BD9576MUF and BD9573MUF PMICs.

These PMICs are primarily intended to be used to power the R-Car family
processors. BD9576MUF includes some additional safety features the
BD9573MUF does not have. This initial version of drivers provides
temperature, over voltage and under voltage warnings is IRQ information
is passed via DT.

This patch series includes MFD and watchdog drivers. Regulator part was
already applied but this series brings the over-/undervoltage and
temperature error notifications which consumer drivers can utilize.

WDG supports
- Enabling and pinging the watchdog
- configuring watchog timeout / window from device-tree

BD9576MUF and BD9573MUF are designed to keep the IRQ line low for whole
duration of error condition. Yet the IRQ must be acked before line is
pulled low. This means that handling the IRQ as edge triggered IRQ
will introduce the classic race of new IRQ occurring while one is
handled. (New status bit being set just after status was read but before
it was acked. That will cause the new IRQ to not be acked which leaves the
IRQ line low. With edge triggered IRQs this means that no more edges will
be seen.) In order to prevent the processor from staying in IRQ handling
loop we only handle the main status register with regmap IRQ
irq-controller (main status bits can be masked) but leave the sub-status
bits (some of which can't be masked) to be handled by the IRQ handlers.
When regulator driver handler is run, it will 'increase the depth' of IRQ
disabling (causing main status bit to stay masked when handler exits)
and arms a 1sec delayed_work to do unmasking. I am open to suggestions as
how to handle this more elegantly. Please note that the BD9573 does not
offer 'warning' interrupts and will only generate IRQ when it is
entering into emergency state and shutting down the power from the SOC.

This far the IRQ logic has only received a limited amount of testing. I
managed to get the OVD/UVD condition by probing break-out board
manually. This however usually did  lead the PMIC to go to emergency
state so there may be corner cases not covered by my tests. Basic IRQ
limiting seems to be working though.

Please note that not all of the boards are expected to be utilizing the
warning IRQs. Thus populating the IRQ information from DT is optional.

Changelog v7:
  - Added interrupt handling
  - Added notifications and error_flag getter to regulators

Changelog v6:
  - Fixed watchdog timeout

Changelog v5:
  - rebased on top of v5.10-rc2
  - few styling fixes in MFD as suggested by Lee

Changelog v4:
  - rebased on top of 5.10-rc1
  - Fix typo (repeated word maximum) from the DT binding doc

Changelog v3:
  - use only one binding to specify watchdog time-out window.

Changelog v2:
  - dropped already applied regulator part
  - dt_bindings: Fix case for regulator-names in the example
  - watchdod: unify probe error check and revise includes

---


Matti Vaittinen (6):
  dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs
  mfd: Support ROHM BD9576MUF and BD9573MUF
  mfd: bd9576: Add IRQ support
  wdt: Support wdt on ROHM BD9576MUF and BD9573MUF
  MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers
  regulator: bd9576: Support error reporting

 .../bindings/mfd/rohm,bd9576-pmic.yaml        | 123 ++++
 MAINTAINERS                                   |   4 +
 drivers/mfd/Kconfig                           |  11 +
 drivers/mfd/Makefile                          |   1 +
 drivers/mfd/rohm-bd9576.c                     | 186 ++++++
 drivers/regulator/bd9576-regulator.c          | 534 ++++++++++++++----
 drivers/watchdog/Kconfig                      |  13 +
 drivers/watchdog/Makefile                     |   1 +
 drivers/watchdog/bd9576_wdt.c                 | 291 ++++++++++
 include/linux/mfd/rohm-bd957x.h               | 121 ++++
 include/linux/mfd/rohm-generic.h              |   2 +
 11 files changed, 1165 insertions(+), 122 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml
 create mode 100644 drivers/mfd/rohm-bd9576.c
 create mode 100644 drivers/watchdog/bd9576_wdt.c
 create mode 100644 include/linux/mfd/rohm-bd957x.h


base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837

Comments

Guenter Roeck Jan. 23, 2021, 6:38 p.m. UTC | #1
On Fri, Jan 22, 2021 at 04:35:10PM +0200, Matti Vaittinen wrote:
> Add maintainer entries for ROHM BD9576MUF and ROHM BD9573MUF drivers.
> MFD, regulator and watchdog drivers were introduced for these PMICs.
> 
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

> ---
> Changes since v6:
>  - no changes
>  MAINTAINERS | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc1e6a5ee6e6..b59b7877258c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15336,16 +15336,20 @@ F:	drivers/gpio/gpio-bd71828.c
>  F:	drivers/mfd/rohm-bd70528.c
>  F:	drivers/mfd/rohm-bd71828.c
>  F:	drivers/mfd/rohm-bd718x7.c
> +F:	drivers/mfd/rohm-bd9576.c
>  F:	drivers/power/supply/bd70528-charger.c
>  F:	drivers/regulator/bd70528-regulator.c
>  F:	drivers/regulator/bd71828-regulator.c
>  F:	drivers/regulator/bd718x7-regulator.c
> +F:	drivers/regulator/bd9576-regulator.c
>  F:	drivers/regulator/rohm-regulator.c
>  F:	drivers/rtc/rtc-bd70528.c
>  F:	drivers/watchdog/bd70528_wdt.c
> +F:	drivers/watchdog/bd9576_wdt.c
>  F:	include/linux/mfd/rohm-bd70528.h
>  F:	include/linux/mfd/rohm-bd71828.h
>  F:	include/linux/mfd/rohm-bd718x7.h
> +F:	include/linux/mfd/rohm-bd957x.h
>  F:	include/linux/mfd/rohm-generic.h
>  F:	include/linux/mfd/rohm-shared.h
>
Matti Vaittinen Feb. 9, 2021, 2:19 p.m. UTC | #2
Hello Lee, Mark All,

On Fri, 2021-01-22 at 16:30 +0200, Matti Vaittinen wrote:
> Initial support for ROHM BD9576MUF and BD9573MUF PMICs.
> 
> These PMICs are primarily intended to be used to power the R-Car
> family
> processors. BD9576MUF includes some additional safety features the
> BD9573MUF does not have. This initial version of drivers provides
> temperature, over voltage and under voltage warnings is IRQ
> information
> is passed via DT.
> 
> This patch series includes MFD and watchdog drivers. Regulator part
> was
> already applied but this series brings the over-/undervoltage and
> temperature error notifications which consumer drivers can utilize.

I had some discussion with Mark and Angelo about creating a helper for
handling this kind of regulator notification IRQs.
(For anyone interested: the discussion can be seen here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.camel@fi.rohmeurope.com/
)

I've now drafted RFCv1 for that support (not sent it yet). The RFC
converts the BD9576 regulator driver to use the new helper and adds
some new definitions to MFD headers.

What would be the most convenient way of handling this? Should I merge
this series in the RFC and make it just one big series? Or should I
keep these as two separated series? If I keep these as separate series,
should I then omit all the MFD patches from RFC series - and add
potential MFD changes (like OVD/UVD configuration registers) in this
series (which makes bd9576 regulators not compiling) - or should the
MFD parts be included in both series - in which case we need to somehow
stay on track what parts of MFD is reviewed.

Simplest for me would be if we could get the oldest patches 1,2,4 and 5
from this series in-tree (only MFD is not acked) - but I guess it won't
happen at this point of the development cycle - and bring in the IRQ
(patch 3) and regulator notifications (patch 6) using the RFC series.

How do you see it? Should I meld this in the RFC or keep two separate
series - in which case, how should I handle the MFD changes brought by
the RFC series?

Best Regards
	Matti Vaittinen
Lee Jones Feb. 9, 2021, 2:55 p.m. UTC | #3
On Fri, 22 Jan 2021, Matti Vaittinen wrote:

> Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> mainly used to power the R-Car series processors.
> 
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> ---
> Changes since v6:
>  - no changes
>  drivers/mfd/Kconfig              |  11 ++++
>  drivers/mfd/Makefile             |   1 +
>  drivers/mfd/rohm-bd9576.c        | 108 +++++++++++++++++++++++++++++++
>  include/linux/mfd/rohm-bd957x.h  |  59 +++++++++++++++++
>  include/linux/mfd/rohm-generic.h |   2 +
>  5 files changed, 181 insertions(+)
>  create mode 100644 drivers/mfd/rohm-bd9576.c
>  create mode 100644 include/linux/mfd/rohm-bd957x.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index bdfce7b15621..53c7c96283bd 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1998,6 +1998,17 @@ config MFD_ROHM_BD71828
>  	  Also included is a Coulomb counter, a real-time clock (RTC), and
>  	  a 32.768 kHz clock gate.
>  
> +config MFD_ROHM_BD957XMUF
> +	tristate "ROHM BD9576MUF and BD9573MUF Power Management ICs"
> +	depends on I2C=y
> +	depends on OF
> +	select REGMAP_I2C
> +	select MFD_CORE
> +	help
> +	  Select this option to get support for the ROHM BD9576MUF and
> +	  BD9573MUF Power Management ICs. BD9576 and BD9573 are primarily
> +	  designed to be used to power R-Car series processors.
> +
>  config MFD_STM32_LPTIMER
>  	tristate "Support for STM32 Low-Power Timer"
>  	depends on (ARCH_STM32 && OF) || COMPILE_TEST
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 14fdb188af02..e58fae024bb2 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -262,6 +262,7 @@ obj-$(CONFIG_RAVE_SP_CORE)	+= rave-sp.o
>  obj-$(CONFIG_MFD_ROHM_BD70528)	+= rohm-bd70528.o
>  obj-$(CONFIG_MFD_ROHM_BD71828)	+= rohm-bd71828.o
>  obj-$(CONFIG_MFD_ROHM_BD718XX)	+= rohm-bd718x7.o
> +obj-$(CONFIG_MFD_ROHM_BD957XMUF)	+= rohm-bd9576.o
>  obj-$(CONFIG_MFD_STMFX) 	+= stmfx.o
>  obj-$(CONFIG_MFD_KHADAS_MCU) 	+= khadas-mcu.o
>  
> diff --git a/drivers/mfd/rohm-bd9576.c b/drivers/mfd/rohm-bd9576.c
> new file mode 100644
> index 000000000000..f4dd9e438427
> --- /dev/null
> +++ b/drivers/mfd/rohm-bd9576.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +//
> +// Copyright (C) 2020 ROHM Semiconductors
> +//
> +// ROHM BD9576MUF and BD9573MUF PMIC driver

No C++ comments (save the SPDX line) please.

> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/ioport.h>
> +#include <linux/irq.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/rohm-bd957x.h>
> +#include <linux/mfd/rohm-generic.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>
> +
> +static struct mfd_cell bd9573_mfd_cells[] = {
> +	{ .name = "bd9573-pmic", },
> +	{ .name = "bd9576-wdt", },
> +};
> +
> +static struct mfd_cell bd9576_mfd_cells[] = {
> +	{ .name = "bd9576-pmic", },
> +	{ .name = "bd9576-wdt", },
> +};

What is a PMIC in this context?

To me a PMIC is a bunch of devices.  What is this probing?

Maybe this is *-regulator?

> +static const struct regmap_range volatile_ranges[] = {
> +	regmap_reg_range(BD957X_REG_SMRB_ASSERT, BD957X_REG_SMRB_ASSERT),
> +	regmap_reg_range(BD957X_REG_PMIC_INTERNAL_STAT,
> +			 BD957X_REG_PMIC_INTERNAL_STAT),
> +	regmap_reg_range(BD957X_REG_INT_THERM_STAT, BD957X_REG_INT_THERM_STAT),
> +	regmap_reg_range(BD957X_REG_INT_OVP_STAT, BD957X_REG_INT_SYS_STAT),
> +	regmap_reg_range(BD957X_REG_INT_MAIN_STAT, BD957X_REG_INT_MAIN_STAT),
> +};
> +
> +static const struct regmap_access_table volatile_regs = {
> +	.yes_ranges = &volatile_ranges[0],
> +	.n_yes_ranges = ARRAY_SIZE(volatile_ranges),
> +};
> +
> +static struct regmap_config bd957x_regmap = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.volatile_table = &volatile_regs,
> +	.max_register = BD957X_MAX_REGISTER,
> +	.cache_type = REGCACHE_RBTREE,
> +};
> +
> +static int bd957x_i2c_probe(struct i2c_client *i2c,
> +			     const struct i2c_device_id *id)
> +{
> +	int ret;
> +	struct regmap *regmap;
> +	struct mfd_cell *mfd;
> +	int cells;
> +	unsigned long chip_type;
> +
> +	chip_type = (unsigned long)of_device_get_match_data(&i2c->dev);
> +
> +	switch (chip_type) {
> +	case ROHM_CHIP_TYPE_BD9576:
> +		mfd = bd9576_mfd_cells;
> +		cells = ARRAY_SIZE(bd9576_mfd_cells);
> +		break;
> +	case ROHM_CHIP_TYPE_BD9573:
> +		mfd = bd9573_mfd_cells;
> +		cells = ARRAY_SIZE(bd9573_mfd_cells);
> +		break;
> +	default:
> +		dev_err(&i2c->dev, "Unknown device type");
> +		return -EINVAL;
> +	}
> +
> +	regmap = devm_regmap_init_i2c(i2c, &bd957x_regmap);
> +	if (IS_ERR(regmap)) {
> +		dev_err(&i2c->dev, "Failed to initialize Regmap\n");
> +		return PTR_ERR(regmap);
> +	}
> +
> +	ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO, mfd, cells,

This nomenclature is confusing.

cells and num_cells would clear it up.

> +				   NULL, 0, NULL);
> +	if (ret)
> +		dev_err(&i2c->dev, "Failed to create subdevices\n");
> +
> +	return ret;
> +}
> +
> +static const struct of_device_id bd957x_of_match[] = {
> +	{ .compatible = "rohm,bd9576", .data = (void *)ROHM_CHIP_TYPE_BD9576, },
> +	{ .compatible = "rohm,bd9573", .data = (void *)ROHM_CHIP_TYPE_BD9573, },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, bd957x_of_match);
> +
> +static struct i2c_driver bd957x_drv = {
> +	.driver = {
> +		.name = "rohm-bd957x",
> +		.of_match_table = bd957x_of_match,
> +	},
> +	.probe = &bd957x_i2c_probe,
> +};
> +module_i2c_driver(bd957x_drv);
> +
> +MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
> +MODULE_DESCRIPTION("ROHM BD9576MUF and BD9573MUF Power Management IC driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/rohm-bd957x.h b/include/linux/mfd/rohm-bd957x.h
> new file mode 100644
> index 000000000000..3e7ca6fe5d4f
> --- /dev/null
> +++ b/include/linux/mfd/rohm-bd957x.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/* Copyright (C) 2020 ROHM Semiconductors */
> +
> +#ifndef __LINUX_MFD_BD957X_H__
> +#define __LINUX_MFD_BD957X_H__
> +
> +enum {
> +	BD957X_VD50,
> +	BD957X_VD18,
> +	BD957X_VDDDR,
> +	BD957X_VD10,
> +	BD957X_VOUTL1,
> +	BD957X_VOUTS1,
> +};
> +
> +#define BD957X_REG_SMRB_ASSERT		0x15
> +#define BD957X_REG_PMIC_INTERNAL_STAT	0x20
> +#define BD957X_REG_INT_THERM_STAT	0x23
> +#define BD957X_REG_INT_THERM_MASK 0x24
> +#define BD957X_REG_INT_OVP_STAT 0x25
> +#define BD957X_REG_INT_SCP_STAT 0x26
> +#define BD957X_REG_INT_OCP_STAT 0x27
> +#define BD957X_REG_INT_OVD_STAT 0x28
> +#define BD957X_REG_INT_UVD_STAT 0x29
> +#define BD957X_REG_INT_UVP_STAT 0x2a
> +#define BD957X_REG_INT_SYS_STAT 0x2b
> +#define BD957X_REG_INT_SYS_MASK 0x2c
> +#define BD957X_REG_INT_MAIN_STAT 0x30
> +#define BD957X_REG_INT_MAIN_MASK 0x31
> +
> +#define BD957X_REG_WDT_CONF 0x16
> +
> +#define BD957X_REG_POW_TRIGGER1 0x41
> +#define BD957X_REG_POW_TRIGGER2 0x42
> +#define BD957X_REG_POW_TRIGGER3 0x43
> +#define BD957X_REG_POW_TRIGGER4 0x44
> +#define BD957X_REG_POW_TRIGGERL1 0x45
> +#define BD957X_REG_POW_TRIGGERS1 0x46
> +
> +#define BD957X_REGULATOR_EN_MASK 0xff
> +#define BD957X_REGULATOR_DIS_VAL 0xff
> +
> +#define BD957X_VSEL_REG_MASK	0xff
> +
> +#define BD957X_MASK_VOUT1_TUNE	0x87
> +#define BD957X_MASK_VOUT2_TUNE	0x87
> +#define BD957X_MASK_VOUT3_TUNE	0x1f
> +#define BD957X_MASK_VOUT4_TUNE	0x1f
> +#define BD957X_MASK_VOUTL1_TUNE	0x87
> +
> +#define BD957X_REG_VOUT1_TUNE	0x50
> +#define BD957X_REG_VOUT2_TUNE	0x53
> +#define BD957X_REG_VOUT3_TUNE	0x56
> +#define BD957X_REG_VOUT4_TUNE	0x59
> +#define BD957X_REG_VOUTL1_TUNE	0x5c
> +
> +#define BD957X_MAX_REGISTER 0x61

Nit: Can you tab these out for improved readability please?

> +#endif
> diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
> index 4283b5b33e04..58b4f1a0f4af 100644
> --- a/include/linux/mfd/rohm-generic.h
> +++ b/include/linux/mfd/rohm-generic.h
> @@ -12,6 +12,8 @@ enum rohm_chip_type {
>  	ROHM_CHIP_TYPE_BD71847,
>  	ROHM_CHIP_TYPE_BD70528,
>  	ROHM_CHIP_TYPE_BD71828,
> +	ROHM_CHIP_TYPE_BD9576,
> +	ROHM_CHIP_TYPE_BD9573,
>  	ROHM_CHIP_TYPE_AMOUNT
>  };
>
Matti Vaittinen Feb. 10, 2021, 6:15 a.m. UTC | #4
Hello Lee,

On Tue, 2021-02-09 at 14:55 +0000, Lee Jones wrote:
> On Fri, 22 Jan 2021, Matti Vaittinen wrote:
> 
> > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> > mainly used to power the R-Car series processors.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> > +
> > +static struct mfd_cell bd9573_mfd_cells[] = {
> > +	{ .name = "bd9573-pmic", },
> > +	{ .name = "bd9576-wdt", },
> > +};
> > +
> > +static struct mfd_cell bd9576_mfd_cells[] = {
> > +	{ .name = "bd9576-pmic", },
> > +	{ .name = "bd9576-wdt", },
> > +};
> 
> What is a PMIC in this context?
> 
> To me a PMIC is a bunch of devices.  What is this probing?

I agree. PMIC is the IC as a whole. This name was not the best one. 
> 
> Maybe this is *-regulator?

That would be more descriptive and I can change this. However, it means
I need to change the already applied regulator part too. Furthermore,
all other ROHM PMIC drivers I've written use the <part-name>-pmic for
regulators and so does a few other drivers at least for ICs from Maxim,
Samsung and TI. That's why I don't think the <partname>-pmic is that
confusing. If it was my decision, I would stick with the pmic for the
sake of the consistency.

+
> > +	ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO, mfd,
> > cells,
> 
> This nomenclature is confusing.
> 
> cells and num_cells would clear it up.

I can change it.
+
> > +#define BD957X_MAX_REGISTER 0x61
> 
> Nit: Can you tab these out for improved readability please?
Sure, no problem.

Thanks for the review!

Best Regards
	--Matti

--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~

Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit

(Thanks for the translation Simon)