From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
"Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>,
"sboyd@kernel.org" <sboyd@kernel.org>
Cc: "dmurphy@ti.com" <dmurphy@ti.com>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
"mturquette@baylibre.com" <mturquette@baylibre.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"a.zummo@towertech.it" <a.zummo@towertech.it>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block
Date: Tue, 5 Nov 2019 08:11:16 +0000 [thread overview]
Message-ID: <992e5c8ae33ca347312fddfc864757df7502d492.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20191105005541.7913220717@mail.kernel.org>
Hello Stephen,
On Mon, 2019-11-04 at 16:55 -0800, Stephen Boyd wrote:
> Quoting Vaittinen, Matti (2019-10-28 23:28:51)
> > On Mon, 2019-10-28 at 16:32 -0700, Stephen Boyd wrote:
> > > Quoting Matti Vaittinen (2019-10-24 04:44:40)
> > > > diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-
> > > > bd718x7.c
> > > > index ae6e5baee330..d17a19e04592 100644
> > > > --- a/drivers/clk/clk-bd718x7.c
> > > > +++ b/drivers/clk/clk-bd718x7.c
> > > > @@ -8,6 +8,7 @@
> > > > #include <linux/platform_device.h>
> > > > #include <linux/slab.h>
> > > > #include <linux/mfd/rohm-bd718x7.h>
> > > > +#include <linux/mfd/rohm-bd71828.h>
> > > > #include <linux/mfd/rohm-bd70528.h>
> > >
> > > It would be really great to not need to include these random
> > > header
> > > files in this driver and just use raw numbers somehow. Looks like
> > > maybe
> > > it can be done by populating a different device name from the mfd
> > > driver
> > > depending on the version of the clk controller desired? Then that
> > > can
> > > be
> > > matched in this clk driver and we can just put the register info
> > > in
> > > this
> > > file?
> >
> > I still like keeping the chip type information on one header - no
> > matter what-ever format the clk-controller type/version information
> > is.
> > Rationale is that MFD and also few other sub-devices (not only the
> > clk)
> > need to use it. Currently at least the RTC.
> >
> > But if we define clk register information for all PMICs in this c-
> > file,
> > then (I think) we can only include the <linux/mfd/rohm-generic.h> -
> > which contains the PMIC type defines and the generic MFD data
> > structure. That would:
> >
> > -#include <linux/mfd/rohm-bd718x7.h>
> > -#include <linux/mfd/rohm-bd71828.h>
> > -#include <linux/mfd/rohm-bd70528.h>
> > +#include <linux/mfd/rohm-generic.h>
> >
> > That way the chip-type information could still be same for MFD and
> > all
> > sub-devices but clk driver would not need to include all the
> > details
> > for all the PMICs. I understand your point well as clk registers
> > for
> > these PMICs are really *limited*.
> >
>
> It's not even just about clk registers. It's also about how we have
> device compatible strings and device names but this driver isn't
> using
> them to differentiate. Instead, it's looking at the parent device. I
> don't get it. Why can't the MFD populate different clk devices for
> the
> different PMICs and make this driver completely oblivious to the
> parent
> device name/structure and these headers?
Probably because I didn't know how MFD/child device 'matching' works.
Do you mean the clk driver could do something like:
static const struct platform_device_id bd718x7_clk_id[] = {
{ "bd71837-clk", FOO},
{ "bd71847-clk", BAR},
{ "bd70528-clk", BAZ},
{ "bd71828-clk", BAF},
{ },
};
MODULE_DEVICE_TABLE(platform, bd718x7_clk_id);
static struct platform_driver bd71837_clk = {
.driver = {
.name = "bd718xx-clk",
},
.probe = bd71837_clk_probe,
.id_table = bd718x7_clk_id
};
and then in MFD we just use correct name string for the mfd cell
representing the clk? (Eg. one of the bd71837-clk, bd71847-clk,
bd70528-clk, bd71828-clk) and in clk probe just differentiate based on
FOO, BAR, BAZ and BAF?
I guess we could do that (didn't try it out yet so I only guess for
now) - but I think this don't really mitigate the need for common
header. If we change the sub-device match mechanism to this then the
same mechanism should probably be applied to all sub-devices. And that
would be a case where I would like to see the very same FOO, BAR, BAZ
and BAF being used for all sub-devices - meaning it should still be a
MFD header. I think the drivers/clk/clk-s2mps11.c, drivers/mfd/sec-
core.c and include/linux/mfd/samsung/core.h are examples of this.
But I do like this platform_device_id based PMIC differentiation
better. It looks like the "de facto" way of doing this. Still, as I
said, I don't see we're getting rid of common header this way. Anyways,
I think I can cook-up patches to change this if I get buy-in from Lee,
Alexandre and Mark for changing the existing mechanism.
Thanks for teaching me something new once again! :)
Br,
Matti Vaittinen
next prev parent reply other threads:[~2019-11-05 8:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 11:40 [RFC PATCH v2 00/13] Support ROHM BD71828 PMIC Matti Vaittinen
2019-10-24 11:41 ` [RFC PATCH v2 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-10-24 11:41 ` [RFC PATCH v2 02/13] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2019-10-24 19:35 ` Dan Murphy
2019-10-25 5:49 ` Vaittinen, Matti
2019-10-29 12:08 ` Lee Jones
2019-10-29 19:34 ` Rob Herring
2019-10-30 8:26 ` Vaittinen, Matti
2019-10-30 19:22 ` Rob Herring
2019-10-31 12:54 ` Vaittinen, Matti
2019-10-31 17:50 ` Rob Herring
2019-11-01 12:52 ` Vaittinen, Matti
2019-11-04 19:28 ` Rob Herring
2019-10-24 11:42 ` [RFC PATCH v2 03/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
2019-10-24 11:44 ` [RFC PATCH v2 04/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-10-24 11:44 ` [RFC PATCH v2 05/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-10-28 23:32 ` Stephen Boyd
2019-10-29 6:28 ` Vaittinen, Matti
[not found] ` <20191105005541.7913220717@mail.kernel.org>
2019-11-05 8:11 ` Vaittinen, Matti [this message]
2019-10-24 11:45 ` [RFC PATCH v2 06/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-10-24 11:46 ` [RFC PATCH v2 07/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-10-24 11:46 ` [RFC PATCH v2 08/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-10-24 11:47 ` [RFC PATCH v2 09/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
2019-10-24 11:47 ` [RFC PATCH v2 10/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
2019-10-24 11:50 ` [RFC PATCH v2 11/13] rtc: bd70528 add BD71828 support Matti Vaittinen
2019-10-24 11:50 ` [RFC PATCH v2 12/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-10-24 11:59 ` Linus Walleij
2019-10-24 13:34 ` Vaittinen, Matti
2019-10-24 11:52 ` [RFC PATCH v2 13/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC 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=992e5c8ae33ca347312fddfc864757df7502d492.camel@fi.rohmeurope.com \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=lee.jones@linaro.org \
--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-leds@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mazziesaccount@gmail.com \
--cc=mturquette@baylibre.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.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).