From: Heiko Stuebner <heiko@sntech.de>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: mturquette@baylibre.com, linux-clk@vger.kernel.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 4/7] clk: rockchip: abstract pll get-params and set-params operations
Date: Sun, 08 May 2016 22:24:37 +0200 [thread overview]
Message-ID: <3451726.6PKcY6Rd6y@phil> (raw)
In-Reply-To: <20160506225543.GF3492@codeaurora.org>
Am Freitag, 6. Mai 2016, 15:55:43 schrieb Stephen Boyd:
> On 04/28, Heiko Stuebner wrote:
> > This moves the pll-specific get_params and set_params functions into a
> > per-pll struct that gets associated at init time and will help us reign
> > in some code duplication we're faced with right now.
> >
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> >
> > drivers/clk/rockchip/clk-pll.c | 54
> > ++++++++++++++++++++++++++++++++---------- 1 file changed, 42
> > insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/clk/rockchip/clk-pll.c
> > b/drivers/clk/rockchip/clk-pll.c index e56637d..2c30f52 100644
> > --- a/drivers/clk/rockchip/clk-pll.c
> > +++ b/drivers/clk/rockchip/clk-pll.c
> > @@ -30,6 +30,14 @@
> >
> > #define PLL_MODE_NORM 0x1
> > #define PLL_MODE_DEEP 0x2
> >
> > +struct rockchip_clk_pll;
> > +struct rockchip_pll_data {
> > + void (*get_params)(struct rockchip_clk_pll *pll,
> > + struct rockchip_pll_rate_table *rate);
> > + int (*set_params)(struct rockchip_clk_pll *pll,
> > + const struct rockchip_pll_rate_table *rate);
> > +};
>
> I'm not a huge fan of function pointer indirection on top of
> function pointer indirection (clk_ops). It would be nice if this
> was more flat design and different clk_ops existed for different
> PLL types that all used the same rockchip_clk_pll structure. But
> I don't care too much because I'm not looking at this code all
> the time, so if you like this approach then I'm fine.
I think the "flat design" is what we have right now. The problem is that the
core code is pretty similar and only the hardware-specific accesses are
special, thus the later indirection.
As we don't save to much right now with the currently handled PLLs, I guess
we could simply only do the first 3 patches and revisit the pll-changes later
once the next pll-type shows up.
next prev parent reply other threads:[~2016-05-08 20:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 13:11 [PATCH 0/7] clk: rockchip: cleanup some code duplication Heiko Stuebner
2016-04-28 13:11 ` [PATCH 1/7] clk: rockchip: lookup General Register Files in rockchip_clk_init Heiko Stuebner
2016-04-28 13:11 ` [PATCH 2/7] clk: rockchip: simplify GRF handling in pll clocks Heiko Stuebner
2016-04-28 13:11 ` [PATCH 3/7] clk: rockchip: drop old_rate calculation on pll rate changes Heiko Stuebner
2016-04-28 13:11 ` [PATCH 4/7] clk: rockchip: abstract pll get-params and set-params operations Heiko Stuebner
2016-05-06 22:55 ` Stephen Boyd
2016-05-08 20:24 ` Heiko Stuebner [this message]
2016-05-09 23:03 ` Stephen Boyd
2016-04-28 13:11 ` [PATCH 5/7] clk: rockchip: generalize pll set-rate operation Heiko Stuebner
2016-04-28 13:11 ` [PATCH 6/7] clk: rockchip: move pll rate-comparison into a callable function Heiko Stuebner
2016-04-28 13:11 ` [PATCH 7/7] clk: rockchip: fold pll init functions into a common one Heiko Stuebner
2016-05-06 22:56 ` [PATCH 0/7] clk: rockchip: cleanup some code duplication Stephen Boyd
2016-05-09 14:28 ` Heiko Stuebner
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=3451726.6PKcY6Rd6y@phil \
--to=heiko@sntech.de \
--cc=linux-clk@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.