Am Mittwoch, 11. Januar 2017, 09:04:24 CET schrieb Xing Zheng: > Hi Doug, > > On 2017年01月11日 02:45, Doug Anderson wrote: > > Hi, > > > > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@xxxxxxxxxxxxxx> wrote: > >> 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 <zhengxing@xxxxxxxxxxxxxx> > >> --- > >> > >> 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 <dianders@xxxxxxxxxxxx> > > > > ...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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
