From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Paul Walmsley <paul@pwsan.com>,
linux-omap@vger.kernel.org, mturquette@linaro.org
Cc: linux-arm-kernel@lists.infradead.org, Tero Kristo <t-kristo@ti.com>
Subject: Re: [PATCH] ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest rate
Date: Wed, 17 Sep 2014 16:02:43 +0300 [thread overview]
Message-ID: <54198673.3090002@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407231043230.32419@utopia.booyaka.com>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
Hi,
On 23/07/14 13:44, Paul Walmsley wrote:
>
> Change the behavior of omap2_dpll_round_rate() to round to either the
> exact rate requested, or the next lowest rate that the clock is able to
> provide.
>
> This is not an ideal fix, but is intended to provide a relatively safe
> way for drivers to set PLL rates, until a better solution can be
> implemented.
>
> For the time being, omap3_noncore_dpll_set_rate() is still allowed to
> set its rate to something other than what the caller requested; but will
> warn when this occurs.
>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/clkt_dpll.c | 28 +++++++++++++++++++++-------
> arch/arm/mach-omap2/dpll3xxx.c | 12 ++++++++++--
> 2 files changed, 31 insertions(+), 9 deletions(-)
This patch improved things quite a bit, but we still have problems. I
noticed that on AM43xx:
clk_round_rate(dss_fclk, 199990846) = 199967213
clk_set_rate(dss_fclk, 199967213) -> 199966387
So similar to the issue that 7e50e7e176634e8cc0335778915be75df41043dc fixed.
Above you say that "omap3_noncore_dpll_set_rate() is still allowed to
set its rate to something other than what the caller requested; but will
warn when this occurs.", but I see no warning printed.
I didn't find out where the error comes from, but I (again) noticed the
two issues we have:
- The omap dpll code has no maximum values, so omap2_dpll_round_rate()
goes on to return ~4GHz rates as valid, which I believe it can't do.
- clk-divider.c driver doesn't handle errors from __clk_round_rate(). At
least omap2_dpll_round_rate() returns ~0 on error.
Any ideas where that round/set issue might come from?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest rate
Date: Wed, 17 Sep 2014 16:02:43 +0300 [thread overview]
Message-ID: <54198673.3090002@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407231043230.32419@utopia.booyaka.com>
Hi,
On 23/07/14 13:44, Paul Walmsley wrote:
>
> Change the behavior of omap2_dpll_round_rate() to round to either the
> exact rate requested, or the next lowest rate that the clock is able to
> provide.
>
> This is not an ideal fix, but is intended to provide a relatively safe
> way for drivers to set PLL rates, until a better solution can be
> implemented.
>
> For the time being, omap3_noncore_dpll_set_rate() is still allowed to
> set its rate to something other than what the caller requested; but will
> warn when this occurs.
>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/clkt_dpll.c | 28 +++++++++++++++++++++-------
> arch/arm/mach-omap2/dpll3xxx.c | 12 ++++++++++--
> 2 files changed, 31 insertions(+), 9 deletions(-)
This patch improved things quite a bit, but we still have problems. I
noticed that on AM43xx:
clk_round_rate(dss_fclk, 199990846) = 199967213
clk_set_rate(dss_fclk, 199967213) -> 199966387
So similar to the issue that 7e50e7e176634e8cc0335778915be75df41043dc fixed.
Above you say that "omap3_noncore_dpll_set_rate() is still allowed to
set its rate to something other than what the caller requested; but will
warn when this occurs.", but I see no warning printed.
I didn't find out where the error comes from, but I (again) noticed the
two issues we have:
- The omap dpll code has no maximum values, so omap2_dpll_round_rate()
goes on to return ~4GHz rates as valid, which I believe it can't do.
- clk-divider.c driver doesn't handle errors from __clk_round_rate(). At
least omap2_dpll_round_rate() returns ~0 on error.
Any ideas where that round/set issue might come from?
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140917/c3a21e5a/attachment.sig>
next prev parent reply other threads:[~2014-09-17 13:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 10:44 [PATCH] ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest rate Paul Walmsley
2014-07-23 10:44 ` Paul Walmsley
2014-07-30 12:18 ` Tomi Valkeinen
2014-07-30 12:18 ` Tomi Valkeinen
2014-09-17 13:02 ` Tomi Valkeinen [this message]
2014-09-17 13:02 ` Tomi Valkeinen
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=54198673.3090002@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.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.