Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Thanks Again Lee,
On Tue, Feb 12, 2019 at 09:17:23AM +, Lee Jones wrote:
> On Fri, 08 Feb 2019, Matti Vaittinen wrote:
>
> > > I think an exported function with comments would be better.
> > So do you mean you would prefer exported function over the pointer from
> Yes please. Call-back pointers for non-subsystem level actions are a
> bit messy IMHO.
That's fine. I'll go with exported function then =)
> > case it just hides the meaning of values we are passing as arguments.
> > With raw assignment we at least have some idea what the 0x40 or 0x20 are
> > referring to =)
>
> Well I do agree with your last comment.
>
> Maybe doing the following would help with the ugliness (i.e. the shear
> number of chars):
>
> unsigned int type_reg_offset_inc = 0;
> for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
> *t = irqs[i].type;
> t->type_reg_offset = type_reg_offset_inc;
> t->type_rising_val = 0x20;
> t->type_falling_val= 0x10;
> t->type_level_high_val = 0x40;
> t->type_level_low_val = 0x50;
> t->types_supported =
> (IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> type_reg_offset_inc += 2;
> }
I'll go with this for next version.
> > > > > > + /* wdt_set must be called rtc_timer_lock held */
> > > > >
> > > > > This doesn't make sense.
> > > >
> > > > Umm.. The comment does not make sense? Maybe I can explain it further.
> > >
> > > "wdt_set must be called when the rtc_timer_lock is held"
> >
> > Yes. I wanted to say that who-ever is calling the wdt_set function
> > below, should have locked the rtc_timer_lock mutex (last in this
> > struct). The function does not do locking inside because we want the RTC
> > to be able to perform:
> >
> > lock
> > disable wdt (store original state)
> > set RTC
> > return wdt original state
> > unlock
> >
> > Locking is needed so that we can exclude the watchdog enabling or
> > disabling the WDT timer between moments when RTC is getting the original
> > WDT state and re-turning back the old state. Without the lock we have a
> > risk that WDT-driver enables or disables the timer when RTC is being
> > set, and RTC overwrites the watchdog driver changes when writing back
> > the old state. I hope this makes sense now... Any suggestions how to
> > explain this nicely in english?
>
> I think I did already:
>
> "wdt_set must be called when the rtc_timer_lock is held"
>
> Actually, this is a little ambiguous. A better sentence could read:
>
> "rtc_timer_lock must be taken before calling wdt_set()"
Sure. I'll ruthlessy plagiarize that sentence. (And as I am not at all
sure if "ruthlessy plagiarize" actually means what I think it does -
I tried to say that I'll take your suggestion and use it :] )
Once again, thanks for the help =)
Br,
Matti
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
On Fri, 08 Feb 2019, Matti Vaittinen wrote:
> Hello Lee,
>
> On Fri, Feb 08, 2019 at 10:57:43AM +, Lee Jones wrote:
> > >
> > > This is needed by both RTC and WDT drivers as RTC driver must stop the
> > > WDT when it sets RTC. WDT HW is using RTC counter and might trigger
> > > timeout/reset when RTC is set. Options are to dublicate the
> > > enable/disable to both drivers or to export a function or share a
> > > function pointer. I didn't want dublication or dependency between RTC
> > > and WDT drivers. Thus I thought that MFD is best place for this code as
> > > both RTC and WDT require it anyways. Perhaps this should be commented
> > > here?
> >
> > I think an exported function with comments would be better.
>
> So do you mean you would prefer exported function over the pointer from
Yes please. Call-back pointers for non-subsystem level actions are a
bit messy IMHO.
> MFD? I guess I can do it but I would still like to keep the code in the
> MFD as I would rather not introduce dependency from WDT driver to RTC or
> other way around. I can easily think of cases where WDT or RTC drivers
> would be unnecessary and user might want to drop one of them out of
Sounds fine.
> configuration. And I wonder if export actually makes any real
> improvement as we need to share the mutex between RTC and WDT anyways.
They all (parent (MFD), RTC and WDT) have shared data anyway.
> > [...]
> >
> > > > > + irqs[BD70528_INT_GPIO3].type.type_reg_offset = 6;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_rising_val = 0x20;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_falling_val = 0x10;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_level_high_val = 0x40;
> > > > > + irqs[BD70528_INT_GPIO3].type.type_level_low_val = 0x50;
> > > > > + irqs[BD70528_INT_GPIO3].type.types_supported =
> > > > > (IRQ_TYPE_EDGE_BOTH |
> > > > > + IRQ_TYPE_LEVEL_HIGH |
> > > > > IRQ_TYPE_LEVEL_LOW);
> > > >
> > > > Could you please explain:
> > > >
> > > > a) what you're doing here
> > >
> > > Regmap-irq gained support for type-setting. On bd70528 the type setting
> > > makes sense only for GPIO interrupts - so we must not populate type
> > > setting information for the rest of the IRQs. The macro REGMAP_IRQ_REG
> > > is nice and makes the irq struct initialization cleaner. Thus it is used.
> > > It does not allow populating the type information - hence we do it here.
> > >
> > > I can change this if you think some other way would be cleaner?
> >
> > It's pretty fugly. Can the REGMAP_IRQ_REG be expanded upon?
>
> I was thinking of that but for vast majority of REGMAP_IRQ_REG users
> initializing type regs would be just unnecessary burden (giving 6
> zeroes for unsupported fields for each IRQ gets dull quite soon) I
No, I don't mean edit REGMAP_IRQ_REG directly. I'm proposing to
create another, separate MACRO based on REGMAP_IRQ_REG.
> was also thinking of adding another macro to be used in cases where
> we have type setting supported - but macros with 9 parameters won't fit
> on a line and (in my opinion) will not bring much improvement over
> plain assignment.
I think a 2 line MACRO is better than the current imp.
> > > > b) why you don't mass assign them
> > > > - seeing as most of the data is identical.
> > >
> > > Maybe I am a bit slow today - but I don't know how the 'mass assignment'
> > > should be done?
> >
> > Something like (completely untested):
> >
> > unsigned int type_reg_offset_inc = 0;
> > for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
> > irqs[i].type.type_reg_offset = type_reg_offset_inc;
> > irqs[i].type.type_rising_val = 0x20;
> > irqs[i].type.type_falling_val= 0x10;
> > irqs[i].type.type_level_high_val = 0x40;
> > irqs[i].type.type_level_low_val = 0x50;
> > irqs[i].type.types_supported =
> > (IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> > type_reg_offset_inc += 2;
> > }
>
> Right. I did this this morning =)
>
> > It's still fugly though.
>
> Agree.
>
> > If we can do this via MACROs, it would be better.
>
> I just dont see how to do a nice macro for this. Truth is that there is
> 6 fields to initialize - and the values can't be guessed so each value
> needs to be given. In best case the macro can somewhat shorten the
> assignment (but no way it'd still fit nicely on one row) - in worst
Don't get hung up on MACROS existing on a single line.
> case it just hides the meaning of values we are passing as arguments.
> With raw assignment we at least have some idea what the 0x40 or 0x20 are
> referring to =)
Well I do agree with your last comment.
Maybe doing the following would help with the ugliness (i.e. the shear
number of chars):
unsigned int type_reg_offset_inc = 0;
for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
*t = irqs[i].type;
t->type_reg_offset = type_reg_offset_inc;
t->type_rising_val = 0x20;
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Hello Lee,
On Fri, Feb 08, 2019 at 10:57:43AM +, Lee Jones wrote:
> >
> > This is needed by both RTC and WDT drivers as RTC driver must stop the
> > WDT when it sets RTC. WDT HW is using RTC counter and might trigger
> > timeout/reset when RTC is set. Options are to dublicate the
> > enable/disable to both drivers or to export a function or share a
> > function pointer. I didn't want dublication or dependency between RTC
> > and WDT drivers. Thus I thought that MFD is best place for this code as
> > both RTC and WDT require it anyways. Perhaps this should be commented
> > here?
>
> I think an exported function with comments would be better.
So do you mean you would prefer exported function over the pointer from
MFD? I guess I can do it but I would still like to keep the code in the
MFD as I would rather not introduce dependency from WDT driver to RTC or
other way around. I can easily think of cases where WDT or RTC drivers
would be unnecessary and user might want to drop one of them out of
configuration. And I wonder if export actually makes any real
improvement as we need to share the mutex between RTC and WDT anyways.
>
> [...]
>
> > > > + irqs[BD70528_INT_GPIO3].type.type_reg_offset = 6;
> > > > + irqs[BD70528_INT_GPIO3].type.type_rising_val = 0x20;
> > > > + irqs[BD70528_INT_GPIO3].type.type_falling_val = 0x10;
> > > > + irqs[BD70528_INT_GPIO3].type.type_level_high_val = 0x40;
> > > > + irqs[BD70528_INT_GPIO3].type.type_level_low_val = 0x50;
> > > > + irqs[BD70528_INT_GPIO3].type.types_supported =
> > > > (IRQ_TYPE_EDGE_BOTH |
> > > > + IRQ_TYPE_LEVEL_HIGH |
> > > > IRQ_TYPE_LEVEL_LOW);
> > >
> > > Could you please explain:
> > >
> > > a) what you're doing here
> >
> > Regmap-irq gained support for type-setting. On bd70528 the type setting
> > makes sense only for GPIO interrupts - so we must not populate type
> > setting information for the rest of the IRQs. The macro REGMAP_IRQ_REG
> > is nice and makes the irq struct initialization cleaner. Thus it is used.
> > It does not allow populating the type information - hence we do it here.
> >
> > I can change this if you think some other way would be cleaner?
>
> It's pretty fugly. Can the REGMAP_IRQ_REG be expanded upon?
I was thinking of that but for vast majority of REGMAP_IRQ_REG users
initializing type regs would be just unnecessary burden (giving 6
zeroes for unsupported fields for each IRQ gets dull quite soon) I
was also thinking of adding another macro to be used in cases where
we have type setting supported - but macros with 9 parameters won't fit
on a line and (in my opinion) will not bring much improvement over
plain assignment.
> > > b) why you don't mass assign them
> > > - seeing as most of the data is identical.
> >
> > Maybe I am a bit slow today - but I don't know how the 'mass assignment'
> > should be done?
>
> Something like (completely untested):
>
> unsigned int type_reg_offset_inc = 0;
> for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
> irqs[i].type.type_reg_offset = type_reg_offset_inc;
> irqs[i].type.type_rising_val = 0x20;
> irqs[i].type.type_falling_val= 0x10;
> irqs[i].type.type_level_high_val = 0x40;
> irqs[i].type.type_level_low_val = 0x50;
> irqs[i].type.types_supported =
> (IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> type_reg_offset_inc += 2;
> }
Right. I did this this morning =)
> It's still fugly though.
Agree.
> If we can do this via MACROs, it would be better.
I just dont see how to do a nice macro for this. Truth is that there is
6 fields to initialize - and the values can't be guessed so each value
needs to be given. In best case the macro can somewhat shorten the
assignment (but no way it'd still fit nicely on one row) - in worst
case it just hides the meaning of values we are passing as arguments.
With raw assignment we at least have some idea what the 0x40 or 0x20 are
referring to =)
> [...]
>
> > > > +subsys_initcall(bd70528_init);
> > >
> > > Does it need to be initialised this early?
> >
> > I think it may be required on some board(s). Is it a problem? I guess I
> > can change this for my purposes but guess it may become a problem later.
>
> If you do this normally, you can use MACROs (see other drivers) and
> remove the boilerplate init code you have here.
Ok. I can change this. We can change it back if we need something
(regulators or GPIO or clk) to be ready at early stage. Currently my
setup does not require this.
> > > > +struct bd70528 {
> > > > + /*
> > > > +* Please keep this as the first member here as some
> > > > +* drivers (clk) supporting more than one chip may only know
> > > > this
> > > > +* generic struct 'struct rohm_regmap_dev' and assume it is
> > > > +* the first chunk of parent device's private data.
> > > > +*/
> > > > + struct
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Mark,
Something for you:
> > > +/* bit [0] - Shutdown register */
> > > +unsigned int bit0_offsets[] = {0};
> > > +/* bit [1] - Power failure register */
> > > +unsigned int bit1_offsets[] = {1};
> > > +/* bit [2] - VR FAULT register */
> > > +unsigned int bit2_offsets[] = {2};
> > > +/* bit [3] - PMU register interrupts */
> > > +unsigned int bit3_offsets[] = {3};
> > > +/* bit [4] - Charger 1 and Charger 2 registers */
> > > +unsigned int bit4_offsets[] = {4, 5};
> > > +/* bit [5] - RTC register */
> > > +unsigned int bit5_offsets[] = {6};
> > > +/* bit [6] - GPIO register */
> > > +unsigned int bit6_offsets[] = {7};
> > > +/* bit [7] - Invalid operation register */
> > > +unsigned int bit7_offsets[] = {8};
> >
> > What on earth is this?
>
> That's the mapping from main IRQ register bits to sub IRQ registers. The
> RFC version 1 had the patch which brough main irq register support. But
> good that you asked as I missed the fact that this commit is now only at
> the regmap tree - and this one depends on that.
>
> > > +static struct regmap_irq_sub_irq_map bd70528_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),
> > > +};
> >
> > This looks totally hairy. What is it mean to look like?
>
> Yes. Sorry. As explained above - this requires commit from regmap tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git/commit/include/linux/regmap.h?h=for-next=66fb181d6f824f7695417e8c19560c5b57dc8c2d
Mark, is this how this should be implemented?
The global arrays are hideous!
> > Shouldn't this be one in the WDT driver?
>
> This is needed by both RTC and WDT drivers as RTC driver must stop the
> WDT when it sets RTC. WDT HW is using RTC counter and might trigger
> timeout/reset when RTC is set. Options are to dublicate the
> enable/disable to both drivers or to export a function or share a
> function pointer. I didn't want dublication or dependency between RTC
> and WDT drivers. Thus I thought that MFD is best place for this code as
> both RTC and WDT require it anyways. Perhaps this should be commented
> here?
I think an exported function with comments would be better.
[...]
> > > + irqs[BD70528_INT_GPIO3].type.type_reg_offset = 6;
> > > + irqs[BD70528_INT_GPIO3].type.type_rising_val = 0x20;
> > > + irqs[BD70528_INT_GPIO3].type.type_falling_val = 0x10;
> > > + irqs[BD70528_INT_GPIO3].type.type_level_high_val = 0x40;
> > > + irqs[BD70528_INT_GPIO3].type.type_level_low_val = 0x50;
> > > + irqs[BD70528_INT_GPIO3].type.types_supported = (IRQ_TYPE_EDGE_BOTH |
> > > + IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> >
> > Could you please explain:
> >
> > a) what you're doing here
>
> Regmap-irq gained support for type-setting. On bd70528 the type setting
> makes sense only for GPIO interrupts - so we must not populate type
> setting information for the rest of the IRQs. The macro REGMAP_IRQ_REG
> is nice and makes the irq struct initialization cleaner. Thus it is used.
> It does not allow populating the type information - hence we do it here.
>
> I can change this if you think some other way would be cleaner?
It's pretty fugly. Can the REGMAP_IRQ_REG be expanded upon?
> > b) why you don't mass assign them
> > - seeing as most of the data is identical.
>
> Maybe I am a bit slow today - but I don't know how the 'mass assignment'
> should be done?
Something like (completely untested):
unsigned int type_reg_offset_inc = 0;
for (i = BD70528_INT_GPIO0; i <= BD70528_INT_GPIO3; i++) {
irqs[i].type.type_reg_offset = type_reg_offset_inc;
irqs[i].type.type_rising_val = 0x20;
irqs[i].type.type_falling_val= 0x10;
irqs[i].type.type_level_high_val = 0x40;
irqs[i].type.type_level_low_val = 0x50;
irqs[i].type.types_supported =
(IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
type_reg_offset_inc += 2;
}
It's still fugly though.
If we can do this via MACROs, it would be better.
[...]
> > > +subsys_initcall(bd70528_init);
> >
> > Does it need to be initialised this early?
>
> I think it may be required on some board(s). Is it a problem? I guess I
> can change this for my purposes but guess it may become a problem later.
If you do this normally, you can use MACROs (see other drivers) and
remove the boilerplate init code you have here.
> > > +struct bd70528 {
> > > + /*
> > > + * Please keep this as the first member here as some
> > > + * drivers (clk) supporting more than one chip may only know this
> > > + * generic struct 'struct rohm_regmap_dev' and assume it is
> > > + * the first chunk of
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Hello Again Lee,
After a good night sleep few things came to my mind =)
On Thu, Feb 07, 2019 at 02:00:53PM +, Lee Jones wrote:
> On Thu, 07 Feb 2019, Matti Vaittinen wrote:
>
> > +
> > +static struct mfd_cell bd70528_mfd_cells[] = {
> > + { .name = "bd70528-pmic", },
> > + { .name = "bd70528-gpio", },
> > + /*
> > +* We use BD71837 driver to drive the clk block. Only differences to
> > +* BD70528 clock gate are the register address and mask.
> > +*/
> > + { .name = "bd718xx-clk", },
> > + { .name = "bd70528-wdt", },
> > + {
> > + .name = "bd70528-power",
> > + .resources = _irqs[0],
> > + .num_resources = ARRAY_SIZE(charger_irqs),
> > + },
> > + {
>
> These should be on the same line.
I know I said 'Ok' yesterday. And I can change the styling to what ever
suits you - but I am not entirely sure what you mean by this? Do you
mean that the brackets should be on same line? After a quick look to
few other MFD devices it seems to be common convention to have these on
separate lines - and such style is used also at other locations
throughout this file.
> > +static const struct regmap_access_table volatile_regs = {
> > + .yes_ranges = _ranges[0],
> > + .n_yes_ranges = ARRAY_SIZE(volatile_ranges),
> > +};
> > +
> > +static struct regmap_config bd70528_regmap = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .volatile_table = _regs,
> > + .max_register = BD70528_MAX_REGISTER,
> > + .cache_type = REGCACHE_RBTREE,
> > +};
>
> '\n' here.
>
> > +/* bit [0] - Shutdown register */
> > +unsigned int bit0_offsets[] = {0};
> > +/* bit [1] - Power failure register */
> > +unsigned int bit1_offsets[] = {1};
> > +/* bit [2] - VR FAULT register */
> > +unsigned int bit2_offsets[] = {2};
> > +/* bit [3] - PMU register interrupts */
> > +unsigned int bit3_offsets[] = {3};
> > +/* bit [4] - Charger 1 and Charger 2 registers */
> > +unsigned int bit4_offsets[] = {4, 5};
> > +/* bit [5] - RTC register */
> > +unsigned int bit5_offsets[] = {6};
> > +/* bit [6] - GPIO register */
> > +unsigned int bit6_offsets[] = {7};
> > +/* bit [7] - Invalid operation register */
> > +unsigned int bit7_offsets[] = {8};
>
> What on earth is this?
Would this comment help:
/*
* 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.
*/
/* bit [0] - Shutdown register */
unsigned int bit0_offsets[] = {0};
/* bit [1] - Power failure register */
unsigned int bit1_offsets[] = {1};
/* bit [2] - VR FAULT register */
unsigned int bit2_offsets[] = {2};
/* bit [3] - PMU register interrupts */
unsigned int bit3_offsets[] = {3};
/* bit [4] - Charger 1 and Charger 2 registers */
unsigned int bit4_offsets[] = {4, 5};
/* bit [5] - RTC register */
unsigned int bit5_offsets[] = {6};
/* bit [6] - GPIO register */
unsigned int bit6_offsets[] = {7};
/* bit [7] - Invalid operation register */
unsigned int bit7_offsets[] = {8};
> > +static int bd70528_wdt_set(struct bd70528 *bd70528, int enable, int
> > *old_state)
> > +{
[..]
> > +}
>
> Shouldn't this be one in the WDT driver?
Maybe I should explain it like this:
/*
* Both the WDT and RTC drivers need to be able to control WDT. WDT uses
* RTC for timeouts and setting the RTC may trigger watchdog. Thus the
* RTC must disable the WDT when RTC time is set. We provide WDT disabling
* code from the MFD parent as we don't want to make direct dependency
* between RTC and WDT. Some may want to use only WDT or only RTC.
*/
#define WD_CTRL_MAGIC1 0x55
#define WD_CTRL_MAGIC2 0xAA
static int bd70528_wdt_set(struct bd70528 *bd70528, int enable, int *old_state)
{
> > + /*
> > +* Disallow type setting for all IRQs by default as
> > +* most of them do not support setting type.
> > +*/
> > + for (i = 0; i < ARRAY_SIZE(irqs); i++)
> > + irqs[i].type.types_supported = 0;
> > +
> > + irqs[BD70528_INT_GPIO0].type.type_reg_offset = 0;
> > + irqs[BD70528_INT_GPIO0].type.type_rising_val = 0x20;
> > + irqs[BD70528_INT_GPIO0].type.type_falling_val = 0x10;
> > + irqs[BD70528_INT_GPIO0].type.type_level_high_val = 0x40;
> > + irqs[BD70528_INT_GPIO0].type.type_level_low_val = 0x50;
> > + irqs[BD70528_INT_GPIO0].type.types_supported = (IRQ_TYPE_EDGE_BOTH |
> > + IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> > + irqs[BD70528_INT_GPIO1].type.type_reg_offset = 2;
> > + irqs[BD70528_INT_GPIO1].type.type_rising_val = 0x20;
> > + irqs[BD70528_INT_GPIO1].type.type_falling_val = 0x10;
> > + irqs[BD70528_INT_GPIO1].type.type_level_high_val = 0x40;
> > + irqs[BD70528_INT_GPIO1].type.type_level_low_val = 0x50;
> > + irqs[BD70528_INT_GPIO1].type.types_supported = (IRQ_TYPE_EDGE_BOTH |
> > + IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW);
> > + irqs[BD70528_INT_GPIO2].type.type_reg_offset = 4;
> > + irqs[BD70528_INT_GPIO2].type.type_rising_val = 0x20;
> >
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Hello Lee,
Thanks for taking a look at this.
On Thu, Feb 07, 2019 at 02:00:53PM +, Lee Jones wrote:
> On Thu, 07 Feb 2019, Matti Vaittinen wrote:
> > +// Copyright (C) 2018 ROHM Semiconductors
>
> This needs updating.
Ok
> > +#define BD70528_INT_RES(_reg, _name) \
> > + { \
> > + .start = (_reg),\
> > + .end = (_reg), \
> > + .name = (_name),\
> > + .flags = IORESOURCE_IRQ,\
> > + }
>
> I think you're looking for DEFINE_RES_IRQ_NAMED()
Thanks! I didn't know of that macro. I'd switch to it.
> > +static struct mfd_cell bd70528_mfd_cells[] = {
> > + { .name = "bd70528-pmic", },
> > + { .name = "bd70528-gpio", },
> > + /*
> > +* We use BD71837 driver to drive the clk block. Only differences to
> > +* BD70528 clock gate are the register address and mask.
> > +*/
> > + { .name = "bd718xx-clk", },
> > + { .name = "bd70528-wdt", },
> > + {
> > + .name = "bd70528-power",
> > + .resources = _irqs[0],
>
> Why not just, 'charger_irqs'?
Old "bad" habit :) I'll change this.
> > + .num_resources = ARRAY_SIZE(charger_irqs),
>
> > + },
> > + {
>
> These should be on the same line.
Ok.
> > + .name = "bd70528-rtc",
> > + .resources = _irqs[0],
>
> As above.
Right. Same bad habit. I'll fix this.
> > + /*
> > +* bd70528 contains also few other registers which require
>
> "BD70528"
Ok, I'll fix all these occurrances.
>
> I don't think this means what you think it does.
>
> I think you want to say "also contains a few".
>
> > +* magic sequence to be written in order to update the value.
>
> "sequences"
And thanks for grammar checks! I am not native english speaker so this
is really helpful. I'll fix these.
> > +static struct regmap_config bd70528_regmap = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .volatile_table = _regs,
> > + .max_register = BD70528_MAX_REGISTER,
> > + .cache_type = REGCACHE_RBTREE,
> > +};
>
> '\n' here.
Ok.
> > +/* bit [0] - Shutdown register */
> > +unsigned int bit0_offsets[] = {0};
> > +/* bit [1] - Power failure register */
> > +unsigned int bit1_offsets[] = {1};
> > +/* bit [2] - VR FAULT register */
> > +unsigned int bit2_offsets[] = {2};
> > +/* bit [3] - PMU register interrupts */
> > +unsigned int bit3_offsets[] = {3};
> > +/* bit [4] - Charger 1 and Charger 2 registers */
> > +unsigned int bit4_offsets[] = {4, 5};
> > +/* bit [5] - RTC register */
> > +unsigned int bit5_offsets[] = {6};
> > +/* bit [6] - GPIO register */
> > +unsigned int bit6_offsets[] = {7};
> > +/* bit [7] - Invalid operation register */
> > +unsigned int bit7_offsets[] = {8};
>
> What on earth is this?
That's the mapping from main IRQ register bits to sub IRQ registers. The
RFC version 1 had the patch which brough main irq register support. But
good that you asked as I missed the fact that this commit is now only at
the regmap tree - and this one depends on that.
> > +static struct regmap_irq_sub_irq_map bd70528_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),
> > +};
>
> This looks totally hairy. What is it mean to look like?
Yes. Sorry. As explained above - this requires commit from regmap tree:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git/commit/include/linux/regmap.h?h=for-next=66fb181d6f824f7695417e8c19560c5b57dc8c2d
> > +static int bd70528_wdt_set(struct bd70528 *bd70528, int enable, int
> > *old_state)
> > +{
[snip]
> > +}
>
> Shouldn't this be one in the WDT driver?
This is needed by both RTC and WDT drivers as RTC driver must stop the
WDT when it sets RTC. WDT HW is using RTC counter and might trigger
timeout/reset when RTC is set. Options are to dublicate the
enable/disable to both drivers or to export a function or share a
function pointer. I didn't want dublication or dependency between RTC
and WDT drivers. Thus I thought that MFD is best place for this code as
both RTC and WDT require it anyways. Perhaps this should be commented
here?
> > + if (!i2c->irq) {
> > + dev_err(>dev, "No IRQ configured\n");
> > + return -EINVAL;
> > + }
>
> '\n' here.
Ok.
> > + bd70528 = devm_kzalloc(>dev, sizeof(*bd70528), GFP_KERNEL);
> > +
>
> Remove this line.
Ok.
> > + if (!bd70528)
> > + return -ENOMEM;
> > +
> > + mutex_init(>rtc_timer_lock);
>
> Shouldn't this in the RTC driver?
As menioned abowe, the WDT is also using the lock. Thus it is
initialized here. Perhaps a comment would help?
> > +
Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
On Thu, 07 Feb 2019, Matti Vaittinen wrote:
> ROHM BD70528MWV is an ultra-low quiescent current general
> purpose single-chip power management IC for battery-powered
> portable devices.
>
> Add MFD core which enables chip access for following subdevices:
> - regulators/LED drivers
> - battery-charger
> - gpios
> - 32.768kHz clk
> - RTC
> - watchdog
>
> Signed-off-by: Matti Vaittinen
> ---
> drivers/mfd/Kconfig | 17 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/rohm-bd70528.c | 410
> +++
> include/linux/mfd/rohm-bd70528.h | 392 +
> 4 files changed, 820 insertions(+)
> create mode 100644 drivers/mfd/rohm-bd70528.c
> create mode 100644 include/linux/mfd/rohm-bd70528.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index f461460a2aeb..f1a0574cebb1 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1847,6 +1847,23 @@ config MFD_ROHM_BD718XX
> NXP i.MX8. It contains 8 BUCK outputs and 7 LDOs, voltage monitoring
> and emergency shut down as well as 32,768KHz clock output.
>
> +config MFD_ROHM_BD70528
> + tristate "ROHM BD70528 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 BD70528 Power
> + Management IC. BD71837 is general purpose single-chip power
> + management IC for battery-powered portable devices. It contains
> + 3 ultra-low current consumption buck converters, 3 LDOs and 2 LED
> + Drivers. Also included are 4 GPIOs, a real-time clock (RTC), a 32kHz
> + crystal oscillator, high-accuracy VREF for use with an external ADC,
> + 10 bits SAR ADC for battery temperature monitor and 1S battery
> + charger.
> +
> 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 12980a4ad460..fc9b1408e39b 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -241,4 +241,5 @@ 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_BD718XX) += rohm-bd718x7.o
> +obj-$(CONFIG_MFD_ROHM_BD70528) += rohm-bd70528.o
>
> diff --git a/drivers/mfd/rohm-bd70528.c b/drivers/mfd/rohm-bd70528.c
> new file mode 100644
> index ..580164addeeb
> --- /dev/null
> +++ b/drivers/mfd/rohm-bd70528.c
> @@ -0,0 +1,410 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +//
> +// Copyright (C) 2018 ROHM Semiconductors
This needs updating.
> +// ROHM BD70528 PMIC driver
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BD70528_INT_RES(_reg, _name) \
> + { \
> + .start = (_reg),\
> + .end = (_reg), \
> + .name = (_name),\
> + .flags = IORESOURCE_IRQ,\
> + }
I think you're looking for DEFINE_RES_IRQ_NAMED()
> +static const struct resource rtc_irqs[] = {
> + BD70528_INT_RES(BD70528_INT_RTC_ALARM, "bd70528-rtc-alm"),
> + BD70528_INT_RES(BD70528_INT_ELPS_TIM, "bd70528-elapsed-timer"),
> +};
> +
> +static const struct resource charger_irqs[] = {
> + BD70528_INT_RES(BD70528_INT_BAT_OV_RES, "bd70528-bat-ov-res"),
> + BD70528_INT_RES(BD70528_INT_BAT_OV_DET, "bd70528-bat-ov-det"),
> + BD70528_INT_RES(BD70528_INT_DBAT_DET, "bd70528-bat-dead"),
> + BD70528_INT_RES(BD70528_INT_BATTSD_COLD_RES, "bd70528-bat-warmed"),
> + BD70528_INT_RES(BD70528_INT_BATTSD_COLD_DET, "bd70528-bat-cold"),
> + BD70528_INT_RES(BD70528_INT_BATTSD_HOT_RES, "bd70528-bat-cooled"),
> + BD70528_INT_RES(BD70528_INT_BATTSD_HOT_DET, "bd70528-bat-hot"),
> + BD70528_INT_RES(BD70528_INT_CHG_TSD, "bd70528-chg-tshd"),
> + BD70528_INT_RES(BD70528_INT_BAT_RMV, "bd70528-bat-removed"),
> + BD70528_INT_RES(BD70528_INT_BAT_DET, "bd70528-bat-detected"),
> + BD70528_INT_RES(BD70528_INT_DCIN2_OV_RES, "bd70528-dcin2-ov-res"),
> + BD70528_INT_RES(BD70528_INT_DCIN2_OV_DET, "bd70528-dcin2-ov-det"),
> + BD70528_INT_RES(BD70528_INT_DCIN2_RMV, "bd70528-dcin2-removed"),
> + BD70528_INT_RES(BD70528_INT_DCIN2_DET, "bd70528-dcin2-detected"),
> + BD70528_INT_RES(BD70528_INT_DCIN1_RMV, "bd70528-dcin1-removed"),
> + BD70528_INT_RES(BD70528_INT_DCIN1_DET, "bd70528-dcin1-detected"),
> +};
> +
> +static struct mfd_cell bd70528_mfd_cells[] = {
> + { .name = "bd70528-pmic", },
> + { .name = "bd70528-gpio", },
> + /*
> + * We use BD71837 driver to drive the clk block. Only differences
