From: Mike Turquette <mturquette@linaro.org>
To: Tero Kristo <t-kristo@ti.com>, Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-omap@vger.kernel.org, Nishanth Menon <nm@ti.com>,
Felipe Balbi <balbi@ti.com>
Subject: Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
Date: Tue, 17 Jun 2014 14:08:39 -0700 [thread overview]
Message-ID: <20140617210839.32686.27704@quantum> (raw)
In-Reply-To: <539FFB03.6070407@ti.com>
Quoting Tero Kristo (2014-06-17 01:23:31)
> On 06/17/2014 11:19 AM, Paul Walmsley wrote:
> > On Tue, 17 Jun 2014, Tero Kristo wrote:
> >
> >> I am fine with this approach, as it seems pretty much all the other mux-clock
> >> users are setting this flag also. The TI clocks have had this way of using mux
> >> clocks from the legacy times... might just be a design flaw.
> >
> > The non-CCF clock framework never automatically switched parents on rate
> > changes, AFAIK.
>
> That might be true yea, so this must have been introduced with CCF.
Correct, which is why the flag exists.
>
> > The only case that approached this was with PLLs. PLLs would
> > automatically be placed into bypass if the PLL rate was set to the bypass
> > rate.
>
> Someone could argue that this is rather strange approach also and would
> be better to use some other API for the purpose.
I have always liked this feature. I had a hack patch on the list a long
time ago for testing bypass mode on the OMAP4 MPU when set to 400MHZ or
something like that (and chained from dpll_core I think...).
The point is to get the rate you ask for when you call clk_set_rate. The
method by which the PLL achieves that rate isn't really important, so
long as you have glitchless clocks (which OMAP's PRCM does).
Regards,
Mike
>
> .Tero
>
next prev parent reply other threads:[~2014-06-17 21:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 8:04 [RFC PATCH] clk: ti: CLK_SET_RATE_NO_REPARENT for ti,mux-clock Tomi Valkeinen
2014-06-17 8:04 ` [RFC PATCH] clk: ti: set " Tomi Valkeinen
2014-06-17 8:11 ` Tero Kristo
2014-06-17 8:19 ` Paul Walmsley
2014-06-17 8:23 ` Tero Kristo
2014-06-17 21:08 ` Mike Turquette [this message]
2014-06-18 6:33 ` Paul Walmsley
2014-06-17 8:15 ` Paul Walmsley
2014-06-17 21:34 ` Mike Turquette
2014-06-18 6:57 ` Paul Walmsley
2014-06-18 7:06 ` Paul Walmsley
2014-06-17 13:23 ` Felipe Balbi
2014-06-19 11:33 ` Tero Kristo
2014-07-01 19:48 ` Felipe Balbi
2014-07-03 7:41 ` Tero Kristo
2014-07-03 22:06 ` Mike Turquette
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=20140617210839.32686.27704@quantum \
--to=mturquette@linaro.org \
--cc=balbi@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.com \
--cc=tomi.valkeinen@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.