From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: Khiem Nguyen <khiem.nguyen.xt@renesas.com>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"marek.vasut+renesas@gmail.com" <marek.vasut+renesas@gmail.com>,
"lee.jones@linaro.org" <lee.jones@linaro.org>
Subject: RE: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF
Date: Thu, 10 Dec 2020 10:58:21 +0000 [thread overview]
Message-ID: <TY2PR01MB369226B2FCFB1E6C91E2EFD5D8CB0@TY2PR01MB3692.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <2916e43d33fd13c88d983d7e8451a41ec3bf9e31.camel@fi.rohmeurope.com>
Hi Matti,
> From: Vaittinen, Matti, Sent: Thursday, December 10, 2020 5:28 PM
>
> On Tue, 2020-12-08 at 17:04 +0900, Yoshihiro Shimoda wrote:
> > From: Khiem Nguyen <khiem.nguyen.xt@renesas.com>
> >
> > The new PMIC BD9574MWF inherits features from BD9571MWV.
> > Add the support of new PMIC to existing bd9571mwv driver.
> >
> > Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@renesas.com>
> > [shimoda: rebase and refactor]
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > ---
> > drivers/mfd/bd9571mwv.c | 92
> > +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/bd9571mwv.h | 80
> > +++++++++++++++++++++++++++++++++++++
> > 2 files changed, 172 insertions(+)
> >
> > diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
> > index 57bdb6a..f8f0a87 100644
> > --- a/drivers/mfd/bd9571mwv.c
> > +++ b/drivers/mfd/bd9571mwv.c
> > @@ -20,6 +20,7 @@ static const struct mfd_cell bd9571mwv_cells[] = {
> > { .name = "bd9571mwv-gpio", },
> > };
> >
> > +/* Regmap for BD9571MWV */
> > static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
> > regmap_reg_range(BD9571MWV_VENDOR_CODE,
> > BD9571MWV_PRODUCT_REVISION),
> > regmap_reg_range(BD9571MWV_BKUP_MODE_CNT,
> > BD9571MWV_BKUP_MODE_CNT),
> > @@ -112,6 +113,95 @@ static const struct bd957x_data bd9571mwv_data =
> > {
> > .num_cells = ARRAY_SIZE(bd9571mwv_cells),
> > };
> >
> > +static const struct mfd_cell bd9574mwf_cells[] = {
> > + { .name = "bd9571mwv-gpio", },
>
> Another 'nit' suggestion which you can ignore if it does not make sense
> :)
>
> Are the GPIO blocks 100% identical? If not, then I would suggest
> changing this to:
> { .name = "bd9574mwf-gpio", },
The GPIO blocks are not 100% identical. BD9574MWF seems to have
an additional feature which GPIOx pin are used for other mode by
using gpio mux regisiter.
> and populating the platform_driver id_table for sub driver(s) using
> something like:
>
> static const struct platform_device_id bd957x_gpio_id[] = {
> { "bd9571mwv-gpio", ROHM_CHIP_TYPE_BD9571 },
> { "bd9574mwf-gpio", ROHM_CHIP_TYPE_BD9574 },
> { },
> };
>
> Then you can get the IC type using
> platform_get_device_id(pdev)->driver_data.
I got it. So, perhaps, I should add these types into
include/linux/mfd/rohm-generic.h.
> Next, I think the parent data from MFD is only used to get the regmap
> and dev in sub-devices, right? Maybe you could simplify this and get
> rid of the whole MFD parent data structure? I think you can use
>
> pdev->dev.parent to get the parent device and
> dev_get_regmap(pdev->dev.parent, NULL);
>
> to get the regmap?
IIUC, these comments are related to gpio-bd9571mwv.c.
# Also, bd9571mwv-regulator.c?
If so, I didn't try this yet, but perhaps, we can modify such things.
> (After this I wonder if you need the
> struct bd9571mwv at all?)
I'm sorry, but I could not understand this.
> > +};
> > +
> > +/* Regmap for BD9574MWF */
> > +static const struct regmap_range bd9574mwf_readable_yes_ranges[] = {
> > + regmap_reg_range(BD9574MWF_VENDOR_CODE,
> > BD9574MWF_PRODUCT_REVISION),
> > + regmap_reg_range(BD9574MWF_GPIO_IN, BD9574MWF_GPIO_IN),
> > + regmap_reg_range(BD9574MWF_GPIO_INT, BD9574MWF_GPIO_INTMASK),
> > + regmap_reg_range(BD9574MWF_GPIO_MUX, BD9574MWF_GPIO_MUX),
> > + regmap_reg_range(BD9574MWF_INT_INTREQ, BD9574MWF_INT_INTMASK),
> > +};
> > +
> > +static const struct regmap_access_table bd9574mwf_readable_table = {
> > + .yes_ranges = bd9574mwf_readable_yes_ranges,
> > + .n_yes_ranges = ARRAY_SIZE(bd9574mwf_readable_yes_ranges),
> > +};
> > +
> > +static const struct regmap_range bd9574mwf_writable_yes_ranges[] = {
> > + regmap_reg_range(BD9574MWF_GPIO_DIR, BD9574MWF_GPIO_OUT),
> > + regmap_reg_range(BD9574MWF_GPIO_INT_SET,
> > BD9574MWF_GPIO_INTMASK),
> > + regmap_reg_range(BD9574MWF_INT_INTREQ, BD9574MWF_INT_INTMASK),
> > +};
> > +
> > +static const struct regmap_access_table bd9574mwf_writable_table = {
> > + .yes_ranges = bd9574mwf_writable_yes_ranges,
> > + .n_yes_ranges = ARRAY_SIZE(bd9574mwf_writable_yes_ranges),
> > +};
> > +
> > +static const struct regmap_range bd9574mwf_volatile_yes_ranges[] = {
> > + regmap_reg_range(BD9574MWF_GPIO_IN, BD9574MWF_GPIO_IN),
> > + regmap_reg_range(BD9574MWF_GPIO_INT, BD9574MWF_GPIO_INT),
> > + regmap_reg_range(BD9574MWF_INT_INTREQ, BD9574MWF_INT_INTREQ),
> > +};
>
> Are you using the other interrupts/statuses or VDCORE MoniVDAC? Should
> they be volatile too?
At least, since BD9571MWV_DVFS_MONIVDAC is used on bd9571mfv-regulator.c,
I should add it into the volatile.
<snip>
> > /**
> > * struct bd957x_data - internal data for the bd957x driver
> > *
>
> Overall a good looking driver! Thanks a lot!
Thank you very much for your review!
By the way, I realized Linux kernel supports bd9576-regulator.c
and it has "bd957x", but it doesn't seem to be compatible with BD9571.
So, I wonder if I should not use "bd957x" in the bd9571mwv driver to avoid
confusion. But, what do you think?
Best regards,
Yoshihiro Shimoda
next prev parent reply other threads:[~2020-12-10 11:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-08 8:04 [PATCH 0/3] " Yoshihiro Shimoda
2020-12-08 8:04 ` [PATCH 1/3] mfd: bd9571mwv: Use the SPDX license identifier Yoshihiro Shimoda
2020-12-09 10:35 ` Geert Uytterhoeven
2020-12-08 8:04 ` [PATCH 2/3] mfd: bd9571mwv: Make the driver more generic Yoshihiro Shimoda
2020-12-09 13:25 ` Geert Uytterhoeven
2020-12-10 4:09 ` Yoshihiro Shimoda
2020-12-10 8:23 ` Geert Uytterhoeven
2020-12-10 8:29 ` Yoshihiro Shimoda
2020-12-08 8:04 ` [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF Yoshihiro Shimoda
2020-12-09 13:30 ` Geert Uytterhoeven
2020-12-10 4:44 ` Yoshihiro Shimoda
2020-12-10 7:33 ` Vaittinen, Matti
2020-12-10 8:19 ` Geert Uytterhoeven
2020-12-10 8:28 ` Yoshihiro Shimoda
2020-12-10 9:13 ` Vaittinen, Matti
2020-12-10 6:32 ` Vaittinen, Matti
2020-12-10 8:28 ` Vaittinen, Matti
2020-12-10 10:58 ` Yoshihiro Shimoda [this message]
2020-12-10 11:56 ` Vaittinen, Matti
2020-12-11 0:49 ` Yoshihiro Shimoda
2020-12-11 11:35 ` Yoshihiro Shimoda
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=TY2PR01MB369226B2FCFB1E6C91E2EFD5D8CB0@TY2PR01MB3692.jpnprd01.prod.outlook.com \
--to=yoshihiro.shimoda.uh@renesas.com \
--cc=Matti.Vaittinen@fi.rohmeurope.com \
--cc=khiem.nguyen.xt@renesas.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marek.vasut+renesas@gmail.com \
/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
all inboxes | Powered by JetHome®