From: tomi.valkeinen@ti•com (Tomi Valkeinen)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
Date: Tue, 29 Apr 2014 19:27:12 +0300 [thread overview]
Message-ID: <535FD2E0.1050806@ti.com> (raw)
In-Reply-To: <20140429155111.GC633@saruman.home>
On 29/04/14 18:51, Felipe Balbi wrote:
> On Thu, Apr 24, 2014 at 11:44:58AM -0700, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti•com> [140424 11:29]:
>>> Hi,
>>>
>>> On Fri, Jan 17, 2014 at 09:44:59AM +0200, Tomi Valkeinen wrote:
>>>> omap2_dpll_round_rate() doesn't actually round the given rate, even if
>>>> the name and the description so hints. Instead it only tries to find an
>>>> exact rate match, or if that fails, return ~0 as an error.
>>>>
>>>> What this basically means is that the user of the clock needs to know
>>>> what rates the dpll can support, which obviously isn't right.
>>>>
>>>> This patch adds a simple method of rounding: during the iteration, the
>>>> code keeps track of the closest rate match. If no exact match is found,
>>>> the closest is returned.
>>>>
>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti•com>
>>>
>>> Tony, looks like this patch was lost. Are you taking it during the -rc ?
>>
>> Would like to hear what Paul thinks of the updated patch suggested
>> by Tomi first.
>
> Paul, any chance you can review Tomi's v2 ? It'd be very nice to get
> display working on BBB.
Btw, I'm fine with my v2 patch, but I think the original one is fine also.
It's true that the original patch changes the dpll behavior when an
exact match is not found. However, I think our drivers always request an
exact match, and in that case the original patch doesn't change the
behavior in practice.
In theory it's possible that a driver requests a non-exact clock from
the dpll, and when it gets an error, it does something else. But, if I'm
not mistaken, all our dplls have a clk-divider after them. And as
clk-divider doesn't handle the error from dpll in any way, and instead
returns bogus rates, I presume all our drivers use exact clocks.
So v2 is perhaps slightly safer option, but I'm not sure if the added
complexity (even if quite small) is worth it.
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/20140429/edfb7ef3/attachment.sig>
next prev parent reply other threads:[~2014-04-29 16:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 7:44 [PATCH 0/2] ARM: OMAP2+: Fix dpll rounding Tomi Valkeinen
2014-01-17 7:44 ` [PATCH 1/2] ARM: OMAP2+: fix rate prints Tomi Valkeinen
2014-02-19 19:25 ` Paul Walmsley
2014-01-17 7:44 ` [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round Tomi Valkeinen
2014-02-13 23:00 ` Tony Lindgren
2014-02-14 13:32 ` Tero Kristo
2014-02-19 19:49 ` Paul Walmsley
2014-02-20 19:30 ` Paul Walmsley
2014-02-26 11:48 ` Tomi Valkeinen
2014-03-05 13:50 ` Tomi Valkeinen
2014-04-30 15:38 ` Felipe Balbi
2014-04-30 15:40 ` Nishanth Menon
2014-02-26 11:42 ` Tomi Valkeinen
2014-04-24 18:34 ` Felipe Balbi
2014-04-24 18:29 ` Felipe Balbi
2014-04-24 18:44 ` Tony Lindgren
2014-04-29 15:51 ` Felipe Balbi
2014-04-29 16:27 ` Tomi Valkeinen [this message]
2014-05-07 22:16 ` Paul Walmsley
2014-05-12 12:11 ` 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=535FD2E0.1050806@ti.com \
--to=tomi.valkeinen@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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