From: Mike Turquette <mturquette@linaro.org>
To: "Mohammed, Afzal" <afzal@ti.com>, Paul Walmsley <paul@pwsan.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>,
Russell King <linux@arm.linux.org.uk>
Subject: Re: RE: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Date: Fri, 25 Jan 2013 14:20:32 -0800 [thread overview]
Message-ID: <20130125222032.10623.47200@quantum> (raw)
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9388C@DBDE01.ent.ti.com>
Quoting Mohammed, Afzal (2013-01-25 04:18:22)
> Hi Paul,
>
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > On Wed, 23 Jan 2013, Afzal Mohammed wrote:
>
> > > Currently round rate function would return proper rate iff requested
> > > rate exactly matches the PLL lockable rate. This causes set_rate to
> > > fail if exact rate could not be set. Instead round rate may return
> > > closest rate possible (less than the requested). And if any user is
> > > badly in need of exact rate, then return value of round rate could
> > > be used to decide whether to invoke set rate or not.
> > >
> > > Modify round rate so that it return closest possible rate.
> >
> > This doesn't look like the right approach to me. For some PLLs, an exact
> > rate is desired.
>
> If exact rate is required, there is a way to achieve it as mentioned
> in the commit message, i.e. by first invoking round rate over reqd. rate
> and if it doesn't match, bail out w/o invoking set_rate.
>
> And it seems requirement of CCF w.r.t to round rate is to return closest
> possible rate.
Is MULT_ROUND_UP doing the right thing for you in the clk_divider code?
What is the clock rate requested of the parent PLL? I just want to make
sure that we're doing the right thing in the basic divider code.
Thanks,
Mike
WARNING: multiple messages have this Message-ID (diff)
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
Date: Fri, 25 Jan 2013 14:20:32 -0800 [thread overview]
Message-ID: <20130125222032.10623.47200@quantum> (raw)
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9388C@DBDE01.ent.ti.com>
Quoting Mohammed, Afzal (2013-01-25 04:18:22)
> Hi Paul,
>
> On Fri, Jan 25, 2013 at 13:48:11, Paul Walmsley wrote:
> > On Wed, 23 Jan 2013, Afzal Mohammed wrote:
>
> > > Currently round rate function would return proper rate iff requested
> > > rate exactly matches the PLL lockable rate. This causes set_rate to
> > > fail if exact rate could not be set. Instead round rate may return
> > > closest rate possible (less than the requested). And if any user is
> > > badly in need of exact rate, then return value of round rate could
> > > be used to decide whether to invoke set rate or not.
> > >
> > > Modify round rate so that it return closest possible rate.
> >
> > This doesn't look like the right approach to me. For some PLLs, an exact
> > rate is desired.
>
> If exact rate is required, there is a way to achieve it as mentioned
> in the commit message, i.e. by first invoking round rate over reqd. rate
> and if it doesn't match, bail out w/o invoking set_rate.
>
> And it seems requirement of CCF w.r.t to round rate is to return closest
> possible rate.
Is MULT_ROUND_UP doing the right thing for you in the clk_divider code?
What is the clock rate requested of the parent PLL? I just want to make
sure that we're doing the right thing in the basic divider code.
Thanks,
Mike
next prev parent reply other threads:[~2013-01-25 22:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 11:41 [PATCH v2 0/4] ARM: AM335x: LCDC platform support Afzal Mohammed
2013-01-23 11:41 ` Afzal Mohammed
2013-01-23 11:41 ` Afzal Mohammed
2013-01-23 11:41 ` [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value Afzal Mohammed
2013-01-23 11:41 ` Afzal Mohammed
2013-01-23 11:41 ` Afzal Mohammed
2013-01-25 8:18 ` Paul Walmsley
2013-01-25 8:18 ` Paul Walmsley
2013-01-25 12:18 ` Mohammed, Afzal
2013-01-25 12:18 ` Mohammed, Afzal
2013-01-25 12:18 ` Mohammed, Afzal
2013-01-25 22:20 ` Mike Turquette [this message]
2013-01-25 22:20 ` Mike Turquette
2013-01-28 9:25 ` Mohammed, Afzal
2013-01-28 9:25 ` Mohammed, Afzal
2013-01-28 9:25 ` Mohammed, Afzal
2013-01-28 7:24 ` Paul Walmsley
2013-01-28 7:24 ` Paul Walmsley
2013-01-29 9:42 ` Mohammed, Afzal
2013-01-29 9:42 ` Mohammed, Afzal
2013-01-29 9:42 ` Mohammed, Afzal
2013-01-23 11:42 ` [PATCH v2 2/4] ARM: OMAP2+: dpll: am335x - avoid freqsel Afzal Mohammed
2013-01-23 11:42 ` Afzal Mohammed
2013-01-23 11:42 ` Afzal Mohammed
2013-01-23 11:42 ` [PATCH v2 3/4] ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper Afzal Mohammed
2013-01-23 11:42 ` Afzal Mohammed
2013-01-23 11:42 ` Afzal Mohammed
2013-01-23 11:42 ` [PATCH v2 4/4] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path Afzal Mohammed
2013-01-23 11:42 ` Afzal Mohammed
2013-01-23 11:42 ` Afzal Mohammed
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=20130125222032.10623.47200@quantum \
--to=mturquette@linaro.org \
--cc=afzal@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paul@pwsan.com \
--cc=tony@atomide.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 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.