Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stuebner <hidden>
Date: 2017-01-11 01:14:08
Also in:
linux-arm-kernel, linux-rockchip, lkml
Am Mittwoch, 11. Januar 2017, 09:04:24 CET schrieb Xing Zheng:
Hi Doug, On 2017年01月11日 02:45, Doug Anderson wrote:quoted
Hi, On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng [off-list ref]
wrote:
quoted
quoted
The structure rockchip_clk_provider needs to refer the GRF regmap in somewhere, if the CRU node has not "rockchip,grf" property, calling syscon_regmap_lookup_by_phandle will return an invalid GRF regmap, and the MUXGRF type clock will be not supported. Therefore, we need to add them. Signed-off-by: Xing Zheng <redacted> --- Changes in v4: - separte the binding patch Changes in v3: - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt Changes in v2: - referring pmugrf for PMUGRU - fix the typo "invaild" in COMMIT message arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++ 1 file changed, 2 insertions(+)This seems fine to me, so: Reviewed-by: Douglas Anderson <redacted> ...but I will say that before you actually add any real "MUXGRF" clocks on rk3399 you _might_ need to rework the code to make things truly "optional". If it turns out that any existing clocks that already exist today already go through one of these muxes in the GRF and we've always been assuming one setting of the mux, we'll need to make sure we keep assuming that setting of the mux even if the "grf" isn't specified. As I understand it, your motivation for this patch is to eventually be able to model the EDP reference clock which can either be xin24 or "edp osc". Presumably the eDP "reference clock" isn't related to any of the pre-existing eDP clocks so that one should be safe.Hmm... I had intended to use this patch for EDP reference clock, but we don't need to change the parent clock (see the BUG: 61664).
Yep that sounds ok. As I said in my replies, we don't support the edp in the mainline kernel yet, so nothing old can break here :-)
I just woud like to add this patch to avoid getting some unavailable MUXGRF clock and need to debug it again, if we support it one day in future.
could you just check, if we have any other grf-based muxes that we may need in the future. Right now I only see pclkin_isp1_wrapper describing such a mux, but it would be cool if you could check again. Thanks Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html