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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox