All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.