From: Lee Jones <lee.jones@linaro.org>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: Matti Vaittinen <mazziesaccount@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
heikki.haikola@fi.rohmeurope.com,
mikko.mutanen@fi.rohmeurope.com, robh+dt@kernel.org,
mark.rutland@arm.com, broonie@kernel.org,
gregkh@linuxfoundation.org, rafael@kernel.org,
mturquette@baylibre.com, sboyd@kernel.org,
linus.walleij@linaro.org, bgolaszewski@baylibre.com,
sre@kernel.org, lgirdwood@gmail.com, a.zummo@towertech.it,
alexandre.belloni@bootlin.com, wim@linux-watchdog.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-pm@vger.kernel.org, linux-rtc@vger.kernel.org,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
Date: Fri, 8 Feb 2019 10:57:43 +0000 [thread overview]
Message-ID: <20190208105743.GI20638@dell> (raw)
In-Reply-To: <20190207162807.GB1920@localhost.localdomain>
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&id=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 parent device's private data.
> > > + */
> > > + struct rohm_regmap_dev chip;
> > > + /* 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"
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2019-02-08 10:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 7:27 [PATCH v8 0/8] support ROHM BD70528 PMIC Matti Vaittinen
2019-02-07 7:34 ` [PATCH v8 1/8] mfd: regulator: clk: split rohm-bd718x7.h Matti Vaittinen
2019-02-07 11:41 ` Lee Jones
2019-02-07 7:35 ` [PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core Matti Vaittinen
2019-02-07 14:00 ` Lee Jones
2019-02-07 16:28 ` Matti Vaittinen
2019-02-08 10:57 ` Lee Jones [this message]
2019-02-08 12:41 ` Matti Vaittinen
2019-02-12 9:17 ` Lee Jones
2019-02-12 9:37 ` Matti Vaittinen
2019-02-08 7:30 ` Matti Vaittinen
2019-02-07 7:36 ` [PATCH v8 3/8] clk: bd718x7: Support ROHM BD70528 clk block Matti Vaittinen
2019-02-07 7:37 ` [PATCH v8 4/8] devicetree: bindings: Document first ROHM BD70528 bindings Matti Vaittinen
2019-02-07 14:04 ` Lee Jones
2019-02-07 15:36 ` Matti Vaittinen
2019-02-07 15:42 ` Guenter Roeck
2019-02-07 16:33 ` Matti Vaittinen
2019-02-07 7:38 ` [PATCH v8 5/8] gpio: Initial support for ROHM bd70528 GPIO block Matti Vaittinen
2019-02-07 7:39 ` [PATCH v8 6/8] rtc: bd70528: Initial support for ROHM bd70528 RTC Matti Vaittinen
2019-02-07 7:40 ` [PATCH v8 7/8] power: supply: Initial support for ROHM BD70528 PMIC charger block Matti Vaittinen
2019-02-07 7:42 ` [PATCH v8 8/8] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block Matti Vaittinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190208105743.GI20638@dell \
--to=lee.jones@linaro.org \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.haikola@fi.rohmeurope.com \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.com \
--cc=mikko.mutanen@fi.rohmeurope.com \
--cc=mturquette@baylibre.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sre@kernel.org \
--cc=wim@linux-watchdog.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).