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