From: Heiko Stuebner <heiko@sntech.de>
To: Doug Anderson <dianders@chromium.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Xing Zheng <zhengxing@rock-chips.com>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
zhangqing <zhangqing@rock-chips.com>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
linux-clk <linux-clk@vger.kernel.org>
Subject: Re: [RFC PATCH 2/3] clk: adjust clocks to their requested rate after parent changes
Date: Sun, 08 May 2016 22:34:41 +0200 [thread overview]
Message-ID: <3005442.vcrD3GKCxP@phil> (raw)
In-Reply-To: <CAD=FV=WegPb3AMsUM+Rx_uZ3sMCGUFz-vEh_8WDTqTp1MHWOUQ@mail.gmail.com>
Am Donnerstag, 5. Mai 2016, 17:49:39 schrieb Doug Anderson:
> Hi,
>
> On Thu, May 5, 2016 at 5:35 PM, Doug Anderson <dianders@chromium.org> wrote:
> > I guess we don't care about errors here?
> >
> > ...maybe (?) we could ignore errors if we validated this rate change
> > with PRE_RATE_CHANGE before attempting to change the parent clock, but
> > I don't see the code doing this unless I missed it.
>
> One other related thought: it seems like there should be code
> _somewhere_ that decides whether to adjust the child dividers before
> or after the parent clock changes. Specifically if the parent clock
> is increasing in speed we probably want to slow down the child clock
> ahead of the parent's increase. I don't see such code here, but again
> I'm pretty good at missing things unless they are slapping me in the
> face. ;)
yep, but that problem of a divider exceeding a requested rate temporarily
exist currently already, even before this change ;-)
Recently we did fix it on a small-scale for composite-clocks though [0].
Heiko
[0] https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/commit/drivers/clk/clk-composite.c?h=clk-next&id=9e52cec04fd3b9b686f9256151b47fe61f7c28ef
next prev parent reply other threads:[~2016-05-08 20:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 16:36 [RFC PATCH 0/3] clk: attempt to keep requested rate on parent changes Heiko Stuebner
2016-05-02 16:36 ` [RFC PATCH 1/3] clk: fix inconsistent use of req_rate Heiko Stuebner
2016-05-02 16:36 ` [RFC PATCH 2/3] clk: adjust clocks to their requested rate after parent changes Heiko Stuebner
2016-05-06 0:35 ` Doug Anderson
2016-05-06 0:49 ` Doug Anderson
2016-05-06 0:49 ` Doug Anderson
2016-05-08 20:34 ` Heiko Stuebner [this message]
2016-05-09 11:40 ` Heiko Stuebner
2016-05-09 15:49 ` Doug Anderson
2016-05-09 15:49 ` Doug Anderson
2016-07-05 7:27 ` Elaine Zhang
2016-07-05 7:27 ` Elaine Zhang
2016-07-05 22:24 ` Heiko Stuebner
2016-07-05 22:24 ` Heiko Stuebner
2016-07-06 1:39 ` Elaine Zhang
2016-07-06 23:01 ` Doug Anderson
2016-07-06 23:01 ` Doug Anderson
2016-07-06 22:41 ` Doug Anderson
2016-05-02 16:36 ` [RFC PATCH 3/3] clk: rockchip: make rk3399 vop dclks keep their rate on parent rate changes Heiko Stuebner
2016-05-05 13:30 ` [RFC PATCH 0/3] clk: attempt to keep requested rate on parent changes Tomeu Vizoso
2016-05-05 15:07 ` Heiko Stübner
2016-05-06 0:46 ` Doug Anderson
2016-05-06 0:46 ` Doug Anderson
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=3005442.vcrD3GKCxP@phil \
--to=heiko@sntech.de \
--cc=dianders@chromium.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
--cc=tomeu.vizoso@collabora.com \
--cc=zhangqing@rock-chips.com \
--cc=zhengxing@rock-chips.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.