From: Heiko Stuebner <heiko@sntech.de>
To: Doug Anderson <dianders@chromium.org>
Cc: Xing Zheng <zhengxing@rock-chips.com>,
elaine zhang <elaine.zhang@rock-chips.com>,
Tao Huang <huangtao@rock-chips.com>,
Brian Norris <briannorris@chromium.org>,
Yakir Yang <ykk@rock-chips.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@codeaurora.org>,
linux-clk <linux-clk@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
tomasz.figa@chromium.org
Subject: Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399
Date: Mon, 27 Jun 2016 00:18:57 +0200 [thread overview]
Message-ID: <3441187.YrMqoaIQDf@phil> (raw)
In-Reply-To: <CAD=FV=V5UvQGtYQ26gZ+U7+TygEWuqRoHhiH8SiQSK7GcvkF5w@mail.gmail.com>
Am Dienstag, 21. Juni 2016, 17:31:16 schrieb Doug Anderson:
> OK, so what do we do? Personally I can't see us coming up with a
> one-size fits all approach, can you? That means some type of
> configuration. ...and, as seen by the assigned-clocks device tree
> binding, _some_ types of configuration is allowed in the device tree
> presuming it is well thought out and describing how the designers of
> the hardware "intended" it to be used.
>
> So maybe:
>
> i) Unless there's a counter example, I see no reason to let any clocks
> other than the VOP display clocks parent on the "dynamic" PLL. If we
> later find a counter example then presumably we should add a device
> tree property on that board. We could have code at boot time that
> goes through all clocks parented on "dynamic" PLL and reparents them
> (trying to keep the rate?), they disallows future muxing to the
> "dynamic" PLL.
Two problems:
- "disallowing future muxing to the pll" feels a bit far on the "policy"-
side on the policy<->hw-description scale, I still guess the kernel should
be allowed to shoot itself in the foot :-)
- would probably include hacking up the clock parent-names, which won't work
at runtime, as they are init params and get memcpy'd on clk creation.
But I guess this issue of depending clock maybe needing to adapt to a
changed pll-rate here would be solvable with my rate-reassignment I still
need to revisit.
> ii) It seems sane to me to add a device tree property to the board
> that will effectively enable CLK_SET_RATE_PARENT on one of the
> dclk_vop clocks and forcing it to the "dynamic" PLL (no
> auto-remuxing). Maybe we would add something to the HDMI node, for
> instance, like "rockchip,intended-dclk-pll = <&...>". Then somehow
> this would need to affect whichever VOP was assigned to HDMI.
Right now I see two issues:
- can the drm reassign vops at runtime [don't know enough about drm], but
what would happen in such a case when hdmi jumps from one to the other vop.
- clock-flags [CLK_SET_RATE_PARENT and friends] are clk-init data, set when
creating a clock, so there is no changing this at runtime - see above
I guess one option to handle this could be to not have anybody getting a
real CLK_SET_RATE_PARENT to the vpll, but instead having the vops handle
this special pll if necessary. Aka check if the requested rate is possible
using the current sources (clk_round_rate on the dclk_vopX) and if not adapt
the special pll to a suitable source rate and re-check.
And if there is no dclk-vpll, then simply skip that step and try to get the
best rate possible.
> iii) If later someone can propose how to handle D) above, we can
> handle it then. Until a solution is proposed those boards would work
> like today.
Having the "rockchip,dclk-pll = <&...>;" live in the display-subsystem node
or so (=assigned to the global display-subsystem not one special vop) the
available vops might even be able to work out between them who should get
access to it depending on connected displays / modes?
Heiko
prev parent reply other threads:[~2016-06-26 22:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-12 9:48 [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399 Xing Zheng
2016-06-12 10:46 ` Yakir Yang
2016-06-13 18:37 ` Brian Norris
2016-06-13 20:43 ` Doug Anderson
2016-06-13 22:46 ` Heiko Stübner
2016-06-14 16:04 ` Doug Anderson
2016-06-22 0:31 ` Doug Anderson
2016-06-26 22:18 ` Heiko Stuebner [this message]
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=3441187.YrMqoaIQDf@phil \
--to=heiko@sntech.de \
--cc=briannorris@chromium.org \
--cc=dianders@chromium.org \
--cc=elaine.zhang@rock-chips.com \
--cc=huangtao@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
--cc=tomasz.figa@chromium.org \
--cc=ykk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).