linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC
@ 2019-10-24 11:40 Matti Vaittinen
  2019-10-24 11:41 ` [RFC PATCH v2 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
                   ` (12 more replies)
  0 siblings, 13 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:40 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Patch series introducing support for ROHM BD71828 PMIC

ROHM BD71828 is a power management IC containing 7 bucks and 7 LDOs. All
regulators can either be controlled individually via I2C. Bucks 1,2,6 and
7 can also be assigned to a "regulator group" controlled by run-levels.
Eg. Run level specific voltages and enable/disable statuses for each of
these bucks can be set via register interface. The buck run-level group
assignment (selection if buck is to be controlled individually or via
run-levels) can be changed at run-time via I2C.

Run level changes can then be initiated wither via I2C writes or GPIO.
and when run-level is changed, state of all bucks which are set to be
controlled via run-levels are changed accrdingly.

This control mechanism selection (I2C or GPIO) is selected by data in
one time programmable PMIC memory area (during production) and can't be
changed later.

In addition to the bucks and LDOs there are:

- The usual clk gate
- 4 IO pins (mostly usable as GPO or tied to specific purpose)
- power button support
- RTC
- two LEDs
- battery charger
- HALL sensor input

This patch series adds support to regulators, clk, RTC, GPIOs and LEDs.
Power-supply driver for charger is "under construction" and not included
in this RFC series.

Reason for RFC status is the regulator grouping to run-levels. I don't
know what would be the best way to do what patches 8,9 and 10 intend to
provide. (Sure some of this is visible also patches 2 and 3 which
provide dt binding documents.) All suggestions are welcome. Rest of the
patches should be business as usual.

Changelog v2: Mainly RTC and GPIO fixes suggested by Alexandre and Bartosz.
	      LED changes are still under discussion and not included in
	      this version.
  General
    -Patch ordering changed to provide dt binding documents right after the
     MFD core.
  DT-Bindings for regulators (Patch 3)
    -Fix typo in PMIC model number
  RTC (patch 11)
    -Reverted renaming in order to reduce patch size.
    -Reworded commit message
  BD71828 regulator (patch 7)
    -Add MODULE_ALIAS
  GPIO (patch 12)
    -Remove file-name from comment
    -prefix IN and OUT defines with chip type
    -improved documentation for the INPUT only pin.
    -removed empty left-over function
    -removed unnecessary #ifdef CONFIG_OF_GPIO
    -removed unnecessary error print
    -Add MODULE_ALIAS

Patch 1:
        BD71828 MFD core.
Patch 2:
	dt-bindings for BD71828 PMIC
Patch 3:
        dt-bindings for regulators on BD71828 PMIC
Patch 4:
	Power button support using GPIO keys.
Patch 5:
        CLK gate support using existing clk-bd718x7
Patch 6:
        Split existing bd718x7 regulator driver to generic ROHM dt
        parsing portion (used by more than one ROHM drivers) and
        bd718x8 specific parts
Patch 7:
        Basic regulator support (individual control via I2C). This
        should be pretty standard stuff.
Patch 8:
        Add support for getting regulator voltages when GPIO controlled
        run-levels are used. Allow specifying voltages for run-levels
        via DT. Allow controlling run-levels via sysfs entries (I am not
        happy about this. Probably should only provide in-kernel API for
        this or is there better ideas? Showing can be done vis sysfs?
        Debugfs?)
Patch 9:
        Support setting/getting run-levels when they are controlled via
        I2C instead of GPIO. Add in-kernel API for settin run-level
        voltages for regulators at run-time.
Patch 10:
        Add in-kernel APIs for changing the RUN-level. Safer than sysfs
        I guess. But is there some better method for controlling this
        kind of dynamic group of regulators?
Patch 11:
        Support BD71828 RTC block using BD70528 RTC driver
Patch 12:
        Allow control of GP(I)O pins on BD71828 via GPIO subsystem
Patch 13:
        Support toggling the LEDs

This patch series is based on v5.3-rc4

---

Matti Vaittinen (13):
  mfd: bd71828: Support ROHM BD71828 PMIC - core
  dt-bindings: mfd: Document ROHM BD71828 bindings
  dt-bindings: regulator: Document ROHM BD71282 regulator bindings
  mfd: input: bd71828: Add power-key support
  clk: bd718x7: Support ROHM BD71828 clk block
  regulator: bd718x7: Split driver to common and bd718x7 specific parts
  regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators
  regulator: bd71828: Add GPIO based run-level control for regulators
  regulator: bd71828: enhanced run-level support
  regulator: bd71828: Support in-kernel APIs to change run-level
  rtc: bd70528 add BD71828 support
  gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs
  led: bd71828: Support LED outputs on ROHM BD71828 PMIC

 .../bindings/mfd/rohm,bd71828-pmic.txt        |  180 ++
 .../regulator/rohm,bd71828-regulator.txt      |  164 ++
 drivers/clk/Kconfig                           |    6 +-
 drivers/clk/clk-bd718x7.c                     |   15 +-
 drivers/gpio/Kconfig                          |   12 +
 drivers/gpio/Makefile                         |    1 +
 drivers/gpio/gpio-bd71828.c                   |  151 ++
 drivers/leds/Kconfig                          |   10 +
 drivers/leds/Makefile                         |    1 +
 drivers/leds/leds-bd71828.c                   |   97 ++
 drivers/mfd/Kconfig                           |   15 +
 drivers/mfd/Makefile                          |    2 +-
 drivers/mfd/rohm-bd71828.c                    |  350 ++++
 drivers/regulator/Kconfig                     |   16 +
 drivers/regulator/Makefile                    |    2 +
 drivers/regulator/bd71828-regulator.c         | 1443 +++++++++++++++++
 drivers/regulator/bd718x7-regulator.c         |  183 +--
 drivers/regulator/rohm-regulator.c            |   95 ++
 drivers/rtc/Kconfig                           |    5 +-
 drivers/rtc/rtc-bd70528.c                     |  145 +-
 include/linux/mfd/rohm-bd70528.h              |   13 +-
 include/linux/mfd/rohm-bd71828.h              |  432 +++++
 include/linux/mfd/rohm-generic.h              |   45 +
 include/linux/mfd/rohm-shared.h               |   27 +
 24 files changed, 3247 insertions(+), 163 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
 create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.txt
 create mode 100644 drivers/gpio/gpio-bd71828.c
 create mode 100644 drivers/leds/leds-bd71828.c
 create mode 100644 drivers/mfd/rohm-bd71828.c
 create mode 100644 drivers/regulator/bd71828-regulator.c
 create mode 100644 drivers/regulator/rohm-regulator.c
 create mode 100644 include/linux/mfd/rohm-bd71828.h
 create mode 100644 include/linux/mfd/rohm-shared.h

-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
@ 2019-10-24 11:41 ` Matti Vaittinen
  2019-10-24 11:41 ` [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
                   ` (11 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:41 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

BD71828GW is a single-chip power management IC for battery-powered portable
devices. The IC integrates 7 buck converters, 7 LDOs, and a 1500 mA
single-cell linear charger. Also included is a Coulomb counter, a real-time
clock (RTC), 3 GPO/regulator control pins, HALL input and a 32.768 kHz
clock gate.

Add MFD core driver providing interrupt controller facilities and i2c
access to sub device drivers.

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

No changes since v1

 drivers/mfd/Kconfig              |  15 ++
 drivers/mfd/Makefile             |   2 +-
 drivers/mfd/rohm-bd71828.c       | 322 +++++++++++++++++++++++
 include/linux/mfd/rohm-bd71828.h | 425 +++++++++++++++++++++++++++++++
 include/linux/mfd/rohm-generic.h |   1 +
 5 files changed, 764 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/rohm-bd71828.c
 create mode 100644 include/linux/mfd/rohm-bd71828.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f129f9678940..c0d6d3921f18 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1921,6 +1921,21 @@ config MFD_ROHM_BD70528
 	  10 bits SAR ADC for battery temperature monitor and 1S battery
 	  charger.
 
+config MFD_ROHM_BD71828
+	tristate "ROHM BD71828 Power Management IC"
+	depends on I2C=y
+	depends on OF
+	select REGMAP_I2C
+	select REGMAP_IRQ
+	select MFD_CORE
+	help
+	  Select this option to get support for the ROHM BD71828 Power
+	  Management IC. BD71828GW is a single-chip power management IC for
+	  battery-powered portable devices. The IC integrates 7 buck
+	  converters, 7 LDOs, and a 1500 mA single-cell linear charger.
+	  Also included is a Coulomb counter, a real-time clock (RTC), and
+	  a 32.768 kHz clock gate.
+
 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 f026ada68f6a..d154dfcaf665 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -254,6 +254,6 @@ obj-$(CONFIG_MFD_MXS_LRADC)     += mxs-lradc.o
 obj-$(CONFIG_MFD_SC27XX_PMIC)	+= sprd-sc27xx-spi.o
 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_STMFX) 	+= stmfx.o
-
diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
new file mode 100644
index 000000000000..b7de79e1fcdb
--- /dev/null
+++ b/drivers/mfd/rohm-bd71828.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2019 ROHM Semiconductors
+//
+// ROHM BD71828 PMIC driver
+
+#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-bd71828.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+static const struct resource rtc_irqs[] = {
+	DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC0, "bd71828-rtc-alm-0"),
+	DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC1, "bd71828-rtc-alm-1"),
+	DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC2, "bd71828-rtc-alm-2"),
+};
+
+static struct mfd_cell bd71828_mfd_cells[] = {
+	{ .name = "bd71828-pmic", },
+	{ .name = "bd71828-gpio", },
+	{ .name = "bd71828-led", },
+	/*
+	 * We use BD71837 driver to drive the clock block. Only differences to
+	 * BD70528 clock gate are the register address and mask.
+	 */
+	{ .name = "bd718xx-clk", },
+	{
+		.name = "bd71827-power",
+	}, {
+		.name = "bd70528-rtc",
+		.resources = rtc_irqs,
+		.num_resources = ARRAY_SIZE(rtc_irqs),
+	},
+};
+
+static const struct regmap_range volatile_ranges[] = {
+	{
+		.range_min = BD71828_REG_PS_CTRL_1,
+		.range_max = BD71828_REG_PS_CTRL_1,
+	}, {
+		.range_min = BD71828_REG_PS_CTRL_3,
+		.range_max = BD71828_REG_PS_CTRL_3,
+	}, {
+		.range_min = BD71828_REG_RTC_SEC,
+		.range_max = BD71828_REG_RTC_YEAR,
+	}, {
+		/*
+		 * For now make all charger registers volatile because many
+		 * needs to be and because the charger block is not that
+		 * performance critical. TBD: Check which charger registers
+		 * could be cached
+		 */
+		.range_min = BD71828_REG_CHG_STATE,
+		.range_max = BD71828_REG_CHG_FULL,
+	}, {
+		.range_min = BD71828_REG_INT_MAIN,
+		.range_max = BD71828_REG_IO_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 bd71828_regmap = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.volatile_table = &volatile_regs,
+	.max_register = BD71828_MAX_REGISTER,
+	.cache_type = REGCACHE_RBTREE,
+};
+
+/*
+ * Mapping of main IRQ register bits to sub-IRQ register offsets so that we can
+ * access corect sub-IRQ registers based on bits that are set in main IRQ
+ * register.
+ */
+
+unsigned int bit0_offsets[] = {11};		/* RTC IRQ register */
+unsigned int bit1_offsets[] = {10};		/* TEMP IRQ register */
+unsigned int bit2_offsets[] = {6, 7, 8, 9};	/* BAT MON IRQ registers */
+unsigned int bit3_offsets[] = {5};		/* BAT IRQ register */
+unsigned int bit4_offsets[] = {4};		/* CHG IRQ register */
+unsigned int bit5_offsets[] = {3};		/* VSYS IRQ register */
+unsigned int bit6_offsets[] = {1, 2};		/* DCIN IRQ registers */
+unsigned int bit7_offsets[] = {0};		/* BUCK IRQ register */
+
+static struct regmap_irq_sub_irq_map bd71828_sub_irq_offsets[] = {
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit0_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit1_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit2_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit3_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit4_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit5_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit6_offsets),
+	REGMAP_IRQ_MAIN_REG_OFFSET(bit7_offsets),
+};
+
+static struct regmap_irq bd71828_irqs[] = {
+	REGMAP_IRQ_REG(BD71828_INT_BUCK1_OCP, 0, BD71828_INT_BUCK1_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BUCK2_OCP, 0, BD71828_INT_BUCK2_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BUCK3_OCP, 0, BD71828_INT_BUCK3_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BUCK4_OCP, 0, BD71828_INT_BUCK4_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BUCK5_OCP, 0, BD71828_INT_BUCK5_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BUCK6_OCP, 0, BD71828_INT_BUCK6_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BUCK7_OCP, 0, BD71828_INT_BUCK7_OCP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_PGFAULT, 0, BD71828_INT_PGFAULT_MASK),
+	/* DCIN1 interrupts */
+	REGMAP_IRQ_REG(BD71828_INT_DCIN_DET, 1, BD71828_INT_DCIN_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_DCIN_RMV, 1, BD71828_INT_DCIN_RMV_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CLPS_OUT, 1, BD71828_INT_CLPS_OUT_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CLPS_IN, 1, BD71828_INT_CLPS_IN_MASK),
+	/* DCIN2 interrupts */
+	REGMAP_IRQ_REG(BD71828_INT_DCIN_MON_RES, 2,
+		       BD71828_INT_DCIN_MON_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_DCIN_MON_DET, 2,
+		       BD71828_INT_DCIN_MON_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_LONGPUSH, 2, BD71828_INT_LONGPUSH_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_MIDPUSH, 2, BD71828_INT_MIDPUSH_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_SHORTPUSH, 2, BD71828_INT_SHORTPUSH_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_PUSH, 2, BD71828_INT_PUSH_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_WDOG, 2, BD71828_INT_WDOG_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_SWRESET, 2, BD71828_INT_SWRESET_MASK),
+	/* Vsys */
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_UV_RES, 3,
+		       BD71828_INT_VSYS_UV_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_UV_DET, 3,
+		       BD71828_INT_VSYS_UV_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_LOW_RES, 3,
+		       BD71828_INT_VSYS_LOW_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_LOW_DET, 3,
+		       BD71828_INT_VSYS_LOW_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_HALL_IN, 3,
+		       BD71828_INT_VSYS_HALL_IN_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_HALL_TOGGLE, 3,
+		       BD71828_INT_VSYS_HALL_TOGGLE_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_MON_RES, 3,
+		       BD71828_INT_VSYS_MON_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_VSYS_MON_DET, 3,
+		       BD71828_INT_VSYS_MON_DET_MASK),
+	/* Charger */
+	REGMAP_IRQ_REG(BD71828_INT_CHG_DCIN_ILIM, 4,
+		       BD71828_INT_CHG_DCIN_ILIM_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_TOPOFF_TO_DONE, 4,
+		       BD71828_INT_CHG_TOPOFF_TO_DONE_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_WDG_TEMP, 4,
+		       BD71828_INT_CHG_WDG_TEMP_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_WDG_TIME, 4,
+		       BD71828_INT_CHG_WDG_TIME_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_RECHARGE_RES, 4,
+		       BD71828_INT_CHG_RECHARGE_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_RECHARGE_DET, 4,
+		       BD71828_INT_CHG_RECHARGE_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_RANGED_TEMP_TRANSITION, 4,
+		       BD71828_INT_CHG_RANGED_TEMP_TRANSITION_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_CHG_STATE_TRANSITION, 4,
+		       BD71828_INT_CHG_STATE_TRANSITION_MASK),
+	/* Battery */
+	REGMAP_IRQ_REG(BD71828_INT_BAT_TEMP_NORMAL, 5,
+		       BD71828_INT_BAT_TEMP_NORMAL_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_TEMP_ERANGE, 5,
+		       BD71828_INT_BAT_TEMP_ERANGE_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_TEMP_WARN, 5,
+		       BD71828_INT_BAT_TEMP_WARN_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_REMOVED, 5,
+		       BD71828_INT_BAT_REMOVED_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_DETECTED, 5,
+		       BD71828_INT_BAT_DETECTED_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_THERM_REMOVED, 5,
+		       BD71828_INT_THERM_REMOVED_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_THERM_DETECTED, 5,
+		       BD71828_INT_THERM_DETECTED_MASK),
+	/* Battery Mon 1 */
+	REGMAP_IRQ_REG(BD71828_INT_BAT_DEAD, 6, BD71828_INT_BAT_DEAD_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_SHORTC_RES, 6,
+		       BD71828_INT_BAT_SHORTC_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_SHORTC_DET, 6,
+		       BD71828_INT_BAT_SHORTC_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_LOW_VOLT_RES, 6,
+		       BD71828_INT_BAT_LOW_VOLT_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_LOW_VOLT_DET, 6,
+		       BD71828_INT_BAT_LOW_VOLT_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_VOLT_RES, 6,
+		       BD71828_INT_BAT_OVER_VOLT_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_VOLT_DET, 6,
+		       BD71828_INT_BAT_OVER_VOLT_DET_MASK),
+	/* Battery Mon 2 */
+	REGMAP_IRQ_REG(BD71828_INT_BAT_MON_RES, 7,
+		       BD71828_INT_BAT_MON_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_MON_DET, 7,
+		       BD71828_INT_BAT_MON_DET_MASK),
+	/* Battery Mon 3 (Coulomb counter) */
+	REGMAP_IRQ_REG(BD71828_INT_BAT_CC_MON1, 8,
+		       BD71828_INT_BAT_CC_MON1_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_CC_MON2, 8,
+		       BD71828_INT_BAT_CC_MON2_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_CC_MON3, 8,
+		       BD71828_INT_BAT_CC_MON3_MASK),
+	/* Battery Mon 4 */
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_CURR_1_RES, 9,
+		       BD71828_INT_BAT_OVER_CURR_1_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_CURR_1_DET, 9,
+		       BD71828_INT_BAT_OVER_CURR_1_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_CURR_2_RES, 9,
+		       BD71828_INT_BAT_OVER_CURR_2_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_CURR_2_DET, 9,
+		       BD71828_INT_BAT_OVER_CURR_2_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_CURR_3_RES, 9,
+		       BD71828_INT_BAT_OVER_CURR_3_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_BAT_OVER_CURR_3_DET, 9,
+		       BD71828_INT_BAT_OVER_CURR_3_DET_MASK),
+	/* Temperature */
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_BAT_LOW_RES, 10,
+		       BD71828_INT_TEMP_BAT_LOW_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_BAT_LOW_DET, 10,
+		       BD71828_INT_TEMP_BAT_LOW_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_BAT_HI_RES, 10,
+		       BD71828_INT_TEMP_BAT_HI_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_BAT_HI_DET, 10,
+		       BD71828_INT_TEMP_BAT_HI_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_CHIP_OVER_125_RES, 10,
+		       BD71828_INT_TEMP_CHIP_OVER_125_RES_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_CHIP_OVER_125_DET, 10,
+		       BD71828_INT_TEMP_CHIP_OVER_125_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_CHIP_OVER_VF_DET, 10,
+		       BD71828_INT_TEMP_CHIP_OVER_VF_DET_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_TEMP_CHIP_OVER_VF_RES, 10,
+		       BD71828_INT_TEMP_CHIP_OVER_VF_RES_MASK),
+	/* RTC Alarm */
+	REGMAP_IRQ_REG(BD71828_INT_RTC0, 11, BD71828_INT_RTC0_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_RTC1, 11, BD71828_INT_RTC1_MASK),
+	REGMAP_IRQ_REG(BD71828_INT_RTC2, 11, BD71828_INT_RTC2_MASK),
+};
+
+static struct regmap_irq_chip bd71828_irq_chip = {
+	.name = "bd71828_irq",
+	.main_status = BD71828_REG_INT_MAIN,
+	.irqs = &bd71828_irqs[0],
+	.num_irqs = ARRAY_SIZE(bd71828_irqs),
+	.status_base = BD71828_REG_INT_BUCK,
+	.mask_base = BD71828_REG_INT_MASK_BUCK,
+	.ack_base = BD71828_REG_INT_BUCK,
+	.mask_invert = true,
+	.init_ack_masked = true,
+	.num_regs = 12,
+	.num_main_regs = 1,
+	.sub_reg_offsets = &bd71828_sub_irq_offsets[0],
+	.num_main_status_bits = 8,
+	.irq_reg_stride = 1,
+};
+
+static int bd71828_i2c_probe(struct i2c_client *i2c,
+			     const struct i2c_device_id *id)
+{
+	struct rohm_regmap_dev *chip;
+	struct regmap_irq_chip_data *irq_data;
+	int ret;
+
+	if (!i2c->irq) {
+		dev_err(&i2c->dev, "No IRQ configured\n");
+		return -EINVAL;
+	}
+
+	chip = devm_kzalloc(&i2c->dev, sizeof(*chip), GFP_KERNEL);
+	if (!chip)
+		return -ENOMEM;
+
+	dev_set_drvdata(&i2c->dev, chip);
+
+	chip->chip_type = ROHM_CHIP_TYPE_BD71828;
+	chip->regmap = devm_regmap_init_i2c(i2c, &bd71828_regmap);
+	if (IS_ERR(chip->regmap)) {
+		dev_err(&i2c->dev, "Failed to initialize Regmap\n");
+		return PTR_ERR(chip->regmap);
+	}
+
+	ret = devm_regmap_add_irq_chip(&i2c->dev, chip->regmap,
+				       i2c->irq, IRQF_ONESHOT, 0,
+				       &bd71828_irq_chip, &irq_data);
+	if (ret) {
+		dev_err(&i2c->dev, "Failed to add IRQ chip\n");
+		return ret;
+	}
+	dev_dbg(&i2c->dev, "Registered %d IRQs for chip\n",
+		bd71828_irq_chip.num_irqs);
+
+	ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO,
+				   bd71828_mfd_cells,
+				   ARRAY_SIZE(bd71828_mfd_cells), NULL, 0,
+				   regmap_irq_get_domain(irq_data));
+	if (ret)
+		dev_err(&i2c->dev, "Failed to create subdevices\n");
+
+	return ret;
+}
+
+static const struct of_device_id bd71828_of_match[] = {
+	{ .compatible = "rohm,bd71828", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, bd71828_of_match);
+
+static struct i2c_driver bd71828_drv = {
+	.driver = {
+		.name = "rohm-bd71828",
+		.of_match_table = bd71828_of_match,
+	},
+	.probe = &bd71828_i2c_probe,
+};
+
+module_i2c_driver(bd71828_drv);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("ROHM BD71828 Power Management IC driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/rohm-bd71828.h b/include/linux/mfd/rohm-bd71828.h
new file mode 100644
index 000000000000..eb0557eb5314
--- /dev/null
+++ b/include/linux/mfd/rohm-bd71828.h
@@ -0,0 +1,425 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* Copyright (C) 2019 ROHM Semiconductors */
+
+#ifndef __LINUX_MFD_BD71828_H__
+#define __LINUX_MFD_BD71828_H__
+
+#include <linux/mfd/rohm-generic.h>
+
+/* Regulator IDs */
+enum {
+	BD71828_BUCK1,
+	BD71828_BUCK2,
+	BD71828_BUCK3,
+	BD71828_BUCK4,
+	BD71828_BUCK5,
+	BD71828_BUCK6,
+	BD71828_BUCK7,
+	BD71828_LDO1,
+	BD71828_LDO2,
+	BD71828_LDO3,
+	BD71828_LDO4,
+	BD71828_LDO5,
+	BD71828_LDO6,
+	BD71828_LDO_SNVS,
+	BD71828_REGULATOR_AMOUNT,
+};
+
+#define BD71828_BUCK1267_VOLTS		0xEF
+#define BD71828_BUCK3_VOLTS		0x10
+#define BD71828_BUCK4_VOLTS		0x20
+#define BD71828_BUCK5_VOLTS		0x10
+#define BD71828_LDO_VOLTS		0x32
+/* LDO6 is fixed 1.8V voltage */
+#define BD71828_LDO_6_VOLTAGE		1800000
+
+/* Registers and masks*/
+
+/* MODE control */
+#define BD71828_REG_PS_CTRL_1		0x04
+#define BD71828_REG_PS_CTRL_2		0x05
+#define BD71828_REG_PS_CTRL_3		0x06
+
+//#define BD71828_REG_SWRESET		0x06
+#define BD71828_MASK_RUN_LVL_CTRL	0x30
+
+/* Regulator control masks */
+
+#define BD71828_MASK_RAMP_DELAY		0x6
+
+#define BD71828_MASK_RUN_EN		0x08
+#define BD71828_MASK_SUSP_EN		0x04
+#define BD71828_MASK_IDLE_EN		0x02
+#define BD71828_MASK_LPSR_EN		0x01
+
+#define BD71828_MASK_RUN0_EN		0x01
+#define BD71828_MASK_RUN1_EN		0x02
+#define BD71828_MASK_RUN2_EN		0x04
+#define BD71828_MASK_RUN3_EN		0x08
+
+#define BD71828_MASK_DVS_BUCK1_CTRL	0x10
+#define BD71828_DVS_BUCK1_CTRL_I2C	0
+#define BD71828_DVS_BUCK1_USE_RUNLVL	0x10
+
+#define BD71828_MASK_DVS_BUCK2_CTRL	0x20
+#define BD71828_DVS_BUCK2_CTRL_I2C	0
+#define BD71828_DVS_BUCK2_USE_RUNLVL	0x20
+
+#define BD71828_MASK_DVS_BUCK6_CTRL	0x40
+#define BD71828_DVS_BUCK6_CTRL_I2C	0
+#define BD71828_DVS_BUCK6_USE_RUNLVL	0x40
+
+#define BD71828_MASK_DVS_BUCK7_CTRL	0x80
+#define BD71828_DVS_BUCK7_CTRL_I2C	0
+#define BD71828_DVS_BUCK7_USE_RUNLVL	0x80
+
+#define BD71828_MASK_BUCK1267_VOLT	0xff
+#define BD71828_MASK_BUCK3_VOLT		0x1f
+#define BD71828_MASK_BUCK4_VOLT		0x3f
+#define BD71828_MASK_BUCK5_VOLT		0x1f
+#define BD71828_MASK_LDO_VOLT		0x3f
+
+/* Regulator control regs */
+#define BD71828_REG_BUCK1_EN		0x08
+#define BD71828_REG_BUCK1_CTRL		0x09
+#define BD71828_REG_BUCK1_MODE		0x0a
+#define BD71828_REG_BUCK1_IDLE_VOLT	0x0b
+#define BD71828_REG_BUCK1_SUSP_VOLT	0x0c
+#define BD71828_REG_BUCK1_VOLT		0x0d
+
+#define BD71828_REG_BUCK2_EN		0x12
+#define BD71828_REG_BUCK2_CTRL		0x13
+#define BD71828_REG_BUCK2_MODE		0x14
+#define BD71828_REG_BUCK2_IDLE_VOLT	0x15
+#define BD71828_REG_BUCK2_SUSP_VOLT	0x16
+#define BD71828_REG_BUCK2_VOLT		0x17
+
+#define BD71828_REG_BUCK3_EN		0x1c
+#define BD71828_REG_BUCK3_MODE		0x1d
+#define BD71828_REG_BUCK3_VOLT		0x1e
+
+#define BD71828_REG_BUCK4_EN		0x1f
+#define BD71828_REG_BUCK4_MODE		0x20
+#define BD71828_REG_BUCK4_VOLT		0x21
+
+#define BD71828_REG_BUCK5_EN		0x22
+#define BD71828_REG_BUCK5_MODE		0x23
+#define BD71828_REG_BUCK5_VOLT		0x24
+
+#define BD71828_REG_BUCK6_EN		0x25
+#define BD71828_REG_BUCK6_CTRL		0x26
+#define BD71828_REG_BUCK6_MODE		0x27
+#define BD71828_REG_BUCK6_IDLE_VOLT	0x28
+#define BD71828_REG_BUCK6_SUSP_VOLT	0x29
+#define BD71828_REG_BUCK6_VOLT		0x2a
+
+#define BD71828_REG_BUCK7_EN		0x2f
+#define BD71828_REG_BUCK7_CTRL		0x30
+#define BD71828_REG_BUCK7_MODE		0x31
+#define BD71828_REG_BUCK7_IDLE_VOLT	0x32
+#define BD71828_REG_BUCK7_SUSP_VOLT	0x33
+#define BD71828_REG_BUCK7_VOLT		0x34
+
+#define BD71828_REG_LDO1_EN		0x39
+#define BD71828_REG_LDO1_VOLT		0x3a
+#define BD71828_REG_LDO2_EN		0x3b
+#define BD71828_REG_LDO2_VOLT		0x3c
+#define BD71828_REG_LDO3_EN		0x3d
+#define BD71828_REG_LDO3_VOLT		0x3e
+#define BD71828_REG_LDO4_EN		0x3f
+#define BD71828_REG_LDO4_VOLT		0x40
+#define BD71828_REG_LDO5_EN		0x41
+#define BD71828_REG_LDO5_VOLT		0x43
+#define BD71828_REG_LDO5_VOLT_OPT	0x42
+#define BD71828_REG_LDO6_EN		0x44
+//#define BD71828_REG_LDO6_VOLT		0x4
+#define BD71828_REG_LDO7_EN		0x45
+#define BD71828_REG_LDO7_VOLT		0x46
+
+/* GPIO */
+
+#define BD71828_GPIO_DRIVE_MASK		0x2
+#define BD71828_GPIO_OPEN_DRAIN		0x0
+#define BD71828_GPIO_PUSH_PULL		0x2
+#define BD71828_GPIO_OUT_HI		0x1
+#define BD71828_GPIO_OUT_LO		0x0
+#define BD71828_GPIO_OUT_MASK		0x1
+
+#define BD71828_REG_GPIO_CTRL1		0x47
+#define BD71828_REG_GPIO_CTRL2		0x48
+#define BD71828_REG_GPIO_CTRL3		0x49
+#define BD71828_REG_IO_STAT		0xed
+
+/* RTC */
+#define BD71828_REG_RTC_SEC		0x4c
+#define BD71828_REG_RTC_MINUTE		0x4d
+#define BD71828_REG_RTC_HOUR		0x4e
+#define BD71828_REG_RTC_WEEK		0x4f
+#define BD71828_REG_RTC_DAY		0x50
+#define BD71828_REG_RTC_MONTH		0x51
+#define BD71828_REG_RTC_YEAR		0x52
+
+#define BD71828_REG_RTC_ALM0_SEC	0x53
+#define BD71828_REG_RTC_ALM0_MINUTE	0x54
+#define BD71828_REG_RTC_ALM0_HOUR	0x55
+#define BD71828_REG_RTC_ALM0_WEEK	0x56
+#define BD71828_REG_RTC_ALM0_DAY	0x57
+#define BD71828_REG_RTC_ALM0_MONTH	0x58
+#define BD71828_REG_RTC_ALM0_YEAR	0x59
+#define BD71828_REG_RTC_ALM0_MASK	0x61
+
+#define BD71828_REG_RTC_ALM1_SEC	0x5a
+#define BD71828_REG_RTC_ALM1_MINUTE	0x5b
+#define BD71828_REG_RTC_ALM1_HOUR	0x5c
+#define BD71828_REG_RTC_ALM1_WEEK	0x5d
+#define BD71828_REG_RTC_ALM1_DAY	0x5e
+#define BD71828_REG_RTC_ALM1_MONTH	0x5f
+#define BD71828_REG_RTC_ALM1_YEAR	0x60
+#define BD71828_REG_RTC_ALM1_MASK	0x62
+
+#define BD71828_REG_RTC_ALM2		0x63
+
+/* Charger/Battey */
+#define BD71828_REG_CHG_STATE		0x65
+#define BD71828_REG_CHG_FULL		0xd2
+
+/* CLK */
+#define BD71828_REG_OUT32K		0x4B
+
+/* LEDs */
+#define BD71828_REG_LED_CTRL		0x4A
+#define BD71828_MASK_LED_AMBER		0x80
+#define BD71828_MASK_LED_GREEN		0x40
+#define BD71828_LED_ON			0xff
+#define BD71828_LED_OFF			0x0
+
+/* IRQ registers */
+#define BD71828_REG_INT_MASK_BUCK	0xd3
+#define BD71828_REG_INT_MASK_DCIN1	0xd4
+#define BD71828_REG_INT_MASK_DCIN2	0xd5
+#define BD71828_REG_INT_MASK_VSYS	0xd6
+#define BD71828_REG_INT_MASK_CHG	0xd7
+#define BD71828_REG_INT_MASK_BAT	0xd8
+#define BD71828_REG_INT_MASK_BAT_MON1	0xd9
+#define BD71828_REG_INT_MASK_BAT_MON2	0xda
+#define BD71828_REG_INT_MASK_BAT_MON3	0xdb
+#define BD71828_REG_INT_MASK_BAT_MON4	0xdc
+#define BD71828_REG_INT_MASK_TEMP	0xdd
+#define BD71828_REG_INT_MASK_RTC	0xde
+
+
+#define BD71828_REG_INT_MAIN		0xdf
+#define BD71828_REG_INT_BUCK		0xe0
+#define BD71828_REG_INT_DCIN1		0xe1
+#define BD71828_REG_INT_DCIN2		0xe2
+#define BD71828_REG_INT_VSYS		0xe3
+#define BD71828_REG_INT_CHG		0xe4
+#define BD71828_REG_INT_BAT		0xe5
+#define BD71828_REG_INT_BAT_MON1	0xe6
+#define BD71828_REG_INT_BAT_MON2	0xe7
+#define BD71828_REG_INT_BAT_MON3	0xe8
+#define BD71828_REG_INT_BAT_MON4	0xe9
+#define BD71828_REG_INT_TEMP		0xea
+#define BD71828_REG_INT_RTC		0xeb
+#define BD71828_REG_INT_UPDATE		0xec
+
+#define BD71828_MAX_REGISTER BD71828_REG_IO_STAT
+
+/* Masks for main IRQ register bits */
+enum {
+	BD71828_INT_BUCK,
+#define BD71828_INT_BUCK_MASK BIT(BD71828_INT_BUCK)
+	BD71828_INT_DCIN,
+#define BD71828_INT_DCIN_MASK BIT(BD71828_INT_DCIN)
+	BD71828_INT_VSYS,
+#define BD71828_INT_VSYS_MASK BIT(BD71828_INT_VSYS)
+	BD71828_INT_CHG,
+#define BD71828_INT_CHG_MASK BIT(BD71828_INT_CHG)
+	BD71828_INT_BAT,
+#define BD71828_INT_BAT_MASK BIT(BD71828_INT_BAT)
+	BD71828_INT_BAT_MON,
+#define BD71828_INT_BAT_MON_MASK BIT(BD71828_INT_BAT_MON)
+	BD71828_INT_TEMP,
+#define BD71828_INT_TEMP_MASK BIT(BD71828_INT_TEMP)
+	BD71828_INT_RTC,
+#define BD71828_INT_RTC_MASK BIT(BD71828_INT_RTC)
+};
+
+/* Interrupts */
+enum {
+	/* BUCK reg interrupts */
+	BD71828_INT_BUCK1_OCP,
+	BD71828_INT_BUCK2_OCP,
+	BD71828_INT_BUCK3_OCP,
+	BD71828_INT_BUCK4_OCP,
+	BD71828_INT_BUCK5_OCP,
+	BD71828_INT_BUCK6_OCP,
+	BD71828_INT_BUCK7_OCP,
+	BD71828_INT_PGFAULT,
+	/* DCIN1 interrupts */
+	BD71828_INT_DCIN_DET,
+	BD71828_INT_DCIN_RMV,
+	BD71828_INT_CLPS_OUT,
+	BD71828_INT_CLPS_IN,
+	/* DCIN2 interrupts */
+	BD71828_INT_DCIN_MON_RES,
+	BD71828_INT_DCIN_MON_DET,
+	BD71828_INT_LONGPUSH,
+	BD71828_INT_MIDPUSH,
+	BD71828_INT_SHORTPUSH,
+	BD71828_INT_PUSH,
+	BD71828_INT_WDOG,
+	BD71828_INT_SWRESET,
+	/* Vsys */
+	BD71828_INT_VSYS_UV_RES,
+	BD71828_INT_VSYS_UV_DET,
+	BD71828_INT_VSYS_LOW_RES,
+	BD71828_INT_VSYS_LOW_DET,
+	BD71828_INT_VSYS_HALL_IN,
+	BD71828_INT_VSYS_HALL_TOGGLE,
+	BD71828_INT_VSYS_MON_RES,
+	BD71828_INT_VSYS_MON_DET,
+	/* Charger */
+	BD71828_INT_CHG_DCIN_ILIM,
+	BD71828_INT_CHG_TOPOFF_TO_DONE,
+	BD71828_INT_CHG_WDG_TEMP,
+	BD71828_INT_CHG_WDG_TIME,
+	BD71828_INT_CHG_RECHARGE_RES,
+	BD71828_INT_CHG_RECHARGE_DET,
+	BD71828_INT_CHG_RANGED_TEMP_TRANSITION,
+	BD71828_INT_CHG_STATE_TRANSITION,
+	/* Battery */
+	BD71828_INT_BAT_TEMP_NORMAL,
+	BD71828_INT_BAT_TEMP_ERANGE,
+	BD71828_INT_BAT_TEMP_WARN,
+	BD71828_INT_BAT_REMOVED,
+	BD71828_INT_BAT_DETECTED,
+	BD71828_INT_THERM_REMOVED,
+	BD71828_INT_THERM_DETECTED,
+	/* Battery Mon 1 */
+	BD71828_INT_BAT_DEAD,
+	BD71828_INT_BAT_SHORTC_RES,
+	BD71828_INT_BAT_SHORTC_DET,
+	BD71828_INT_BAT_LOW_VOLT_RES,
+	BD71828_INT_BAT_LOW_VOLT_DET,
+	BD71828_INT_BAT_OVER_VOLT_RES,
+	BD71828_INT_BAT_OVER_VOLT_DET,
+	/* Battery Mon 2 */
+	BD71828_INT_BAT_MON_RES,
+	BD71828_INT_BAT_MON_DET,
+	/* Battery Mon 3 (Coulomb counter) */
+	BD71828_INT_BAT_CC_MON1,
+	BD71828_INT_BAT_CC_MON2,
+	BD71828_INT_BAT_CC_MON3,
+	/* Battery Mon 4 */
+	BD71828_INT_BAT_OVER_CURR_1_RES,
+	BD71828_INT_BAT_OVER_CURR_1_DET,
+	BD71828_INT_BAT_OVER_CURR_2_RES,
+	BD71828_INT_BAT_OVER_CURR_2_DET,
+	BD71828_INT_BAT_OVER_CURR_3_RES,
+	BD71828_INT_BAT_OVER_CURR_3_DET,
+	/* Temperature */
+	BD71828_INT_TEMP_BAT_LOW_RES,
+	BD71828_INT_TEMP_BAT_LOW_DET,
+	BD71828_INT_TEMP_BAT_HI_RES,
+	BD71828_INT_TEMP_BAT_HI_DET,
+	BD71828_INT_TEMP_CHIP_OVER_125_RES,
+	BD71828_INT_TEMP_CHIP_OVER_125_DET,
+	BD71828_INT_TEMP_CHIP_OVER_VF_DET,
+	BD71828_INT_TEMP_CHIP_OVER_VF_RES,
+	/* RTC Alarm */
+	BD71828_INT_RTC0,
+	BD71828_INT_RTC1,
+	BD71828_INT_RTC2,
+};
+
+#define BD71828_INT_BUCK1_OCP_MASK			0x1
+#define BD71828_INT_BUCK2_OCP_MASK			0x2
+#define BD71828_INT_BUCK3_OCP_MASK			0x4
+#define BD71828_INT_BUCK4_OCP_MASK			0x8
+#define BD71828_INT_BUCK5_OCP_MASK			0x10
+#define BD71828_INT_BUCK6_OCP_MASK			0x20
+#define BD71828_INT_BUCK7_OCP_MASK			0x40
+#define BD71828_INT_PGFAULT_MASK			0x80
+
+#define BD71828_INT_DCIN_DET_MASK			0x1
+#define BD71828_INT_DCIN_RMV_MASK			0x2
+#define BD71828_INT_CLPS_OUT_MASK			0x4
+#define BD71828_INT_CLPS_IN_MASK			0x8
+	/* DCIN2 interrupts */
+#define BD71828_INT_DCIN_MON_RES_MASK			0x1
+#define BD71828_INT_DCIN_MON_DET_MASK			0x2
+#define BD71828_INT_LONGPUSH_MASK			0x4
+#define BD71828_INT_MIDPUSH_MASK			0x8
+#define BD71828_INT_SHORTPUSH_MASK			0x10
+#define BD71828_INT_PUSH_MASK				0x20
+#define BD71828_INT_WDOG_MASK				0x40
+#define BD71828_INT_SWRESET_MASK			0x80
+	/* Vsys */
+#define BD71828_INT_VSYS_UV_RES_MASK			0x1
+#define BD71828_INT_VSYS_UV_DET_MASK			0x2
+#define BD71828_INT_VSYS_LOW_RES_MASK			0x4
+#define BD71828_INT_VSYS_LOW_DET_MASK			0x8
+#define BD71828_INT_VSYS_HALL_IN_MASK			0x10
+#define BD71828_INT_VSYS_HALL_TOGGLE_MASK		0x20
+#define BD71828_INT_VSYS_MON_RES_MASK			0x40
+#define BD71828_INT_VSYS_MON_DET_MASK			0x80
+	/* Charger */
+#define BD71828_INT_CHG_DCIN_ILIM_MASK			0x1
+#define BD71828_INT_CHG_TOPOFF_TO_DONE_MASK		0x2
+#define BD71828_INT_CHG_WDG_TEMP_MASK			0x4
+#define BD71828_INT_CHG_WDG_TIME_MASK			0x8
+#define BD71828_INT_CHG_RECHARGE_RES_MASK		0x10
+#define BD71828_INT_CHG_RECHARGE_DET_MASK		0x20
+#define BD71828_INT_CHG_RANGED_TEMP_TRANSITION_MASK	0x40
+#define BD71828_INT_CHG_STATE_TRANSITION_MASK		0x80
+	/* Battery */
+#define BD71828_INT_BAT_TEMP_NORMAL_MASK		0x1
+#define BD71828_INT_BAT_TEMP_ERANGE_MASK		0x2
+#define BD71828_INT_BAT_TEMP_WARN_MASK			0x4
+#define BD71828_INT_BAT_REMOVED_MASK			0x10
+#define BD71828_INT_BAT_DETECTED_MASK			0x20
+#define BD71828_INT_THERM_REMOVED_MASK			0x40
+#define BD71828_INT_THERM_DETECTED_MASK			0x80
+	/* Battery Mon 1 */
+#define BD71828_INT_BAT_DEAD_MASK			0x2
+#define BD71828_INT_BAT_SHORTC_RES_MASK			0x4
+#define BD71828_INT_BAT_SHORTC_DET_MASK			0x8
+#define BD71828_INT_BAT_LOW_VOLT_RES_MASK		0x10
+#define BD71828_INT_BAT_LOW_VOLT_DET_MASK		0x20
+#define BD71828_INT_BAT_OVER_VOLT_RES_MASK		0x40
+#define BD71828_INT_BAT_OVER_VOLT_DET_MASK		0x80
+	/* Battery Mon 2 */
+#define BD71828_INT_BAT_MON_RES_MASK			0x1
+#define BD71828_INT_BAT_MON_DET_MASK			0x2
+	/* Battery Mon 3 (Coulomb counter) */
+#define BD71828_INT_BAT_CC_MON1_MASK			0x1
+#define BD71828_INT_BAT_CC_MON2_MASK			0x2
+#define BD71828_INT_BAT_CC_MON3_MASK			0x4
+	/* Battery Mon 4 */
+#define BD71828_INT_BAT_OVER_CURR_1_RES_MASK		0x1
+#define BD71828_INT_BAT_OVER_CURR_1_DET_MASK		0x2
+#define BD71828_INT_BAT_OVER_CURR_2_RES_MASK		0x4
+#define BD71828_INT_BAT_OVER_CURR_2_DET_MASK		0x8
+#define BD71828_INT_BAT_OVER_CURR_3_RES_MASK		0x10
+#define BD71828_INT_BAT_OVER_CURR_3_DET_MASK		0x20
+	/* Temperature */
+#define BD71828_INT_TEMP_BAT_LOW_RES_MASK		0x1
+#define BD71828_INT_TEMP_BAT_LOW_DET_MASK		0x2
+#define BD71828_INT_TEMP_BAT_HI_RES_MASK		0x4
+#define BD71828_INT_TEMP_BAT_HI_DET_MASK		0x8
+#define BD71828_INT_TEMP_CHIP_OVER_125_RES_MASK		0x10
+#define BD71828_INT_TEMP_CHIP_OVER_125_DET_MASK		0x20
+#define BD71828_INT_TEMP_CHIP_OVER_VF_RES_MASK		0x40
+#define BD71828_INT_TEMP_CHIP_OVER_VF_DET_MASK		0x80
+	/* RTC Alarm */
+#define BD71828_INT_RTC0_MASK				0x1
+#define BD71828_INT_RTC1_MASK				0x2
+#define BD71828_INT_RTC2_MASK				0x4
+
+#define BD71828_OUT32K_EN				0x1
+#define BD71828_OUT_TYPE_MASK				0x2
+#define BD71828_OUT_TYPE_OPEN_DRAIN			0x0
+#define BD71828_OUT_TYPE_CMOS				0x2
+
+#endif /* __LINUX_MFD_BD71828_H__ */
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index bff15ac26f2c..b280f3100d6c 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -8,6 +8,7 @@ enum {
 	ROHM_CHIP_TYPE_BD71837 = 0,
 	ROHM_CHIP_TYPE_BD71847,
 	ROHM_CHIP_TYPE_BD70528,
+	ROHM_CHIP_TYPE_BD71828,
 	ROHM_CHIP_TYPE_AMOUNT
 };
 
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
  2019-10-24 11:41 ` [RFC PATCH v2 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
@ 2019-10-24 11:41 ` Matti Vaittinen
  2019-10-24 19:35   ` Dan Murphy
  2019-10-24 11:42 ` [RFC PATCH v2 03/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
                   ` (10 subsequent siblings)
  12 siblings, 1 reply; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:41 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

ROHM BD71828 Power management IC integrates 7 buck converters, 7 LDOs,
a real-time clock (RTC), 3 GPO/regulator control pins, HALL input
and a 32.768 kHz clock gate.

Document the dt bindings drivers are using.

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

No changes since v1

 .../bindings/mfd/rohm,bd71828-pmic.txt        | 180 ++++++++++++++++++
 1 file changed, 180 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt

diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
new file mode 100644
index 000000000000..125efa9f3de0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
@@ -0,0 +1,180 @@
+* ROHM BD71828 Power Management Integrated Circuit bindings
+
+BD71828GW is a single-chip power management IC for battery-powered portable
+devices. The IC integrates 7 buck converters, 7 LDOs, and a 1500 mA single-cell
+linear charger. Also included is a Coulomb counter, a real-time clock (RTC),
+and a 32.768 kHz clock gate.
+
+Required properties:
+ - compatible			: Should be "rohm,bd71828".
+ - reg				: I2C slave address.
+ - interrupt-parent		: Phandle to the parent interrupt controller.
+ - interrupts			: The interrupt line the device is connected to.
+ - clocks			: The parent clock connected to PMIC.
+ - #clock-cells			: Should be 0.
+ - regulators			: List of child nodes that specify the
+				  regulators. Please see
+				  ../regulator/rohm,bd71828-regulator.txt
+ - gpio-controller		: To indicate BD71828 acts as a GPIO controller.
+ - #gpio-cells			: Should be 2. The first cell is the pin number
+				  and the second cell is used to specify flags.
+				  See ../gpio/gpio.txt for more information.
+
+The BD71828 RUN state is divided into 4 configurable run-levels named RUN0,
+RUN1, RUN2 and RUN3. Bucks 1, 2, 6 and 7 can be either controlled individually
+via I2C, or some/all of them can be bound to run-levels and controlled as a
+group. If bucks are controlled individually these run-levels are ignored. See
+../regulator/rohm,bd71828-regulator.txt for how to define regulator voltages
+for run-levels. Run-levels can be changed by I2C or GPIO depending on PMIC's OTP
+configuration.
+
+Optional properties:
+- clock-output-names		: Should contain name for output clock.
+- rohm,dvs-vsel-gpios		: GPIOs used to control PMIC run-levels. Should
+				  describe two GPIOs. (See run-level control in
+				  data-sheet). If this property is omitted but
+				  some bucks are marked to be controlled by
+				  run-levels - then OTP option allowing
+				  run-level control via I2C is assumed.
+- gpio-reserved-ranges		: Usage of GPIO pins can be changed via OTP.
+				  This property can be used to mark the pins
+				  which should not be configured for GPIO.
+				  Please see the ../gpio/gpio.txt for more
+				  information.
+
+Example:
+
+        /* external oscillator node */
+        osc: oscillator {
+                compatible = "fixed-clock";
+                #clock-cells = <1>;
+                clock-frequency  = <32768>;
+                clock-output-names = "osc";
+        };
+
+	pmic: pmic@4b {
+		compatible = "rohm,bd71828";
+		reg = <0x4b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <29 GPIO_ACTIVE_LOW>;
+		clocks = <&osc 0>;
+		#clock-cells = <0>;
+		clock-output-names = "bd71828-32k-out";
+		gpio-controller;
+		#gpio-cells = <2>;
+		ngpios = <4>;
+		gpio-reserved-ranges = <0 1 2 1>;
+		gpio-line-names = "EPDEN";
+		rohm,dvs-vsel-gpios = <&gpio1 12 0>,
+				      <&gpio1 13 0>;
+		regulators {
+			buck1: BUCK1 {
+				regulator-name = "buck1";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <2500>;
+				rohm,dvs-runlvl-ctrl;
+				rohm,dvs-runlevel0-voltage = <500000>;
+				rohm,dvs-runlevel1-voltage = <506250>;
+				rohm,dvs-runlevel2-voltage = <512500>;
+				rohm,dvs-runlevel3-voltage = <518750>;
+				regulator-boot-on;
+			};
+			buck2: BUCK2 {
+				regulator-name = "buck2";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <2500>;
+				rohm,dvs-runlvl-ctrl;
+				rohm,dvs-runlevel0-voltage = <500000>;
+				rohm,dvs-runlevel1-voltage = <506250>;
+				rohm,dvs-runlevel2-voltage = <512500>;
+				rohm,dvs-runlevel3-voltage = <518750>;
+				regulator-boot-on;
+			};
+			buck3: BUCK3 {
+				regulator-name = "buck3";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-boot-on;
+			};
+			buck4: BUCK4 {
+				regulator-name = "buck4";
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+			};
+			buck5: BUCK5 {
+				regulator-name = "buck5";
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+			buck6: BUCK6 {
+				regulator-name = "buck6";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <2500>;
+				rohm,dvs-runlvl-ctrl;
+				rohm,dvs-runlevel0-voltage = <500000>;
+				rohm,dvs-runlevel1-voltage = <506250>;
+				rohm,dvs-runlevel2-voltage = <512500>;
+				rohm,dvs-runlevel3-voltage = <518750>;
+				regulator-boot-on;
+			};
+			buck7: BUCK7 {
+				regulator-name = "buck7";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <2000000>;
+				regulator-ramp-delay = <2500>;
+				rohm,dvs-runlvl-ctrl;
+				rohm,dvs-runlevel0-voltage = <500000>;
+				rohm,dvs-runlevel1-voltage = <506250>;
+				rohm,dvs-runlevel2-voltage = <512500>;
+				rohm,dvs-runlevel3-voltage = <518750>;
+				regulator-boot-on;
+			};
+			ldo1: LDO1 {
+				regulator-name = "ldo1";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+			ldo2: LDO2 {
+				regulator-name = "ldo2";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+			ldo3: LDO3 {
+				regulator-name = "ldo3";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+			ldo4: LDO4 {
+				regulator-name = "ldo4";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+			ldo5: LDO5 {
+				regulator-name = "ldo5";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+			ldo6: LDO6 {
+				regulator-name = "ldo6";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+			};
+			ldo7_reg: LDO7 {
+				regulator-name = "ldo7";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+			};
+		};
+	};
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 03/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
  2019-10-24 11:41 ` [RFC PATCH v2 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
  2019-10-24 11:41 ` [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
@ 2019-10-24 11:42 ` Matti Vaittinen
  2019-10-24 11:44 ` [RFC PATCH v2 04/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:42 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Document ROHM BD71828 PMIC regulator device tree bindings.

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

Only commit title changed since v1

 .../regulator/rohm,bd71828-regulator.txt      | 164 ++++++++++++++++++
 1 file changed, 164 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.txt b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.txt
new file mode 100644
index 000000000000..cf6a5123b98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.txt
@@ -0,0 +1,164 @@
+ROHM BD71828 Power Management Integrated Circuit regulator bindings
+
+Required properties:
+ - regulator-name: should be "buck1", ..., "buck7", and "ldo1", ..., "ldo7"
+
+List of regulators provided by this controller. BD71828 regulators node
+should be sub node of the BD71828 MFD node. See BD71828 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
+Regulator nodes should be named to BUCK_<number> and LDO_<number>. The
+definition for each of these nodes is defined using the standard
+binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for BD71828 regulator nodes are:
+BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7
+LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7
+
+Optional properties:
+- rohm,dvs-run-voltage		: PMIC default "RUN" state voltage in uV.
+				  See below table for bucks which support this.
+- rohm,dvs-idle-voltage		: PMIC default "IDLE" state voltage in uV.
+				  See below table for bucks which support this.
+- rohm,dvs-suspend-voltage	: PMIC default "SUSPEND" state voltage in uV.
+				  See below table for bucks which support this.
+- rohm,dvs-lpsr-voltage		: PMIC default "LPSR" state voltage in uV.
+- rohm,dvs-runlvl-ctrl		: buck control is done based on run-level.
+				  Regulator is not individually controllable.
+				  See ../mfd/rohm,bd71828-pmic.txt for how to
+				  specify run-level control mechanism. Only
+				  bucks 1, 2, 6 and 7 support this.
+- rohm,dvs-runlevel0-voltage    : voltage for run-level 0. Microvolts.
+- rohm,dvs-runlevel1-voltage	: voltage for run-level 1. Microvolts.
+- rohm,dvs-runlevel2-voltage	: voltage for run-level 2. Microvolts.
+- rohm,dvs-runlevel3-voltage	: voltage for run-level 3. Microvolts.
+
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Supported default DVS states:
+
+buck		| run		| idle		| suspend	| lpsr
+-----------------------------------------------------------------------------
+1, 2, 6, and 7	| supported	| supported	| 	supported (*)
+----------------------------------------------------------------------------
+3, 4, and 5	| 			supported (**)
+----------------------------------------------------------------------------
+(*)  LPSR and SUSPEND states use same voltage but both states have own enable /
+     disable settings. Voltage 0 can be specified for a state to make regulator
+     disabled on that state.
+(**) All states use same voltage but have own enable / disable settings. Voltage
+     0 can be specified for a state to make regulator disabled on that state.
+
+Example:
+regulators {
+	buck1: BUCK1 {
+		regulator-name = "buck1";
+		regulator-min-microvolt = <500000>;
+		regulator-max-microvolt = <2000000>;
+		regulator-ramp-delay = <2500>;
+		rohm,dvs-runlvl-ctrl;
+		rohm,dvs-runlevel0-voltage = <500000>;
+		rohm,dvs-runlevel1-voltage = <506250>;
+		rohm,dvs-runlevel2-voltage = <512500>;
+		rohm,dvs-runlevel3-voltage = <518750>;
+		regulator-boot-on;
+	};
+	buck2: BUCK2 {
+		regulator-name = "buck2";
+		regulator-min-microvolt = <500000>;
+		regulator-max-microvolt = <2000000>;
+		regulator-ramp-delay = <2500>;
+		rohm,dvs-runlvl-ctrl;
+		rohm,dvs-runlevel0-voltage = <500000>;
+		rohm,dvs-runlevel1-voltage = <506250>;
+		rohm,dvs-runlevel2-voltage = <512500>;
+		rohm,dvs-runlevel3-voltage = <518750>;
+		regulator-boot-on;
+	};
+	buck3: BUCK3 {
+		regulator-name = "buck3";
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <2000000>;
+		regulator-boot-on;
+	};
+	buck4: BUCK4 {
+		regulator-name = "buck4";
+		regulator-min-microvolt = <1000000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-boot-on;
+	};
+	buck5: BUCK5 {
+		regulator-name = "buck5";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+	buck6: BUCK6 {
+		regulator-name = "buck6";
+		regulator-min-microvolt = <500000>;
+		regulator-max-microvolt = <2000000>;
+		regulator-ramp-delay = <2500>;
+		rohm,dvs-runlvl-ctrl;
+		rohm,dvs-runlevel0-voltage = <500000>;
+		rohm,dvs-runlevel1-voltage = <506250>;
+		rohm,dvs-runlevel2-voltage = <512500>;
+		rohm,dvs-runlevel3-voltage = <518750>;
+		regulator-boot-on;
+	};
+	buck7: BUCK7 {
+		regulator-name = "buck7";
+		regulator-min-microvolt = <500000>;
+		regulator-max-microvolt = <2000000>;
+		regulator-ramp-delay = <2500>;
+		rohm,dvs-runlvl-ctrl;
+		rohm,dvs-runlevel0-voltage = <500000>;
+		rohm,dvs-runlevel1-voltage = <506250>;
+		rohm,dvs-runlevel2-voltage = <512500>;
+		rohm,dvs-runlevel3-voltage = <518750>;
+		regulator-boot-on;
+	};
+	ldo1: LDO1 {
+		regulator-name = "ldo1";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+	ldo2: LDO2 {
+		regulator-name = "ldo2";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+	ldo3: LDO3 {
+		regulator-name = "ldo3";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+	ldo4: LDO4 {
+		regulator-name = "ldo4";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+	ldo5: LDO5 {
+		regulator-name = "ldo5";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+	ldo6: LDO6 {
+		regulator-name = "ldo6";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-boot-on;
+	};
+	ldo7_reg: LDO7 {
+		regulator-name = "ldo7";
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+};
+
+
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 04/13] mfd: input: bd71828: Add power-key support
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (2 preceding siblings ...)
  2019-10-24 11:42 ` [RFC PATCH v2 03/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
@ 2019-10-24 11:44 ` Matti Vaittinen
  2019-10-24 11:44 ` [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
                   ` (8 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:44 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc, Dmitry Torokhov

Use gpio_keys to send power input-event to user-space when power
button (short) press is detected.

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

No changes since v1

 drivers/mfd/rohm-bd71828.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
index b7de79e1fcdb..f77ba1ec3e99 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -4,7 +4,9 @@
 //
 // ROHM BD71828 PMIC driver
 
+#include <linux/gpio_keys.h>
 #include <linux/i2c.h>
+#include <linux/input.h>
 #include <linux/interrupt.h>
 #include <linux/ioport.h>
 #include <linux/irq.h>
@@ -15,6 +17,18 @@
 #include <linux/regmap.h>
 #include <linux/types.h>
 
+static struct gpio_keys_button button = {
+	.code = KEY_POWER,
+	.gpio = -1,
+	.type = EV_KEY,
+};
+
+static struct gpio_keys_platform_data bd71828_powerkey_data = {
+	.buttons = &button,
+	.nbuttons = 1,
+	.name = "bd71828-pwrkey",
+};
+
 static const struct resource rtc_irqs[] = {
 	DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC0, "bd71828-rtc-alm-0"),
 	DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC1, "bd71828-rtc-alm-1"),
@@ -36,6 +50,10 @@ static struct mfd_cell bd71828_mfd_cells[] = {
 		.name = "bd70528-rtc",
 		.resources = rtc_irqs,
 		.num_resources = ARRAY_SIZE(rtc_irqs),
+	}, {
+		.name = "gpio-keys",
+		.platform_data = &bd71828_powerkey_data,
+		.pdata_size = sizeof(bd71828_powerkey_data),
 	},
 };
 
@@ -288,9 +306,19 @@ static int bd71828_i2c_probe(struct i2c_client *i2c,
 		dev_err(&i2c->dev, "Failed to add IRQ chip\n");
 		return ret;
 	}
+
 	dev_dbg(&i2c->dev, "Registered %d IRQs for chip\n",
 		bd71828_irq_chip.num_irqs);
 
+	ret = regmap_irq_get_virq(irq_data, BD71828_INT_SHORTPUSH);
+
+	if (ret < 0) {
+		dev_err(&i2c->dev, "Failed to get the power-key IRQ\n");
+		return ret;
+	}
+
+	button.irq = ret;
+
 	ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO,
 				   bd71828_mfd_cells,
 				   ARRAY_SIZE(bd71828_mfd_cells), NULL, 0,
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (3 preceding siblings ...)
  2019-10-24 11:44 ` [RFC PATCH v2 04/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
@ 2019-10-24 11:44 ` Matti Vaittinen
  2019-10-28 23:32   ` Stephen Boyd
  2019-10-24 11:45 ` [RFC PATCH v2 06/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
                   ` (7 subsequent siblings)
  12 siblings, 1 reply; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:44 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

BD71828GW is a single-chip power management IC for battery-powered portable
devices. Add support for controlling BD71828 clk using bd718x7 driver.

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

No changes since v1

 drivers/clk/Kconfig       |  6 +++---
 drivers/clk/clk-bd718x7.c | 15 ++++++++++-----
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 801fa1cd0321..1d61d94cdb29 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -302,10 +302,10 @@ config COMMON_CLK_STM32H7
 	  Support for stm32h7 SoC family clocks
 
 config COMMON_CLK_BD718XX
-	tristate "Clock driver for ROHM BD718x7 PMIC"
-	depends on MFD_ROHM_BD718XX || MFD_ROHM_BD70528
+	tristate "Clock driver for 32K clk gates on ROHM PMICs"
+	depends on MFD_ROHM_BD718XX || MFD_ROHM_BD70528 || MFD_ROHM_BD71828
 	help
-	  This driver supports ROHM BD71837, ROHM BD71847 and
+	  This driver supports ROHM BD71837, ROHM BD71847, ROHM BD71828 and
 	  ROHM BD70528 PMICs clock gates.
 
 config COMMON_CLK_FIXED_MMIO
diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index ae6e5baee330..d17a19e04592 100644
--- a/drivers/clk/clk-bd718x7.c
+++ b/drivers/clk/clk-bd718x7.c
@@ -8,6 +8,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/mfd/rohm-bd718x7.h>
+#include <linux/mfd/rohm-bd71828.h>
 #include <linux/mfd/rohm-bd70528.h>
 #include <linux/clk-provider.h>
 #include <linux/clkdev.h>
@@ -21,10 +22,8 @@ struct bd718xx_clk {
 	struct rohm_regmap_dev *mfd;
 };
 
-static int bd71837_clk_set(struct clk_hw *hw, int status)
+static int bd71837_clk_set(struct bd718xx_clk *c, int status)
 {
-	struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
-
 	return regmap_update_bits(c->mfd->regmap, c->reg, c->mask, status);
 }
 
@@ -33,14 +32,16 @@ static void bd71837_clk_disable(struct clk_hw *hw)
 	int rv;
 	struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
 
-	rv = bd71837_clk_set(hw, 0);
+	rv = bd71837_clk_set(c, 0);
 	if (rv)
 		dev_dbg(&c->pdev->dev, "Failed to disable 32K clk (%d)\n", rv);
 }
 
 static int bd71837_clk_enable(struct clk_hw *hw)
 {
-	return bd71837_clk_set(hw, 1);
+	struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
+
+	return bd71837_clk_set(c, 0xffffffff);
 }
 
 static int bd71837_clk_is_enabled(struct clk_hw *hw)
@@ -93,6 +94,10 @@ static int bd71837_clk_probe(struct platform_device *pdev)
 		c->reg = BD718XX_REG_OUT32K;
 		c->mask = BD718XX_OUT32K_EN;
 		break;
+	case ROHM_CHIP_TYPE_BD71828:
+		c->reg = BD71828_REG_OUT32K;
+		c->mask = BD71828_OUT32K_EN;
+		break;
 	case ROHM_CHIP_TYPE_BD70528:
 		c->reg = BD70528_REG_CLK_OUT;
 		c->mask = BD70528_CLK_OUT_EN_MASK;
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 06/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (4 preceding siblings ...)
  2019-10-24 11:44 ` [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
@ 2019-10-24 11:45 ` Matti Vaittinen
  2019-10-24 11:46 ` [RFC PATCH v2 07/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
                   ` (6 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:45 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Few ROHM PMICs allow setting the voltage states for different system states
like RUN, IDLE, SUSPEND and LPSR. States are then changed via SoC specific
mechanisms. bd718x7 driver implemented device-tree parsing functions for
these state specific voltages. The parsing functions can be re-used by
other ROHM chip drivers like bd71828. Split the generic functions from
bd718x7-regulator.c to rohm-regulator.c and export them for other modules
to use.

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

No changes since v1

 drivers/regulator/Kconfig             |   4 +
 drivers/regulator/Makefile            |   1 +
 drivers/regulator/bd718x7-regulator.c | 183 ++++++++------------------
 drivers/regulator/rohm-regulator.c    |  95 +++++++++++++
 include/linux/mfd/rohm-generic.h      |  44 +++++++
 5 files changed, 199 insertions(+), 128 deletions(-)
 create mode 100644 drivers/regulator/rohm-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index b57093d7c01f..74de76bf98d7 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -196,6 +196,7 @@ config REGULATOR_BD70528
 config REGULATOR_BD718XX
 	tristate "ROHM BD71837 Power Regulator"
 	depends on MFD_ROHM_BD718XX
+	select REGULATOR_ROHM
 	help
 	  This driver supports voltage regulators on ROHM BD71837 PMIC.
 	  This will enable support for the software controllable buck
@@ -780,6 +781,9 @@ config REGULATOR_RN5T618
 	  Say y here to support the regulators found on Ricoh RN5T567,
 	  RN5T618 or RC5T619 PMIC.
 
+config REGULATOR_ROHM
+	tristate
+
 config REGULATOR_RT5033
 	tristate "Richtek RT5033 Regulators"
 	depends on MFD_RT5033
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index eef73b5a35a4..41e4055d2d66 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_RC5T583)  += rc5t583-regulator.o
 obj-$(CONFIG_REGULATOR_RK808)   += rk808-regulator.o
 obj-$(CONFIG_REGULATOR_RN5T618) += rn5t618-regulator.o
+obj-$(CONFIG_REGULATOR_ROHM)	+= rohm-regulator.o
 obj-$(CONFIG_REGULATOR_RT5033)	+= rt5033-regulator.o
 obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
 obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/regulator/bd718x7-regulator.c
index bdab46a5c461..2dcb010a626c 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -318,6 +318,7 @@ struct reg_init {
 };
 struct bd718xx_regulator_data {
 	struct regulator_desc desc;
+	const struct rohm_dvs_config dvs;
 	const struct reg_init init;
 	const struct reg_init *additional_inits;
 	int additional_init_amnt;
@@ -349,133 +350,15 @@ static const struct reg_init bd71837_ldo6_inits[] = {
 	},
 };
 
-#define NUM_DVS_BUCKS 4
-
-struct of_dvs_setting {
-	const char *prop;
-	unsigned int reg;
-};
-
-static int set_dvs_levels(const struct of_dvs_setting *dvs,
-			  struct device_node *np,
-			  const struct regulator_desc *desc,
-			  struct regmap *regmap)
-{
-	int ret, i;
-	unsigned int uv;
-
-	ret = of_property_read_u32(np, dvs->prop, &uv);
-	if (ret) {
-		if (ret != -EINVAL)
-			return ret;
-		return 0;
-	}
-
-	for (i = 0; i < desc->n_voltages; i++) {
-		ret = regulator_desc_list_voltage_linear_range(desc, i);
-		if (ret < 0)
-			continue;
-		if (ret == uv) {
-			i <<= ffs(desc->vsel_mask) - 1;
-			ret = regmap_update_bits(regmap, dvs->reg,
-						 DVS_BUCK_RUN_MASK, i);
-			break;
-		}
-	}
-	return ret;
-}
-
-static int buck4_set_hw_dvs_levels(struct device_node *np,
+static int buck_set_hw_dvs_levels(struct device_node *np,
 			    const struct regulator_desc *desc,
 			    struct regulator_config *cfg)
 {
-	int ret, i;
-	const struct of_dvs_setting dvs[] = {
-		{
-			.prop = "rohm,dvs-run-voltage",
-			.reg = BD71837_REG_BUCK4_VOLT_RUN,
-		},
-	};
+	struct bd718xx_regulator_data *data;
 
-	for (i = 0; i < ARRAY_SIZE(dvs); i++) {
-		ret = set_dvs_levels(&dvs[i], np, desc, cfg->regmap);
-		if (ret)
-			break;
-	}
-	return ret;
-}
-static int buck3_set_hw_dvs_levels(struct device_node *np,
-			    const struct regulator_desc *desc,
-			    struct regulator_config *cfg)
-{
-	int ret, i;
-	const struct of_dvs_setting dvs[] = {
-		{
-			.prop = "rohm,dvs-run-voltage",
-			.reg = BD71837_REG_BUCK3_VOLT_RUN,
-		},
-	};
+	data = container_of(desc, struct bd718xx_regulator_data, desc);
 
-	for (i = 0; i < ARRAY_SIZE(dvs); i++) {
-		ret = set_dvs_levels(&dvs[i], np, desc, cfg->regmap);
-		if (ret)
-			break;
-	}
-	return ret;
-}
-
-static int buck2_set_hw_dvs_levels(struct device_node *np,
-			    const struct regulator_desc *desc,
-			    struct regulator_config *cfg)
-{
-	int ret, i;
-	const struct of_dvs_setting dvs[] = {
-		{
-			.prop = "rohm,dvs-run-voltage",
-			.reg = BD718XX_REG_BUCK2_VOLT_RUN,
-		},
-		{
-			.prop = "rohm,dvs-idle-voltage",
-			.reg = BD718XX_REG_BUCK2_VOLT_IDLE,
-		},
-	};
-
-
-
-	for (i = 0; i < ARRAY_SIZE(dvs); i++) {
-		ret = set_dvs_levels(&dvs[i], np, desc, cfg->regmap);
-		if (ret)
-			break;
-	}
-	return ret;
-}
-
-static int buck1_set_hw_dvs_levels(struct device_node *np,
-			    const struct regulator_desc *desc,
-			    struct regulator_config *cfg)
-{
-	int ret, i;
-	const struct of_dvs_setting dvs[] = {
-		{
-			.prop = "rohm,dvs-run-voltage",
-			.reg = BD718XX_REG_BUCK1_VOLT_RUN,
-		},
-		{
-			.prop = "rohm,dvs-idle-voltage",
-			.reg = BD718XX_REG_BUCK1_VOLT_IDLE,
-		},
-		{
-			.prop = "rohm,dvs-suspend-voltage",
-			.reg = BD718XX_REG_BUCK1_VOLT_SUSP,
-		},
-	};
-
-	for (i = 0; i < ARRAY_SIZE(dvs); i++) {
-		ret = set_dvs_levels(&dvs[i], np, desc, cfg->regmap);
-		if (ret)
-			break;
-	}
-	return ret;
+	return rohm_regulator_set_dvs_levels(&data->dvs, np, desc, cfg->regmap);
 }
 
 static const struct bd718xx_regulator_data bd71847_regulators[] = {
@@ -496,7 +379,17 @@ static const struct bd718xx_regulator_data bd71847_regulators[] = {
 			.enable_reg = BD718XX_REG_BUCK1_CTRL,
 			.enable_mask = BD718XX_BUCK_EN,
 			.owner = THIS_MODULE,
-			.of_parse_cb = buck1_set_hw_dvs_levels,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND,
+			.run_reg = BD718XX_REG_BUCK1_VOLT_RUN,
+			.run_mask = DVS_BUCK_RUN_MASK,
+			.idle_reg = BD718XX_REG_BUCK1_VOLT_IDLE,
+			.idle_mask = DVS_BUCK_RUN_MASK,
+			.suspend_reg = BD718XX_REG_BUCK1_VOLT_SUSP,
+			.suspend_mask = DVS_BUCK_RUN_MASK,
 		},
 		.init = {
 			.reg = BD718XX_REG_BUCK1_CTRL,
@@ -520,7 +413,14 @@ static const struct bd718xx_regulator_data bd71847_regulators[] = {
 			.enable_reg = BD718XX_REG_BUCK2_CTRL,
 			.enable_mask = BD718XX_BUCK_EN,
 			.owner = THIS_MODULE,
-			.of_parse_cb = buck2_set_hw_dvs_levels,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE,
+			.run_reg = BD718XX_REG_BUCK2_VOLT_RUN,
+			.run_mask = DVS_BUCK_RUN_MASK,
+			.idle_reg = BD718XX_REG_BUCK2_VOLT_IDLE,
+			.idle_mask = DVS_BUCK_RUN_MASK,
 		},
 		.init = {
 			.reg = BD718XX_REG_BUCK2_CTRL,
@@ -792,7 +692,17 @@ static const struct bd718xx_regulator_data bd71837_regulators[] = {
 			.enable_reg = BD718XX_REG_BUCK1_CTRL,
 			.enable_mask = BD718XX_BUCK_EN,
 			.owner = THIS_MODULE,
-			.of_parse_cb = buck1_set_hw_dvs_levels,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND,
+			.run_reg = BD718XX_REG_BUCK1_VOLT_RUN,
+			.run_mask = DVS_BUCK_RUN_MASK,
+			.idle_reg = BD718XX_REG_BUCK1_VOLT_IDLE,
+			.idle_mask = DVS_BUCK_RUN_MASK,
+			.suspend_reg = BD718XX_REG_BUCK1_VOLT_SUSP,
+			.suspend_mask = DVS_BUCK_RUN_MASK,
 		},
 		.init = {
 			.reg = BD718XX_REG_BUCK1_CTRL,
@@ -816,7 +726,14 @@ static const struct bd718xx_regulator_data bd71837_regulators[] = {
 			.enable_reg = BD718XX_REG_BUCK2_CTRL,
 			.enable_mask = BD718XX_BUCK_EN,
 			.owner = THIS_MODULE,
-			.of_parse_cb = buck2_set_hw_dvs_levels,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE,
+			.run_reg = BD718XX_REG_BUCK2_VOLT_RUN,
+			.run_mask = DVS_BUCK_RUN_MASK,
+			.idle_reg = BD718XX_REG_BUCK2_VOLT_IDLE,
+			.idle_mask = DVS_BUCK_RUN_MASK,
 		},
 		.init = {
 			.reg = BD718XX_REG_BUCK2_CTRL,
@@ -840,7 +757,12 @@ static const struct bd718xx_regulator_data bd71837_regulators[] = {
 			.enable_reg = BD71837_REG_BUCK3_CTRL,
 			.enable_mask = BD718XX_BUCK_EN,
 			.owner = THIS_MODULE,
-			.of_parse_cb = buck3_set_hw_dvs_levels,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN,
+			.run_reg = BD71837_REG_BUCK3_VOLT_RUN,
+			.run_mask = DVS_BUCK_RUN_MASK,
 		},
 		.init = {
 			.reg = BD71837_REG_BUCK3_CTRL,
@@ -864,7 +786,12 @@ static const struct bd718xx_regulator_data bd71837_regulators[] = {
 			.enable_reg = BD71837_REG_BUCK4_CTRL,
 			.enable_mask = BD718XX_BUCK_EN,
 			.owner = THIS_MODULE,
-			.of_parse_cb = buck4_set_hw_dvs_levels,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN,
+			.run_reg = BD71837_REG_BUCK4_VOLT_RUN,
+			.run_mask = DVS_BUCK_RUN_MASK,
 		},
 		.init = {
 			.reg = BD71837_REG_BUCK4_CTRL,
diff --git a/drivers/regulator/rohm-regulator.c b/drivers/regulator/rohm-regulator.c
new file mode 100644
index 000000000000..ca368ada53c6
--- /dev/null
+++ b/drivers/regulator/rohm-regulator.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 ROHM Semiconductors
+
+#include <linux/errno.h>
+#include <linux/mfd/rohm-generic.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+
+static int set_dvs_level(const struct regulator_desc *desc,
+			 struct device_node *np, struct regmap *regmap,
+			 char *prop, unsigned int reg, unsigned int mask,
+			 unsigned int omask, unsigned int oreg)
+{
+	int ret, i;
+	uint32_t uv;
+
+	ret = of_property_read_u32(np, prop, &uv);
+	if (ret) {
+		if (ret != -EINVAL)
+			return ret;
+		return 0;
+	}
+
+	if (uv == 0) {
+		if (omask)
+			return regmap_update_bits(regmap, oreg, omask, 0);
+	}
+	for (i = 0; i < desc->n_voltages; i++) {
+		ret = regulator_desc_list_voltage_linear_range(desc, i);
+		if (ret < 0)
+			continue;
+		if (ret == uv) {
+			i <<= ffs(desc->vsel_mask) - 1;
+			ret = regmap_update_bits(regmap, reg, mask, i);
+			if (omask && !ret)
+				ret = regmap_update_bits(regmap, oreg, omask,
+							 omask);
+			break;
+		}
+	}
+	return ret;
+}
+
+int rohm_regulator_set_dvs_levels(const struct rohm_dvs_config *dvs,
+			  struct device_node *np,
+			  const struct regulator_desc *desc,
+			  struct regmap *regmap)
+{
+	int i, ret = 0;
+	char *prop;
+	unsigned int reg, mask, omask, oreg = desc->enable_reg;
+
+	for (i = 0; i < ROHM_DVS_LEVEL_MAX && !ret; i++) {
+		if (dvs->level_map & (1 << i)) {
+			switch (i + 1) {
+			case ROHM_DVS_LEVEL_RUN:
+				prop = "rohm,dvs-run-voltage";
+				reg = dvs->run_reg;
+				mask = dvs->run_mask;
+				omask = dvs->run_on_mask;
+				break;
+			case ROHM_DVS_LEVEL_IDLE:
+				prop = "rohm,dvs-idle-voltage";
+				reg = dvs->idle_reg;
+				mask = dvs->idle_mask;
+				omask = dvs->idle_on_mask;
+				break;
+			case ROHM_DVS_LEVEL_SUSPEND:
+				prop = "rohm,dvs-suspend-voltage";
+				reg = dvs->suspend_reg;
+				mask = dvs->suspend_mask;
+				omask = dvs->suspend_on_mask;
+				break;
+			case ROHM_DVS_LEVEL_LPSR:
+				prop = "rohm,dvs-lpsr-voltage";
+				reg = dvs->lpsr_reg;
+				mask = dvs->lpsr_mask;
+				omask = dvs->lpsr_on_mask;
+				break;
+			default:
+				return -EINVAL;
+			}
+			ret = set_dvs_level(desc, np, regmap, prop, reg, mask,
+					    omask, oreg);
+		}
+	}
+	return ret;
+}
+EXPORT_SYMBOL(rohm_regulator_set_dvs_levels);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("Generic helpers for ROHM PMIC regulator drivers");
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index b280f3100d6c..86397b42e9bf 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -4,6 +4,9 @@
 #ifndef __LINUX_MFD_ROHM_H__
 #define __LINUX_MFD_ROHM_H__
 
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+
 enum {
 	ROHM_CHIP_TYPE_BD71837 = 0,
 	ROHM_CHIP_TYPE_BD71847,
@@ -18,4 +21,45 @@ struct rohm_regmap_dev {
 	struct regmap *regmap;
 };
 
+enum {
+	ROHM_DVS_LEVEL_UNKNOWN,
+	ROHM_DVS_LEVEL_RUN,
+	ROHM_DVS_LEVEL_IDLE,
+	ROHM_DVS_LEVEL_SUSPEND,
+	ROHM_DVS_LEVEL_LPSR,
+#define ROHM_DVS_LEVEL_MAX ROHM_DVS_LEVEL_LPSR
+};
+
+struct rohm_dvs_config {
+	uint64_t level_map;
+	unsigned int run_reg;
+	unsigned int run_mask;
+	unsigned int run_on_mask;
+	unsigned int idle_reg;
+	unsigned int idle_mask;
+	unsigned int idle_on_mask;
+	unsigned int suspend_reg;
+	unsigned int suspend_mask;
+	unsigned int suspend_on_mask;
+	unsigned int lpsr_reg;
+	unsigned int lpsr_mask;
+	unsigned int lpsr_on_mask;
+};
+
+#if IS_ENABLED(CONFIG_REGULATOR_ROHM)
+int rohm_regulator_set_dvs_levels(const struct rohm_dvs_config *dvs,
+				  struct device_node *np,
+				  const struct regulator_desc *desc,
+				  struct regmap *regmap);
+
+#else
+static inline int rohm_regulator_set_dvs_levels(const struct rohm_dvs_config *dvs,
+						struct device_node *np,
+						const struct regulator_desc *desc,
+						struct regmap *regmap)
+{
+	return 0;
+}
+#endif //IS_ENABLED(CONFIG_REGULATOR_ROHM)
+
 #endif
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 07/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (5 preceding siblings ...)
  2019-10-24 11:45 ` [RFC PATCH v2 06/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
@ 2019-10-24 11:46 ` Matti Vaittinen
  2019-10-24 11:46 ` [RFC PATCH v2 08/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
                   ` (5 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:46 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

ROHM BD71828 is a power management IC containing 7 bucks and 7 LDOs. Bucks
1,2,6 and 7 can be assigned to a regulator group controlled by run-levels.
Eg. Voltages and enable/disable statuses for specific run-levels (run0 to
run3) can be set via register interface and run level changes can then be
done either via I2C or GPIO.

This initial commit does not support assigning bucks to be controlled via
run-levels but only allows them to be individually controlled.

LDO5 voltage can also be controlled by GPIO2 pin and register interfaces
but this driver only supports the control via register.

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

Only MODULE_ALIAS added since v1

 drivers/regulator/Kconfig             |  12 +
 drivers/regulator/Makefile            |   1 +
 drivers/regulator/bd71828-regulator.c | 833 ++++++++++++++++++++++++++
 3 files changed, 846 insertions(+)
 create mode 100644 drivers/regulator/bd71828-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 74de76bf98d7..8c94a35d059a 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -193,6 +193,18 @@ config REGULATOR_BD70528
 	  This driver can also be built as a module. If so, the module
 	  will be called bd70528-regulator.
 
+config REGULATOR_BD71828
+	tristate "ROHM BD71828 Power Regulator"
+	depends on MFD_ROHM_BD71828
+	select REGULATOR_ROHM
+	help
+	  This driver supports voltage regulators on ROHM BD71828 PMIC.
+	  This will enable support for the software controllable buck
+	  and LDO regulators.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called bd71828-regulator.
+
 config REGULATOR_BD718XX
 	tristate "ROHM BD71837 Power Regulator"
 	depends on MFD_ROHM_BD718XX
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 41e4055d2d66..b363b592a429 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
 obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
 obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
 obj-$(CONFIG_REGULATOR_BD70528) += bd70528-regulator.o
+obj-$(CONFIG_REGULATOR_BD71828) += bd71828-regulator.o
 obj-$(CONFIG_REGULATOR_BD718XX) += bd718x7-regulator.o
 obj-$(CONFIG_REGULATOR_BD9571MWV) += bd9571mwv-regulator.o
 obj-$(CONFIG_REGULATOR_DA903X)	+= da903x.o
diff --git a/drivers/regulator/bd71828-regulator.c b/drivers/regulator/bd71828-regulator.c
new file mode 100644
index 000000000000..3f46658280be
--- /dev/null
+++ b/drivers/regulator/bd71828-regulator.c
@@ -0,0 +1,833 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2019 ROHM Semiconductors
+// bd71828-regulator.c ROHM BD71828GW-DS1 regulator driver
+//
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/rohm-bd71828.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
+
+struct reg_init {
+	unsigned int reg;
+	unsigned int mask;
+	unsigned int val;
+};
+struct bd71828_regulator_data {
+	struct regulator_desc desc;
+	const struct rohm_dvs_config dvs;
+	const struct reg_init *reg_inits;
+	int reg_init_amnt;
+};
+
+static const struct reg_init buck1_inits[] = {
+	/*
+	 * DVS Buck voltages can be changed by register values or via GPIO.
+	 * Use register accesses by default.
+	 */
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK1_CTRL,
+		.val = BD71828_DVS_BUCK1_CTRL_I2C,
+	},
+};
+
+static const struct reg_init buck2_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK2_CTRL,
+		.val = BD71828_DVS_BUCK2_CTRL_I2C,
+	},
+};
+
+static const struct reg_init buck6_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK6_CTRL,
+		.val = BD71828_DVS_BUCK6_CTRL_I2C,
+	},
+};
+
+static const struct reg_init buck7_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK7_CTRL,
+		.val = BD71828_DVS_BUCK7_CTRL_I2C,
+	},
+};
+
+static const struct regulator_linear_range bd71828_buck1267_volts[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0x00, 0xef, 6250),
+	REGULATOR_LINEAR_RANGE(2000000, 0xf0, 0xff, 0),
+};
+
+static const struct regulator_linear_range bd71828_buck3_volts[] = {
+	REGULATOR_LINEAR_RANGE(1200000, 0x00, 0x0f, 50000),
+	REGULATOR_LINEAR_RANGE(2000000, 0x10, 0x1f, 0),
+};
+
+static const struct regulator_linear_range bd71828_buck4_volts[] = {
+	REGULATOR_LINEAR_RANGE(1000000, 0x00, 0x1f, 25000),
+	REGULATOR_LINEAR_RANGE(1800000, 0x20, 0x3f, 0),
+};
+
+static const struct regulator_linear_range bd71828_buck5_volts[] = {
+	REGULATOR_LINEAR_RANGE(2500000, 0x00, 0x0f, 50000),
+	REGULATOR_LINEAR_RANGE(3300000, 0x10, 0x1f, 0),
+};
+
+static const struct regulator_linear_range bd71828_ldo_volts[] = {
+	REGULATOR_LINEAR_RANGE(800000, 0x00, 0x31, 50000),
+	REGULATOR_LINEAR_RANGE(3300000, 0x32, 0x3f, 0),
+};
+
+static int ramp_delay_supported(struct regulator_dev *rdev)
+{
+	switch (rdev->desc->id) {
+	case BD71828_BUCK1:
+	case BD71828_BUCK2:
+	case BD71828_BUCK6:
+	case BD71828_BUCK7:
+		return 1;
+	default:
+		break;
+	}
+	return 0;
+}
+
+static int bd71828_set_ramp_delay(struct regulator_dev *rdev, int ramp_delay)
+{
+	unsigned int val;
+
+	if (!ramp_delay_supported(rdev)) {
+		dev_err(&rdev->dev, "%s: can't set ramp-delay\n",
+			rdev->desc->name);
+		return -EINVAL;
+	}
+
+	switch (ramp_delay) {
+	case 1 ... 2500:
+		val = 0;
+		break;
+	case 2501 ... 5000:
+		val = 1;
+		break;
+	case 5001 ... 10000:
+		val = 2;
+		break;
+	case 10001 ... 20000:
+		val = 3;
+		break;
+	default:
+		val = 3;
+		dev_err(&rdev->dev,
+			"ramp_delay: %d not supported, setting 20mV/uS",
+			 ramp_delay);
+	}
+
+	/*
+	 * On BD71828 the ramp delay level control reg is at offset +2 to
+	 * enable reg
+	 */
+	return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg + 2,
+				  BD71828_MASK_RAMP_DELAY,
+				  val << (ffs(BD71828_MASK_RAMP_DELAY) - 1));
+
+}
+
+static int buck_set_hw_dvs_levels(struct device_node *np,
+				  const struct regulator_desc *desc,
+				  struct regulator_config *cfg)
+{
+	struct bd71828_regulator_data *data;
+
+	data = container_of(desc, struct bd71828_regulator_data, desc);
+
+	return rohm_regulator_set_dvs_levels(&data->dvs, np, desc, cfg->regmap);
+}
+
+static int ldo6_parse_dt(struct device_node *np,
+			 const struct regulator_desc *desc,
+			 struct regulator_config *cfg)
+{
+	int ret, i;
+	uint32_t uv = 0;
+	unsigned int en;
+	struct regmap *regmap = cfg->regmap;
+	static const char * const props[] = { "rohm,dvs-run-voltage",
+					      "rohm,dvs-idle-voltage",
+					      "rohm,dvs-suspend-voltage",
+					      "rohm,dvs-lpsr-voltage" };
+	unsigned int mask[] = { BD71828_MASK_RUN_EN, BD71828_MASK_IDLE_EN,
+			       BD71828_MASK_SUSP_EN, BD71828_MASK_LPSR_EN };
+
+	for (i = 0; i < ARRAY_SIZE(props); i++) {
+		ret = of_property_read_u32(np, props[i], &uv);
+		if (ret) {
+			if (ret != -EINVAL)
+				return ret;
+			continue;
+		}
+		if (uv)
+			en = 0xffffffff;
+		else
+			en = 0;
+
+		ret = regmap_update_bits(regmap, desc->enable_reg, mask[i], en);
+		if (ret)
+			return ret;
+	}
+	return 0;
+}
+
+static const struct regulator_ops bd71828_buck_ops = {
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.list_voltage = regulator_list_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+};
+
+static const struct regulator_ops bd71828_dvs_buck_ops = {
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.list_voltage = regulator_list_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.set_ramp_delay = bd71828_set_ramp_delay,
+};
+
+static const struct regulator_ops bd71828_ldo_ops = {
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.list_voltage = regulator_list_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+};
+
+static int bd71828_ldo6_get_voltage(struct regulator_dev *rdev)
+{
+	return BD71828_LDO_6_VOLTAGE;
+}
+
+static const struct regulator_ops bd71828_ldo6_ops = {
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.get_voltage = bd71828_ldo6_get_voltage,
+	.is_enabled = regulator_is_enabled_regmap,
+};
+
+static const struct bd71828_regulator_data bd71828_rdata[] = {
+	{
+		.desc = {
+			.name = "buck1",
+			.of_match = of_match_ptr("BUCK1"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK1,
+			.ops = &bd71828_dvs_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck1267_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck1267_volts),
+			.n_voltages = BD71828_BUCK1267_VOLTS,
+			.enable_reg = BD71828_REG_BUCK1_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK1_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK1267_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK1_VOLT,
+			.run_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_reg = BD71828_REG_BUCK1_IDLE_VOLT,
+			.idle_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_reg = BD71828_REG_BUCK1_SUSP_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK1267_VOLT,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+			/*
+			 * LPSR voltage is same as SUSPEND voltage. Allow
+			 * setting it so that regulator can be set enabled at
+			 * LPSR state
+			 */
+			.lpsr_reg = BD71828_REG_BUCK1_SUSP_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK1267_VOLT,
+		},
+		.reg_inits = buck1_inits,
+		.reg_init_amnt = ARRAY_SIZE(buck1_inits),
+	},
+	{
+		.desc = {
+			.name = "buck2",
+			.of_match = of_match_ptr("BUCK2"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK2,
+			.ops = &bd71828_dvs_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck1267_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck1267_volts),
+			.n_voltages = BD71828_BUCK1267_VOLTS,
+			.enable_reg = BD71828_REG_BUCK2_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK2_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK1267_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK2_VOLT,
+			.run_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_reg = BD71828_REG_BUCK2_IDLE_VOLT,
+			.idle_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_reg = BD71828_REG_BUCK2_SUSP_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK1267_VOLT,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+			.lpsr_reg = BD71828_REG_BUCK2_SUSP_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK1267_VOLT,
+		},
+		.reg_inits = buck2_inits,
+		.reg_init_amnt = ARRAY_SIZE(buck2_inits),
+	},
+	{
+		.desc = {
+			.name = "buck3",
+			.of_match = of_match_ptr("BUCK3"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK3,
+			.ops = &bd71828_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck3_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck3_volts),
+			.n_voltages = BD71828_BUCK3_VOLTS,
+			.enable_reg = BD71828_REG_BUCK3_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK3_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK3_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * BUCK3 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK3_VOLT,
+			.idle_reg = BD71828_REG_BUCK3_VOLT,
+			.suspend_reg = BD71828_REG_BUCK3_VOLT,
+			.lpsr_reg = BD71828_REG_BUCK3_VOLT,
+			.run_mask = BD71828_MASK_BUCK3_VOLT,
+			.idle_mask = BD71828_MASK_BUCK3_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK3_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK3_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+	},
+	{
+		.desc = {
+			.name = "buck4",
+			.of_match = of_match_ptr("BUCK4"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK4,
+			.ops = &bd71828_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck4_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck4_volts),
+			.n_voltages = BD71828_BUCK4_VOLTS,
+			.enable_reg = BD71828_REG_BUCK4_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK4_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK4_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * BUCK4 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK4_VOLT,
+			.idle_reg = BD71828_REG_BUCK4_VOLT,
+			.suspend_reg = BD71828_REG_BUCK4_VOLT,
+			.lpsr_reg = BD71828_REG_BUCK4_VOLT,
+			.run_mask = BD71828_MASK_BUCK4_VOLT,
+			.idle_mask = BD71828_MASK_BUCK4_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK4_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK4_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+	},
+	{
+		.desc = {
+			.name = "buck5",
+			.of_match = of_match_ptr("BUCK5"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK5,
+			.ops = &bd71828_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck5_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck5_volts),
+			.n_voltages = BD71828_BUCK5_VOLTS,
+			.enable_reg = BD71828_REG_BUCK5_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK5_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK5_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * BUCK5 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK5_VOLT,
+			.idle_reg = BD71828_REG_BUCK5_VOLT,
+			.suspend_reg = BD71828_REG_BUCK5_VOLT,
+			.lpsr_reg = BD71828_REG_BUCK5_VOLT,
+			.run_mask = BD71828_MASK_BUCK5_VOLT,
+			.idle_mask = BD71828_MASK_BUCK5_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK5_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK5_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+	},
+	{
+		.desc = {
+			.name = "buck6",
+			.of_match = of_match_ptr("BUCK6"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK6,
+			.ops = &bd71828_dvs_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck1267_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck1267_volts),
+			.n_voltages = BD71828_BUCK1267_VOLTS,
+			.enable_reg = BD71828_REG_BUCK6_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK6_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK1267_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK6_VOLT,
+			.run_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_reg = BD71828_REG_BUCK6_IDLE_VOLT,
+			.idle_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_reg = BD71828_REG_BUCK6_SUSP_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK1267_VOLT,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+			.lpsr_reg = BD71828_REG_BUCK6_SUSP_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK1267_VOLT,
+		},
+		.reg_inits = buck6_inits,
+		.reg_init_amnt = ARRAY_SIZE(buck6_inits),
+	},
+	{
+		.desc = {
+			.name = "buck7",
+			.of_match = of_match_ptr("BUCK7"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_BUCK7,
+			.ops = &bd71828_dvs_buck_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_buck1267_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_buck1267_volts),
+			.n_voltages = BD71828_BUCK1267_VOLTS,
+			.enable_reg = BD71828_REG_BUCK7_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_BUCK7_VOLT,
+			.vsel_mask = BD71828_MASK_BUCK1267_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_BUCK7_VOLT,
+			.run_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_reg = BD71828_REG_BUCK7_IDLE_VOLT,
+			.idle_mask = BD71828_MASK_BUCK1267_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_reg = BD71828_REG_BUCK7_SUSP_VOLT,
+			.suspend_mask = BD71828_MASK_BUCK1267_VOLT,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+			.lpsr_reg = BD71828_REG_BUCK7_SUSP_VOLT,
+			.lpsr_mask = BD71828_MASK_BUCK1267_VOLT,
+		},
+		.reg_inits = buck7_inits,
+		.reg_init_amnt = ARRAY_SIZE(buck7_inits),
+	},
+	{
+		.desc = {
+			.name = "ldo1",
+			.of_match = of_match_ptr("LDO1"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO1,
+			.ops = &bd71828_ldo_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_ldo_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_ldo_volts),
+			.n_voltages = BD71828_LDO_VOLTS,
+			.enable_reg = BD71828_REG_LDO1_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_LDO1_VOLT,
+			.vsel_mask = BD71828_MASK_LDO_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * LDO1 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_LDO1_VOLT,
+			.idle_reg = BD71828_REG_LDO1_VOLT,
+			.suspend_reg = BD71828_REG_LDO1_VOLT,
+			.lpsr_reg = BD71828_REG_LDO1_VOLT,
+			.run_mask = BD71828_MASK_LDO_VOLT,
+			.idle_mask = BD71828_MASK_LDO_VOLT,
+			.suspend_mask = BD71828_MASK_LDO_VOLT,
+			.lpsr_mask = BD71828_MASK_LDO_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+	}, {
+		.desc = {
+			.name = "ldo2",
+			.of_match = of_match_ptr("LDO2"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO2,
+			.ops = &bd71828_ldo_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_ldo_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_ldo_volts),
+			.n_voltages = BD71828_LDO_VOLTS,
+			.enable_reg = BD71828_REG_LDO2_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_LDO2_VOLT,
+			.vsel_mask = BD71828_MASK_LDO_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * LDO2 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_LDO2_VOLT,
+			.idle_reg = BD71828_REG_LDO2_VOLT,
+			.suspend_reg = BD71828_REG_LDO2_VOLT,
+			.lpsr_reg = BD71828_REG_LDO2_VOLT,
+			.run_mask = BD71828_MASK_LDO_VOLT,
+			.idle_mask = BD71828_MASK_LDO_VOLT,
+			.suspend_mask = BD71828_MASK_LDO_VOLT,
+			.lpsr_mask = BD71828_MASK_LDO_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+	}, {
+		.desc = {
+			.name = "ldo3",
+			.of_match = of_match_ptr("LDO3"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO3,
+			.ops = &bd71828_ldo_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_ldo_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_ldo_volts),
+			.n_voltages = BD71828_LDO_VOLTS,
+			.enable_reg = BD71828_REG_LDO3_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_LDO3_VOLT,
+			.vsel_mask = BD71828_MASK_LDO_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * LDO3 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_LDO3_VOLT,
+			.idle_reg = BD71828_REG_LDO3_VOLT,
+			.suspend_reg = BD71828_REG_LDO3_VOLT,
+			.lpsr_reg = BD71828_REG_LDO3_VOLT,
+			.run_mask = BD71828_MASK_LDO_VOLT,
+			.idle_mask = BD71828_MASK_LDO_VOLT,
+			.suspend_mask = BD71828_MASK_LDO_VOLT,
+			.lpsr_mask = BD71828_MASK_LDO_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+
+	}, {
+		.desc = {
+			.name = "ldo4",
+			.of_match = of_match_ptr("LDO4"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO4,
+			.ops = &bd71828_ldo_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_ldo_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_ldo_volts),
+			.n_voltages = BD71828_LDO_VOLTS,
+			.enable_reg = BD71828_REG_LDO4_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_LDO4_VOLT,
+			.vsel_mask = BD71828_MASK_LDO_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * LDO1 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_LDO4_VOLT,
+			.idle_reg = BD71828_REG_LDO4_VOLT,
+			.suspend_reg = BD71828_REG_LDO4_VOLT,
+			.lpsr_reg = BD71828_REG_LDO4_VOLT,
+			.run_mask = BD71828_MASK_LDO_VOLT,
+			.idle_mask = BD71828_MASK_LDO_VOLT,
+			.suspend_mask = BD71828_MASK_LDO_VOLT,
+			.lpsr_mask = BD71828_MASK_LDO_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+	}, {
+		.desc = {
+			.name = "ldo5",
+			.of_match = of_match_ptr("LDO5"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO5,
+			.ops = &bd71828_ldo_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_ldo_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_ldo_volts),
+			.n_voltages = BD71828_LDO_VOLTS,
+			.enable_reg = BD71828_REG_LDO5_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_LDO5_VOLT,
+			.vsel_mask = BD71828_MASK_LDO_VOLT,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+			.owner = THIS_MODULE,
+		},
+		/*
+		 * LDO5 is special. It can choose vsel settings to be configured
+		 * from 2 different registers (by GPIO).
+		 *
+		 * This driver supports only configuration where
+		 * BD71828_REG_LDO5_VOLT_L is used.
+		 */
+		.dvs = {
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_LDO5_VOLT,
+			.idle_reg = BD71828_REG_LDO5_VOLT,
+			.suspend_reg = BD71828_REG_LDO5_VOLT,
+			.lpsr_reg = BD71828_REG_LDO5_VOLT,
+			.run_mask = BD71828_MASK_LDO_VOLT,
+			.idle_mask = BD71828_MASK_LDO_VOLT,
+			.suspend_mask = BD71828_MASK_LDO_VOLT,
+			.lpsr_mask = BD71828_MASK_LDO_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+
+	}, {
+		.desc = {
+			.name = "ldo6",
+			.of_match = of_match_ptr("LDO6"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO6,
+			.ops = &bd71828_ldo6_ops,
+			.type = REGULATOR_VOLTAGE,
+			.n_voltages = 1,
+			.enable_reg = BD71828_REG_LDO6_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.owner = THIS_MODULE,
+			/*
+			 * LDO6 only supports enable/disable for all states.
+			 * Voltage for LDO6 is fixed.
+			 */
+			.of_parse_cb = ldo6_parse_dt,
+		},
+	}, {
+		.desc = {
+			/* SNVS LDO in data-sheet */
+			.name = "ldo7",
+			.of_match = of_match_ptr("LDO7"),
+			.regulators_node = of_match_ptr("regulators"),
+			.id = BD71828_LDO_SNVS,
+			.ops = &bd71828_ldo_ops,
+			.type = REGULATOR_VOLTAGE,
+			.linear_ranges = bd71828_ldo_volts,
+			.n_linear_ranges = ARRAY_SIZE(bd71828_ldo_volts),
+			.n_voltages = BD71828_LDO_VOLTS,
+			.enable_reg = BD71828_REG_LDO7_EN,
+			.enable_mask = BD71828_MASK_RUN_EN,
+			.vsel_reg = BD71828_REG_LDO7_VOLT,
+			.vsel_mask = BD71828_MASK_LDO_VOLT,
+			.owner = THIS_MODULE,
+			.of_parse_cb = buck_set_hw_dvs_levels,
+		},
+		.dvs = {
+			/*
+			 * LDO7 only supports single voltage for all states.
+			 * voltage can be individually enabled for each state
+			 * though => allow setting all states to support
+			 * enabling power rail on different states.
+			 */
+			.level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_IDLE |
+				     ROHM_DVS_LEVEL_SUSPEND |
+				     ROHM_DVS_LEVEL_LPSR,
+			.run_reg = BD71828_REG_LDO7_VOLT,
+			.idle_reg = BD71828_REG_LDO7_VOLT,
+			.suspend_reg = BD71828_REG_LDO7_VOLT,
+			.lpsr_reg = BD71828_REG_LDO7_VOLT,
+			.run_mask = BD71828_MASK_LDO_VOLT,
+			.idle_mask = BD71828_MASK_LDO_VOLT,
+			.suspend_mask = BD71828_MASK_LDO_VOLT,
+			.lpsr_mask = BD71828_MASK_LDO_VOLT,
+			.idle_on_mask = BD71828_MASK_IDLE_EN,
+			.suspend_on_mask = BD71828_MASK_SUSP_EN,
+			.lpsr_on_mask = BD71828_MASK_LPSR_EN,
+		},
+
+	},
+};
+
+static int bd71828_probe(struct platform_device *pdev)
+{
+	struct rohm_regmap_dev *bd71828;
+	int i, j, ret;
+	struct regulator_config config = {
+		.dev = pdev->dev.parent,
+	};
+
+	bd71828 = dev_get_drvdata(pdev->dev.parent);
+	if (!bd71828) {
+		dev_err(&pdev->dev, "No MFD driver data\n");
+		return -EINVAL;
+	}
+
+	config.regmap = bd71828->regmap;
+
+	for (i = 0; i < ARRAY_SIZE(bd71828_rdata); i++) {
+		struct regulator_dev *rdev;
+		const struct bd71828_regulator_data *rd;
+
+		rd = &bd71828_rdata[i];
+		rdev = devm_regulator_register(&pdev->dev,
+					       &rd->desc, &config);
+		if (IS_ERR(rdev)) {
+			dev_err(&pdev->dev,
+				"failed to register %s regulator\n",
+				rd->desc.name);
+			return PTR_ERR(rdev);
+		}
+		for (j = 0; j < rd->reg_init_amnt; j++) {
+			ret = regmap_update_bits(bd71828->regmap,
+						 rd->reg_inits[j].reg,
+						 rd->reg_inits[j].mask,
+						 rd->reg_inits[j].val);
+			if (ret) {
+				dev_err(&pdev->dev,
+					"regulator %s init failed\n",
+					rd->desc.name);
+				return ret;
+			}
+		}
+	}
+	return 0;
+}
+
+static struct platform_driver bd71828_regulator = {
+	.driver = {
+		.name = "bd71828-pmic"
+	},
+	.probe = bd71828_probe,
+};
+
+module_platform_driver(bd71828_regulator);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("BD71828 voltage regulator driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:bd71828-pmic");
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 08/13] regulator: bd71828: Add GPIO based run-level control for regulators
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (6 preceding siblings ...)
  2019-10-24 11:46 ` [RFC PATCH v2 07/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
@ 2019-10-24 11:46 ` Matti Vaittinen
  2019-10-24 11:47 ` [RFC PATCH v2 09/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
                   ` (4 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:46 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Bucks 1,2,6 and 7 on RPHM BD71828 can be either controlled as
individual regulartors - or they can be grouped to a group of
regulators that are controlled by 'run levels'. This can be
done via I2C. Each regulator can be assigned a voltage and
enable/disable status for each run-level. These statuses are
also changeable via I2C.

Run-levels can then be changed either by I2C or GPIO. This
control mechanism is selected by data in one time programmable
area (during production) and can't be changed later.

Allow regulators to be controlled via run-levels and allow
getting/setting the current run-level also via GPIO.

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

No changes since v1

 drivers/regulator/bd71828-regulator.c | 373 +++++++++++++++++++++++++-
 1 file changed, 362 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/bd71828-regulator.c b/drivers/regulator/bd71828-regulator.c
index 3f46658280be..e82e94ecf747 100644
--- a/drivers/regulator/bd71828-regulator.c
+++ b/drivers/regulator/bd71828-regulator.c
@@ -4,8 +4,10 @@
 //
 
 #include <linux/delay.h>
+#include <linux/device.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/mfd/rohm-bd71828.h>
@@ -17,16 +19,27 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/of_regulator.h>
 
+#define MAX_GPIO_DVS_BUCKS 4
+#define DVS_RUN_LEVELS 4
+
 struct reg_init {
 	unsigned int reg;
 	unsigned int mask;
 	unsigned int val;
 };
+
+struct run_lvl_ctrl {
+	unsigned int voltage;
+	bool enabled;
+};
+
 struct bd71828_regulator_data {
 	struct regulator_desc desc;
-	const struct rohm_dvs_config dvs;
+	struct rohm_dvs_config dvs;
 	const struct reg_init *reg_inits;
 	int reg_init_amnt;
+	struct run_lvl_ctrl run_lvl[DVS_RUN_LEVELS];
+	struct gpio_descs *gps;
 };
 
 static const struct reg_init buck1_inits[] = {
@@ -41,6 +54,14 @@ static const struct reg_init buck1_inits[] = {
 	},
 };
 
+static const struct reg_init buck1_gpio_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK1_CTRL,
+		.val = BD71828_DVS_BUCK1_USE_RUNLVL,
+	},
+};
+
 static const struct reg_init buck2_inits[] = {
 	{
 		.reg = BD71828_REG_PS_CTRL_1,
@@ -49,6 +70,14 @@ static const struct reg_init buck2_inits[] = {
 	},
 };
 
+static const struct reg_init buck2_gpio_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK2_CTRL,
+		.val = BD71828_DVS_BUCK2_USE_RUNLVL,
+	},
+};
+
 static const struct reg_init buck6_inits[] = {
 	{
 		.reg = BD71828_REG_PS_CTRL_1,
@@ -57,6 +86,14 @@ static const struct reg_init buck6_inits[] = {
 	},
 };
 
+static const struct reg_init buck6_gpio_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK6_CTRL,
+		.val = BD71828_DVS_BUCK6_USE_RUNLVL,
+	},
+};
+
 static const struct reg_init buck7_inits[] = {
 	{
 		.reg = BD71828_REG_PS_CTRL_1,
@@ -65,6 +102,14 @@ static const struct reg_init buck7_inits[] = {
 	},
 };
 
+static const struct reg_init buck7_gpio_inits[] = {
+	{
+		.reg = BD71828_REG_PS_CTRL_1,
+		.mask = BD71828_MASK_DVS_BUCK7_CTRL,
+		.val = BD71828_DVS_BUCK7_USE_RUNLVL,
+	},
+};
+
 static const struct regulator_linear_range bd71828_buck1267_volts[] = {
 	REGULATOR_LINEAR_RANGE(500000, 0x00, 0xef, 6250),
 	REGULATOR_LINEAR_RANGE(2000000, 0xf0, 0xff, 0),
@@ -155,6 +200,80 @@ static int buck_set_hw_dvs_levels(struct device_node *np,
 	return rohm_regulator_set_dvs_levels(&data->dvs, np, desc, cfg->regmap);
 }
 
+static int set_runlevel_voltage(struct regmap *regmap,
+				const struct regulator_desc *desc,
+				unsigned int uv, unsigned int level)
+{
+	int i, ret = -EINVAL;
+	/*
+	 * RUN level registers are next to vsel_reg. RUN0 reg is next, then
+	 * is the RUN 1 reg and so on...
+	 */
+	u8 reg = desc->vsel_reg + level + 1;
+	u8 mask = BD71828_MASK_BUCK1267_VOLT;
+
+	for (i = 0; i < desc->n_voltages; i++) {
+		ret = regulator_desc_list_voltage_linear_range(desc, i);
+		if (ret < 0)
+			continue;
+		if (ret == uv) {
+			i <<= ffs(desc->vsel_mask) - 1;
+			ret = regmap_update_bits(regmap, reg, mask, i);
+			break;
+		}
+	}
+	return ret;
+}
+
+static int buck_set_gpio_hw_dvs_levels(struct device_node *np,
+				       const struct regulator_desc *desc,
+				       struct regulator_config *cfg)
+{
+	struct bd71828_regulator_data *data;
+	uint32_t uv;
+	int i, ret;
+	/* On BD71828 the RUN level control reg is next to enable reg */
+	u8 en_reg = desc->enable_reg + 1;
+	const char *props[DVS_RUN_LEVELS] = { "rohm,dvs-runlevel0-voltage",
+					      "rohm,dvs-runlevel1-voltage",
+					      "rohm,dvs-runlevel2-voltage",
+					      "rohm,dvs-runlevel3-voltage" };
+	u8 en_masks[DVS_RUN_LEVELS] = { BD71828_MASK_RUN0_EN,
+					BD71828_MASK_RUN1_EN,
+					BD71828_MASK_RUN2_EN,
+					BD71828_MASK_RUN3_EN };
+
+	data = container_of(desc, struct bd71828_regulator_data, desc);
+
+	for (i = 0; i < DVS_RUN_LEVELS; i++) {
+		ret = of_property_read_u32(np, props[i], &uv);
+		if (ret) {
+			if (ret != -EINVAL)
+				return ret;
+			uv = 0;
+		}
+		if (uv) {
+			data->run_lvl[i].voltage = uv;
+			data->run_lvl[i].enabled = true;
+
+			ret = set_runlevel_voltage(cfg->regmap, desc, uv, i);
+
+			if (ret)
+				return ret;
+
+			ret = regmap_update_bits(cfg->regmap, en_reg,
+						 en_masks[i], en_masks[i]);
+		} else {
+			ret = regmap_update_bits(cfg->regmap, en_reg,
+						 en_masks[i], 0);
+		}
+		if (ret)
+			return ret;
+	}
+
+	return rohm_regulator_set_dvs_levels(&data->dvs, np, desc, cfg->regmap);
+}
+
 static int ldo6_parse_dt(struct device_node *np,
 			 const struct regulator_desc *desc,
 			 struct regulator_config *cfg)
@@ -189,6 +308,85 @@ static int ldo6_parse_dt(struct device_node *np,
 	return 0;
 }
 
+static int bd71828_dvs_gpio_set_run_level(struct bd71828_regulator_data *rd,
+					  int val)
+{
+	DECLARE_BITMAP(values, 2);
+
+	if (rd->gps->ndescs != 2)
+		return -EINVAL;
+
+	if (val < 0 || val > 3)
+		return -EINVAL;
+
+	values[0] = val;
+
+	return gpiod_set_array_value_cansleep(rd->gps->ndescs, rd->gps->desc,
+				     rd->gps->info, values);
+}
+static int bd71828_dvs_gpio_get_run_level(struct bd71828_regulator_data *rd)
+{
+	int run_level;
+	int ret;
+
+	DECLARE_BITMAP(values, 2);
+
+	values[0] = 0;
+
+	if (rd->gps->ndescs != 2)
+		return -EINVAL;
+
+	ret = gpiod_get_array_value_cansleep(rd->gps->ndescs, rd->gps->desc,
+				     rd->gps->info, values);
+	if (ret)
+		return ret;
+
+	run_level = values[0];
+
+	return run_level;
+}
+
+static int bd71828_dvs_gpio_is_enabled(struct regulator_dev *rdev)
+{
+	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
+	int ret;
+
+	// TODO: lock GPIO state (Is this needed)
+	ret = bd71828_dvs_gpio_get_run_level(data);
+	if (ret < 0)
+		goto unlock_out;
+
+	ret = data->run_lvl[ret].enabled;
+
+unlock_out:
+	//TODO: unlock
+
+	return ret;
+}
+
+static int bd71828_dvs_gpio_get_voltage(struct regulator_dev *rdev)
+{
+	int ret;
+	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
+
+	// TODO: lock GPIO state (Is this needed)
+	ret = bd71828_dvs_gpio_get_run_level(data);
+	if (ret < 0)
+		goto unlock_out;
+
+	ret = data->run_lvl[ret].voltage;
+
+unlock_out:
+	//TODO: unlock
+
+	return ret;
+}
+
+static const struct regulator_ops dvs_buck_gpio_ops = {
+	.is_enabled = bd71828_dvs_gpio_is_enabled,
+	.get_voltage = bd71828_dvs_gpio_get_voltage,
+};
+
 static const struct regulator_ops bd71828_buck_ops = {
 	.enable = regulator_enable_regmap,
 	.disable = regulator_disable_regmap,
@@ -773,6 +971,132 @@ static const struct bd71828_regulator_data bd71828_rdata[] = {
 	},
 };
 
+struct bd71828_gpio_cfg {
+	unsigned int gpiobucks;
+	struct gpio_descs *gps;
+};
+
+static int check_dt_for_gpio_controls(struct device *d,
+				      struct bd71828_gpio_cfg *g)
+{
+	int ret, i;
+	struct device_node *np = d->of_node;
+	const char *prop = "rohm,dvs_gpio_bucks";
+	uint32_t bucks[MAX_GPIO_DVS_BUCKS];
+
+	g->gps = devm_gpiod_get_array(d, "rohm,dvs-vsel", GPIOD_OUT_LOW);
+
+	if (IS_ERR(g->gps)) {
+		ret = PTR_ERR(g->gps);
+		if (ret == -ENOENT)
+			return 0;
+		return ret;
+	}
+
+	if (g->gps->ndescs != 2)
+		return -ENOENT;
+
+	ret = of_property_read_variable_u32_array(np, prop, bucks, 0,
+						  ARRAY_SIZE(bucks));
+
+	if (ret < 0) {
+		if (ret == -EOVERFLOW)
+			return -EINVAL;
+	}
+	for (i = 0; i < ret; i++)
+		g->gpiobucks |= 1 << bucks[i];
+
+	return 0;
+}
+
+static void set_buck_gpio_controlled(struct rohm_regmap_dev *bd71828,
+				     struct bd71828_regulator_data *rd,
+				     struct bd71828_gpio_cfg *g)
+{
+	switch (rd->desc.id) {
+	case BD71828_BUCK1:
+		rd->reg_inits = buck1_gpio_inits;
+		break;
+	case BD71828_BUCK2:
+		rd->reg_inits = buck2_gpio_inits;
+		break;
+	case BD71828_BUCK6:
+		rd->reg_inits = buck6_gpio_inits;
+		break;
+	case BD71828_BUCK7:
+		rd->reg_inits = buck7_gpio_inits;
+		break;
+	default:
+		return;
+	}
+	/*
+	 * Disallow setters. Get voltages/enable states based
+	 * on current RUN level
+	 */
+	rd->gps = g->gps;
+	rd->desc.ops = &dvs_buck_gpio_ops;
+	rd->desc.of_parse_cb = buck_set_gpio_hw_dvs_levels;
+}
+
+static ssize_t show_runlevel(struct device *dev,
+			   struct device_attribute *attr, char *buf)
+{
+	int runlevel;
+	struct bd71828_regulator_data *rd = dev_get_drvdata(dev);
+
+	if (!rd || !rd->gps)
+		return -ENOENT;
+
+	runlevel = bd71828_dvs_gpio_get_run_level(rd);
+	if (runlevel < 0)
+		return runlevel;
+
+	return sprintf(buf, "0x%x\n", runlevel);
+}
+
+static ssize_t set_runlevel(struct device *dev, struct device_attribute *attr,
+			  const char *buf, size_t count)
+{
+	struct bd71828_regulator_data *rd = dev_get_drvdata(dev);
+	long val;
+
+	if (kstrtol(buf, 0, &val) != 0)
+		return -EINVAL;
+
+	val = bd71828_dvs_gpio_set_run_level(rd, val);
+	if (val)
+		return val;
+
+	return count;
+}
+
+static DEVICE_ATTR(runlevel, 0664, show_runlevel, set_runlevel);
+
+static struct attribute *runlevel_attributes[] = {
+	&dev_attr_runlevel.attr,
+	NULL
+};
+
+static const struct attribute_group bd71828_attr_group = {
+	.attrs	= runlevel_attributes,
+};
+
+static int bd71828_create_sysfs(struct platform_device *pdev)
+{
+	return sysfs_create_group(&pdev->dev.kobj, &bd71828_attr_group);
+}
+
+static int bd71828_remove_sysfs(struct platform_device *pdev)
+{
+	sysfs_remove_group(&pdev->dev.kobj, &bd71828_attr_group);
+	return 0;
+}
+
+static int bd71828_remove(struct platform_device *pdev)
+{
+	return bd71828_remove_sysfs(pdev);
+}
+
 static int bd71828_probe(struct platform_device *pdev)
 {
 	struct rohm_regmap_dev *bd71828;
@@ -780,6 +1104,8 @@ static int bd71828_probe(struct platform_device *pdev)
 	struct regulator_config config = {
 		.dev = pdev->dev.parent,
 	};
+	struct bd71828_gpio_cfg gcfg = {0};
+	struct bd71828_regulator_data *rd;
 
 	bd71828 = dev_get_drvdata(pdev->dev.parent);
 	if (!bd71828) {
@@ -787,35 +1113,59 @@ static int bd71828_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
+	ret = check_dt_for_gpio_controls(pdev->dev.parent, &gcfg);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to get DVS gpio resources\n");
+		return ret;
+	}
+
+	/*
+	 * Allocate device data to allow controlling more than one PMICs
+	 */
+	rd = devm_kmalloc_array(&pdev->dev, ARRAY_SIZE(bd71828_rdata),
+				sizeof(*rd), GFP_KERNEL);
+	if (!rd)
+		return -ENOMEM;
+
+	dev_set_drvdata(&pdev->dev, rd);
+
+	for (i = 0; i < ARRAY_SIZE(bd71828_rdata); i++) {
+		/* Use bd71828_rdata as template */
+		rd[i] = bd71828_rdata[i];
+
+		if (gcfg.gpiobucks & (1 << i))
+			set_buck_gpio_controlled(bd71828, &rd[i], &gcfg);
+	}
+
 	config.regmap = bd71828->regmap;
 
 	for (i = 0; i < ARRAY_SIZE(bd71828_rdata); i++) {
 		struct regulator_dev *rdev;
-		const struct bd71828_regulator_data *rd;
 
-		rd = &bd71828_rdata[i];
+		config.driver_data = &rd[i];
+
 		rdev = devm_regulator_register(&pdev->dev,
-					       &rd->desc, &config);
+					       &rd[i].desc, &config);
 		if (IS_ERR(rdev)) {
 			dev_err(&pdev->dev,
 				"failed to register %s regulator\n",
-				rd->desc.name);
+				rd[i].desc.name);
 			return PTR_ERR(rdev);
 		}
-		for (j = 0; j < rd->reg_init_amnt; j++) {
+		for (j = 0; j < rd[i].reg_init_amnt; j++) {
 			ret = regmap_update_bits(bd71828->regmap,
-						 rd->reg_inits[j].reg,
-						 rd->reg_inits[j].mask,
-						 rd->reg_inits[j].val);
+						 rd[i].reg_inits[j].reg,
+						 rd[i].reg_inits[j].mask,
+						 rd[i].reg_inits[j].val);
 			if (ret) {
 				dev_err(&pdev->dev,
 					"regulator %s init failed\n",
-					rd->desc.name);
+					rd[i].desc.name);
 				return ret;
 			}
 		}
 	}
-	return 0;
+	return bd71828_create_sysfs(pdev);
 }
 
 static struct platform_driver bd71828_regulator = {
@@ -823,6 +1173,7 @@ static struct platform_driver bd71828_regulator = {
 		.name = "bd71828-pmic"
 	},
 	.probe = bd71828_probe,
+	.remove = bd71828_remove,
 };
 
 module_platform_driver(bd71828_regulator);
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 09/13] regulator: bd71828: enhanced run-level support
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (7 preceding siblings ...)
  2019-10-24 11:46 ` [RFC PATCH v2 08/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
@ 2019-10-24 11:47 ` Matti Vaittinen
  2019-10-24 11:47 ` [RFC PATCH v2 10/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
                   ` (3 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:47 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Support changing run-level via I2C and add in-kernel API for allowing
run time changes of run-level voltages.

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

No changes since v1

 drivers/regulator/bd71828-regulator.c | 266 ++++++++++++++++++++++----
 include/linux/mfd/rohm-bd71828.h      |   3 +
 2 files changed, 232 insertions(+), 37 deletions(-)

diff --git a/drivers/regulator/bd71828-regulator.c b/drivers/regulator/bd71828-regulator.c
index e82e94ecf747..d9e1381b5964 100644
--- a/drivers/regulator/bd71828-regulator.c
+++ b/drivers/regulator/bd71828-regulator.c
@@ -19,6 +19,12 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/of_regulator.h>
 
+/* Drivers should not do this. But we provide this custom kernel interface
+ * for users to switch the run-level. Hence we need to get the rdev from
+ * struct regulator
+ */
+#include "internal.h"
+
 #define MAX_GPIO_DVS_BUCKS 4
 #define DVS_RUN_LEVELS 4
 
@@ -39,7 +45,10 @@ struct bd71828_regulator_data {
 	const struct reg_init *reg_inits;
 	int reg_init_amnt;
 	struct run_lvl_ctrl run_lvl[DVS_RUN_LEVELS];
+	struct mutex dvs_lock;
 	struct gpio_descs *gps;
+	struct regmap *regmap;
+	bool allow_runlvl;
 };
 
 static const struct reg_init buck1_inits[] = {
@@ -225,7 +234,7 @@ static int set_runlevel_voltage(struct regmap *regmap,
 	return ret;
 }
 
-static int buck_set_gpio_hw_dvs_levels(struct device_node *np,
+static int buck_set_runlvl_hw_dvs_levels(struct device_node *np,
 				       const struct regulator_desc *desc,
 				       struct regulator_config *cfg)
 {
@@ -245,11 +254,12 @@ static int buck_set_gpio_hw_dvs_levels(struct device_node *np,
 
 	data = container_of(desc, struct bd71828_regulator_data, desc);
 
+	mutex_lock(&data->dvs_lock);
 	for (i = 0; i < DVS_RUN_LEVELS; i++) {
 		ret = of_property_read_u32(np, props[i], &uv);
 		if (ret) {
 			if (ret != -EINVAL)
-				return ret;
+				goto unlock_out;
 			uv = 0;
 		}
 		if (uv) {
@@ -259,7 +269,7 @@ static int buck_set_gpio_hw_dvs_levels(struct device_node *np,
 			ret = set_runlevel_voltage(cfg->regmap, desc, uv, i);
 
 			if (ret)
-				return ret;
+				goto unlock_out;
 
 			ret = regmap_update_bits(cfg->regmap, en_reg,
 						 en_masks[i], en_masks[i]);
@@ -268,10 +278,15 @@ static int buck_set_gpio_hw_dvs_levels(struct device_node *np,
 						 en_masks[i], 0);
 		}
 		if (ret)
-			return ret;
+			goto unlock_out;
 	}
 
-	return rohm_regulator_set_dvs_levels(&data->dvs, np, desc, cfg->regmap);
+	ret = rohm_regulator_set_dvs_levels(&data->dvs, np, desc, cfg->regmap);
+
+unlock_out:
+	mutex_unlock(&data->dvs_lock);
+
+	return ret;
 }
 
 static int ldo6_parse_dt(struct device_node *np,
@@ -324,11 +339,40 @@ static int bd71828_dvs_gpio_set_run_level(struct bd71828_regulator_data *rd,
 	return gpiod_set_array_value_cansleep(rd->gps->ndescs, rd->gps->desc,
 				     rd->gps->info, values);
 }
+
+/* Get current run level when RUN levels are controlled using I2C */
+static int bd71828_dvs_i2c_set_run_level(struct regmap *regmap,
+					 int lvl)
+{
+	unsigned int reg;
+
+	reg = lvl << (ffs(BD71828_MASK_RUN_LVL_CTRL) - 1);
+
+	return regmap_update_bits(regmap, BD71828_REG_PS_CTRL_3,
+				  BD71828_MASK_RUN_LVL_CTRL, reg);
+}
+/* Get current run level when RUN levels are controlled using I2C */
+static int bd71828_dvs_i2c_get_run_level(struct regmap *regmap,
+					 struct bd71828_regulator_data *rd)
+{
+	int ret;
+	unsigned int val;
+
+	ret = regmap_read(regmap, BD71828_REG_PS_CTRL_3, &val);
+	if (ret)
+		return ret;
+
+	ret = (val & BD71828_MASK_RUN_LVL_CTRL);
+	ret >>= ffs(BD71828_MASK_RUN_LVL_CTRL) - 1;
+
+	return ret;
+}
+
+/* Get current RUN level when run levels are controlled by GPIO */
 static int bd71828_dvs_gpio_get_run_level(struct bd71828_regulator_data *rd)
 {
 	int run_level;
 	int ret;
-
 	DECLARE_BITMAP(values, 2);
 
 	values[0] = 0;
@@ -346,47 +390,131 @@ static int bd71828_dvs_gpio_get_run_level(struct bd71828_regulator_data *rd)
 	return run_level;
 }
 
+/*
+ * To be used when BD71828 regulator is controlled by RUN levels
+ * via I2C instead of GPIO
+ */
+static int bd71828_dvs_i2c_is_enabled(struct regulator_dev *rdev)
+{
+	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
+	int ret;
+
+	mutex_lock(&data->dvs_lock);
+	ret = bd71828_dvs_i2c_get_run_level(rdev->regmap, data);
+	if (ret < 0)
+		goto unlock_out;
+
+	ret = data->run_lvl[ret].enabled;
+
+unlock_out:
+	mutex_unlock(&data->dvs_lock);
+
+	return ret;
+}
+
+/*
+ * To be used when BD71828 regulator is controlled by RUN levels
+ * via GPIO
+ */
 static int bd71828_dvs_gpio_is_enabled(struct regulator_dev *rdev)
 {
 	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
 	int ret;
 
-	// TODO: lock GPIO state (Is this needed)
+	mutex_lock(&data->dvs_lock);
 	ret = bd71828_dvs_gpio_get_run_level(data);
-	if (ret < 0)
+	if (ret < 0 || ret >= DVS_RUN_LEVELS)
 		goto unlock_out;
 
 	ret = data->run_lvl[ret].enabled;
 
 unlock_out:
-	//TODO: unlock
+	mutex_unlock(&data->dvs_lock);
 
 	return ret;
 }
 
+/*
+ * To be used when BD71828 regulator is controlled by RUN levels
+ * via I2C instead of GPIO
+ */
+static int bd71828_dvs_i2c_get_voltage(struct regulator_dev *rdev)
+{
+	int ret;
+	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
+
+	mutex_lock(&data->dvs_lock);
+	ret = bd71828_dvs_i2c_get_run_level(rdev->regmap, data);
+	if (ret < 0)
+		goto unlock_out;
+
+	ret = data->run_lvl[ret].voltage;
+
+unlock_out:
+	mutex_unlock(&data->dvs_lock);
+
+	return ret;
+}
+
+/*
+ * To be used when BD71828 regulator is controlled by RUN levels
+ * via GPIO
+ */
 static int bd71828_dvs_gpio_get_voltage(struct regulator_dev *rdev)
 {
 	int ret;
 	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
 
-	// TODO: lock GPIO state (Is this needed)
+	mutex_lock(&data->dvs_lock);
 	ret = bd71828_dvs_gpio_get_run_level(data);
-	if (ret < 0)
+	if (ret < 0 || DVS_RUN_LEVELS <= ret)
 		goto unlock_out;
 
 	ret = data->run_lvl[ret].voltage;
 
 unlock_out:
-	//TODO: unlock
+	mutex_unlock(&data->dvs_lock);
+
+	return ret;
+}
+
+/**
+ * bd71828_set_runlevel_voltage - change run-level voltage
+ *
+ * @regulator:  pointer to regulator for which the run-level voltage is changed
+ * @uv:		New voltage for run-level in micro volts
+ * @level:	run-level for which the voltage is to be changed
+ *
+ * Changes the run-level voltage for given regulator
+ */
+int bd71828_set_runlevel_voltage(struct regulator *regulator, unsigned int uv,
+				 unsigned int level)
+{
+	struct regulator_dev *rdev = regulator->rdev;
+	struct bd71828_regulator_data *data = rdev_get_drvdata(rdev);
+	int ret;
+
+	if (!data || !data->allow_runlvl)
+		return -EINVAL;
+
+	mutex_lock(&data->dvs_lock);
+	ret = set_runlevel_voltage(rdev->regmap, rdev->desc, uv, level);
+	mutex_unlock(&data->dvs_lock);
 
 	return ret;
 }
+EXPORT_SYMBOL(bd71828_set_runlevel_voltage);
 
 static const struct regulator_ops dvs_buck_gpio_ops = {
 	.is_enabled = bd71828_dvs_gpio_is_enabled,
 	.get_voltage = bd71828_dvs_gpio_get_voltage,
 };
 
+static const struct regulator_ops dvs_buck_i2c_ops = {
+	.is_enabled = bd71828_dvs_i2c_is_enabled,
+	.get_voltage = bd71828_dvs_i2c_get_voltage,
+};
+
 static const struct regulator_ops bd71828_buck_ops = {
 	.enable = regulator_enable_regmap,
 	.disable = regulator_disable_regmap,
@@ -972,17 +1100,72 @@ static const struct bd71828_regulator_data bd71828_rdata[] = {
 };
 
 struct bd71828_gpio_cfg {
-	unsigned int gpiobucks;
+	bool use_gpio;
+	unsigned int runlvl;
 	struct gpio_descs *gps;
 };
 
+static void mark_regulator_runlvl_controlled(struct device *dev,
+					     struct device_node *np,
+					     struct bd71828_gpio_cfg *g)
+{
+	int i;
+
+	for (i = 1; i <= ARRAY_SIZE(bd71828_rdata); i++) {
+		if (!of_node_name_eq(np, bd71828_rdata[i-1].desc.of_match))
+			continue;
+		switch (i) {
+		case 1:
+		case 2:
+		case 6:
+		case 7:
+			g->runlvl |= 1 << (i - 1);
+			dev_dbg(dev, "buck %d runlevel controlled\n", i);
+			break;
+		default:
+			dev_err(dev,
+				"Only bucks 1,2,6,7 support run-level dvs\n");
+			break;
+		}
+	}
+}
+
+static int get_runcontrolled_bucks_dt(struct device *dev,
+				      struct bd71828_gpio_cfg *g)
+{
+	struct device_node *np;
+	struct device_node *nproot = dev->of_node;
+	const char *prop = "rohm,dvs-runlvl-ctrl";
+
+	g->runlvl = 0;
+
+	nproot = of_get_child_by_name(nproot, "regulators");
+	if (!nproot) {
+		dev_err(dev, "failed to find regulators node\n");
+		return -ENODEV;
+	}
+	for_each_child_of_node(nproot, np)
+		if (of_property_read_bool(np, prop))
+			mark_regulator_runlvl_controlled(dev, np, g);
+
+	of_node_put(nproot);
+	return 0;
+}
+
 static int check_dt_for_gpio_controls(struct device *d,
 				      struct bd71828_gpio_cfg *g)
 {
-	int ret, i;
-	struct device_node *np = d->of_node;
-	const char *prop = "rohm,dvs_gpio_bucks";
-	uint32_t bucks[MAX_GPIO_DVS_BUCKS];
+	int ret;
+
+	ret = get_runcontrolled_bucks_dt(d, g);
+	if (ret)
+		return ret;
+
+	g->use_gpio = false;
+
+	/* If the run level control is not requested by any bucks we're done */
+	if (!g->runlvl)
+		return 0;
 
 	g->gps = devm_gpiod_get_array(d, "rohm,dvs-vsel", GPIOD_OUT_LOW);
 
@@ -996,22 +1179,14 @@ static int check_dt_for_gpio_controls(struct device *d,
 	if (g->gps->ndescs != 2)
 		return -ENOENT;
 
-	ret = of_property_read_variable_u32_array(np, prop, bucks, 0,
-						  ARRAY_SIZE(bucks));
-
-	if (ret < 0) {
-		if (ret == -EOVERFLOW)
-			return -EINVAL;
-	}
-	for (i = 0; i < ret; i++)
-		g->gpiobucks |= 1 << bucks[i];
+	g->use_gpio = true;
 
 	return 0;
 }
 
-static void set_buck_gpio_controlled(struct rohm_regmap_dev *bd71828,
-				     struct bd71828_regulator_data *rd,
-				     struct bd71828_gpio_cfg *g)
+static void set_buck_runlvl_controlled(struct rohm_regmap_dev *bd71828,
+				      struct bd71828_regulator_data *rd,
+				      struct bd71828_gpio_cfg *g)
 {
 	switch (rd->desc.id) {
 	case BD71828_BUCK1:
@@ -1033,9 +1208,16 @@ static void set_buck_gpio_controlled(struct rohm_regmap_dev *bd71828,
 	 * Disallow setters. Get voltages/enable states based
 	 * on current RUN level
 	 */
-	rd->gps = g->gps;
-	rd->desc.ops = &dvs_buck_gpio_ops;
-	rd->desc.of_parse_cb = buck_set_gpio_hw_dvs_levels;
+
+	rd->allow_runlvl = true;
+
+	if (g->use_gpio) {
+		rd->gps = g->gps;
+		rd->desc.ops = &dvs_buck_gpio_ops;
+	} else {
+		rd->desc.ops = &dvs_buck_i2c_ops;
+	}
+	rd->desc.of_parse_cb = buck_set_runlvl_hw_dvs_levels;
 }
 
 static ssize_t show_runlevel(struct device *dev,
@@ -1044,10 +1226,14 @@ static ssize_t show_runlevel(struct device *dev,
 	int runlevel;
 	struct bd71828_regulator_data *rd = dev_get_drvdata(dev);
 
-	if (!rd || !rd->gps)
+	if (!rd)
 		return -ENOENT;
 
-	runlevel = bd71828_dvs_gpio_get_run_level(rd);
+	if (!rd->gps)
+		runlevel = bd71828_dvs_i2c_get_run_level(rd->regmap, rd);
+	else
+		runlevel = bd71828_dvs_gpio_get_run_level(rd);
+
 	if (runlevel < 0)
 		return runlevel;
 
@@ -1063,7 +1249,10 @@ static ssize_t set_runlevel(struct device *dev, struct device_attribute *attr,
 	if (kstrtol(buf, 0, &val) != 0)
 		return -EINVAL;
 
-	val = bd71828_dvs_gpio_set_run_level(rd, val);
+	if (rd->gps)
+		val = bd71828_dvs_gpio_set_run_level(rd, val);
+	else
+		val = bd71828_dvs_i2c_set_run_level(rd->regmap, val);
 	if (val)
 		return val;
 
@@ -1133,8 +1322,11 @@ static int bd71828_probe(struct platform_device *pdev)
 		/* Use bd71828_rdata as template */
 		rd[i] = bd71828_rdata[i];
 
-		if (gcfg.gpiobucks & (1 << i))
-			set_buck_gpio_controlled(bd71828, &rd[i], &gcfg);
+		mutex_init(&rd[i].dvs_lock);
+		if (gcfg.runlvl & (1 << i))
+			set_buck_runlvl_controlled(bd71828, &rd[i], &gcfg);
+
+		rd[i].regmap = bd71828->regmap;
 	}
 
 	config.regmap = bd71828->regmap;
diff --git a/include/linux/mfd/rohm-bd71828.h b/include/linux/mfd/rohm-bd71828.h
index eb0557eb5314..5f15c6a309e6 100644
--- a/include/linux/mfd/rohm-bd71828.h
+++ b/include/linux/mfd/rohm-bd71828.h
@@ -422,4 +422,7 @@ enum {
 #define BD71828_OUT_TYPE_OPEN_DRAIN			0x0
 #define BD71828_OUT_TYPE_CMOS				0x2
 
+int bd71828_set_runlevel_voltage(struct regulator *regulator, unsigned int uv,
+				 unsigned int level);
+
 #endif /* __LINUX_MFD_BD71828_H__ */
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 10/13] regulator: bd71828: Support in-kernel APIs to change run-level
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (8 preceding siblings ...)
  2019-10-24 11:47 ` [RFC PATCH v2 09/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
@ 2019-10-24 11:47 ` Matti Vaittinen
  2019-10-24 11:50 ` [RFC PATCH v2 11/13] rtc: bd70528 add BD71828 support Matti Vaittinen
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:47 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Add exported functions bd71828_set_runlevel and
bd71828_get_runlevel for setting and getting the system run
level.

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

No changes since v1

 drivers/regulator/bd71828-regulator.c | 67 +++++++++++++++++++++++++++
 include/linux/mfd/rohm-bd71828.h      |  2 +
 2 files changed, 69 insertions(+)

diff --git a/drivers/regulator/bd71828-regulator.c b/drivers/regulator/bd71828-regulator.c
index d9e1381b5964..eaff9b1b20f9 100644
--- a/drivers/regulator/bd71828-regulator.c
+++ b/drivers/regulator/bd71828-regulator.c
@@ -505,6 +505,73 @@ int bd71828_set_runlevel_voltage(struct regulator *regulator, unsigned int uv,
 }
 EXPORT_SYMBOL(bd71828_set_runlevel_voltage);
 
+/**
+ * bd71828_set_runlevel - change system run-level.
+ *
+ * @regulator:	pointer to one of the BD71828 regulators obtained by
+ *		call to regulator_get
+ * @level:	New run-level the system should enter
+ *
+ * Changes the system to run-level which was given as argument. This
+ * operation will change state of all regulators which are set to be
+ * controlled by run-levels. Note that 'regulator' must point to a
+ * regulator which is controlled by run-levels.
+ */
+int bd71828_set_runlevel(struct regulator *regulator, unsigned int level)
+{
+	struct regulator_dev *rdev = regulator->rdev;
+	struct bd71828_regulator_data *rd = rdev_get_drvdata(rdev);
+
+	if (!rd)
+		return -ENOENT;
+
+	if (!rd || !rd->allow_runlvl)
+		return -EINVAL;
+
+	if (rd->gps)
+		return bd71828_dvs_gpio_set_run_level(rd, level);
+
+	return bd71828_dvs_i2c_set_run_level(rd->regmap, level);
+}
+EXPORT_SYMBOL(bd71828_set_runlevel);
+
+/**
+ * bd71828_get_runlevel - get the current system run-level.
+ *
+ * @regulator:	pointer to one of the BD71828 regulators obtained by
+ *		call to regulator_get
+ * @level:	Pointer to value where current run-level is stored
+ *
+ * Returns the current system run-level. Note that 'regulator' must
+ * point to a regulator which is controlled by run-levels.
+ */
+int bd71828_get_runlevel(struct regulator *regulator, unsigned int *level)
+{
+	struct regulator_dev *rdev = regulator->rdev;
+	struct bd71828_regulator_data *rd = rdev_get_drvdata(rdev);
+	int ret;
+
+	if (!rd)
+		return -ENOENT;
+
+	if (!rd || !rd->allow_runlvl)
+		return -EINVAL;
+
+	if (!rd->gps)
+		ret = bd71828_dvs_i2c_get_run_level(rd->regmap, rd);
+	else
+		ret = bd71828_dvs_gpio_get_run_level(rd);
+
+	if (ret < 0)
+		return ret;
+
+	*level = (unsigned int) ret;
+
+	return 0;
+}
+EXPORT_SYMBOL(bd71828_get_runlevel);
+
+
 static const struct regulator_ops dvs_buck_gpio_ops = {
 	.is_enabled = bd71828_dvs_gpio_is_enabled,
 	.get_voltage = bd71828_dvs_gpio_get_voltage,
diff --git a/include/linux/mfd/rohm-bd71828.h b/include/linux/mfd/rohm-bd71828.h
index 5f15c6a309e6..bbbd4f118550 100644
--- a/include/linux/mfd/rohm-bd71828.h
+++ b/include/linux/mfd/rohm-bd71828.h
@@ -424,5 +424,7 @@ enum {
 
 int bd71828_set_runlevel_voltage(struct regulator *regulator, unsigned int uv,
 				 unsigned int level);
+int bd71828_set_runlevel(struct regulator *regulator, unsigned int level);
+int bd71828_get_runlevel(struct regulator *regulator, unsigned int *level);
 
 #endif /* __LINUX_MFD_BD71828_H__ */
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 11/13] rtc: bd70528 add BD71828 support
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (9 preceding siblings ...)
  2019-10-24 11:47 ` [RFC PATCH v2 10/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
@ 2019-10-24 11:50 ` Matti Vaittinen
  2019-10-24 11:50 ` [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
  2019-10-24 11:52 ` [RFC PATCH v2 13/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:50 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

ROHM BD71828 PMIC RTC block is from many parts similar to one
on BD70528. Support BD71828 RTC using BD70528 RTC driver and
avoid re-inventing the wheel.

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

Mostly reverted naming changes since v1. Also added own rtc_ops for
both PMICs.

 drivers/rtc/Kconfig              |   5 +-
 drivers/rtc/rtc-bd70528.c        | 145 ++++++++++++++++++++++++++++---
 include/linux/mfd/rohm-bd70528.h |  13 +--
 include/linux/mfd/rohm-bd71828.h |   4 +-
 include/linux/mfd/rohm-shared.h  |  27 ++++++
 5 files changed, 167 insertions(+), 27 deletions(-)
 create mode 100644 include/linux/mfd/rohm-shared.h

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e72f65b61176..5c5b18a99bf9 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -498,11 +498,12 @@ config RTC_DRV_M41T80_WDT
 	help
 	  If you say Y here you will get support for the
 	  watchdog timer in the ST M41T60 and M41T80 RTC chips series.
+
 config RTC_DRV_BD70528
-	tristate "ROHM BD70528 PMIC RTC"
+	tristate "ROHM BD70528 and BD71828 PMIC RTC"
 	help
 	  If you say Y here you will get support for the RTC
-	  on ROHM BD70528 Power Management IC.
+	  block on ROHM BD70528 and BD71828 Power Management IC.
 
 	  This driver can also be built as a module. If so, the module
 	  will be called rtc-bd70528.
diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
index f9bdd555e1a2..0975728d3cbe 100644
--- a/drivers/rtc/rtc-bd70528.c
+++ b/drivers/rtc/rtc-bd70528.c
@@ -6,6 +6,7 @@
 
 #include <linux/bcd.h>
 #include <linux/mfd/rohm-bd70528.h>
+#include <linux/mfd/rohm-bd71828.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
@@ -15,7 +16,7 @@
 /*
  * We read regs RTC_SEC => RTC_YEAR
  * this struct is ordered according to chip registers.
- * Keep it u8 only to avoid padding issues.
+ * Keep it u8 only (or packed) to avoid padding issues.
  */
 struct bd70528_rtc_day {
 	u8 sec;
@@ -36,6 +37,13 @@ struct bd70528_rtc_wake {
 	u8 ctrl;
 } __packed;
 
+struct bd71828_rtc_alm {
+	struct bd70528_rtc_data alm0;
+	struct bd70528_rtc_data alm1;
+	u8 alm_mask;
+	u8 alm1_mask;
+} __packed;
+
 struct bd70528_rtc_alm {
 	struct bd70528_rtc_data data;
 	u8 alm_mask;
@@ -45,6 +53,8 @@ struct bd70528_rtc_alm {
 struct bd70528_rtc {
 	struct rohm_regmap_dev *mfd;
 	struct device *dev;
+	u8 reg_time_start;
+	bool has_rtc_timers;
 };
 
 static int bd70528_set_wake(struct rohm_regmap_dev *bd70528,
@@ -152,12 +162,18 @@ static int bd70528_set_rtc_based_timers(struct bd70528_rtc *r, int new_state,
 static int bd70528_re_enable_rtc_based_timers(struct bd70528_rtc *r,
 					      int old_state)
 {
+	if (!r->has_rtc_timers)
+		return 0;
+
 	return bd70528_set_rtc_based_timers(r, old_state, NULL);
 }
 
 static int bd70528_disable_rtc_based_timers(struct bd70528_rtc *r,
 					    int *old_state)
 {
+	if (!r->has_rtc_timers)
+		return 0;
+
 	return bd70528_set_rtc_based_timers(r, 0, old_state);
 }
 
@@ -213,6 +229,36 @@ static inline void rtc2tm(struct bd70528_rtc_data *r, struct rtc_time *t)
 	t->tm_wday = bcd2bin(r->week & BD70528_MASK_RTC_WEEK);
 }
 
+static int bd71828_set_alarm(struct device *dev, struct rtc_wkalrm *a)
+{
+	int ret;
+	struct bd71828_rtc_alm alm;
+	struct bd70528_rtc *r = dev_get_drvdata(dev);
+	struct rohm_regmap_dev *bd71828 = r->mfd;
+
+	ret = regmap_bulk_read(bd71828->regmap, BD71828_REG_RTC_ALM_START,
+			       &alm, sizeof(alm));
+	if (ret) {
+		dev_err(dev, "Failed to read alarm regs\n");
+		return ret;
+	}
+
+	tm2rtc(&a->time, &alm.alm0);
+
+	if (!a->enabled)
+		alm.alm_mask &= ~BD70528_MASK_ALM_EN;
+	else
+		alm.alm_mask |= BD70528_MASK_ALM_EN;
+
+	ret = regmap_bulk_write(bd71828->regmap, BD71828_REG_RTC_ALM_START,
+				&alm, sizeof(alm));
+	if (ret)
+		dev_err(dev, "Failed to set alarm time\n");
+
+	return ret;
+
+}
+
 static int bd70528_set_alarm(struct device *dev, struct rtc_wkalrm *a)
 {
 	struct bd70528_rtc_wake wake;
@@ -261,6 +307,30 @@ static int bd70528_set_alarm(struct device *dev, struct rtc_wkalrm *a)
 	return ret;
 }
 
+static int bd71828_read_alarm(struct device *dev, struct rtc_wkalrm *a)
+{
+	int ret;
+	struct bd71828_rtc_alm alm;
+	struct bd70528_rtc *r = dev_get_drvdata(dev);
+	struct rohm_regmap_dev *bd71828 = r->mfd;
+
+	ret = regmap_bulk_read(bd71828->regmap, BD71828_REG_RTC_ALM_START,
+			       &alm, sizeof(alm));
+	if (ret) {
+		dev_err(dev, "Failed to read alarm regs\n");
+		return ret;
+	}
+
+	rtc2tm(&alm.alm0, &a->time);
+	a->time.tm_mday = -1;
+	a->time.tm_mon = -1;
+	a->time.tm_year = -1;
+	a->enabled = !!(alm.alm_mask & BD70528_MASK_ALM_EN);
+	a->pending = 0;
+
+	return 0;
+}
+
 static int bd70528_read_alarm(struct device *dev, struct rtc_wkalrm *a)
 {
 	struct bd70528_rtc_alm alm;
@@ -297,7 +367,7 @@ static int bd70528_set_time_locked(struct device *dev, struct rtc_time *t)
 		return ret;
 
 	tmpret = regmap_bulk_read(bd70528->regmap,
-				  BD70528_REG_RTC_START, &rtc_data,
+				  r->reg_time_start, &rtc_data,
 				  sizeof(rtc_data));
 	if (tmpret) {
 		dev_err(dev, "Failed to read RTC time registers\n");
@@ -306,7 +376,7 @@ static int bd70528_set_time_locked(struct device *dev, struct rtc_time *t)
 	tm2rtc(t, &rtc_data);
 
 	tmpret = regmap_bulk_write(bd70528->regmap,
-				   BD70528_REG_RTC_START, &rtc_data,
+				   r->reg_time_start, &rtc_data,
 				   sizeof(rtc_data));
 	if (tmpret) {
 		dev_err(dev, "Failed to set RTC time\n");
@@ -341,7 +411,7 @@ static int bd70528_get_time(struct device *dev, struct rtc_time *t)
 
 	/* read the RTC date and time registers all at once */
 	ret = regmap_bulk_read(bd70528->regmap,
-			       BD70528_REG_RTC_START, &rtc_data,
+			       r->reg_time_start, &rtc_data,
 			       sizeof(rtc_data));
 	if (ret) {
 		dev_err(dev, "Failed to read RTC time (err %d)\n", ret);
@@ -378,6 +448,23 @@ static int bd70528_alm_enable(struct device *dev, unsigned int enabled)
 	return ret;
 }
 
+static int bd71828_alm_enable(struct device *dev, unsigned int enabled)
+{
+	int ret;
+	struct bd70528_rtc *r = dev_get_drvdata(dev);
+	unsigned int enableval = BD70528_MASK_ALM_EN;
+
+	if (!enabled)
+		enableval = 0;
+
+	ret = regmap_update_bits(r->mfd->regmap, BD71828_REG_RTC_ALM0_MASK,
+				 BD70528_MASK_ALM_EN, enableval);
+	if (ret)
+		dev_err(dev, "Failed to change alarm state\n");
+
+	return ret;
+}
+
 static const struct rtc_class_ops bd70528_rtc_ops = {
 	.read_time		= bd70528_get_time,
 	.set_time		= bd70528_set_time,
@@ -386,6 +473,14 @@ static const struct rtc_class_ops bd70528_rtc_ops = {
 	.alarm_irq_enable	= bd70528_alm_enable,
 };
 
+static const struct rtc_class_ops bd71828_rtc_ops = {
+	.read_time		= bd70528_get_time,
+	.set_time		= bd70528_set_time,
+	.read_alarm		= bd71828_read_alarm,
+	.set_alarm		= bd71828_set_alarm,
+	.alarm_irq_enable	= bd71828_alm_enable,
+};
+
 static irqreturn_t alm_hndlr(int irq, void *data)
 {
 	struct rtc_device *rtc = data;
@@ -397,11 +492,15 @@ static irqreturn_t alm_hndlr(int irq, void *data)
 static int bd70528_probe(struct platform_device *pdev)
 {
 	struct bd70528_rtc *bd_rtc;
+	const struct rtc_class_ops *rtc_ops;
 	struct rohm_regmap_dev *mfd;
+	const char *irq_name;
 	int ret;
 	struct rtc_device *rtc;
 	int irq;
 	unsigned int hr;
+	bool enable_main_irq = false;
+	u8 hour_reg;
 
 	mfd = dev_get_drvdata(pdev->dev.parent);
 	if (!mfd) {
@@ -415,7 +514,27 @@ static int bd70528_probe(struct platform_device *pdev)
 	bd_rtc->mfd = mfd;
 	bd_rtc->dev = &pdev->dev;
 
-	irq = platform_get_irq_byname(pdev, "bd70528-rtc-alm");
+	switch (mfd->chip_type) {
+	case ROHM_CHIP_TYPE_BD70528:
+		irq_name = "bd70528-rtc-alm";
+		bd_rtc->has_rtc_timers = true;
+		bd_rtc->reg_time_start = BD70528_REG_RTC_START;
+		hour_reg = BD70528_REG_RTC_HOUR;
+		enable_main_irq = true;
+		rtc_ops = &bd70528_rtc_ops;
+		break;
+	case ROHM_CHIP_TYPE_BD71828:
+		irq_name = "bd71828-rtc-alm-0";
+		bd_rtc->reg_time_start = BD71828_REG_RTC_START;
+		hour_reg = BD71828_REG_RTC_HOUR;
+		rtc_ops = &bd71828_rtc_ops;
+		break;
+	default:
+		dev_err(&pdev->dev, "Unknown chip\n");
+		return -ENOENT;
+	}
+
+	irq = platform_get_irq_byname(pdev, irq_name);
 
 	if (irq < 0) {
 		dev_err(&pdev->dev, "Failed to get irq\n");
@@ -424,7 +543,7 @@ static int bd70528_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, bd_rtc);
 
-	ret = regmap_read(mfd->regmap, BD70528_REG_RTC_HOUR, &hr);
+	ret = regmap_read(mfd->regmap, hour_reg, &hr);
 
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to reag RTC clock\n");
@@ -457,7 +576,7 @@ static int bd70528_probe(struct platform_device *pdev)
 
 	rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
 	rtc->range_max = RTC_TIMESTAMP_END_2099;
-	rtc->ops = &bd70528_rtc_ops;
+	rtc->ops = rtc_ops;
 
 	/* Request alarm IRQ prior to registerig the RTC */
 	ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, &alm_hndlr,
@@ -471,12 +590,14 @@ static int bd70528_probe(struct platform_device *pdev)
 	 *  leave them enabled as irq-controller should disable irqs
 	 *  from sub-registers when IRQ is disabled or freed.
 	 */
-	ret = regmap_update_bits(mfd->regmap,
+	if (enable_main_irq) {
+		ret = regmap_update_bits(mfd->regmap,
 				 BD70528_REG_INT_MAIN_MASK,
 				 BD70528_INT_RTC_MASK, 0);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to enable RTC interrupts\n");
-		return ret;
+		if (ret) {
+			dev_err(&pdev->dev, "Failed to enable RTC interrupts\n");
+			return ret;
+		}
 	}
 
 	ret = rtc_register_device(rtc);
@@ -496,5 +617,5 @@ static struct platform_driver bd70528_rtc = {
 module_platform_driver(bd70528_rtc);
 
 MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
-MODULE_DESCRIPTION("BD70528 RTC driver");
+MODULE_DESCRIPTION("ROHM BD70528 and BD71828 PMIC RTC driver");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/rohm-bd70528.h b/include/linux/mfd/rohm-bd70528.h
index 1013e60c5b25..e2859840b09d 100644
--- a/include/linux/mfd/rohm-bd70528.h
+++ b/include/linux/mfd/rohm-bd70528.h
@@ -7,6 +7,7 @@
 #include <linux/bits.h>
 #include <linux/device.h>
 #include <linux/mfd/rohm-generic.h>
+#include <linux/mfd/rohm-shared.h>
 #include <linux/regmap.h>
 
 enum {
@@ -313,17 +314,6 @@ enum {
 
 /* RTC masks to mask out reserved bits */
 
-#define BD70528_MASK_RTC_SEC		0x7f
-#define BD70528_MASK_RTC_MINUTE		0x7f
-#define BD70528_MASK_RTC_HOUR_24H	0x80
-#define BD70528_MASK_RTC_HOUR_PM	0x20
-#define BD70528_MASK_RTC_HOUR		0x1f
-#define BD70528_MASK_RTC_DAY		0x3f
-#define BD70528_MASK_RTC_WEEK		0x07
-#define BD70528_MASK_RTC_MONTH		0x1f
-#define BD70528_MASK_RTC_YEAR		0xff
-#define BD70528_MASK_RTC_COUNT_L	0x7f
-
 #define BD70528_MASK_ELAPSED_TIMER_EN	0x1
 /* Mask second, min and hour fields
  * HW would support ALM irq for over 24h
@@ -332,7 +322,6 @@ enum {
  * wake-up we limit ALM to 24H and only
  * unmask sec, min and hour
  */
-#define BD70528_MASK_ALM_EN		0x7
 #define BD70528_MASK_WAKE_EN		0x1
 
 /* WDT masks */
diff --git a/include/linux/mfd/rohm-bd71828.h b/include/linux/mfd/rohm-bd71828.h
index bbbd4f118550..bd9dfd53759d 100644
--- a/include/linux/mfd/rohm-bd71828.h
+++ b/include/linux/mfd/rohm-bd71828.h
@@ -5,6 +5,7 @@
 #define __LINUX_MFD_BD71828_H__
 
 #include <linux/mfd/rohm-generic.h>
+#include <linux/mfd/rohm-shared.h>
 
 /* Regulator IDs */
 enum {
@@ -160,6 +161,7 @@ enum {
 #define BD71828_REG_RTC_YEAR		0x52
 
 #define BD71828_REG_RTC_ALM0_SEC	0x53
+#define BD71828_REG_RTC_ALM_START	BD71828_REG_RTC_ALM0_SEC
 #define BD71828_REG_RTC_ALM0_MINUTE	0x54
 #define BD71828_REG_RTC_ALM0_HOUR	0x55
 #define BD71828_REG_RTC_ALM0_WEEK	0x56
@@ -178,6 +180,7 @@ enum {
 #define BD71828_REG_RTC_ALM1_MASK	0x62
 
 #define BD71828_REG_RTC_ALM2		0x63
+#define BD71828_REG_RTC_START		BD71828_REG_RTC_SEC
 
 /* Charger/Battey */
 #define BD71828_REG_CHG_STATE		0x65
@@ -207,7 +210,6 @@ enum {
 #define BD71828_REG_INT_MASK_TEMP	0xdd
 #define BD71828_REG_INT_MASK_RTC	0xde
 
-
 #define BD71828_REG_INT_MAIN		0xdf
 #define BD71828_REG_INT_BUCK		0xe0
 #define BD71828_REG_INT_DCIN1		0xe1
diff --git a/include/linux/mfd/rohm-shared.h b/include/linux/mfd/rohm-shared.h
new file mode 100644
index 000000000000..f16fc3b5000e
--- /dev/null
+++ b/include/linux/mfd/rohm-shared.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/* Copyright (C) 2018 ROHM Semiconductors */
+
+
+#ifndef __LINUX_MFD_ROHM_SHARED_H__
+#define __LINUX_MFD_ROHM_SHARED_H__
+
+/*
+ * RTC definitions shared between
+ *
+ * BD70528
+ * and BD71828
+ */
+
+
+#define BD70528_MASK_RTC_SEC		0x7f
+#define BD70528_MASK_RTC_MINUTE	0x7f
+#define BD70528_MASK_RTC_HOUR_24H	0x80
+#define BD70528_MASK_RTC_HOUR_PM	0x20
+#define BD70528_MASK_RTC_HOUR		0x3f
+#define BD70528_MASK_RTC_DAY		0x3f
+#define BD70528_MASK_RTC_WEEK		0x07
+#define BD70528_MASK_RTC_MONTH		0x1f
+#define BD70528_MASK_RTC_YEAR		0xff
+#define BD70528_MASK_ALM_EN		0x7
+
+#endif /* __LINUX_MFD_ROHM_SHARED_H__ */
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (10 preceding siblings ...)
  2019-10-24 11:50 ` [RFC PATCH v2 11/13] rtc: bd70528 add BD71828 support Matti Vaittinen
@ 2019-10-24 11:50 ` Matti Vaittinen
  2019-10-24 11:59   ` Linus Walleij
  2019-10-24 11:52 ` [RFC PATCH v2 13/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
  12 siblings, 1 reply; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:50 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

ROHM BD71828 PMIC contains 4 pins which can be configured by OTP
to be used for general purposes. First 3 can be used as outputs
and 4.th pin can be used as input. Allow them to be controlled
via GPIO framework.

The driver assumes all of the pins are configured as GPIOs and
trusts that the reserved pins in other OTP configurations are
excluded from control using "gpio-reserved-ranges" device tree
property (or left untouched by GPIO users).

Typical use for 4.th pin (input) is to use it as HALL sensor
input so that this pin state is toggled when HALL sensor detects
LID position change (from close to open or open to close). PMIC
HW implements some extra logic which allows PMIC to power-up the
system when this pin is toggled. Please see the data sheet for
details of GPIO options which can be selcted by OTP settings.

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

Mainly styling fixes since v1.

 drivers/gpio/Kconfig        |  12 +++
 drivers/gpio/Makefile       |   1 +
 drivers/gpio/gpio-bd71828.c | 151 ++++++++++++++++++++++++++++++++++++
 3 files changed, 164 insertions(+)
 create mode 100644 drivers/gpio/gpio-bd71828.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bb13c266c329..fb0a099de961 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -986,6 +986,18 @@ config GPIO_BD70528
 	  This driver can also be built as a module. If so, the module
 	  will be called gpio-bd70528.
 
+config GPIO_BD71828
+	tristate "ROHM BD71828 GPIO support"
+	depends on MFD_ROHM_BD71828
+	help
+	  Support for GPIOs on ROHM BD71828 PMIC. There are three GPIOs
+	  available on the ROHM PMIC in total. The GPIOs are limited to
+	  outputs only and pins must be configured to GPIO outputs by
+	  OTP. Enable this only if you want to use these pins as outputs.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called gpio-bd71828.
+
 config GPIO_BD9571MWV
 	tristate "ROHM BD9571 GPIO support"
 	depends on MFD_BD9571MWV
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a4e91175c708..b11932844768 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_GPIO_ASPEED)		+= gpio-aspeed.o
 obj-$(CONFIG_GPIO_ATH79)		+= gpio-ath79.o
 obj-$(CONFIG_GPIO_BCM_KONA)		+= gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BD70528)		+= gpio-bd70528.o
+obj-$(CONFIG_GPIO_BD71828)		+= gpio-bd71828.o
 obj-$(CONFIG_GPIO_BD9571MWV)		+= gpio-bd9571mwv.o
 obj-$(CONFIG_GPIO_BRCMSTB)		+= gpio-brcmstb.o
 obj-$(CONFIG_GPIO_BT8XX)		+= gpio-bt8xx.o
diff --git a/drivers/gpio/gpio-bd71828.c b/drivers/gpio/gpio-bd71828.c
new file mode 100644
index 000000000000..0ec3a1d9adc0
--- /dev/null
+++ b/drivers/gpio/gpio-bd71828.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 ROHM Semiconductors
+
+#include <linux/gpio/driver.h>
+#include <linux/mfd/rohm-bd71828.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define BD71828_OUT 0
+#define BD71828_IN 1
+#define GPIO_OUT_REG(off) (BD71828_REG_GPIO_CTRL1 + (off))
+#define HALL_GPIO_OFFSET 3
+
+struct bd71828_gpio {
+	struct rohm_regmap_dev chip;
+	struct gpio_chip gpio;
+};
+
+static void bd71828_gpio_set(struct gpio_chip *chip, unsigned int offset,
+			     int value)
+{
+	int ret;
+	struct bd71828_gpio *bdgpio = gpiochip_get_data(chip);
+	u8 val = (value) ? BD71828_GPIO_OUT_HI : BD71828_GPIO_OUT_LO;
+
+	/*
+	 * The HALL input pin can only be used as input. If this is the pin
+	 * we are dealing with - then we are done
+	 */
+	if (offset == HALL_GPIO_OFFSET)
+		return;
+
+	ret = regmap_update_bits(bdgpio->chip.regmap, GPIO_OUT_REG(offset),
+				 BD71828_GPIO_OUT_MASK, val);
+	if (ret)
+		dev_err(bdgpio->chip.dev, "Could not set gpio to %d\n", value);
+}
+
+static int bd71828_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+	int ret;
+	unsigned int val;
+	struct bd71828_gpio *bdgpio = gpiochip_get_data(chip);
+
+	if (offset == HALL_GPIO_OFFSET)
+		ret = regmap_read(bdgpio->chip.regmap, BD71828_REG_IO_STAT,
+				  &val);
+	else
+		ret = regmap_read(bdgpio->chip.regmap, GPIO_OUT_REG(offset),
+				  &val);
+	if (!ret)
+		ret = (val & BD71828_GPIO_OUT_MASK);
+
+	return ret;
+}
+
+static int bd71828_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+				   unsigned long config)
+{
+	struct bd71828_gpio *bdgpio = gpiochip_get_data(chip);
+
+	if (offset == HALL_GPIO_OFFSET)
+		return -ENOTSUPP;
+
+	switch (pinconf_to_config_param(config)) {
+	case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+		return regmap_update_bits(bdgpio->chip.regmap,
+					  GPIO_OUT_REG(offset),
+					  BD71828_GPIO_DRIVE_MASK,
+					  BD71828_GPIO_OPEN_DRAIN);
+	case PIN_CONFIG_DRIVE_PUSH_PULL:
+		return regmap_update_bits(bdgpio->chip.regmap,
+					  GPIO_OUT_REG(offset),
+					  BD71828_GPIO_DRIVE_MASK,
+					  BD71828_GPIO_PUSH_PULL);
+	default:
+		break;
+	}
+	return -ENOTSUPP;
+}
+
+static int bd71828_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+	/*
+	 * Pin usage is selected by OTP data. We can't read it runtime. Hence
+	 * we trust that if the pin is not excluded by "gpio-reserved-ranges"
+	 * the OTP configuration is set to OUT. (Other pins but HALL input pin
+	 * on BD71828 can't really be used for general purpose input - input
+	 * states are used for specific cases like regulator control or
+	 * PMIC_ON_REQ.
+	 */
+	if (offset == HALL_GPIO_OFFSET)
+		return BD71828_IN;
+
+	return BD71828_OUT;
+}
+
+static int bd71828_probe(struct platform_device *pdev)
+{
+	struct bd71828_gpio *bdgpio;
+	struct rohm_regmap_dev *bd71828;
+
+	bd71828 = dev_get_drvdata(pdev->dev.parent);
+	if (!bd71828) {
+		dev_err(&pdev->dev, "No MFD driver data\n");
+		return -EINVAL;
+	}
+
+	bdgpio = devm_kzalloc(&pdev->dev, sizeof(*bdgpio),
+			      GFP_KERNEL);
+	if (!bdgpio)
+		return -ENOMEM;
+
+	bdgpio->chip.dev = &pdev->dev;
+	bdgpio->gpio.parent = pdev->dev.parent;
+	bdgpio->gpio.label = "bd71828-gpio";
+	bdgpio->gpio.owner = THIS_MODULE;
+	bdgpio->gpio.get_direction = bd71828_get_direction;
+	bdgpio->gpio.set_config = bd71828_gpio_set_config;
+	bdgpio->gpio.can_sleep = true;
+	bdgpio->gpio.get = bd71828_gpio_get;
+	bdgpio->gpio.set = bd71828_gpio_set;
+	bdgpio->gpio.base = -1;
+
+	/*
+	 * See if we need some implementation to mark some PINs as
+	 * not controllable based on DT info or if core can handle
+	 * "gpio-reserved-ranges" and exclude them from control
+	 */
+	bdgpio->gpio.ngpio = 4;
+	bdgpio->gpio.of_node = pdev->dev.parent->of_node;
+	bdgpio->chip.regmap = bd71828->regmap;
+
+	return devm_gpiochip_add_data(&pdev->dev, &bdgpio->gpio,
+				     bdgpio);
+}
+
+static struct platform_driver bd71828_gpio = {
+	.driver = {
+		.name = "bd71828-gpio"
+	},
+	.probe = bd71828_probe,
+};
+
+module_platform_driver(bd71828_gpio);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("BD71828 voltage regulator driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:bd71828-gpio");
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* [RFC PATCH v2 13/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC
  2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
                   ` (11 preceding siblings ...)
  2019-10-24 11:50 ` [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
@ 2019-10-24 11:52 ` Matti Vaittinen
  12 siblings, 0 replies; 29+ messages in thread
From: Matti Vaittinen @ 2019-10-24 11:52 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

ROHM BD71828 power management IC has two LED outputs for charge status
and button pressing indications. The LED outputs can also be forced
by SW so add driver allowing to use these LEDs for other indications
as well.

Leds are controlled by SW using 'Force ON' bits. Please note the
constrains mentioned in data-sheet:
1. If one LED is forced ON - then also the other LED is forced.
	=> You can't use SW control to force ON one LED and allow HW
	   to control the other.
2. You can't force both LEDs OFF. If the FORCE bit for both LED's is
   zero, then LEDs are controlled by HW and indicate button/charger
   states as explained in data-sheet.

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

No changes since v1. Changes still under discussion.

 drivers/leds/Kconfig        | 10 ++++
 drivers/leds/Makefile       |  1 +
 drivers/leds/leds-bd71828.c | 97 +++++++++++++++++++++++++++++++++++++
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/leds/leds-bd71828.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b0fdeef10bd9..ec59f28bcb39 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -529,6 +529,16 @@ config LEDS_BD2802
 	  This option enables support for BD2802GU RGB LED driver chips
 	  accessed via the I2C bus.
 
+config LEDS_BD71828
+	tristate "LED driver for LED pins on ROHM BD71828 PMIC"
+	depends on LEDS_CLASS
+	depends on I2C
+	help
+	  This option enables support for LED outputs located on ROHM
+	   BD71828 power management IC. ROHM BD71828 has two led output pins
+	   which can be left to indicate HW states or controlled by SW. Say
+	   yes here if you want to enable SW control for these LEDs.
+
 config LEDS_INTEL_SS4200
 	tristate "LED driver for Intel NAS SS4200 series"
 	depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 41fb073a39c1..2a8f6a8e4c7c 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_LEDS_AN30259A)		+= leds-an30259a.o
 obj-$(CONFIG_LEDS_BCM6328)		+= leds-bcm6328.o
 obj-$(CONFIG_LEDS_BCM6358)		+= leds-bcm6358.o
 obj-$(CONFIG_LEDS_BD2802)		+= leds-bd2802.o
+obj-$(CONFIG_LEDS_BD71828)		+= leds-bd71828.o
 obj-$(CONFIG_LEDS_CPCAP)		+= leds-cpcap.o
 obj-$(CONFIG_LEDS_LOCOMO)		+= leds-locomo.o
 obj-$(CONFIG_LEDS_LM3530)		+= leds-lm3530.o
diff --git a/drivers/leds/leds-bd71828.c b/drivers/leds/leds-bd71828.c
new file mode 100644
index 000000000000..2427619444f5
--- /dev/null
+++ b/drivers/leds/leds-bd71828.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2019 ROHM Semiconductors
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/leds.h>
+#include <linux/mfd/rohm-bd71828.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define BD71828_LED_TO_DATA(l) ((l)->id == ID_GREEN_LED ? \
+	container_of((l), struct bd71828_leds, green) : \
+	container_of((l), struct bd71828_leds, amber))
+
+enum {
+	ID_GREEN_LED,
+	ID_AMBER_LED,
+	ID_NMBR_OF,
+};
+
+struct bd71828_led {
+	int id;
+	struct led_classdev l;
+	u8 force_mask;
+};
+
+struct bd71828_leds {
+	struct rohm_regmap_dev *bd71828;
+	struct bd71828_led green;
+	struct bd71828_led amber;
+};
+
+static int bd71828_led_brightness_set(struct led_classdev *led_cdev,
+				      enum led_brightness value)
+{
+	struct bd71828_led *l = container_of(led_cdev, struct bd71828_led, l);
+	struct bd71828_leds *data;
+	unsigned int val = BD71828_LED_OFF;
+
+	data = BD71828_LED_TO_DATA(l);
+	if (value != LED_OFF)
+		val = BD71828_LED_ON;
+
+	return regmap_update_bits(data->bd71828->regmap, BD71828_REG_LED_CTRL,
+			    l->force_mask, val);
+}
+
+static int bd71828_led_probe(struct platform_device *pdev)
+{
+	struct rohm_regmap_dev *bd71828;
+	struct bd71828_leds *l;
+	struct bd71828_led *g, *a;
+	static const char *GNAME = "bd71828-green-led";
+	static const char *ANAME = "bd71828-amber-led";
+	int ret;
+
+	pr_info("bd71828 LED driver probed\n");
+
+	bd71828 = dev_get_drvdata(pdev->dev.parent);
+	l = devm_kzalloc(&pdev->dev, sizeof(*l), GFP_KERNEL);
+	if (!l)
+		return -ENOMEM;
+	l->bd71828 = bd71828;
+	a = &l->amber;
+	g = &l->green;
+	a->id = ID_AMBER_LED;
+	g->id = ID_GREEN_LED;
+	a->force_mask = BD71828_MASK_LED_AMBER;
+	g->force_mask = BD71828_MASK_LED_GREEN;
+
+	a->l.name = ANAME;
+	g->l.name = GNAME;
+	a->l.brightness_set_blocking = bd71828_led_brightness_set;
+	g->l.brightness_set_blocking = bd71828_led_brightness_set;
+
+	ret = devm_led_classdev_register(&pdev->dev, &g->l);
+	if (ret)
+		return ret;
+
+	return devm_led_classdev_register(&pdev->dev, &a->l);
+}
+
+static struct platform_driver bd71828_led_driver = {
+	.driver = {
+		.name  = "bd71828-led",
+	},
+	.probe  = bd71828_led_probe,
+};
+
+module_platform_driver(bd71828_led_driver);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("ROHM BD71828 LED driver");
+MODULE_LICENSE("GPL");
-- 
2.21.0


-- 
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 to Simon Glass for the translation =] 

^ permalink raw reply related	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs
  2019-10-24 11:50 ` [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
@ 2019-10-24 11:59   ` Linus Walleij
  2019-10-24 13:34     ` Vaittinen, Matti
  0 siblings, 1 reply; 29+ messages in thread
From: Linus Walleij @ 2019-10-24 11:59 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Lee Jones, Rob Herring, Mark Rutland,
	Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek, Dan Murphy,
	Alessandro Zummo, Alexandre Belloni,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	linux-kernel, linux-clk, open list:GPIO SUBSYSTEM,
	Linux LED Subsystem, linux-rtc

Hi Matti,

Thanks for your patch!

On Thu, Oct 24, 2019 at 1:51 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> ROHM BD71828 PMIC contains 4 pins which can be configured by OTP
> to be used for general purposes. First 3 can be used as outputs
> and 4.th pin can be used as input. Allow them to be controlled
> via GPIO framework.
>
> The driver assumes all of the pins are configured as GPIOs and
> trusts that the reserved pins in other OTP configurations are
> excluded from control using "gpio-reserved-ranges" device tree
> property (or left untouched by GPIO users).
>
> Typical use for 4.th pin (input) is to use it as HALL sensor
> input so that this pin state is toggled when HALL sensor detects
> LID position change (from close to open or open to close). PMIC
> HW implements some extra logic which allows PMIC to power-up the
> system when this pin is toggled. Please see the data sheet for
> details of GPIO options which can be selcted by OTP settings.

spelling of selected

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

Overall looks very good.

> +// SPDX-License-Identifier: GPL-2.0

I think they want you to use GPL-2.0-only these days.

> +#define BD71828_OUT 0
> +#define BD71828_IN 1

These have nothing to do with BD71828, just skip these defines
and hardcode 0/1 in the code called from gpiolib. If we want defines
for this they should be generically named and put in
<linux/gpio/driver.h>

Nice use of the config API!

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs
  2019-10-24 11:59   ` Linus Walleij
@ 2019-10-24 13:34     ` Vaittinen, Matti
  0 siblings, 0 replies; 29+ messages in thread
From: Vaittinen, Matti @ 2019-10-24 13:34 UTC (permalink / raw)
  To: linus.walleij
  Cc: dmurphy, linux-leds, linux-rtc, linux-gpio, alexandre.belloni,
	linux-kernel, mturquette, lgirdwood, jacek.anaszewski,
	mazziesaccount, a.zummo, devicetree, mark.rutland, robh+dt,
	bgolaszewski, linux-clk, pavel, sboyd, broonie, lee.jones

Hello Linus,

Thanks again for the review :) Highly appreciated!

On Thu, 2019-10-24 at 13:59 +0200, Linus Walleij wrote:
> On Thu, Oct 24, 2019 at 1:51 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
> 
> > ROHM BD71828 PMIC contains 4 pins which can be configured by OTP
> > to be used for general purposes. First 3 can be used as outputs
> > and 4.th pin can be used as input. Allow them to be controlled
> > via GPIO framework.
> > 
> > The driver assumes all of the pins are configured as GPIOs and
> > trusts that the reserved pins in other OTP configurations are
> > excluded from control using "gpio-reserved-ranges" device tree
> > property (or left untouched by GPIO users).
> > 
> > Typical use for 4.th pin (input) is to use it as HALL sensor
> > input so that this pin state is toggled when HALL sensor detects
> > LID position change (from close to open or open to close). PMIC
> > HW implements some extra logic which allows PMIC to power-up the
> > system when this pin is toggled. Please see the data sheet for
> > details of GPIO options which can be selcted by OTP settings.
> 
> spelling of selected

Right, thanks.

> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> 
> Overall looks very good.
> 
> > +// SPDX-License-Identifier: GPL-2.0
> 
> I think they want you to use GPL-2.0-only these days.

Hmm. Is this documented somewhere? The LICENSES/preferred/GPL-2.0
still states:
Valid-License-Identifier: GPL-2.0
Valid-License-Identifier: GPL-2.0-only
Valid-License-Identifier: GPL-2.0+
Valid-License-Identifier: GPL-2.0-or-later
SPDX-URL: https://spdx.org/licenses/GPL-2.0.html
Usage-Guide:
  To use this license in source code, put one of the following SPDX
  tag/value pairs into a comment according to the placement
  guidelines in the licensing rules documentation.
  For 'GNU General Public License (GPL) version 2 only' use:
    SPDX-License-Identifier: GPL-2.0
  or
    SPDX-License-Identifier: GPL-2.0-only
  For 'GNU General Public License (GPL) version 2 or any later version'
use:
    SPDX-License-Identifier: GPL-2.0+
  or
    SPDX-License-Identifier: GPL-2.0-or-later

(at least for 5.4-rc2)

This looks like "GPL-2.0" should still be valid. Not that I have
anything against the "GPL-2.0-only" - I am just a tiny bit frustrated
what comes to polishing the SPDX format :/

> > +#define BD71828_OUT 0
> > +#define BD71828_IN 1
> 
> These have nothing to do with BD71828, just skip these defines
> and hardcode 0/1 in the code called from gpiolib.

I personally don't like using 0/1 as I _always_ need to check which is
IN and which is OUT. It must be somehow related to my brain chemistry
but this just does not stay in my mind over a weekend... But you are
right - having these defines in bd71828 driver does not help much. When
I start with next GPIO chip I must once again dig the values from these
defines or from somewhere else. Thus...

>  If we want defines
> for this they should be generically named and put in
> <linux/gpio/driver.h>

...placing the defines in this header which is visible also in next
driver would be "the right thing to do"(tm).

Do you think we should add the defines there then? I was not trying to
do that as I thought that someone really loves the raw numbers and
dislikes defines - as these hard-coded values 1 and 0 seem to be used
everywhere... :] Maybe the plain numbers are only difficult for me?

> Nice use of the config API!

Thanks =) I admit I have stolen that from some other driver. So I don't
really deserve the credits =) It's easy to build when the foundations
are done well ;)

Br,
	Matti Vaittinen

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-24 11:41 ` [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
@ 2019-10-24 19:35   ` Dan Murphy
  2019-10-25  5:49     ` Vaittinen, Matti
  0 siblings, 1 reply; 29+ messages in thread
From: Dan Murphy @ 2019-10-24 19:35 UTC (permalink / raw)
  To: Matti Vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Stephen Boyd, Linus Walleij,
	Bartosz Golaszewski, Jacek Anaszewski, Pavel Machek,
	Alessandro Zummo, Alexandre Belloni, devicetree, linux-kernel,
	linux-clk, linux-gpio, linux-leds, linux-rtc

Matti

On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> ROHM BD71828 Power management IC integrates 7 buck converters, 7 LDOs,
> a real-time clock (RTC), 3 GPO/regulator control pins, HALL input
> and a 32.768 kHz clock gate.
>
> Document the dt bindings drivers are using.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> ---
>
> No changes since v1
>
>   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180 ++++++++++++++++++
>   1 file changed, 180 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt

I will let maintainers weigh in here but if this is new this should 
probably be in the yaml format to avoid conversion in the future


> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> new file mode 100644
> index 000000000000..125efa9f3de0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> @@ -0,0 +1,180 @@
> +* ROHM BD71828 Power Management Integrated Circuit bindings
> +
> +BD71828GW is a single-chip power management IC for battery-powered portable
> +devices. The IC integrates 7 buck converters, 7 LDOs, and a 1500 mA single-cell
> +linear charger. Also included is a Coulomb counter, a real-time clock (RTC),
> +and a 32.768 kHz clock gate.
> +
> +Required properties:
> + - compatible			: Should be "rohm,bd71828".
> + - reg				: I2C slave address.
> + - interrupt-parent		: Phandle to the parent interrupt controller.
> + - interrupts			: The interrupt line the device is connected to.
> + - clocks			: The parent clock connected to PMIC.
> + - #clock-cells			: Should be 0.
> + - regulators			: List of child nodes that specify the
> +				  regulators. Please see
> +				  ../regulator/rohm,bd71828-regulator.txt
> + - gpio-controller		: To indicate BD71828 acts as a GPIO controller.
> + - #gpio-cells			: Should be 2. The first cell is the pin number
> +				  and the second cell is used to specify flags.
> +				  See ../gpio/gpio.txt for more information.
> +
> +The BD71828 RUN state is divided into 4 configurable run-levels named RUN0,
> +RUN1, RUN2 and RUN3. Bucks 1, 2, 6 and 7 can be either controlled individually
> +via I2C, or some/all of them can be bound to run-levels and controlled as a
> +group. If bucks are controlled individually these run-levels are ignored. See
> +../regulator/rohm,bd71828-regulator.txt for how to define regulator voltages
The rohm,bd71828-regulator.txt should be yaml if the maintainers want it 
that way.
> +for run-levels. Run-levels can be changed by I2C or GPIO depending on PMIC's OTP
> +configuration.
> +
> +Optional properties:
> +- clock-output-names		: Should contain name for output clock.
> +- rohm,dvs-vsel-gpios		: GPIOs used to control PMIC run-levels. Should
> +				  describe two GPIOs. (See run-level control in
> +				  data-sheet). If this property is omitted but
> +				  some bucks are marked to be controlled by
> +				  run-levels - then OTP option allowing
> +				  run-level control via I2C is assumed.
> +- gpio-reserved-ranges		: Usage of GPIO pins can be changed via OTP.
> +				  This property can be used to mark the pins
> +				  which should not be configured for GPIO.
> +				  Please see the ../gpio/gpio.txt for more
> +				  information.
> +
> +Example:
> +

This example does not look right.

I see that I2C is referenced above so the example could look like this

osc: oscillator {
                 compatible = "fixed-clock";
                 #clock-cells = <1>;
                 clock-frequency  = <32768>;
                 clock-output-names = "osc";
         };

This is an external oscillator and is not really part of the pmic 
itself.  I am not sure you even need to define that since it is not part 
of the pmic.

i2c {

         pmic@4b {

                 [...]

         };

};

Dan

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-24 19:35   ` Dan Murphy
@ 2019-10-25  5:49     ` Vaittinen, Matti
  2019-10-29 12:08       ` Lee Jones
  2019-10-29 19:34       ` Rob Herring
  0 siblings, 2 replies; 29+ messages in thread
From: Vaittinen, Matti @ 2019-10-25  5:49 UTC (permalink / raw)
  To: mazziesaccount, dmurphy
  Cc: linux-leds, linux-rtc, linux-gpio, linux-kernel,
	alexandre.belloni, mturquette, lgirdwood, devicetree,
	jacek.anaszewski, a.zummo, linus.walleij, mark.rutland, robh+dt,
	bgolaszewski, linux-clk, sboyd, pavel, broonie, lee.jones

Hello Dan,

Thanks again for checking this :)

On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> Matti
> 
> On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > ROHM BD71828 Power management IC integrates 7 buck converters, 7
> > LDOs,
> > a real-time clock (RTC), 3 GPO/regulator control pins, HALL input
> > and a 32.768 kHz clock gate.
> > 
> > Document the dt bindings drivers are using.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> > 
> > No changes since v1
> > 
> >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > ++++++++++++++++++
> >   1 file changed, 180 insertions(+)
> >   create mode 100644
> > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> 
> I will let maintainers weigh in here but if this is new this should 
> probably be in the yaml format to avoid conversion in the future

Oh... This is new to me. I guess there are reasons for this - but I
must say I am not excited as I have never used yaml for anything. I'll
do as you suggest and wait for what others have to say :) Thanks for
pointing this out though.

> > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-
> > pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71828-
> > pmic.txt
> > new file mode 100644
> > index 000000000000..125efa9f3de0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > @@ -0,0 +1,180 @@
> > +* ROHM BD71828 Power Management Integrated Circuit bindings
> > +
> > +BD71828GW is a single-chip power management IC for battery-powered 
> > portable
> > +devices. The IC integrates 7 buck converters, 7 LDOs, and a 1500
> > mA single-cell
> > +linear charger. Also included is a Coulomb counter, a real-time
> > clock (RTC),
> > +and a 32.768 kHz clock gate.
> > +
> > +Required properties:
> > + - compatible			: Should be "rohm,bd71828".
> > + - reg				: I2C slave address.
> > + - interrupt-parent		: Phandle to the parent
> > interrupt controller.
> > + - interrupts			: The interrupt line the device
> > is connected to.
> > + - clocks			: The parent clock connected to PMIC.
> > + - #clock-cells			: Should be 0.
> > + - regulators			: List of child nodes that
> > specify the
> > +				  regulators. Please see
> > +				  ../regulator/rohm,bd71828-
> > regulator.txt
> > + - gpio-controller		: To indicate BD71828 acts as a GPIO
> > controller.
> > + - #gpio-cells			: Should be 2. The first cell
> > is the pin number
> > +				  and the second cell is used to
> > specify flags.
> > +				  See ../gpio/gpio.txt for more
> > information.
> > +
> > +The BD71828 RUN state is divided into 4 configurable run-levels
> > named RUN0,
> > +RUN1, RUN2 and RUN3. Bucks 1, 2, 6 and 7 can be either controlled
> > individually
> > +via I2C, or some/all of them can be bound to run-levels and
> > controlled as a
> > +group. If bucks are controlled individually these run-levels are
> > ignored. See
> > +../regulator/rohm,bd71828-regulator.txt for how to define
> > regulator voltages

> The rohm,bd71828-regulator.txt should be yaml if the maintainers want
> it 
> that way.

Let's see if this should be changed then :)

> > +for run-levels. Run-levels can be changed by I2C or GPIO depending
> > on PMIC's OTP
> > +configuration.
> > +
> > +Optional properties:
> > +- clock-output-names		: Should contain name for
> > output clock.
> > +- rohm,dvs-vsel-gpios		: GPIOs used to control PMIC
> > run-levels. Should
> > +				  describe two GPIOs. (See run-level
> > control in
> > +				  data-sheet). If this property is
> > omitted but
> > +				  some bucks are marked to be
> > controlled by
> > +				  run-levels - then OTP option allowing
> > +				  run-level control via I2C is assumed.
> > +- gpio-reserved-ranges		: Usage of GPIO pins can be
> > changed via OTP.
> > +				  This property can be used to mark the
> > pins
> > +				  which should not be configured for
> > GPIO.
> > +				  Please see the ../gpio/gpio.txt for
> > more
> > +				  information.
> > +
> > +Example:
> > +
> 
> This example does not look right.
> 
> I see that I2C is referenced above so the example could look like
> this
> 
> osc: oscillator {
>                  compatible = "fixed-clock";
>                  #clock-cells = <1>;
>                  clock-frequency  = <32768>;
>                  clock-output-names = "osc";
>          };
> 
> This is an external oscillator and is not really part of the pmic 
> itself.  I am not sure you even need to define that since it is not
> part 
> of the pmic.

I think you are correct. I'll drop this oscillator for next patch.

> 
> i2c {
> 
>          pmic@4b {
> 
>                  [...]
> 
>          };
> 
> };

I don't think the I2C node is needed in example. It is not part of the
PMIC - and I don't see the containing bus in other examples I just
opened. (the two other rohm,xxx PMIC docs - well, biased as I wrote
them), da9150.txt, lp3943.txt, max77686.txt, tps6507x.txt, tps65910.txt
...

Br,
	Matti Vaittinen


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block
  2019-10-24 11:44 ` [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
@ 2019-10-28 23:32   ` Stephen Boyd
  2019-10-29  6:28     ` Vaittinen, Matti
  0 siblings, 1 reply; 29+ messages in thread
From: Stephen Boyd @ 2019-10-28 23:32 UTC (permalink / raw)
  To: matti.vaittinen, mazziesaccount
  Cc: Lee Jones, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
	Michael Turquette, Linus Walleij, Bartosz Golaszewski,
	Jacek Anaszewski, Pavel Machek, Dan Murphy, Alessandro Zummo,
	Alexandre Belloni, devicetree, linux-kernel, linux-clk,
	linux-gpio, linux-leds, linux-rtc

Quoting Matti Vaittinen (2019-10-24 04:44:40)
> diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
> index ae6e5baee330..d17a19e04592 100644
> --- a/drivers/clk/clk-bd718x7.c
> +++ b/drivers/clk/clk-bd718x7.c
> @@ -8,6 +8,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
>  #include <linux/mfd/rohm-bd718x7.h>
> +#include <linux/mfd/rohm-bd71828.h>
>  #include <linux/mfd/rohm-bd70528.h>

It would be really great to not need to include these random header
files in this driver and just use raw numbers somehow. Looks like maybe
it can be done by populating a different device name from the mfd driver
depending on the version of the clk controller desired? Then that can be
matched in this clk driver and we can just put the register info in this
file?

>  #include <linux/clk-provider.h>
>  #include <linux/clkdev.h>
> @@ -21,10 +22,8 @@ struct bd718xx_clk {
>         struct rohm_regmap_dev *mfd;
>  };
>  
> -static int bd71837_clk_set(struct clk_hw *hw, int status)
> +static int bd71837_clk_set(struct bd718xx_clk *c, int status)

should it be unsigned int status? Or maybe u32?

>  {
> -       struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
> -
>         return regmap_update_bits(c->mfd->regmap, c->reg, c->mask, status);
>  }
>  
> @@ -33,14 +32,16 @@ static void bd71837_clk_disable(struct clk_hw *hw)
>         int rv;
>         struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
>  
> -       rv = bd71837_clk_set(hw, 0);
> +       rv = bd71837_clk_set(c, 0);
>         if (rv)
>                 dev_dbg(&c->pdev->dev, "Failed to disable 32K clk (%d)\n", rv);
>  }
>  
>  static int bd71837_clk_enable(struct clk_hw *hw)
>  {
> -       return bd71837_clk_set(hw, 1);
> +       struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
> +
> +       return bd71837_clk_set(c, 0xffffffff);

Because now this is passing -1 to unsigned int taking
regmap_update_bits()?


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block
  2019-10-28 23:32   ` Stephen Boyd
@ 2019-10-29  6:28     ` Vaittinen, Matti
       [not found]       ` <20191105005541.7913220717@mail.kernel.org>
  0 siblings, 1 reply; 29+ messages in thread
From: Vaittinen, Matti @ 2019-10-29  6:28 UTC (permalink / raw)
  To: mazziesaccount, sboyd
  Cc: dmurphy, linux-leds, linux-rtc, linux-gpio, linux-kernel,
	alexandre.belloni, mturquette, lgirdwood, jacek.anaszewski,
	devicetree, a.zummo, linus.walleij, mark.rutland, robh+dt,
	bgolaszewski, linux-clk, pavel, lee.jones, broonie

Hello Stephen,

Thanks for the comments once again :)

On Mon, 2019-10-28 at 16:32 -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2019-10-24 04:44:40)
> > diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
> > index ae6e5baee330..d17a19e04592 100644
> > --- a/drivers/clk/clk-bd718x7.c
> > +++ b/drivers/clk/clk-bd718x7.c
> > @@ -8,6 +8,7 @@
> >  #include <linux/platform_device.h>
> >  #include <linux/slab.h>
> >  #include <linux/mfd/rohm-bd718x7.h>
> > +#include <linux/mfd/rohm-bd71828.h>
> >  #include <linux/mfd/rohm-bd70528.h>
> 
> It would be really great to not need to include these random header
> files in this driver and just use raw numbers somehow. Looks like
> maybe
> it can be done by populating a different device name from the mfd
> driver
> depending on the version of the clk controller desired? Then that can
> be
> matched in this clk driver and we can just put the register info in
> this
> file?

I still like keeping the chip type information on one header - no
matter what-ever format the clk-controller type/version information is.
Rationale is that MFD and also few other sub-devices (not only the clk)
need to use it. Currently at least the RTC.

But if we define clk register information for all PMICs in this c-file, 
then (I think) we can only include the <linux/mfd/rohm-generic.h> -
which contains the PMIC type defines and the generic MFD data
structure. That would:

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

That way the chip-type information could still be same for MFD and all
sub-devices but clk driver would not need to include all the details
for all the PMICs. I understand your point well as clk registers for
these PMICs are really *limited*.

> 
> >  #include <linux/clk-provider.h>
> >  #include <linux/clkdev.h>
> > @@ -21,10 +22,8 @@ struct bd718xx_clk {
> >         struct rohm_regmap_dev *mfd;
> >  };
> >  
> > -static int bd71837_clk_set(struct clk_hw *hw, int status)
> > +static int bd71837_clk_set(struct bd718xx_clk *c, int status)
> 
> should it be unsigned int status? Or maybe u32?
> 
> >  {
> > -       struct bd718xx_clk *c = container_of(hw, struct
> > bd718xx_clk, hw);
> > -
> >         return regmap_update_bits(c->mfd->regmap, c->reg, c->mask,
> > status);
> >  }
> >  
> > @@ -33,14 +32,16 @@ static void bd71837_clk_disable(struct clk_hw
> > *hw)
> >         int rv;
> >         struct bd718xx_clk *c = container_of(hw, struct
> > bd718xx_clk, hw);
> >  
> > -       rv = bd71837_clk_set(hw, 0);
> > +       rv = bd71837_clk_set(c, 0);
> >         if (rv)
> >                 dev_dbg(&c->pdev->dev, "Failed to disable 32K clk
> > (%d)\n", rv);
> >  }
> >  
> >  static int bd71837_clk_enable(struct clk_hw *hw)
> >  {
> > -       return bd71837_clk_set(hw, 1);
> > +       struct bd718xx_clk *c = container_of(hw, struct
> > bd718xx_clk, hw);
> > +
> > +       return bd71837_clk_set(c, 0xffffffff);
> 
> Because now this is passing -1 to unsigned int taking
> regmap_update_bits()?

I think that bit-wise it is all the same. Currently registers are only
8bits wide so it is enough that lowest 8 bits are set. And 0xffffffff
should work nicely up-to 32bit registers as long as int is 32 bit or
more.

But you are correct that this is not looking good. At first sight
unsigned int is much nicer. I prefer unsigned int over forced u32 to
guarantee natural alignment - which does not really matter in this case
either. unsigned int matches regmap though so I'll switch to it. Thanks
for pointing this out :)

I'll try to include these clk changes in v3.


Br,
	Matti Vaittinen

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-25  5:49     ` Vaittinen, Matti
@ 2019-10-29 12:08       ` Lee Jones
  2019-10-29 19:34       ` Rob Herring
  1 sibling, 0 replies; 29+ messages in thread
From: Lee Jones @ 2019-10-29 12:08 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: mazziesaccount, dmurphy, linux-leds, linux-rtc, linux-gpio,
	linux-kernel, alexandre.belloni, mturquette, lgirdwood,
	devicetree, jacek.anaszewski, a.zummo, linus.walleij,
	mark.rutland, robh+dt, bgolaszewski, linux-clk, sboyd, pavel,
	broonie

On Fri, 25 Oct 2019, Vaittinen, Matti wrote:

> Hello Dan,
> 
> Thanks again for checking this :)
> 
> On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > Matti
> > 
> > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > ROHM BD71828 Power management IC integrates 7 buck converters, 7
> > > LDOs,
> > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL input
> > > and a 32.768 kHz clock gate.
> > > 
> > > Document the dt bindings drivers are using.
> > > 
> > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > > ---
> > > 
> > > No changes since v1
> > > 
> > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > ++++++++++++++++++
> > >   1 file changed, 180 insertions(+)
> > >   create mode 100644
> > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > 
> > I will let maintainers weigh in here but if this is new this should 
> > probably be in the yaml format to avoid conversion in the future

Yes please.

> Oh... This is new to me. I guess there are reasons for this - but I
> must say I am not excited as I have never used yaml for anything. I'll
> do as you suggest and wait for what others have to say :) Thanks for
> pointing this out though.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-25  5:49     ` Vaittinen, Matti
  2019-10-29 12:08       ` Lee Jones
@ 2019-10-29 19:34       ` Rob Herring
  2019-10-30  8:26         ` Vaittinen, Matti
  1 sibling, 1 reply; 29+ messages in thread
From: Rob Herring @ 2019-10-29 19:34 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: mazziesaccount, dmurphy, linux-leds, linux-rtc, linux-gpio,
	linux-kernel, alexandre.belloni, mturquette, lgirdwood,
	devicetree, jacek.anaszewski, a.zummo, linus.walleij,
	mark.rutland, bgolaszewski, linux-clk, sboyd, pavel, broonie,
	lee.jones

On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti wrote:
> Hello Dan,
> 
> Thanks again for checking this :)
> 
> On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > Matti
> > 
> > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > ROHM BD71828 Power management IC integrates 7 buck converters, 7
> > > LDOs,
> > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL input
> > > and a 32.768 kHz clock gate.
> > > 
> > > Document the dt bindings drivers are using.
> > > 
> > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > > ---
> > > 
> > > No changes since v1
> > > 
> > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > ++++++++++++++++++
> > >   1 file changed, 180 insertions(+)
> > >   create mode 100644
> > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > 
> > I will let maintainers weigh in here but if this is new this should 
> > probably be in the yaml format to avoid conversion in the future
> 
> Oh... This is new to me. I guess there are reasons for this - but I
> must say I am not excited as I have never used yaml for anything. I'll
> do as you suggest and wait for what others have to say :) Thanks for
> pointing this out though.

Sorry for your lack of excitement. It could be XML...

There aren't many MFD examples yet, but there is max77650 in my tree and 
linux-next.

> > > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-
> > > pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71828-
> > > pmic.txt
> > > new file mode 100644
> > > index 000000000000..125efa9f3de0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > > @@ -0,0 +1,180 @@
> > > +* ROHM BD71828 Power Management Integrated Circuit bindings
> > > +
> > > +BD71828GW is a single-chip power management IC for battery-powered 
> > > portable
> > > +devices. The IC integrates 7 buck converters, 7 LDOs, and a 1500
> > > mA single-cell
> > > +linear charger. Also included is a Coulomb counter, a real-time
> > > clock (RTC),
> > > +and a 32.768 kHz clock gate.
> > > +
> > > +Required properties:
> > > + - compatible			: Should be "rohm,bd71828".
> > > + - reg				: I2C slave address.
> > > + - interrupt-parent		: Phandle to the parent
> > > interrupt controller.
> > > + - interrupts			: The interrupt line the device
> > > is connected to.
> > > + - clocks			: The parent clock connected to PMIC.
> > > + - #clock-cells			: Should be 0.
> > > + - regulators			: List of child nodes that
> > > specify the
> > > +				  regulators. Please see
> > > +				  ../regulator/rohm,bd71828-
> > > regulator.txt
> > > + - gpio-controller		: To indicate BD71828 acts as a GPIO
> > > controller.
> > > + - #gpio-cells			: Should be 2. The first cell
> > > is the pin number
> > > +				  and the second cell is used to
> > > specify flags.
> > > +				  See ../gpio/gpio.txt for more
> > > information.
> > > +
> > > +The BD71828 RUN state is divided into 4 configurable run-levels
> > > named RUN0,
> > > +RUN1, RUN2 and RUN3. Bucks 1, 2, 6 and 7 can be either controlled
> > > individually
> > > +via I2C, or some/all of them can be bound to run-levels and
> > > controlled as a
> > > +group. If bucks are controlled individually these run-levels are
> > > ignored. See
> > > +../regulator/rohm,bd71828-regulator.txt for how to define
> > > regulator voltages
> 
> > The rohm,bd71828-regulator.txt should be yaml if the maintainers want
> > it 
> > that way.
> 
> Let's see if this should be changed then :)
> 
> > > +for run-levels. Run-levels can be changed by I2C or GPIO depending
> > > on PMIC's OTP
> > > +configuration.
> > > +
> > > +Optional properties:
> > > +- clock-output-names		: Should contain name for
> > > output clock.
> > > +- rohm,dvs-vsel-gpios		: GPIOs used to control PMIC
> > > run-levels. Should
> > > +				  describe two GPIOs. (See run-level
> > > control in
> > > +				  data-sheet). If this property is
> > > omitted but
> > > +				  some bucks are marked to be
> > > controlled by
> > > +				  run-levels - then OTP option allowing
> > > +				  run-level control via I2C is assumed.
> > > +- gpio-reserved-ranges		: Usage of GPIO pins can be
> > > changed via OTP.
> > > +				  This property can be used to mark the
> > > pins
> > > +				  which should not be configured for
> > > GPIO.
> > > +				  Please see the ../gpio/gpio.txt for
> > > more
> > > +				  information.
> > > +
> > > +Example:
> > > +
> > 
> > This example does not look right.
> > 
> > I see that I2C is referenced above so the example could look like
> > this
> > 
> > osc: oscillator {
> >                  compatible = "fixed-clock";
> >                  #clock-cells = <1>;
> >                  clock-frequency  = <32768>;
> >                  clock-output-names = "osc";
> >          };
> > 
> > This is an external oscillator and is not really part of the pmic 
> > itself.  I am not sure you even need to define that since it is not
> > part 
> > of the pmic.
> 
> I think you are correct. I'll drop this oscillator for next patch.
> 
> > 
> > i2c {
> > 
> >          pmic@4b {
> > 
> >                  [...]
> > 
> >          };
> > 
> > };
> 
> I don't think the I2C node is needed in example. It is not part of the
> PMIC - and I don't see the containing bus in other examples I just
> opened. (the two other rohm,xxx PMIC docs - well, biased as I wrote
> them), da9150.txt, lp3943.txt, max77686.txt, tps6507x.txt, tps65910.txt

It will be needed for the schema because the examples are compiled and 
validated.

Rob

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-29 19:34       ` Rob Herring
@ 2019-10-30  8:26         ` Vaittinen, Matti
  2019-10-30 19:22           ` Rob Herring
  0 siblings, 1 reply; 29+ messages in thread
From: Vaittinen, Matti @ 2019-10-30  8:26 UTC (permalink / raw)
  To: robh
  Cc: dmurphy, linux-leds, linux-rtc, linux-gpio, linux-kernel,
	alexandre.belloni, mazziesaccount, mturquette, devicetree,
	jacek.anaszewski, linus.walleij, a.zummo, lgirdwood,
	mark.rutland, bgolaszewski, linux-clk, sboyd, pavel, broonie,
	lee.jones


On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti wrote:
> > Hello Dan,
> > 
> > Thanks again for checking this :)
> > 
> > On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > > Matti
> > > 
> > > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > > ROHM BD71828 Power management IC integrates 7 buck converters,
> > > > 7
> > > > LDOs,
> > > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL
> > > > input
> > > > and a 32.768 kHz clock gate.
> > > > 
> > > > Document the dt bindings drivers are using.
> > > > 
> > > > Signed-off-by: Matti Vaittinen <
> > > > matti.vaittinen@fi.rohmeurope.com>
> > > > ---
> > > > 
> > > > No changes since v1
> > > > 
> > > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > > ++++++++++++++++++
> > > >   1 file changed, 180 insertions(+)
> > > >   create mode 100644
> > > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > > 
> > > I will let maintainers weigh in here but if this is new this
> > > should 
> > > probably be in the yaml format to avoid conversion in the future
> > 
> > Oh... This is new to me. I guess there are reasons for this - but I
> > must say I am not excited as I have never used yaml for anything.
> > I'll
> > do as you suggest and wait for what others have to say :) Thanks
> > for
> > pointing this out though.
> 
> Sorry for your lack of excitement. It could be XML...

Thanks, I appreciate that, apology accepted X-D

> There aren't many MFD examples yet, but there is max77650 in my tree
> and 
> linux-next.

I looked at the max77650 MFD binding from linux-next. After that I also
looked some of the generic documents for DT bindings (I know - I should
have done that earlier and your job had been easier). But all that left
me "slightly" puzzled. After some further wandering in the virtual
world I spotted this:
https://elinux.org/images/6/6b/LPC2018_json-schema_for_Devicetree.pdf

I think this link in some dt-yaml-binding-readme might be helpful.

So if I understand this correctly, idea is to convert the dts sources
to use yaml (right?). This is seen better because more people know
JSON/YAML than dts format(?) Fair enough. Although some of us know dts
format decently well but have never used JSON or yaml. I guess dts
support is not going away though and yaml examples do not seem terribly
hard at first sight.

What comes to binding docs - well, in my eyes (which may be biased)
writing documentation in anything intended to be interpreted by a
machine is still a step backwards for a human document reader. Sure
syntax validation or reviewing is easier if format is machine readable
- but free text info is more, well, informative (form me at least). I
for example wouldn't like reading a book written in any script or
markup language. Nor writing one. It is difficult for me to understand
the documentation change to yaml, maybe because I am more often using
the binding docs for composing DT for a device than reviewing them ;)

Anyways, I guess I'd better either try learning the yaml, figure out
what are schemas and see how to convert yaml docs to text for nicer
reading (I assume this is doable) and how to verify yaml binding docs
are Ok - or quit contributing. No one is forcing me to do this.
Continuing complaining on this is probably not getting us anywhere so I
might as well shut up now :/

And Sorry Rob. I am seeing you have been really close to this yaml/JSON
change so my wondering may be frustrating. I don't intend to be
disrespectful - I see that you have done huge work with this. I am
just... ...Slightly set in my ways. Little bit pig-headed and somewhat
a smart-arse - so I couldn't just let it go without giving out an
opinion.

> > > i2c {
> > > 
> > >          pmic@4b {
> > > 
> > >                  [...]
> > > 
> > >          };
> > > 
> > > };
> > 
> > I don't think the I2C node is needed in example. It is not part of
> > the
> > PMIC - and I don't see the containing bus in other examples I just
> > opened. (the two other rohm,xxx PMIC docs - well, biased as I wrote
> > them), da9150.txt, lp3943.txt, max77686.txt, tps6507x.txt,
> > tps65910.txt
> 
> It will be needed for the schema because the examples are compiled
> and 
> validated.

Thanks for explaining the reason.

Br,
	Matti Vaittinen


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-30  8:26         ` Vaittinen, Matti
@ 2019-10-30 19:22           ` Rob Herring
  2019-10-31 12:54             ` Vaittinen, Matti
  0 siblings, 1 reply; 29+ messages in thread
From: Rob Herring @ 2019-10-30 19:22 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: dmurphy, linux-leds, linux-rtc, linux-gpio, linux-kernel,
	alexandre.belloni, mazziesaccount, mturquette, devicetree,
	jacek.anaszewski, linus.walleij, a.zummo, lgirdwood,
	mark.rutland, bgolaszewski, linux-clk, sboyd, pavel, broonie,
	lee.jones

On Wed, Oct 30, 2019 at 3:27 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:
>
>
> On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> > On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti wrote:
> > > Hello Dan,
> > >
> > > Thanks again for checking this :)
> > >
> > > On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > > > Matti
> > > >
> > > > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > > > ROHM BD71828 Power management IC integrates 7 buck converters,
> > > > > 7
> > > > > LDOs,
> > > > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL
> > > > > input
> > > > > and a 32.768 kHz clock gate.
> > > > >
> > > > > Document the dt bindings drivers are using.
> > > > >
> > > > > Signed-off-by: Matti Vaittinen <
> > > > > matti.vaittinen@fi.rohmeurope.com>
> > > > > ---
> > > > >
> > > > > No changes since v1
> > > > >
> > > > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > > > ++++++++++++++++++
> > > > >   1 file changed, 180 insertions(+)
> > > > >   create mode 100644
> > > > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > > >
> > > > I will let maintainers weigh in here but if this is new this
> > > > should
> > > > probably be in the yaml format to avoid conversion in the future
> > >
> > > Oh... This is new to me. I guess there are reasons for this - but I
> > > must say I am not excited as I have never used yaml for anything.
> > > I'll
> > > do as you suggest and wait for what others have to say :) Thanks
> > > for
> > > pointing this out though.
> >
> > Sorry for your lack of excitement. It could be XML...
>
> Thanks, I appreciate that, apology accepted X-D
>
> > There aren't many MFD examples yet, but there is max77650 in my tree
> > and
> > linux-next.
>
> I looked at the max77650 MFD binding from linux-next. After that I also
> looked some of the generic documents for DT bindings (I know - I should
> have done that earlier and your job had been easier). But all that left
> me "slightly" puzzled. After some further wandering in the virtual
> world I spotted this:
> https://elinux.org/images/6/6b/LPC2018_json-schema_for_Devicetree.pdf
>
> I think this link in some dt-yaml-binding-readme might be helpful.

Presentations bit rot, so I'd rather not. I'd hope that
writing-schema.rst and example-schema.yaml capture what's in the
presentation. What do you think is missing?

> So if I understand this correctly, idea is to convert the dts sources
> to use yaml (right?). This is seen better because more people know
> JSON/YAML than dts format(?) Fair enough. Although some of us know dts
> format decently well but have never used JSON or yaml. I guess dts
> support is not going away though and yaml examples do not seem terribly
> hard at first sight.

No, nothing is changing for .dts files (other than fixing errors the
schemas find). The free form, human readable only prose called binding
documentation is changing to YAML formatted, json-schema vocabulary
binding schema which can be used to validate dts files.

> What comes to binding docs - well, in my eyes (which may be biased)
> writing documentation in anything intended to be interpreted by a
> machine is still a step backwards for a human document reader. Sure
> syntax validation or reviewing is easier if format is machine readable
> - but free text info is more, well, informative (form me at least). I
> for example wouldn't like reading a book written in any script or
> markup language. Nor writing one. It is difficult for me to understand
> the documentation change to yaml, maybe because I am more often using
> the binding docs for composing DT for a device than reviewing them ;)

ICYMI, all the kernel docs are in a markup language now...

Free form descriptions are easier to use because you can put in dts
whatever you want. Nothing is going to check. There's been no shortage
of errors and inconsistencies that we've already found.

You can have as much description and comments as you like (though I'm
trying to cut down on the copy-n-paste genericish 'clock for the
module' type comments).

> Anyways, I guess I'd better either try learning the yaml, figure out
> what are schemas and see how to convert yaml docs to text for nicer
> reading (I assume this is doable) and how to verify yaml binding docs
> are Ok - or quit contributing. No one is forcing me to do this.
> Continuing complaining on this is probably not getting us anywhere so I
> might as well shut up now :/

There is some notion to convert the DT spec to schema and then
generate the spec from the schema. Take properties, their type, and
descriptions and put that back into tables for example. Would love to
have someone work on that. :)

> And Sorry Rob. I am seeing you have been really close to this yaml/JSON
> change so my wondering may be frustrating. I don't intend to be
> disrespectful - I see that you have done huge work with this. I am
> just... ...Slightly set in my ways. Little bit pig-headed and somewhat
> a smart-arse - so I couldn't just let it go without giving out an
> opinion.

Everyone is welcome to their opinion.

Rob

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-30 19:22           ` Rob Herring
@ 2019-10-31 12:54             ` Vaittinen, Matti
  2019-10-31 17:50               ` Rob Herring
  0 siblings, 1 reply; 29+ messages in thread
From: Vaittinen, Matti @ 2019-10-31 12:54 UTC (permalink / raw)
  To: robh
  Cc: lee.jones, dmurphy, linux-leds, linux-rtc, linux-gpio,
	linux-kernel, alexandre.belloni, mazziesaccount, mturquette,
	lgirdwood, devicetree, linus.walleij, a.zummo, mark.rutland,
	bgolaszewski, linux-clk, sboyd, pavel, jacek.anaszewski, broonie


On Wed, 2019-10-30 at 14:22 -0500, Rob Herring wrote:
> On Wed, Oct 30, 2019 at 3:27 AM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > 
> > On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> > > On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti wrote:
> > > > Hello Dan,
> > > > 
> > > > Thanks again for checking this :)
> > > > 
> > > > On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > > > > Matti
> > > > > 
> > > > > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > > > > ROHM BD71828 Power management IC integrates 7 buck
> > > > > > converters,
> > > > > > 7
> > > > > > LDOs,
> > > > > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL
> > > > > > input
> > > > > > and a 32.768 kHz clock gate.
> > > > > > 
> > > > > > Document the dt bindings drivers are using.
> > > > > > 
> > > > > > Signed-off-by: Matti Vaittinen <
> > > > > > matti.vaittinen@fi.rohmeurope.com>
> > > > > > ---
> > > > > > 
> > > > > > No changes since v1
> > > > > > 
> > > > > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > > > > ++++++++++++++++++
> > > > > >   1 file changed, 180 insertions(+)
> > > > > >   create mode 100644
> > > > > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > > > > 
> > > > > I will let maintainers weigh in here but if this is new this
> > > > > should
> > > > > probably be in the yaml format to avoid conversion in the
> > > > > future
> > > > 
> > > > Oh... This is new to me. I guess there are reasons for this -
> > > > but I
> > > > must say I am not excited as I have never used yaml for
> > > > anything.
> > > > I'll
> > > > do as you suggest and wait for what others have to say :)
> > > > Thanks
> > > > for
> > > > pointing this out though.
> > > 
> > > Sorry for your lack of excitement. It could be XML...
> > 
> > Thanks, I appreciate that, apology accepted X-D
> > 
> > > There aren't many MFD examples yet, but there is max77650 in my
> > > tree
> > > and
> > > linux-next.
> > 
> > I looked at the max77650 MFD binding from linux-next. After that I
> > also
> > looked some of the generic documents for DT bindings (I know - I
> > should
> > have done that earlier and your job had been easier). But all that
> > left
> > me "slightly" puzzled. After some further wandering in the virtual
> > world I spotted this:
> > https://elinux.org/images/6/6b/LPC2018_json-schema_for_Devicetree.pdf
> > 
> > I think this link in some dt-yaml-binding-readme might be helpful.
> 
> Presentations bit rot, so I'd rather not. I'd hope that
> writing-schema.rst and example-schema.yaml capture what's in the
> presentation. What do you think is missing?

I personally wanted to understand "why?". Why not text doc. What is the
yaml thing aiming at? What are the problems we are solving here. And
maybe most crucially - I had no idea what is schema? It sure sounded
like some toolchain thingy or perhaps piece of new yaml representation
of dts (please note, I somehow thought that dts files were going to be
converted to yaml - maybe due to some reading about DTC getting yaml
support) which I thought would not need to be touched by me :) It took
me quite a while to understand that the old binding doc is actually a
schema. Without that piece finding out the new format of binding docs
was painful.

Also, binding and binding document were not completely same thing in my
mind. I thought that binding is actual piece of dt - probably living
under arch/x/boot/dts - binding document is what explains how that
should be construct and is under Documentation/devicetree/bindings/.
This is probably largely due to my ignorance and habit oh skipping much
of reading and just trying out things. But I hoped I had these cleared
in first documents I tried reading for creation binding docs..

...which brings me here. I looked at the
Documentation/devicetree/bindings folder and did read the 'writing-
bindings.txt' and 'submitting-patches.txt' from there. Then I also
checked the Documentation/devicetree/usage-model.txt None of which
helped me out. I did also open the 'writing-schema.rst' but I didn't
read it carefully enough. Probably because I thought after reading the
opening chapter that this described how to do actual dts in yaml.

Anyways, I might add some notes about using yaml format (and perhaps
shortly note that the yaml dt binding doc is called schema) in
Documentation/devicetree/bindings/writing-bindings.txt and
Documentation/devicetree/bindings/submitting-patches.txt

I could also appreciate some note about benefits/goals of using yaml
instead of text docs in writing-schema.rst - although I understand that
this may not be relevant for all readers.

> > So if I understand this correctly, idea is to convert the dts
> > sources
> > to use yaml (right?). This is seen better because more people
> > knowsubmitting-patches.txt
> > JSON/YAML than dts format(?) Fair enough. Although some of us know
> > dts
> > format decently well but have never used JSON or yaml. I guess dts
> > support is not going away though and yaml examples do not seem
> > terribly
> > hard at first sight.
> 
> No, nothing is changing for .dts files (other than fixing errors the
> schemas find). The free form, human readable only prose called
> binding
> documentation is changing to YAML formatted, json-schema vocabulary
> binding schema which can be used to validate dts files.

Thanks for sorting this out. It all makes more sense now.

> > What comes to binding docs - well, in my eyes (which may be biased)
> > writing documentation in anything intended to be interpreted by a
> > machine is still a step backwards for a human document reader. Sure
> > syntax validation or reviewing is easier if format is machine
> > readable
> > - but free text info is more, well, informative (form me at least).
> > I
> > for example wouldn't like reading a book written in any script or
> > markup language. Nor writing one. It is difficult for me to
> > understand
> > the documentation change to yaml, maybe because I am more often
> > using
> > the binding docs for composing DT for a device than reviewing them
> > ;)
> 
> ICYMI, all the kernel docs are in a markup language now...
> 
> Free form descriptions are easier to use because you can put in dts
> whatever you want. Nothing is going to check. There's been no
> shortage
> of errors and inconsistencies that we've already found.

I won't start arguing on this :)

> You can have as much description and comments as you like (though I'm
> trying to cut down on the copy-n-paste genericish 'clock for the
> module' type comments).

This is good to note. Thanks.

> > Anyways, I guess I'd better either try learning the yaml, figure
> > out
> > what are schemas and see how to convert yaml docs to text for nicer
> > reading (I assume this is doable) and how to verify yaml binding
> > docs
> > are Ok - or quit contributing. No one is forcing me to do this.
> > Continuing complaining on this is probably not getting us anywhere
> > so I
> > might as well shut up now :/
> 
> There is some notion to convert the DT spec to schema and then
> generate the spec from the schema. Take properties, their type, and
> descriptions and put that back into tables for example. Would love to
> have someone work on that. :)

I am glad to hear you have developed / are developing such tooling. I
really appreciate it. What comes to giving a helping hand - I'd better
to stick the simple C drivers for now ;) But if I ever get the feeling
that I don't know what to do I'll keep this in mind :] Let me do some
calculus... Only 11 years and my youngest son will probably leave our
house - do you think 2030 is a bit too late? Just let me know if this
is still relevant then - and I'll buy you a beer or write a tool (of
some kind) xD

Meanwhile... I have tried to convert the BD71828 DT doc from the RFC
patch to yaml - and I am having hard time. Especially with the
regulators node - which I would like to place in
Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml

My problem is the
regulators {
buck1: BUCK1 {                                                   
                    regulator-name = "buck1";       
                    regulator-min-microvolt = <500000>;
                    regulator-max-microvolt = <2000000>;
                    regulator-ramp-delay = <2500>;
                    rohm,dvs-runlvl-ctrl;
                    rohm,dvs-runlevel0-voltage = <500000>;
                    rohm,dvs-runlevel1-voltage = <506250>;
                    rohm,dvs-runlevel2-voltage = <512500>;
                    rohm,dvs-runlevel3-voltage = <518750>;
                    regulator-boot-on;
    }; 
    ...
};
node which only contains BUCKX and LDOX sub-nodes. It has no own
properties.

From MFD yaml I did try:

  regulators:        
    $ref: ../regulator/rohm,bd71828-regulator.yaml
    description:          
      List of child nodes that specify the regulators.

and in rohm,bd71828-regulator.yaml

I tried doing:

patternProperties:
  "^BUCK[1-7]$":
    type: object
    description:
      Properties for single regulator.
    properties:
        ...

but this fails validation as properties: is not given.

[mvaittin@localhost linux]$ dt-doc-validate
Documentation/devicetree/bindings/regulator/rohm,bd71828-
regulator.yaml 
/home/mvaittin/torvalds/linux/Documentation/devicetree/bindings/regulat
or/rohm,bd71828-regulator.yaml: 'properties' is a required property

If I try and add:

properties:          
  foo: true

patternProperties:
    "^BUCK[1-7]$":
      type: object
      description:
        Properties for single regulator.
      properties:
        ...


then the validation goes (seemingly) smoothly.

I did not find any examples about handiling the empty regulators sub-
node in examples for regulators. Any pointers?

Br,
	Matti Vaittinen





^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-31 12:54             ` Vaittinen, Matti
@ 2019-10-31 17:50               ` Rob Herring
  2019-11-01 12:52                 ` Vaittinen, Matti
  0 siblings, 1 reply; 29+ messages in thread
From: Rob Herring @ 2019-10-31 17:50 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: lee.jones, dmurphy, linux-leds, linux-rtc, linux-gpio,
	linux-kernel, alexandre.belloni, mazziesaccount, mturquette,
	lgirdwood, devicetree, linus.walleij, a.zummo, mark.rutland,
	bgolaszewski, linux-clk, sboyd, pavel, jacek.anaszewski, broonie

On Thu, Oct 31, 2019 at 7:54 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:
>
>
> On Wed, 2019-10-30 at 14:22 -0500, Rob Herring wrote:
> > On Wed, Oct 30, 2019 at 3:27 AM Vaittinen, Matti
> > <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > >
> > > On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> > > > On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti wrote:
> > > > > Hello Dan,
> > > > >
> > > > > Thanks again for checking this :)
> > > > >
> > > > > On Thu, 2019-10-24 at 14:35 -0500, Dan Murphy wrote:
> > > > > > Matti
> > > > > >
> > > > > > On 10/24/19 6:41 AM, Matti Vaittinen wrote:
> > > > > > > ROHM BD71828 Power management IC integrates 7 buck
> > > > > > > converters,
> > > > > > > 7
> > > > > > > LDOs,
> > > > > > > a real-time clock (RTC), 3 GPO/regulator control pins, HALL
> > > > > > > input
> > > > > > > and a 32.768 kHz clock gate.
> > > > > > >
> > > > > > > Document the dt bindings drivers are using.
> > > > > > >
> > > > > > > Signed-off-by: Matti Vaittinen <
> > > > > > > matti.vaittinen@fi.rohmeurope.com>
> > > > > > > ---
> > > > > > >
> > > > > > > No changes since v1
> > > > > > >
> > > > > > >   .../bindings/mfd/rohm,bd71828-pmic.txt        | 180
> > > > > > > ++++++++++++++++++
> > > > > > >   1 file changed, 180 insertions(+)
> > > > > > >   create mode 100644
> > > > > > > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.txt
> > > > > >
> > > > > > I will let maintainers weigh in here but if this is new this
> > > > > > should
> > > > > > probably be in the yaml format to avoid conversion in the
> > > > > > future
> > > > >
> > > > > Oh... This is new to me. I guess there are reasons for this -
> > > > > but I
> > > > > must say I am not excited as I have never used yaml for
> > > > > anything.
> > > > > I'll
> > > > > do as you suggest and wait for what others have to say :)
> > > > > Thanks
> > > > > for
> > > > > pointing this out though.
> > > >
> > > > Sorry for your lack of excitement. It could be XML...
> > >
> > > Thanks, I appreciate that, apology accepted X-D
> > >
> > > > There aren't many MFD examples yet, but there is max77650 in my
> > > > tree
> > > > and
> > > > linux-next.
> > >
> > > I looked at the max77650 MFD binding from linux-next. After that I
> > > also
> > > looked some of the generic documents for DT bindings (I know - I
> > > should
> > > have done that earlier and your job had been easier). But all that
> > > left
> > > me "slightly" puzzled. After some further wandering in the virtual
> > > world I spotted this:
> > > https://elinux.org/images/6/6b/LPC2018_json-schema_for_Devicetree.pdf
> > >
> > > I think this link in some dt-yaml-binding-readme might be helpful.
> >
> > Presentations bit rot, so I'd rather not. I'd hope that
> > writing-schema.rst and example-schema.yaml capture what's in the
> > presentation. What do you think is missing?
>
> I personally wanted to understand "why?". Why not text doc. What is the
> yaml thing aiming at? What are the problems we are solving here. And
> maybe most crucially - I had no idea what is schema? It sure sounded
> like some toolchain thingy or perhaps piece of new yaml representation
> of dts (please note, I somehow thought that dts files were going to be
> converted to yaml - maybe due to some reading about DTC getting yaml
> support) which I thought would not need to be touched by me :) It took
> me quite a while to understand that the old binding doc is actually a
> schema. Without that piece finding out the new format of binding docs
> was painful.

I guess 'why' is easy enough to address.

> Also, binding and binding document were not completely same thing in my
> mind. I thought that binding is actual piece of dt - probably living
> under arch/x/boot/dts - binding document is what explains how that
> should be construct and is under Documentation/devicetree/bindings/.
> This is probably largely due to my ignorance and habit oh skipping much
> of reading and just trying out things. But I hoped I had these cleared
> in first documents I tried reading for creation binding docs..
>
> ...which brings me here. I looked at the
> Documentation/devicetree/bindings folder and did read the 'writing-
> bindings.txt' and 'submitting-patches.txt' from there. Then I also
> checked the Documentation/devicetree/usage-model.txt None of which
> helped me out. I did also open the 'writing-schema.rst' but I didn't
> read it carefully enough. Probably because I thought after reading the
> opening chapter that this described how to do actual dts in yaml.

Things are a bit scattered around I'll admit. I feel like we need a
'start here', but the challenge is people have different starting
points.

> Anyways, I might add some notes about using yaml format (and perhaps
> shortly note that the yaml dt binding doc is called schema) in
> Documentation/devicetree/bindings/writing-bindings.txt and
> Documentation/devicetree/bindings/submitting-patches.txt
>
> I could also appreciate some note about benefits/goals of using yaml
> instead of text docs in writing-schema.rst - although I understand that
> this may not be relevant for all readers.
>
> > > So if I understand this correctly, idea is to convert the dts
> > > sources
> > > to use yaml (right?). This is seen better because more people
> > > knowsubmitting-patches.txt
> > > JSON/YAML than dts format(?) Fair enough. Although some of us know
> > > dts
> > > format decently well but have never used JSON or yaml. I guess dts
> > > support is not going away though and yaml examples do not seem
> > > terribly
> > > hard at first sight.
> >
> > No, nothing is changing for .dts files (other than fixing errors the
> > schemas find). The free form, human readable only prose called
> > binding
> > documentation is changing to YAML formatted, json-schema vocabulary
> > binding schema which can be used to validate dts files.
>
> Thanks for sorting this out. It all makes more sense now.
>
> > > What comes to binding docs - well, in my eyes (which may be biased)
> > > writing documentation in anything intended to be interpreted by a
> > > machine is still a step backwards for a human document reader. Sure
> > > syntax validation or reviewing is easier if format is machine
> > > readable
> > > - but free text info is more, well, informative (form me at least).
> > > I
> > > for example wouldn't like reading a book written in any script or
> > > markup language. Nor writing one. It is difficult for me to
> > > understand
> > > the documentation change to yaml, maybe because I am more often
> > > using
> > > the binding docs for composing DT for a device than reviewing them
> > > ;)
> >
> > ICYMI, all the kernel docs are in a markup language now...
> >
> > Free form descriptions are easier to use because you can put in dts
> > whatever you want. Nothing is going to check. There's been no
> > shortage
> > of errors and inconsistencies that we've already found.
>
> I won't start arguing on this :)
>
> > You can have as much description and comments as you like (though I'm
> > trying to cut down on the copy-n-paste genericish 'clock for the
> > module' type comments).
>
> This is good to note. Thanks.
>
> > > Anyways, I guess I'd better either try learning the yaml, figure
> > > out
> > > what are schemas and see how to convert yaml docs to text for nicer
> > > reading (I assume this is doable) and how to verify yaml binding
> > > docs
> > > are Ok - or quit contributing. No one is forcing me to do this.
> > > Continuing complaining on this is probably not getting us anywhere
> > > so I
> > > might as well shut up now :/
> >
> > There is some notion to convert the DT spec to schema and then
> > generate the spec from the schema. Take properties, their type, and
> > descriptions and put that back into tables for example. Would love to
> > have someone work on that. :)
>
> I am glad to hear you have developed / are developing such tooling.

TBC, I have not and am not. It's just an idea. There's been nothing
done beyond experimenting if rST could be embedded into yaml.

> I
> really appreciate it. What comes to giving a helping hand - I'd better
> to stick the simple C drivers for now ;) But if I ever get the feeling
> that I don't know what to do I'll keep this in mind :] Let me do some
> calculus... Only 11 years and my youngest son will probably leave our
> house - do you think 2030 is a bit too late? Just let me know if this
> is still relevant then - and I'll buy you a beer or write a tool (of
> some kind) xD

I've scheduled you in for 2030. :)

> Meanwhile... I have tried to convert the BD71828 DT doc from the RFC
> patch to yaml - and I am having hard time. Especially with the
> regulators node - which I would like to place in
> Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
>
> My problem is the
> regulators {
> buck1: BUCK1 {
>                     regulator-name = "buck1";
>                     regulator-min-microvolt = <500000>;
>                     regulator-max-microvolt = <2000000>;
>                     regulator-ramp-delay = <2500>;
>                     rohm,dvs-runlvl-ctrl;
>                     rohm,dvs-runlevel0-voltage = <500000>;
>                     rohm,dvs-runlevel1-voltage = <506250>;
>                     rohm,dvs-runlevel2-voltage = <512500>;
>                     rohm,dvs-runlevel3-voltage = <518750>;
>                     regulator-boot-on;
>     };
>     ...
> };
> node which only contains BUCKX and LDOX sub-nodes. It has no own
> properties.
>
> From MFD yaml I did try:
>
>   regulators:
>     $ref: ../regulator/rohm,bd71828-regulator.yaml
>     description:
>       List of child nodes that specify the regulators.
>
> and in rohm,bd71828-regulator.yaml
>
> I tried doing:
>
> patternProperties:
>   "^BUCK[1-7]$":
>     type: object
>     description:
>       Properties for single regulator.
>     properties:
>         ...
>
> but this fails validation as properties: is not given.
>
> [mvaittin@localhost linux]$ dt-doc-validate
> Documentation/devicetree/bindings/regulator/rohm,bd71828-
> regulator.yaml
> /home/mvaittin/torvalds/linux/Documentation/devicetree/bindings/regulat
> or/rohm,bd71828-regulator.yaml: 'properties' is a required property
>
> If I try and add:
>
> properties:
>   foo: true
>
> patternProperties:
>     "^BUCK[1-7]$":
>       type: object
>       description:
>         Properties for single regulator.
>       properties:
>         ...

That's a case of needing to adjust the meta-schema (the schema that
checks the schemas). It's a bit overly restrictive just to try to
contain what's allowed. I've fixed it now. Update dtschema and it
should work now.

BTW, what you will also need is to reference the common schema:

"^BUCK[1-7]$":
  type: object
  allOf:
    - $ref: regulator.yaml#
  properties:
   rohm,dvs-runlvl-ctrl:
     type: boolean
     description: ...
   ...

Rob

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-10-31 17:50               ` Rob Herring
@ 2019-11-01 12:52                 ` Vaittinen, Matti
  2019-11-04 19:28                   ` Rob Herring
  0 siblings, 1 reply; 29+ messages in thread
From: Vaittinen, Matti @ 2019-11-01 12:52 UTC (permalink / raw)
  To: robh
  Cc: broonie, dmurphy, linux-leds, linux-rtc, linux-gpio,
	linux-kernel, alexandre.belloni, mazziesaccount, mturquette,
	lgirdwood, devicetree, linus.walleij, a.zummo, mark.rutland,
	bgolaszewski, linux-clk, lee.jones, sboyd, jacek.anaszewski,
	pavel


On Thu, 2019-10-31 at 12:50 -0500, Rob Herring wrote:
> On Thu, Oct 31, 2019 at 7:54 AM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > 
> > On Wed, 2019-10-30 at 14:22 -0500, Rob Herring wrote:
> > > On Wed, Oct 30, 2019 at 3:27 AM Vaittinen, Matti
> > > <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > > > On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> > > > > On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti 
> > ...which brings me here. I looked at the
> > Documentation/devicetree/bindings folder and did read the 'writing-
> > bindings.txt' and 'submitting-patches.txt' from there. Then I also
> > checked the Documentation/devicetree/usage-model.txt None of which
> > helped me out. I did also open the 'writing-schema.rst' but I
> > didn't
> > read it carefully enough. Probably because I thought after reading
> > the
> > opening chapter that this described how to do actual dts in yaml.
> 
> Things are a bit scattered around I'll admit. I feel like we need a
> 'start here', but the challenge is people have different starting
> points.

cross-referencing? =)

I guess that if yaml is what is expected to be used as patch format,
then we should probably mention this in submitting-patches.txt and
writing-bindings.txt. Actyually, I think that writing-bindings.txt
could be combined with writing-schema.rst - they are about the same
thing, right?

> > > There is some notion to convert the DT spec to schema and then
> > > generate the spec from the schema. Take properties, their type,
> > > and
> > > descriptions and put that back into tables for example. Would
> > > love to
> > > have someone work on that. :)
> > 
> > I am glad to hear you have developed / are developing such tooling.
> 
> TBC, I have not and am not. It's just an idea. There's been nothing
> done beyond experimenting if rST could be embedded into yaml.
> 
> > I
> > really appreciate it. What comes to giving a helping hand - I'd
> > better
> > to stick the simple C drivers for now ;) But if I ever get the
> > feeling
> > that I don't know what to do I'll keep this in mind :] Let me do
> > some
> > calculus... Only 11 years and my youngest son will probably leave
> > our
> > house - do you think 2030 is a bit too late? Just let me know if
> > this
> > is still relevant then - and I'll buy you a beer or write a tool
> > (of
> > some kind) xD
> 
> I've scheduled you in for 2030. :)

Fine. Let's see if it is a beer or a tool then :]

> > Meanwhile... I have tried to convert the BD71828 DT doc from the
> > RFC
> > patch to yaml - and I am having hard time. Especially with the
> > regulators node - which I would like to place in
> > Documentation/devicetree/bindings/regulator/rohm,bd71828-
> > regulator.yaml
> > 
> > My problem is the
> > regulators {
> > buck1: BUCK1 {
> >                     regulator-name = "buck1";
> >                     regulator-min-microvolt = <500000>;
> >                     regulator-max-microvolt = <2000000>;
> >                     regulator-ramp-delay = <2500>;
> >                     rohm,dvs-runlvl-ctrl;
> >                     rohm,dvs-runlevel0-voltage = <500000>;
> >                     rohm,dvs-runlevel1-voltage = <506250>;
> >                     rohm,dvs-runlevel2-voltage = <512500>;
> >                     rohm,dvs-runlevel3-voltage = <518750>;
> >                     regulator-boot-on;
> >     };
> >     ...
> > };
> > node which only contains BUCKX and LDOX sub-nodes. It has no own
> > properties.
> > 
> > From MFD yaml I did try:
> > 
> >   regulators:
> >     $ref: ../regulator/rohm,bd71828-regulator.yaml
> >     description:
> >       List of child nodes that specify the regulators.
> > 
> > and in rohm,bd71828-regulator.yaml
> > 
> > I tried doing:
> > 
> > patternProperties:
> >   "^BUCK[1-7]$":
> >     type: object
> >     description:
> >       Properties for single regulator.
> >     properties:
> >         ...
> > 
> > but this fails validation as properties: is not given.
> > 
> > [mvaittin@localhost linux]$ dt-doc-validate
> > Documentation/devicetree/bindings/regulator/rohm,bd71828-
> > regulator.yaml
> > /home/mvaittin/torvalds/linux/Documentation/devicetree/bindings/reg
> > ulat
> > or/rohm,bd71828-regulator.yaml: 'properties' is a required property
> > 
> > If I try and add:
> > 
> > properties:
> >   foo: true
> > 
> > patternProperties:
> >     "^BUCK[1-7]$":
> >       type: object
> >       description:
> >         Properties for single regulator.
> >       properties:
> >         ...
> 
> That's a case of needing to adjust the meta-schema (the schema that
> checks the schemas). It's a bit overly restrictive just to try to
> contain what's allowed. I've fixed it now. Update dtschema and it
> should work now.

Thanks. At least the make dt_binding_check passed now. dt-doc-validate
is not able to locate the regulator.yaml and errors out - but it does
no longer complain about missing 'properties:'.

> BTW, what you will also need is to reference the common schema:
> 
> "^BUCK[1-7]$":
>   type: object
>   allOf:
>     - $ref: regulator.yaml#
>   properties:
>    rohm,dvs-runlvl-ctrl:
>      type: boolean
>      description: ...
>    ...

Thanks for the pointers ;) I just submitted the RFC v3 :)

Br,
	Matti Vaittinen


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings
  2019-11-01 12:52                 ` Vaittinen, Matti
@ 2019-11-04 19:28                   ` Rob Herring
  0 siblings, 0 replies; 29+ messages in thread
From: Rob Herring @ 2019-11-04 19:28 UTC (permalink / raw)
  To: Vaittinen, Matti
  Cc: broonie, dmurphy, linux-leds, linux-rtc, linux-gpio,
	linux-kernel, alexandre.belloni, mazziesaccount, mturquette,
	lgirdwood, devicetree, linus.walleij, a.zummo, mark.rutland,
	bgolaszewski, linux-clk, lee.jones, sboyd, jacek.anaszewski,
	pavel

On Fri, Nov 1, 2019 at 7:52 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:
>
>
> On Thu, 2019-10-31 at 12:50 -0500, Rob Herring wrote:
> > On Thu, Oct 31, 2019 at 7:54 AM Vaittinen, Matti
> > <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > >
> > > On Wed, 2019-10-30 at 14:22 -0500, Rob Herring wrote:
> > > > On Wed, Oct 30, 2019 at 3:27 AM Vaittinen, Matti
> > > > <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > > > > On Tue, 2019-10-29 at 14:34 -0500, Rob Herring wrote:
> > > > > > On Fri, Oct 25, 2019 at 05:49:17AM +0000, Vaittinen, Matti
> > > ...which brings me here. I looked at the
> > > Documentation/devicetree/bindings folder and did read the 'writing-
> > > bindings.txt' and 'submitting-patches.txt' from there. Then I also
> > > checked the Documentation/devicetree/usage-model.txt None of which
> > > helped me out. I did also open the 'writing-schema.rst' but I
> > > didn't
> > > read it carefully enough. Probably because I thought after reading
> > > the
> > > opening chapter that this described how to do actual dts in yaml.
> >
> > Things are a bit scattered around I'll admit. I feel like we need a
> > 'start here', but the challenge is people have different starting
> > points.
>
> cross-referencing? =)
>
> I guess that if yaml is what is expected to be used as patch format,
> then we should probably mention this in submitting-patches.txt and
> writing-bindings.txt.

I've actually added that to submitting-patches.txt already and
checkpatch.pl now warns for non-schema bindings. Both are pending for
5.5.

> Actyually, I think that writing-bindings.txt
> could be combined with writing-schema.rst - they are about the same
> thing, right?

Not really. writing-bindings.txt is about how to design bindings. It's
the DO's and DON'Ts that I give in review comments over and over and
over. Mostly an attempt to ensure I'm saying things that are
documented somewhere. Probably need to come up with better names, but
naming is hard(TM).


> > > > There is some notion to convert the DT spec to schema and then
> > > > generate the spec from the schema. Take properties, their type,
> > > > and
> > > > descriptions and put that back into tables for example. Would
> > > > love to
> > > > have someone work on that. :)
> > >
> > > I am glad to hear you have developed / are developing such tooling.
> >
> > TBC, I have not and am not. It's just an idea. There's been nothing
> > done beyond experimenting if rST could be embedded into yaml.
> >
> > > I
> > > really appreciate it. What comes to giving a helping hand - I'd
> > > better
> > > to stick the simple C drivers for now ;) But if I ever get the
> > > feeling
> > > that I don't know what to do I'll keep this in mind :] Let me do
> > > some
> > > calculus... Only 11 years and my youngest son will probably leave
> > > our
> > > house - do you think 2030 is a bit too late? Just let me know if
> > > this
> > > is still relevant then - and I'll buy you a beer or write a tool
> > > (of
> > > some kind) xD
> >
> > I've scheduled you in for 2030. :)
>
> Fine. Let's see if it is a beer or a tool then :]
>
> > > Meanwhile... I have tried to convert the BD71828 DT doc from the
> > > RFC
> > > patch to yaml - and I am having hard time. Especially with the
> > > regulators node - which I would like to place in
> > > Documentation/devicetree/bindings/regulator/rohm,bd71828-
> > > regulator.yaml
> > >
> > > My problem is the
> > > regulators {
> > > buck1: BUCK1 {
> > >                     regulator-name = "buck1";
> > >                     regulator-min-microvolt = <500000>;
> > >                     regulator-max-microvolt = <2000000>;
> > >                     regulator-ramp-delay = <2500>;
> > >                     rohm,dvs-runlvl-ctrl;
> > >                     rohm,dvs-runlevel0-voltage = <500000>;
> > >                     rohm,dvs-runlevel1-voltage = <506250>;
> > >                     rohm,dvs-runlevel2-voltage = <512500>;
> > >                     rohm,dvs-runlevel3-voltage = <518750>;
> > >                     regulator-boot-on;
> > >     };
> > >     ...
> > > };
> > > node which only contains BUCKX and LDOX sub-nodes. It has no own
> > > properties.
> > >
> > > From MFD yaml I did try:
> > >
> > >   regulators:
> > >     $ref: ../regulator/rohm,bd71828-regulator.yaml
> > >     description:
> > >       List of child nodes that specify the regulators.
> > >
> > > and in rohm,bd71828-regulator.yaml
> > >
> > > I tried doing:
> > >
> > > patternProperties:
> > >   "^BUCK[1-7]$":
> > >     type: object
> > >     description:
> > >       Properties for single regulator.
> > >     properties:
> > >         ...
> > >
> > > but this fails validation as properties: is not given.
> > >
> > > [mvaittin@localhost linux]$ dt-doc-validate
> > > Documentation/devicetree/bindings/regulator/rohm,bd71828-
> > > regulator.yaml
> > > /home/mvaittin/torvalds/linux/Documentation/devicetree/bindings/reg
> > > ulat
> > > or/rohm,bd71828-regulator.yaml: 'properties' is a required property
> > >
> > > If I try and add:
> > >
> > > properties:
> > >   foo: true
> > >
> > > patternProperties:
> > >     "^BUCK[1-7]$":
> > >       type: object
> > >       description:
> > >         Properties for single regulator.
> > >       properties:
> > >         ...
> >
> > That's a case of needing to adjust the meta-schema (the schema that
> > checks the schemas). It's a bit overly restrictive just to try to
> > contain what's allowed. I've fixed it now. Update dtschema and it
> > should work now.
>
> Thanks. At least the make dt_binding_check passed now. dt-doc-validate
> is not able to locate the regulator.yaml and errors out - but it does
> no longer complain about missing 'properties:'.

Either look at how Kbuild calls dt-doc-validate or just use 'make
dt_binding_check'. (It needs the base path to the schema passed in.)

Rob

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block
       [not found]       ` <20191105005541.7913220717@mail.kernel.org>
@ 2019-11-05  8:11         ` Vaittinen, Matti
  0 siblings, 0 replies; 29+ messages in thread
From: Vaittinen, Matti @ 2019-11-05  8:11 UTC (permalink / raw)
  To: mazziesaccount, Vaittinen, Matti, sboyd
  Cc: dmurphy, linux-leds, linux-rtc, linux-gpio, linux-kernel,
	alexandre.belloni, mturquette, lgirdwood, jacek.anaszewski,
	devicetree, a.zummo, linus.walleij, mark.rutland, robh+dt,
	bgolaszewski, linux-clk, pavel, lee.jones, broonie

Hello Stephen,

On Mon, 2019-11-04 at 16:55 -0800, Stephen Boyd wrote:
> Quoting Vaittinen, Matti (2019-10-28 23:28:51)
> > On Mon, 2019-10-28 at 16:32 -0700, Stephen Boyd wrote:
> > > Quoting Matti Vaittinen (2019-10-24 04:44:40)
> > > > diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-
> > > > bd718x7.c
> > > > index ae6e5baee330..d17a19e04592 100644
> > > > --- a/drivers/clk/clk-bd718x7.c
> > > > +++ b/drivers/clk/clk-bd718x7.c
> > > > @@ -8,6 +8,7 @@
> > > >  #include <linux/platform_device.h>
> > > >  #include <linux/slab.h>
> > > >  #include <linux/mfd/rohm-bd718x7.h>
> > > > +#include <linux/mfd/rohm-bd71828.h>
> > > >  #include <linux/mfd/rohm-bd70528.h>
> > > 
> > > It would be really great to not need to include these random
> > > header
> > > files in this driver and just use raw numbers somehow. Looks like
> > > maybe
> > > it can be done by populating a different device name from the mfd
> > > driver
> > > depending on the version of the clk controller desired? Then that
> > > can
> > > be
> > > matched in this clk driver and we can just put the register info
> > > in
> > > this
> > > file?
> > 
> > I still like keeping the chip type information on one header - no
> > matter what-ever format the clk-controller type/version information
> > is.
> > Rationale is that MFD and also few other sub-devices (not only the
> > clk)
> > need to use it. Currently at least the RTC.
> > 
> > But if we define clk register information for all PMICs in this c-
> > file, 
> > then (I think) we can only include the <linux/mfd/rohm-generic.h> -
> > which contains the PMIC type defines and the generic MFD data
> > structure. That would:
> > 
> > -#include <linux/mfd/rohm-bd718x7.h>
> > -#include <linux/mfd/rohm-bd71828.h>
> > -#include <linux/mfd/rohm-bd70528.h>
> > +#include <linux/mfd/rohm-generic.h>
> > 
> > That way the chip-type information could still be same for MFD and
> > all
> > sub-devices but clk driver would not need to include all the
> > details
> > for all the PMICs. I understand your point well as clk registers
> > for
> > these PMICs are really *limited*.
> > 
> 
> It's not even just about clk registers. It's also about how we have
> device compatible strings and device names but this driver isn't
> using
> them to differentiate. Instead, it's looking at the parent device. I
> don't get it. Why can't the MFD populate different clk devices for
> the
> different PMICs and make this driver completely oblivious to the
> parent
> device name/structure and these headers?

Probably because I didn't know how MFD/child device 'matching' works.

Do you mean the clk driver could do something like:

static const struct platform_device_id bd718x7_clk_id[] = {
        { "bd71837-clk", FOO},
        { "bd71847-clk", BAR},
        { "bd70528-clk", BAZ},
        { "bd71828-clk", BAF},
        { },
};
MODULE_DEVICE_TABLE(platform, bd718x7_clk_id);

static struct platform_driver bd71837_clk = {
        .driver = {
                .name = "bd718xx-clk",
        },
        .probe = bd71837_clk_probe,
	.id_table = bd718x7_clk_id
};

and then in MFD we just use correct name string for the mfd cell
representing the clk? (Eg. one of the bd71837-clk, bd71847-clk,
bd70528-clk, bd71828-clk) and in clk probe just differentiate based on
FOO, BAR, BAZ and BAF?

I guess we could do that (didn't try it out yet so I only guess for
now) - but I think this don't really mitigate the need for common
header. If we change the sub-device match mechanism to this then the
same mechanism should probably be applied to all sub-devices. And that
would be a case where I would like to see the very same FOO, BAR, BAZ
and BAF being used for all sub-devices - meaning it should still be a
MFD header. I think the drivers/clk/clk-s2mps11.c, drivers/mfd/sec-
core.c and include/linux/mfd/samsung/core.h are examples of this.

But I do like this platform_device_id based PMIC differentiation
better. It looks like the "de facto" way of doing this. Still, as I
said, I don't see we're getting rid of common header this way. Anyways,
I think I can cook-up patches to change this if I get buy-in from Lee,
Alexandre and Mark for changing the existing mechanism.

Thanks for teaching me something new once again! :)

Br,
	Matti Vaittinen



^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2019-11-05  8:11 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
2019-10-24 11:41 ` [RFC PATCH v2 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-10-24 11:41 ` [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2019-10-24 19:35   ` Dan Murphy
2019-10-25  5:49     ` Vaittinen, Matti
2019-10-29 12:08       ` Lee Jones
2019-10-29 19:34       ` Rob Herring
2019-10-30  8:26         ` Vaittinen, Matti
2019-10-30 19:22           ` Rob Herring
2019-10-31 12:54             ` Vaittinen, Matti
2019-10-31 17:50               ` Rob Herring
2019-11-01 12:52                 ` Vaittinen, Matti
2019-11-04 19:28                   ` Rob Herring
2019-10-24 11:42 ` [RFC PATCH v2 03/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
2019-10-24 11:44 ` [RFC PATCH v2 04/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-10-24 11:44 ` [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-10-28 23:32   ` Stephen Boyd
2019-10-29  6:28     ` Vaittinen, Matti
     [not found]       ` <20191105005541.7913220717@mail.kernel.org>
2019-11-05  8:11         ` Vaittinen, Matti
2019-10-24 11:45 ` [RFC PATCH v2 06/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-10-24 11:46 ` [RFC PATCH v2 07/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-10-24 11:46 ` [RFC PATCH v2 08/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-10-24 11:47 ` [RFC PATCH v2 09/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
2019-10-24 11:47 ` [RFC PATCH v2 10/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
2019-10-24 11:50 ` [RFC PATCH v2 11/13] rtc: bd70528 add BD71828 support Matti Vaittinen
2019-10-24 11:50 ` [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-10-24 11:59   ` Linus Walleij
2019-10-24 13:34     ` Vaittinen, Matti
2019-10-24 11:52 ` [RFC PATCH v2 13/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen

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).