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
WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner) To: linux-arm-kernel@lists.infradead.org Subject: [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
next prev parent reply other threads:[~2016-06-26 22:19 UTC|newest] Thread overview: 22+ 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 9:48 ` Xing Zheng 2016-06-12 10:46 ` Yakir Yang 2016-06-12 10:46 ` Yakir Yang 2016-06-13 18:37 ` Brian Norris 2016-06-13 18:37 ` Brian Norris 2016-06-13 18:37 ` Brian Norris 2016-06-13 20:43 ` Doug Anderson 2016-06-13 20:43 ` Doug Anderson 2016-06-13 22:46 ` Heiko Stübner 2016-06-13 22:46 ` Heiko Stübner 2016-06-14 16:04 ` Doug Anderson 2016-06-14 16:04 ` Doug Anderson 2016-06-14 16:04 ` Doug Anderson 2016-06-14 16:04 ` Doug Anderson 2016-06-22 0:31 ` Doug Anderson 2016-06-22 0:31 ` Doug Anderson 2016-06-22 0:31 ` Doug Anderson 2016-06-22 0:31 ` Doug Anderson 2016-06-26 22:18 ` Heiko Stuebner [this message] 2016-06-26 22:18 ` Heiko Stuebner 2016-06-26 22:18 ` Heiko Stuebner
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: linkBe 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.