| Message ID | cover.1577694311.git.matti.vaittinen@fi.rohmeurope.com |
|---|---|
| Headers | show |
| Series | Support ROHM BD71828 PMIC | expand |
On Mon, 30 Dec 2019, Matti Vaittinen wrote: > ROHM BD71850 PMIC is almost identical to BD71847. Main difference is some > initial voltage values for regulators. The BD71850 can be handled by > BD71847 driver but adding own compatible makes it clearer for one who > creates the DT for board containing this PMIC and allows SW to be > differentiating PMICs if needed. > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> > --- > > Changes from v7 - no changes > > drivers/mfd/rohm-bd718x7.c | 4 ++++ > 1 file changed, 4 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
On Mon, 30 Dec 2019, Matti Vaittinen wrote: > 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> > Acked-by: Mark Brown <broonie@kernel.org> > --- > > Changes from v7 - no changes > > 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/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h > index ff3dd7578fd3..8037421cc6a1 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 { > ROHM_CHIP_TYPE_BD71837 = 0, > ROHM_CHIP_TYPE_BD71847, > @@ -17,4 +20,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; > +}; I think this deserves a kernel-doc header. > +#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); Does these really need to live in the parent's header file? What other call-sites are there? > +#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) a) This comment is not really required b) You shouldn't be using C++ comments
On Mon, 30 Dec 2019, Matti Vaittinen wrote: > 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> > Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > --- > > Changes from v7 - no changes > > drivers/rtc/Kconfig | 3 +- > drivers/rtc/rtc-bd70528.c | 168 ++++++++++++++++++++++++++++--- > include/linux/mfd/rohm-bd70528.h | 13 +-- > include/linux/mfd/rohm-bd71828.h | 4 +- > include/linux/mfd/rohm-shared.h | 27 +++++ > 5 files changed, 186 insertions(+), 29 deletions(-) > create mode 100644 include/linux/mfd/rohm-shared.h > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index d77515d8382c..df7a3843069d 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -498,12 +498,13 @@ 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" > depends on MFD_ROHM_BD70528 && (BD70528_WATCHDOG || !BD70528_WATCHDOG) > 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 627037aa66a8..2ce202040556 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; I think it would be better if you fixed this up be more forthcoming. It took some grepping to find out what this actually meant. An MFD isn't really a thing, we made it up. Here you are referring to this platform device's parent's device data. With that in mind I offer some suggestions: 'struct rohm_parent_ddata pddata' 'struct rohm_parent_ddata parent' > struct device *dev; > + u8 reg_time_start; > + bool has_rtc_timers; > }; [...] > +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; Then ... struct rohm_parent_ddata *parent = r->parent; ret = regmap_bulk_read(parent->regmap, BD71828_REG_RTC_ALM_START, &alm, sizeof(alm)); if (ret) { dev_err(dev, "Failed to read alarm regs\n"); return ret; } [...] > diff --git a/include/linux/mfd/rohm-bd70528.h b/include/linux/mfd/rohm-bd70528.h > index 2ad2320d0a96..a57af878fd0c 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 { > @@ -307,17 +308,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 > @@ -326,7 +316,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 d013e03f742d..017a4c01cb31 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> Isn't generic shared? > /* 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 > @@ -204,7 +207,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 */ This is very out of data now! > + > +#ifndef __LINUX_MFD_ROHM_SHARED_H__ > +#define __LINUX_MFD_ROHM_SHARED_H__ > + > +/* > + * RTC definitions shared between > + * > + * BD70528 > + * and BD71828 This reads poorly. Either form a bullet pointed list, or just write it out. > + */ > + > + > +#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__ */
Hello Lee, Thanks for taking a look at this. On Tue, 2020-01-07 at 12:57 +0000, Lee Jones wrote: > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > 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> > > Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > > --- > > + > > 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; > > I think it would be better if you fixed this up be more forthcoming. > It took some grepping to find out what this actually meant. An MFD > isn't really a thing, we made it up. Here you are referring to this > platform device's parent's device data. I like MFD. Multi Function Device is a real thing. Device with multiple functionalities meld in. It describes many PMICs or FPGA designs terribly well. But the naming is not something I like fighting for - if MFD is not nice to your eyes we can change it. But let's do it in separate patch set Ok? Changing the "rohm_regmap_dev" will involve changing bunch of existing drivers and is not by any means related with adding the support for BD71828. > > With that in mind I offer some suggestions: > > 'struct rohm_parent_ddata pddata' > 'struct rohm_parent_ddata parent' Both are fine with me but this change is reflected to drivers not related to BD71828 like: bd70528-regulator.c gpio-bd70528.c watchdog/bd70528_wdt.c I'd rather not change WDT with this series. So I'd prefer incremental patch for this in the release following this series. > > /* WDT masks */ > > diff --git a/include/linux/mfd/rohm-bd71828.h > > b/include/linux/mfd/rohm-bd71828.h > > index d013e03f742d..017a4c01cb31 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> > > Isn't generic shared? Good point. The rohm-shared contains stuff common for only few of the PMICs (currently BD70528 and BD71828) where as rohm-generic is intended to be used for stuff that is generic to more or less all of the PMICs. Or that was my initial idea. But as I've been told - naming-is-hard :) Suggestions? > > > 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 */ > > This is very out of data now! Ok. > > +/* > > + * RTC definitions shared between > > + * > > + * BD70528 > > + * and BD71828 > > This reads poorly. > > Either form a bullet pointed list, or just write it out. Ok Best Regards Matti
Hello Lee, On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote: > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > 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> > > Acked-by: Mark Brown <broonie@kernel.org> > > --- > > > > + > > +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; > > +}; > > I think this deserves a kernel-doc header. Oh, the struct here? Hmm. You might be correct. I can add some. > > > +#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); > > Does these really need to live in the parent's header file? I don't know what would be a better place? > What other call-sites are there? After this series the bd718x7-regulator.c and bd71828-regulator.c are the in-tree drivers using these. rohm-regulator.c is implementing them. And I hope we see yet another driver landing in later this year. Anyways, I will investigate if I can switch this to some common (not rohm specific) DT bindings at some point (I've scheduled this study to March) - If I can then they should live in regulator core headers. But changing the existing properties should again be own set of patches and I'd prefer doing that work independently of this series and not delaying the BD71828 due to not-yet-evaluated bd718x7 property changes. > > > +#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) > > a) This comment is not really required > b) You shouldn't be using C++ comments Thanks, I'll remove it. Best Regards Matti
On Wed, 08 Jan 2020, Vaittinen, Matti wrote: > Hello Lee, > > On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote: > > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > > > 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> > > > Acked-by: Mark Brown <broonie@kernel.org> > > > --- [...] > > > +#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); > > > > Does these really need to live in the parent's header file? > > I don't know what would be a better place? You don't have a regulator header file? It seems over-kill to create one for this, so leave it as is. > > What other call-sites are there? > > After this series the bd718x7-regulator.c and bd71828-regulator.c are > the in-tree drivers using these. rohm-regulator.c is implementing them. > And I hope we see yet another driver landing in later this year. > > Anyways, I will investigate if I can switch this to some common (not > rohm specific) DT bindings at some point (I've scheduled this study to > March) - If I can then they should live in regulator core headers. > > But changing the existing properties should again be own set of patches > and I'd prefer doing that work independently of this series and not > delaying the BD71828 due to not-yet-evaluated bd718x7 property changes. That's fine.
Hello Lee, On Mon, 2020-01-13 at 10:53 +0000, Lee Jones wrote: > On Wed, 08 Jan 2020, Vaittinen, Matti wrote: > > > Hello Lee, > > > > On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote: > > > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > > > > > 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> > > > > Acked-by: Mark Brown <broonie@kernel.org> > > > > --- > > [...] > > > > > +#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); > > > > > > Does these really need to live in the parent's header file? > > > > I don't know what would be a better place? > > You don't have a regulator header file? > > It seems over-kill to create one for this, so leave it as is. > > > > What other call-sites are there? > > > > After this series the bd718x7-regulator.c and bd71828-regulator.c > > are > > the in-tree drivers using these. rohm-regulator.c is implementing > > them. > > And I hope we see yet another driver landing in later this year. > > > > Anyways, I will investigate if I can switch this to some common > > (not > > rohm specific) DT bindings at some point (I've scheduled this study > > to > > March) - If I can then they should live in regulator core headers. > > > > But changing the existing properties should again be own set of > > patches > > and I'd prefer doing that work independently of this series and not > > delaying the BD71828 due to not-yet-evaluated bd718x7 property > > changes. > > That's fine. Glad to hear :) By the way, I already sent the v9 ;) Br, Matti
On Mon, 13 Jan 2020, Vaittinen, Matti wrote: > Hello Lee, > > On Mon, 2020-01-13 at 10:53 +0000, Lee Jones wrote: > > On Wed, 08 Jan 2020, Vaittinen, Matti wrote: > > > > > Hello Lee, > > > > > > On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote: > > > > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > > > > > > > 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> > > > > > Acked-by: Mark Brown <broonie@kernel.org> > > > > > --- > > > > [...] > > > > > > > +#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); > > > > > > > > Does these really need to live in the parent's header file? > > > > > > I don't know what would be a better place? > > > > You don't have a regulator header file? > > > > It seems over-kill to create one for this, so leave it as is. > > > > > > What other call-sites are there? > > > > > > After this series the bd718x7-regulator.c and bd71828-regulator.c > > > are > > > the in-tree drivers using these. rohm-regulator.c is implementing > > > them. > > > And I hope we see yet another driver landing in later this year. > > > > > > Anyways, I will investigate if I can switch this to some common > > > (not > > > rohm specific) DT bindings at some point (I've scheduled this study > > > to > > > March) - If I can then they should live in regulator core headers. > > > > > > But changing the existing properties should again be own set of > > > patches > > > and I'd prefer doing that work independently of this series and not > > > delaying the BD71828 due to not-yet-evaluated bd718x7 property > > > changes. > > > > That's fine. > > Glad to hear :) By the way, I already sent the v9 ;) It's in my queue.
On Mon, 13 Jan 2020, Lee Jones wrote: > On Mon, 13 Jan 2020, Vaittinen, Matti wrote: > > On Mon, 2020-01-13 at 10:53 +0000, Lee Jones wrote: > > > On Wed, 08 Jan 2020, Vaittinen, Matti wrote: > > > > On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote: > > > > > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > > > > > > > > > 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> > > > > > > Acked-by: Mark Brown <broonie@kernel.org> > > > > > > --- > > > > > > [...] > > > > > > > > > +#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); > > > > > > > > > > Does these really need to live in the parent's header file? > > > > > > > > I don't know what would be a better place? > > > > > > You don't have a regulator header file? > > > > > > It seems over-kill to create one for this, so leave it as is. > > > > > > > > What other call-sites are there? > > > > > > > > After this series the bd718x7-regulator.c and bd71828-regulator.c > > > > are > > > > the in-tree drivers using these. rohm-regulator.c is implementing > > > > them. > > > > And I hope we see yet another driver landing in later this year. > > > > > > > > Anyways, I will investigate if I can switch this to some common > > > > (not > > > > rohm specific) DT bindings at some point (I've scheduled this study > > > > to > > > > March) - If I can then they should live in regulator core headers. > > > > > > > > But changing the existing properties should again be own set of > > > > patches > > > > and I'd prefer doing that work independently of this series and not > > > > delaying the BD71828 due to not-yet-evaluated bd718x7 property > > > > changes. > > > > > > That's fine. > > > > Glad to hear :) By the way, I already sent the v9 ;) > > It's in my queue. Although you didn't submit the whole set to me, so I only have a few of the patches. Why did you choose to do that this time?
On Wed, 2020-01-15 at 08:29 +0000, Lee Jones wrote: > On Mon, 13 Jan 2020, Lee Jones wrote: > > On Mon, 13 Jan 2020, Vaittinen, Matti wrote: > > > On Mon, 2020-01-13 at 10:53 +0000, Lee Jones wrote: > > > > On Wed, 08 Jan 2020, Vaittinen, Matti wrote: > > > > > On Tue, 2020-01-07 at 12:41 +0000, Lee Jones wrote: > > > > > > On Mon, 30 Dec 2019, Matti Vaittinen wrote: > > > > > > > > > > > > > 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> > > > > > > > Acked-by: Mark Brown <broonie@kernel.org> > > > > > > > --- > > > > > > > > [...] > > > > > > > > > > > +#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); > > > > > > > > > > > > Does these really need to live in the parent's header file? > > > > > > > > > > I don't know what would be a better place? > > > > > > > > You don't have a regulator header file? > > > > > > > > It seems over-kill to create one for this, so leave it as is. > > > > > > > > > > What other call-sites are there? > > > > > > > > > > After this series the bd718x7-regulator.c and bd71828- > > > > > regulator.c > > > > > are > > > > > the in-tree drivers using these. rohm-regulator.c is > > > > > implementing > > > > > them. > > > > > And I hope we see yet another driver landing in later this > > > > > year. > > > > > > > > > > Anyways, I will investigate if I can switch this to some > > > > > common > > > > > (not > > > > > rohm specific) DT bindings at some point (I've scheduled this > > > > > study > > > > > to > > > > > March) - If I can then they should live in regulator core > > > > > headers. > > > > > > > > > > But changing the existing properties should again be own set > > > > > of > > > > > patches > > > > > and I'd prefer doing that work independently of this series > > > > > and not > > > > > delaying the BD71828 due to not-yet-evaluated bd718x7 > > > > > property > > > > > changes. > > > > > > > > That's fine. > > > > > > Glad to hear :) By the way, I already sent the v9 ;) > > > > It's in my queue. > > Although you didn't submit the whole set to me, so I only have a few > of the patches. Why did you choose to do that this time? Sorry Lee. I have not dropped you intentionally! I will resend the series. Br, Matti Vaittinen
Patch series introducing support for ROHM BD71828 PMIC ROHM BD71828 is a power management IC containing 7 bucks and 7 LDOs. All regulators can 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. This patch series brings only the basic support for controlling regulators individually via I2C. 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 not included in this series. The series also adds LED DT-node lookup based on node name or given property name/value pair in LED core. It also adds generic default-state and default-trigger property handling to LED core. Follow-up patches simplifying few other LED drivers should follow. Changelog v8: LEDs: - Fixed bunch of typos. - Corrected the commit message which errorneously contained the 'leds-compatible' which I dropped in favour of match_property. - use max_brightness instead of LED_FULL if it is given when handling the default_state, "on". - clean fwnode_owned at the end of unsuccessfull registration or at the end of deregistration. - fix the accidental linuxdoc comment. - rename led_find_fwnode to led_get_fwnode as it increases refcount. Changelog v7: - Rebased on top of v5.5-rc2 - Dropped already applied patches - basic regulator support (in regulator tree now) - regulator dt-bindings (in regulator tree now) - gpio devm function documentation (in GPIO tree now) - Dropped new devm-variant of gpio_array getting for MFD sub-devices who have consumer information in parent DT node as gpio consumer was dropped from the series - removed extra line-breaks from MFD driver and Makefile - fixed RTC patch subject line (added missing colon) - included a patch which adds compatible for ROHM BD71850 PMIC Changelog v6: Rebased on top of v5.5-rc1 LED core: - Do new fw-node look-up only if the new match data is given. That way behaviour for existing drivers is not changed - Handle generic LED properties by core only if explisitly requested in init-data. That way behaviour for existing drivers is not changed until they are verified to work. BD71828 LEDs: - Fix module loading by adding "dummy" of_device_id table. DT bindings: All: - Remove regulator run-level properties as run-level support was dropped for now. - Change SPDX to dual lisence LED: - added select: false - replace oneOf + const by enum Regulator: - remove forgotten comments - comment indenting MFD: - remove unnecessary descriptions Regulators: - Dropped patch 12 with run-level controls - Dropped unnecessary ramp_delay_supported() - ram_delay ops were already only filled for DVS bucks. GPIO: - rename internal function. RTC: - Added missing blank line Changelog v5: Only LED patch (patch 15) changed, rest as in v4. LED: - Fixed issues reported by Dan Carpenter and kbuild-bot static analysis. Changelog v4 (first non RFC): General: - Changed subdevice loading and chip version identification to use platform ID. - License identifiers changed to GPL-2.0-only MFD: - Styling fixes mostly DT-Bindings: - a few more checks as suggested by Rob Herring. - Order of DT patches changed. - me as maintainer - standard units to new properties (microvolts, ohms) - runlevel values in an array LED: - BD71828 driver added (back) - Added DT support - Added LED DT node lookup in led framework when init_data is given with DT node match information. - Added common property parsing for default-state and default-trigger. Regulators: - dropped sysfs interfaces - fixed module unload/reload by binding gpio consumer information to regulator device not to MFD. GPIO: - Added devm_gpiod_get_parent_array - added few missing devm functions to documentation Changelog v3: DT-Bindings: - yamlify - add LED binding doc CLK: - Move clk register definitions from MFD headers to clk driver GPIO: - Add generic direction define and use it. LED: - Drop LED driver from the series (for now). Changelog v2: Mainly RTC and GPIO fixes suggested by Alexandre and Bartosz 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: dt-bindings for LEDs on BD71828 PMIC Patch 2: dt-bindings for BD71828 PMIC Patch 3: Convert rohm PMICs with common sub-devices to use platform_ device_id to match MFD sub-devices Patch 4: Add compatible for BD71850 Patch 5: BD71828 MFD core. Patch 6: Power button support using GPIO keys. Patch 7: CLK gate support using existing clk-bd718x7 Patch 8: Split existing bd718x7 regulator driver to generic ROHM dt parsing portion (used by more than one ROHM drivers) and bd718x8 specific parts Patch 9: Support BD71828 RTC block using BD70528 RTC driver Patch 10: Allow control of GP(I)O pins on BD71828 via GPIO subsystem Patch 11: Add LED node lookup and common LED binding parsing support to LED class/core Patch 12: Support toggling the LEDs on BD71828. --- Matti Vaittinen (12): dt-bindings: leds: ROHM BD71282 PMIC LED driver dt-bindings: mfd: Document ROHM BD71828 bindings mfd: rohm PMICs - use platform_device_id to match MFD sub-devices mfd: bd718x7: Add compatible for BD71850 mfd: bd71828: Support ROHM BD71828 PMIC - core mfd: input: bd71828: Add power-key support clk: bd718x7: Support ROHM BD71828 clk block regulator: bd718x7: Split driver to common and bd718x7 specific parts rtc: bd70528: add BD71828 support gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs leds: Add common LED binding parsing support to LED class/core led: bd71828: Support LED outputs on ROHM BD71828 PMIC .../bindings/leds/rohm,bd71828-leds.yaml | 52 +++ .../bindings/mfd/rohm,bd71828-pmic.yaml | 193 ++++++++ drivers/clk/Kconfig | 6 +- drivers/clk/clk-bd718x7.c | 50 ++- drivers/gpio/Kconfig | 12 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-bd71828.c | 159 +++++++ drivers/leds/Kconfig | 10 + drivers/leds/Makefile | 1 + drivers/leds/led-class.c | 115 ++++- drivers/leds/led-core.c | 258 +++++++++-- drivers/leds/leds-bd71828.c | 118 +++++ drivers/mfd/Kconfig | 15 + drivers/mfd/Makefile | 1 + drivers/mfd/rohm-bd70528.c | 3 +- drivers/mfd/rohm-bd71828.c | 344 ++++++++++++++ drivers/mfd/rohm-bd718x7.c | 43 +- drivers/regulator/Kconfig | 4 + drivers/regulator/Makefile | 1 + drivers/regulator/bd718x7-regulator.c | 200 +++------ drivers/regulator/rohm-regulator.c | 95 ++++ drivers/rtc/Kconfig | 3 +- drivers/rtc/rtc-bd70528.c | 168 ++++++- include/linux/leds.h | 94 +++- include/linux/mfd/rohm-bd70528.h | 19 +- include/linux/mfd/rohm-bd71828.h | 423 ++++++++++++++++++ include/linux/mfd/rohm-bd718x7.h | 6 - include/linux/mfd/rohm-generic.h | 48 +- include/linux/mfd/rohm-shared.h | 27 ++ 29 files changed, 2206 insertions(+), 263 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml 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/rohm-regulator.c create mode 100644 include/linux/mfd/rohm-bd71828.h create mode 100644 include/linux/mfd/rohm-shared.h base-commit: commit d1eef1c61974 ("Linux 5.5-rc2")