From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: "Tanwar, Rahul" <rahul.tanwar@linux.intel.com>
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh+dt@kernel.org,
robhkernel.org@smile.fi.intel.com, mark.rutland@arm.com,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
qi-ming.wu@intel.com, yixin.zhu@linux.intel.com,
cheol.yong.kim@intel.com, rahul.tanwar@intel.com
Subject: Re: [PATCH v1 1/2] clk: intel: Add CGU clock driver for a new SoC
Date: Mon, 2 Sep 2019 15:20:30 +0300 [thread overview]
Message-ID: <20190902122030.GE2680@smile.fi.intel.com> (raw)
In-Reply-To: <e4a1fd0a-b179-92dd-fb81-22d9d7465a33@linux.intel.com>
On Mon, Sep 02, 2019 at 03:43:13PM +0800, Tanwar, Rahul wrote:
> On 28/8/2019 11:09 PM, Andy Shevchenko wrote:
> > On Wed, Aug 28, 2019 at 03:00:17PM +0800, Rahul Tanwar wrote:
> > > drivers/clk/intel/Kconfig | 13 +
> > > drivers/clk/intel/Makefile | 4 +
> > Any plans what to do with existing x86 folder there?
> I checked the x86 folder. This driver's clock controller IP is totally
> different than other clock drivers inside x86. So having a common
> driver source is not a option. It is of course possible to move this
> driver inside x86 folder. Please let me know if you think moving
> this driver inside x86 folder makes more sense.
I'm talking about unambiguous folder where we keep Intel's drivers.
With your series it will be confusing x86 vs intel.
> > > +/*
> > > + * Calculate formula:
> > > + * rate = (prate * mult + (prate * frac) / frac_div) / div
> > > + */
> > > +static unsigned long
> > > +intel_pll_calc_rate(unsigned long prate, unsigned int mult,
> > > + unsigned int div, unsigned int frac, unsigned int frac_div)
> > > +{
> > > + u64 crate, frate, rate64;
> > > +
> > > + rate64 = prate;
> > > + crate = rate64 * mult;
> > > +
> > > + if (frac) {
> > This seems unnecessary.
> > I think you would like to check for frac_div instead?
> > Though I would rather to use frac = 0, frac_div = 1 and drop this conditional
> > completely.
> frac_div value is fixed to BIT(24) i.e. always a non zero value. mult & div
> are directly read from registers and by design the register values for
> mult & div is also always a non zero value. However, frac can logically
> be zero. So, I still find if (frac) condition most suitable here.
Then it's simple not needed.
> > > + frate = rate64 * frac;
> > > + do_div(frate, frac_div);
> > > + crate += frate;
> > > + }
> > > + do_div(crate, div);
> > > +
> > > + return (unsigned long)crate;
> > > + hw = &pll->hw;
> > Seems redundant temporary variable.
>
> Agree, will update in v2.
Though in another method you have similar pattern. So, perhaps you may leave it
for sake of consistency with patterns.
> > > + pr_debug("Add clk: %s, id: %u\n", clk_hw_get_name(hw), id);
> > Is this useful?
> Yes, IMO, this proves very useful for system wide clock issues
> debugging during bootup.
You may use function tracer for that.
> > Does val == 0 follows the table, i.e. makes div == 1?
>
> 0 val means output clock is ref clock i.e. div ==1. Agree that adding
> .val = 0, .div =1 entry will make it more clear & complete.
>
> > > + { .val = 0, .div = 1 },
> > > + { .val = 1, .div = 2 },
> > > + { .val = 2, .div = 3 },
1
> > > + { .val = 3, .div = 4 },
> > > + { .val = 4, .div = 5 },
> > > + { .val = 5, .div = 6 },
1
> > > + { .val = 6, .div = 8 },
> > > + { .val = 7, .div = 10 },
> > > + { .val = 8, .div = 12 },
2
> > > + { .val = 9, .div = 16 },
> > > + { .val = 10, .div = 20 },
> > > + { .val = 11, .div = 24 },
4
> > > + { .val = 12, .div = 32 },
> > > + { .val = 13, .div = 40 },
> > > + { .val = 14, .div = 48 },
8
> > > + { .val = 15, .div = 64 },
16
So, now we see the pattern:
div = val < 3 ? (val + 1) : (1 << ((val - 3) / 3));
So, can we eliminate table?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2019-09-02 12:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 7:00 [PATCH v1 0/2] clk: intel: Add a new driver for a new clock controller IP Rahul Tanwar
2019-08-28 7:00 ` [PATCH v1 1/2] clk: intel: Add CGU clock driver for a new SoC Rahul Tanwar
2019-08-28 15:09 ` Andy Shevchenko
2019-09-02 7:43 ` Tanwar, Rahul
2019-09-02 12:20 ` Andy Shevchenko [this message]
2019-09-02 12:24 ` Andy Shevchenko
2019-12-06 4:39 ` Tanwar, Rahul
2019-12-07 14:57 ` Andy Shevchenko
2019-12-24 3:04 ` Stephen Boyd
2019-09-02 22:20 ` Martin Blumenstingl
2019-09-03 9:54 ` Tanwar, Rahul
2019-09-03 18:53 ` Martin Blumenstingl
2019-09-04 8:03 ` Tanwar, Rahul
2019-09-05 20:47 ` Martin Blumenstingl
2019-09-09 14:16 ` Kim, Cheol Yong
2019-09-16 18:36 ` Stephen Boyd
2019-09-03 23:54 ` Stephen Boyd
2019-08-28 7:00 ` [PATCH v1 2/2] dt-bindings: clk: intel: Add bindings document & header file for CGU Rahul Tanwar
2019-12-19 16:33 ` Rob Herring
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=20190902122030.GE2680@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=cheol.yong.kim@intel.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mturquette@baylibre.com \
--cc=qi-ming.wu@intel.com \
--cc=rahul.tanwar@intel.com \
--cc=rahul.tanwar@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=robhkernel.org@smile.fi.intel.com \
--cc=sboyd@kernel.org \
--cc=yixin.zhu@linux.intel.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;
as well as URLs for NNTP newsgroup(s).