All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: balbi@ti.com, Tony Lindgren <tony@atomide.com>
Cc: Tero Kristo <t-kristo@ti.com>,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	Mike Turquette <mturquette@linaro.org>,
	Paul Walmsley <paul@pwsan.com>
Subject: Re: [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>

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

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



[-- 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 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>

  reply	other threads:[~2014-04-29 16:27 UTC|newest]

Thread overview: 40+ 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 ` Tomi Valkeinen
2014-01-17  7:44 ` [PATCH 1/2] ARM: OMAP2+: fix rate prints Tomi Valkeinen
2014-01-17  7:44   ` Tomi Valkeinen
2014-02-19 19:25   ` Paul Walmsley
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-01-17  7:44   ` Tomi Valkeinen
2014-02-13 23:00   ` Tony Lindgren
2014-02-13 23:00     ` Tony Lindgren
2014-02-14 13:32     ` Tero Kristo
2014-02-14 13:32       ` Tero Kristo
2014-02-19 19:49   ` Paul Walmsley
2014-02-19 19:49     ` Paul Walmsley
2014-02-20 19:30     ` Paul Walmsley
2014-02-20 19:30       ` Paul Walmsley
2014-02-26 11:48       ` Tomi Valkeinen
2014-02-26 11:48         ` Tomi Valkeinen
2014-03-05 13:50       ` Tomi Valkeinen
2014-03-05 13:50         ` Tomi Valkeinen
2014-04-30 15:38         ` Felipe Balbi
2014-04-30 15:38           ` Felipe Balbi
2014-04-30 15:40         ` Nishanth Menon
2014-04-30 15:40           ` Nishanth Menon
2014-02-26 11:42     ` Tomi Valkeinen
2014-02-26 11:42       ` Tomi Valkeinen
2014-04-24 18:34       ` Felipe Balbi
2014-04-24 18:34         ` Felipe Balbi
2014-04-24 18:29   ` Felipe Balbi
2014-04-24 18:29     ` Felipe Balbi
2014-04-24 18:44     ` Tony Lindgren
2014-04-24 18:44       ` Tony Lindgren
2014-04-29 15:51       ` Felipe Balbi
2014-04-29 15:51         ` Felipe Balbi
2014-04-29 16:27         ` Tomi Valkeinen [this message]
2014-04-29 16:27           ` Tomi Valkeinen
2014-05-07 22:16           ` Paul Walmsley
2014-05-07 22:16             ` Paul Walmsley
2014-05-12 12:11             ` Tomi Valkeinen
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.com \
    --cc=balbi@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 \
    --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.