From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>, Chen-Yu Tsai <wens@csie.org>,
linux-clk@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>,
Andre Przywara <andre.przywara@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Vishnu Patekar <vishnupatekar0510@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Jean-Francois Moine <moinejf@free.fr>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 14/15] clk: sunxi-ng: Add H3 clocks
Date: Sun, 26 Jun 2016 14:34:09 +0200 [thread overview]
Message-ID: <20160626123409.GK4000@lukather> (raw)
In-Reply-To: <146681451703.35033.17009542256505173233@resonance>
[-- Attachment #1: Type: text/plain, Size: 6414 bytes --]
Hi Mike,
On Fri, Jun 24, 2016 at 05:28:37PM -0700, Michael Turquette wrote:
> Hi Maxime,
>
> Nice series! Looks really great to me. :-)
Great :)
> Quoting Maxime Ripard (2016-06-07 13:41:53)
> > +static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux",
> > + "osc24M", 0x000,
> > + 8, 5, /* N */
> > + 4, 2, /* K */
> > + 0, 2, /* M */
> > + 16, 2, /* P */
> > + BIT(31), /* gate */
> > + BIT(28), /* lock */
> > + 0);
>
> I'm more of a fan of expanding the struct with designated initializers
> versus macro use, but that's only personal preference.
Chen-Yu was very much in favour of having everything defined by
macros, I didn't care that much either, so I guess he wins :)
> > +static const char * const ahb2_parents[] = { "ahb1" , "pll-periph0" };
> > +static struct ccu_mux ahb2_clk = {
> > + .mux = {
> > + .shift = 0,
> > + .width = 1,
> > +
> > + .fixed_prediv = {
> > + .index = 1,
> > + .div = 2,
> > + },
> > + },
> > +
> > + .common = {
> > + .reg = 0x05c,
> > + .features = CCU_FEATURE_FIXED_PREDIV,
> > + .hw.init = SUNXI_HW_INIT_PARENTS("ahb2",
> > + ahb2_parents,
>
> Note that it's possible to initialize the parent strings here if you
> prefer:
>
> .hw.init = &(struct clk_init_data){
> .parent_names = (const char *[]){ "ahb1",
> "pll-periph0" };
>
> Similar to the above, no big deal, just an observation.
A significant bunch of our clocks have the same parent list. Passing
the parent array allows to reuse the same arrays for those, so I'd
really like that over having VA_ARGS based macros (and that would put
the list of parents at the end of the declaration, which seems weird).
> > +static struct ccu_common *sun8i_h3_ccu_clks[] = {
> > + [CLK_PLL_CPUX] = &pll_cpux_clk.common,
> > + [CLK_PLL_AUDIO_BASE] = &pll_audio_base_clk.common,
> > + [CLK_PLL_AUDIO] = &pll_audio_clk.common,
>
> OK, it looks like you followed the qcom clk driver approach here, which
> is a nice way to do things. However, as Stephen alluded to in his
> response to the cover letter, the clk_hw_* api's are an even more
> friendly interface for clock providers. For example, check out the gxbb
> clk driver probe:
>
> static int gxbb_clkc_probe(struct platform_device *pdev)
> {
> void __iomem *clk_base;
> int ret, clkid, i;
> struct device *dev = &pdev->dev;
>
> /* Generic clocks and PLLs */
> clk_base = of_iomap(dev->of_node, 0);
> if (!clk_base) {
> pr_err("%s: Unable to map clk base\n", __func__);
> return -ENXIO;
> }
>
> /* Populate base address for PLLs */
> for (i = 0; i < ARRAY_SIZE(gxbb_clk_plls); i++)
> gxbb_clk_plls[i]->base = clk_base;
>
> /* Populate base address for MPLLs */
> for (i = 0; i < ARRAY_SIZE(gxbb_clk_mplls); i++)
> gxbb_clk_mplls[i]->base = clk_base;
>
> ...
>
> /*
> * register all clks
> */
> for (clkid = 0; clkid < NR_CLKS; clkid++) {
> ret = devm_clk_hw_register(dev, gxbb_hw_onecell_data.hws[clkid]);
> if (ret)
> goto iounmap;
> }
Ok, I'll move the fixed factor clocks out of the common list, and
initialize the clk_hw_onedata_cell structure to register it.
> The nice thing about struct ccu_common is that you don't have to walk
> the list of clocks for each separate clock type like the above probe
> function does. I'm still thinking of the best way to solve this
> generically. Maybe add a .base member struct clk_hw? I dunno, and I've
> resisted the urge to add stuff to struct clk_hw in the past... But I
> really want to minimize this .probe as much as possible, and I do not
> want every clock provider driver to be forced to invent something like
> struct ccu_common every time.
We'd need a few more things (in this case) at least: the register
offset and a private field to store our flags.
> Anyways, that is not a blocker for your implementation to be merged,
> but Stephen's question in patch #4 got me thinking about this
> again...
>
> The real nice part is the call to devm_clk_hw_register. That uses the
> new clk_hw_* apis and struct clk_hw_onecell_data, which is initialized
> statically like so:
>
> static struct clk_hw_onecell_data gxbb_hw_onecell_data = {
> .hws = {
> [CLKID_SYS_PLL] = &gxbb_sys_pll.hw,
> [CLKID_CPUCLK] = &gxbb_cpu_clk.hw,
> ...
> },
> .num = NR_CLKS,
> };
>
> Unfortunately I believe it impossible to replace NR_CLKS with some
> ARRAY_SIZE stuff because C. As Stephen mentioned, please use this method
> instead.
That's unfortunate :/
> > diff --git a/include/dt-bindings/clock/sun8i-h3.h b/include/dt-bindings/clock/sun8i-h3.h
> > new file mode 100644
> > index 000000000000..96eced56e7a2
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/sun8i-h3.h
> > @@ -0,0 +1,162 @@
> > +#ifndef _DT_BINDINGS_CLK_SUN8I_H3_H_
> > +#define _DT_BINDINGS_CLK_SUN8I_H3_H_
> > +
> > +#define CLK_PLL_CPUX 0
> > +#define CLK_PLL_AUDIO_BASE 1
> > +#define CLK_PLL_AUDIO 2
> > +#define CLK_PLL_AUDIO_2X 3
> > +#define CLK_PLL_AUDIO_4X 4
>
> Are you sure you want to expose all of these clocks as part of the ABI?
> I exposed the bare minimum clocks for the gxbb driver in the DT shared
> header (we can always add more later) and kept the rest internal to the
> kernel source.
I thought about it, but that would require a third array with
basically the same clocks:
* the ccu_common array to patch to set the lock and base pointers,
* the list of clocks to register
* the clk_hw_onecell_data to deal with the dt binding.
That seems a bit overkill.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-06-26 12:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 20:41 [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 01/15] dt-bindings: sunxi: Add CCU binding documentation Maxime Ripard
2016-06-08 1:37 ` Chen-Yu Tsai
2016-06-07 20:41 ` [PATCH v2 02/15] clk: sunxi-ng: Add common infrastructure Maxime Ripard
2016-06-09 7:39 ` Jean-Francois Moine
2016-06-07 20:41 ` [PATCH v2 03/15] clk: sunxi-ng: Add fractional lib Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 04/15] clk: sunxi-ng: Add fixed factor clock support Maxime Ripard
2016-06-21 1:15 ` Stephen Boyd
2016-06-21 9:24 ` Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 05/15] clk: sunxi-ng: Add gate " Maxime Ripard
2016-06-09 7:39 ` Jean-Francois Moine
2016-06-07 20:41 ` [PATCH v2 06/15] clk: sunxi-ng: Add mux " Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 07/15] clk: sunxi-ng: Add phase " Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 08/15] clk: sunxi-ng: Add divider Maxime Ripard
2016-06-09 7:40 ` Jean-Francois Moine
2016-06-11 8:27 ` Jean-Francois Moine
2016-06-07 20:41 ` [PATCH v2 09/15] clk: sunxi-ng: Add M-P factor clock support Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 10/15] clk: sunxi-ng: Add N-K-factor " Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 11/15] clk: sunxi-ng: Add N-M-factor " Maxime Ripard
2016-06-09 7:41 ` Jean-Francois Moine
2016-06-27 20:29 ` Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 12/15] clk: sunxi-ng: Add N-K-M Factor clock Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 13/15] clk: sunxi-ng: Add N-K-M-P factor clock Maxime Ripard
2016-06-21 1:42 ` Stephen Boyd
2016-06-07 20:41 ` [PATCH v2 14/15] clk: sunxi-ng: Add H3 clocks Maxime Ripard
2016-06-09 7:42 ` Jean-Francois Moine
2016-06-25 0:28 ` Michael Turquette
2016-06-26 12:34 ` Maxime Ripard [this message]
[not found] ` <146707521689.89261.8354851392822550901@resonance>
2016-06-28 8:32 ` Maxime Ripard
2016-06-07 20:41 ` [PATCH v2 15/15] ARM: dt: sun8i: switch the H3 to the new CCU driver Maxime Ripard
2016-06-21 1:48 ` [PATCH v2 00/15] clk: sunxi: introduce "modern" clock support Stephen Boyd
2016-06-26 16:24 ` Maxime Ripard
2016-06-21 9:40 ` Jean-Francois Moine
2016-06-21 14:47 ` Maxime Ripard
2016-06-21 18:29 ` Jean-Francois Moine
2016-06-27 20:46 ` Maxime Ripard
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=20160626123409.GK4000@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=andre.przywara@arm.com \
--cc=boris.brezillon@free-electrons.com \
--cc=devicetree@vger.kernel.org \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=moinejf@free.fr \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=vishnupatekar0510@gmail.com \
--cc=wens@csie.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).